深入理解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