就我本身閱讀安卓源代碼的經驗，本人研究過 settings,launcher,Sysupdate ,framework /services ,recovery的部分源代碼。並且成功改動google留下來的bug.
android
假設就是熟悉代碼，不帶問題的去看。看的會比較累。但是仍然是有方法可以借鑑的，事實上這種方法。也是生活經驗得來的，你們都會的。設計模式
就是從整體到局部。由總而分。eclipse
比方:你想了解recovery的代碼，就應該先了解這個Recovery的運做流程。網上有很是多人總結了，總歸納圖，先有個大概的瞭解。函數
第二步，再尋找更具體的說明資料，把更爲具體的方法也瞭解一下。工具
第三步，去看源代碼，看源代碼的時候，注意，也是先把全部的方法名看一下。並且作下筆記。而後才細緻的一個模塊一個模塊的看源代碼。跳躍着看源代碼，千萬不要從上到下去看。一個 類上萬行代碼，全部看下來。頭都大了。並且混亂。oop
假設帶着問題去看源代碼。那效率會更高，你們都知道怎麼去找源代碼，找相關的方法來看。post
推薦工具：SouceInsight ,eclipse, UE,NOTEPAD++google
關鍵：一次就看一個點，別貪多。要有必定的基礎，別像我這樣，遇到一個函數又去百度，一個模塊看了2個月才熟悉，才幹改動。spa
下面是網友推薦的好方法：設計
1-----------------------------------------------------------------------------
每個人看源代碼有他本身的方式！
假設爲了讀源代碼而去讀源代碼那麼我認爲你會很痛苦。 因爲可能你是沒有目的的去讀！ 一個類少則幾百。多的幾千行， 看下去要死人的！
在你遇到某些問題需要跟源代碼去解決的時候。源代碼裏面去翻你需要的那部分。這樣讀起來會比較輕鬆點， 每次遇到問題找一部分， 而且同5L說的，每次鑽一個問題就鑽深一點！ 固然找到需要的源代碼是要對源代碼的結構很是瞭解的！
2-----------------------------------------------------------------------------
先要搞清楚這個類是幹什麼用的，
而後搞清楚類裏面的方法是幹什麼用的。
提出問題。比方說這種方法是怎樣實現、這個類的某個功能是怎樣實現的、構造方法爲何要這樣寫之類的。
而後帶着問題去尋找答案。
找到答案後再提出新的問題~
我看代碼的方式就是這種
3-----------------------------------------------------------------------------
方法：
1.先了解業務；
2.熟悉需求文檔和文檔。如無文檔則先熟悉系統的功能和業務流程；
3.掌握開發的技術；
4.看代碼的同一時候執行系統的相關功能。
4-----------------------------------------------------------------------------
要想高速並高效地閱讀源代碼，必定要有好方法，否則看着會挺費勁，固然。用什麼方法取決於詳細的狀況。我就把本身總結的方法給你們show一下，互相交流交流：
一、一邊閱讀代碼一邊寫凝視。這是我用過的最好的方法，對代碼理解得更深刻。看一些重要代碼或者特別難懂的代碼時挺實用。更況且，凝視也是一種文檔嘛。
二、一邊閱讀代碼一邊繪製UML。這種方法適用於類之間的關係較複雜和調用層次較深的狀況，我通常都是先繪製順序圖，而後爲順序圖中的類繪製關係圖。
三、經過Debug來跟蹤程序的主要運行過程，這樣就可以分清主次了。閱讀的時候更有針對性。
四、類的高速閱讀。先弄清楚它在繼承鏈中的位置。看看它的內部狀態。也就是成員變量。通常來講，類的對外接口都是對成員變量的訪問、加工、代理等。而後看看它的對外接口。也就是公有成員函數。識別核心的一個或多個函數，這時候你應該可以大概瞭解這個類的職責或做用了。
可能這個類是某個設計模式中的一個組成部分，因此。設計模式的掌握對代碼的高速閱讀也是很是有幫助的。
五、帶着問題去閱讀。
比方想了解android中的消息機制。那麼看看Looper、Handler、MessegeQueue這幾個類就可以了，其它的不要去看。要否則就跑題了。
如下列幾個閱讀源代碼時所處的情景，在特定場景下用哪些方法：
不太熟悉業務邏輯。還不是很是清楚它是幹啥的，可以用三、5。
代碼量很是大。有幾十萬行，甚至百萬行，可以用二、三、5。
你沒法看見程序的執行過程。比方沒實用戶界面，也有多是沒法執行的，可以用三、5。
設計複雜。用了大量的設計模式，調用鏈很是深，可以用一、二、三、四、5。
時間有限，沒有那麼多時間讓你看源代碼。可以用三、5。