深刻理解Android寫做背後的故事

原本是發表在《程序員》雜誌的，結果編輯整理成一篇書評，內容和深度都大幅縮水，今天把原文post出來，但願能拋磚引玉。

我正式接觸Android的準確時間應該在2010年9月份。那段時間，老聽到公司有人說Donut，CupCake、Eclair等很是奇怪的詞（直到如今，我也不中意Android的版本命名），心中不由很仰慕：居然還有這麼多我聞所未聞的東西。因此內心就特別好奇。不久，我就加入了Android的開發，第一個接觸的大模塊是Audio。一看代碼，就發現有更多不懂的詞了，什麼Binder、AudioFlinger、sp、wp等等。當時，我記得買了韓超老師的《Android系統原理及開發要點詳解》，使勁看，磕磕碰碰總算是入了門。

隨着工做的深刻，我發現本身對Android的學習和理解進入了一個比較尷尬的局面。仔細分析，發現它和個人工做內容有關。個人工做大部分狀況下是維護已有Android系統，簡單點說就是改bug。再改過大量Bug後，腦子裏邊已經把對Android的理解和Bug關聯到一塊兒去。好比，若考察我對Audio的瞭解，那麼我能很快說出相關的bug以及修改狀況。但可悲的是，我卻不能說出整個Audio的工做原理。這不就是典型的只見樹木不見森林麼？這個結局對我（也相信對全部軟件工程師）來講是不可接受的。有問題就須要改正（反正改了那麼多Bug了），因此我下定決心要儘快把所掌握的知識點打通，搭建一個較爲完整的Android知識框架。抱着這種心態，再來看Audio，就發現它所包含的內容是如此之豐富，涉及到sp/wp、Binder、AudioTrack/AudioRecord、AudioFlinger、AudioPolicyService等衆多模塊（之前改bug的時候，眼睛裏看到的就是bug，徹底沒關注這些東西）。

因而乎，我就開始了Android研究之旅。很顯然，前途是光明的，道路卻必定要曲折。首先碰到的曲折之處就是因爲研究工做只能在工做之餘，下班以後穿插進行，因此思路常常被工做打斷。例如，剛看到某段邏輯，這時候來一個任務須要儘快修改，這時就不得不停止研究。等再回來時，發現腦子裏幾乎沒有任何以前研究的信息了。爲了解決此問題，我採用了一種方法，即你們都知道的中斷處理。怎麼作呢？我把研究過程分得很細，每一小步都記錄本身的想法，思路，並隨時總結。當研究過程被工做打斷後，只要去看打斷前的思路軌跡，就能很快恢復中斷前的現場，以保持思惟的連續性。我用得工具是Wiz雲筆記，全部筆記都同步到雲端。因此，不論在家，公司，甚至任何一個只要能上網的地方，就能隨處把思惟鏈接起來了。圖1是這2年來，我在Wiz上記錄的筆記的截圖：

圖1  個人Wiz筆記

圖1是我在Wiz上積累的筆記的一部分。左邊是研究2.3 Framework的記錄，基本上每一個模塊都有一篇筆記。右邊是其中研究ActivityManagerService的學習筆記。

另外，Android中各個模塊的研究方法也是我一直在琢磨的。對於Native Framework層來講，其主要關注數據流程，例如Audio、Surface系統等，對於這種模塊來講，用Source Insight多跟蹤幾遍代碼就能搞明白。但對於Java Framework來講，其關注點是管理、交互規則。例如ActivityManagerService內部有大段代碼來處理Activity不一樣啓動模式（如SingleTop、SingleInstance等）的狀況。對於這種模塊，我以前也採用Source insight加蠻看的方式，結果整整2周，毫無進展。由於分支太多，堆棧太深，大腦很難處理。

怎麼辦？固然是能親自動手調試相關模塊是最好的了。因此，我花了一天時間從網上找調試System_Process的方法。結果把Google的一個論壇翻了底朝天，才找到一篇帖子，不過它指向的確是Android官方網頁上的一個連接http://source.android.com/source/using-eclipse.html（這裏邊有詳細的調試方法。看來，仍是要先好好研究下官方網頁纔是）。掌握調試方法後，我又犯難了：那時Android 4.0剛出來，是否是調試必定要拿真機呢？（沒想過其實用模擬器調試能夠）。手頭只有一個HTC G7。忍下心，千方百計編譯了一個Android原生系統燒上去[1]（boot.image刷得是CM7，2.3版本的，而system.image用得是我本身編譯的4.0系統）。因爲缺少相關的HAL庫支持，這個系統勉強能跑起來，其實也就是一個模擬器（到4.1時，我就沒再折騰了，直接上模擬器調試）。不過對Java Framework的學習來講，這就足夠了。有了Eclipse這個強大的調試工具，後面的研究工做真的是如虎添翼，進展很是快。儘管如此，整個ActivityManagerService研究下來也花了將近1個月的時間。直到感受在知識結構上沒有欠缺的時候，我纔開始動筆寫。固然，寫書實際上是一個反思過程，它會促使我回頭來看以前的結論是否正確。

深刻理解Android這兩本書出來後，我也在想一個問題，讀者看完這兩本書後該達到怎樣的境界呢？我心中有兩個目標：

q  能從「基於Android並高於Android」的角度來看待和分析Android。對於卷I的讀者來講，他們多是芯片廠商、底層廠商的工程師居多。對於這部分讀者，之後轉向其餘平臺的可能性很是大。因此，必定站在更高的角度來學習Android，而不該該侷限在這個平臺。

q  能初步具備大型複雜代碼的分析能力。對於卷II的讀者來講，他們更多多是Java程序員。Java有不少優秀的開源框架，但大部分程序員不會去研究其中的細節。對他們來講，目前缺少的是大型複雜代碼的分析能力（固然，若是您能完整看完《Linux內核情景分析》一書，則不屬於此範疇）。這個能力其實是內功，須要踏踏實實，潛心鑽下去才能修煉獲得。

這就是深刻理解 Android 書寫背後的故事，這裏也歡迎讀者參與討論。另外，這套書有一個詳細的發展規劃（ http://blog.csdn.net/innost/article/details/7648869 ），也敬請你們積極參與。

[1] 見筆者博客http://blog.csdn.net/innost/article/details/6977167