閱讀原始碼策略之我見

read the ****ing code

誰都知道閱讀原始碼的好處，但是數次嘗試進入原始碼的海洋，而數度又無功折返的慘痛經歷，比如android框架的原始碼，linux核心的原始碼…..等等。就好像當年那幫出海尋找寶藏的水手們，在汪洋大海裡歷盡千辛萬苦卻徒勞無獲。

首先得從使用者的角度去了解這個框架或者庫是用來幹啥的，作為上層的開發者去使用把玩他，了解它存在的意義。

只是單純看別人寫的教程資料是不動腦筋的過程，而且無法得到深刻的理解和貫通。而前期「猜它的原理」則是乙個很重要的過程，但如果你對於猜也一點頭緒沒有，那麼不要急著去看原始碼了，而是應該返回第一步或者再補充一些相關的基礎知識。

另一種方式就是提出一大堆問題，去尋找問題的答案，

反正最後的最後就是絕對不能不去思考就去開始原始碼的征程。

根據猜測搜尋關鍵實現。比如在看roboguice的原始碼，它最終的實現肯定跑不開findviewbyid,這麼一搜，一下子就找到最核心的那一層了。

如果從上層api正向深入的話，比較大的源**框架它的實現層級會非常深，看著看著就被帶暈掉了，但是如果一下子找到了這個最核心最關心的那一層，在原始碼的海洋裡就像豎起了一台燈塔，讓人有了方向感。

如果我們帶著自己錯誤的猜測去看**，也許比沒有猜測還差，通過這種方式快速的驗證自己的猜測是否正確，如果有錯誤，那麼是否應該再考慮考慮。

從暴露的api介面開始深入原始碼閱讀。借助時序圖工具，保證自己的思路清晰。

第3步底層出擊已然建立了乙個燈塔，那麼正面深入就需要尋找到通往這座燈塔的一條路徑，一旦這條路徑變得清晰，那麼原始碼探索的征程才算完成一大半。

最好是帶著一些問題？

最好是帶著一種驗證猜想的好奇心？

這樣就不會在**的海洋中迷失。

把握大框架，以自己看原始碼的初衷為主線，不要因為周邊的細節而偏離，跳躍式閱讀關鍵實現。

每次揚帆出航，只為乙個明確的目的，不要試圖一次將每個角落都搞個明白。

當然當你揚帆的次數多了，漸漸的也就每個角度都熟知了，你就成為這個方面的專家。

乙個父類有好幾個子類，而外面使用的是父類的類名，程式龐大，不能很快知道其到底對應的是哪個子類，那麼在每個子類的方法中設定斷點，看看最後是停在哪個子類方法中便可知。