很多人覺得Google能做出Android本身就是一個很了不起的工作過程，真的是這樣嗎？正好在Android上花過半年時間業余研究，從上到下還算是比較熟了，就說說我的印象吧：

　　1. 內核

　　以開發用機G1和Sapphire做例子，內核部分Qualcomm的那部分初始工作最重要（但也稱不上大項目），Google的幾個mechanism實際上工作量很輕、和類似目的的成熟組件比實際上都是超級簡化版，設計的也有不少有欠考慮的地方。

　　lower memory killer多么簡陋就不說了，另一個差勁的設計就是缺乏管理的WakeLock【1】，遍布若干層的這玩意加上我個人最恨的那些沒事醒著等待中斷的內核代碼，無論哪個地方一個小bug，就可能讓你的手機待機超不過仨小時。【2】

　　不是說不能往內核里加東西，也不是說一出手就必須驚天動地，關鍵是不能一拍腦門子想出個方案就上。Android對于內核的改動，很多類似地方的設計都缺乏整體思路，與其說是一組設計，不如干脆說是一堆hack來的確切；所幸Google在這這里干的活不多。

　　2. 中間層

　　能把這么多不同的開源項目粘一起確實是個費心的工作；不過說到具體的活兒，基本上就是因為license和手機環境的設置，照著別人代碼抄一遍，掏空一些邏輯，換上一些邏輯。這一塊主要是麻煩事兒很多：從總體上來看，這些麻煩還是被Google較好地控制住了的。

　　但一些組成部分的選擇還是存在不小的疑問：如媒體框架，我不知道Google怎么想的，非去買PacketVideo的。估計是這公司和Qualcomm有傳統友誼？總而言之自己沒信心做也就算了，買也不買個好點的；弄這么個偽面向對象的丑陋的龐然大物，基本上每次新版Android推出都是讓手機能正常運轉的障礙：太難挑bug了，以至于Google自己都懶的調好。

　　我個人的認識是，Google在這個層面的工作雖然已然不錯，但缺乏真正的精耕細作。在工程上這或許是合理的，發布之后可以回過頭慢慢揉合。但這種發展方式必然要求你有很好的上層抽象，不影響上層建筑。于是問題就變成：Google做到了嗎？

　　3. 運行時引擎

　　說白了就是Dalvik這部分了。這個虛擬機基本上是2000年以后最糟糕的一個虛擬機，而且做這個放到21世紀也沒什么技術含量了。說實在的如果說重量級程序員最多需要兩、三個足夠了，打雜的也不需要幾個；很多時候咱們平時不會自己從事這個方面的開發，不是說這個工作就一定是什么難以逾越的大山。

　　這個部分說白了又是一個照例子抄的活兒，卻做的無比的落后，快趕上Python那個解釋器的水平了。不過我相信HTC之類的廠商一定也有他們自己的想法：我發現HTC在這個部分加入了自己的一些內存管理邏輯，想必是Google又讓他們的在某些情況下郁悶了吧呵呵。

　　我的一個問題是，為什么不更改V8去適應強類型呢？應該不是技術上的問題，而是公司內部統籌安排導致的工作成果和人員不能重用吧。在Android剛推出的時候，我就看到過一個多媒體應用的開發者抱怨，說Android處理XX的速度比Nokia的J2ME還慢，不得不寫Native代碼，想想看，Nokia用的可是更垃圾的CPU!

　　4. 整體運行時環境

　　說起來第一就是Java類庫了，這部分也基本上是照抄加簡化，否則也不至于讓Oracle抓著把柄。實現Java類庫這方面，我的感覺，就是你要把這部分工作放中國來，5000～7000的程序員雇上個20來個，很可能3～5個月就能做出Android 1.5的質量了。這部分Google的實現存在一些問題以前提到過，不過都是些容易改善的。

　　多出來的是界面層、進程內外通訊、功能的配合和不同應用互操作這部分，以及整體上有一組適用于移動嵌入式環境的策略及對應的設計實現。其實這多出來的部分才是Android的核心，上面三個部分雖然更“底層”，卻是服務于這一層次的目的的。（設計一旦確定，以Android的方案來說，其難度和工作量都不大）

　　很遺憾的是如果仔細斟酌，卻會發現Google方案在一到具體應用上漏洞百出。其中一部分牢騷在我上篇文章里提到過了。其他的話題比較大了，很難一句話說明白。不過如果站在開發者角度，并僅僅在Java層進行開發的話，中肯的說除了Java本身帶來的缺點和一些細節，基本上還是和ASP.NET 1.1這類東西在一個水平線上。

　　5. 縱觀各子系統

　　周邊輸出子系統雖然相對不重要但很說明問題，比如notification要決定LED燈一類的表現，開始的設計就過于具體的服務于G1/Sapphire，導致廠商有了其它設計的話，全都按自己的方式四處瞎寫代碼，完全破壞了原有的安排。但人家廠商也是有苦難言：你壓根就沒給人家一個合適地架構和接口。

　　輸入子系統也有類似的問題，雖然現象不同但它設計的也固若金湯鐵桶一般。你如果想從Java層以下，內核層以上自定義一些行為，又不能夠或者不想硬改代碼（改了Android升級了你還得同步），除了掛鉤子，唯一一條出路就是對內核動手了。天殺的，我寧可Google設計的時候能多考慮些我痛罵過得方法論了..

　　網絡子系統的話，已經有的TCP/IP棧肯定是沒問題了，VPN之類的弄點開源代碼改吧改吧實現的也沒問題了，可是啟用WIFI分配地址神馬的時候，居然淪落到用腳本鉤下環境變量用作通知，讓人懷疑設計神馬的都是浮云... 我寨威武！藍牙子系統也拿的是套開源方案，按內行（就不說是誰了嘿嘿）的話，恨不得自己上手重新實現一下。

　　圖形子系統正常使用不會碰到什么麻煩，看了看相關部分的代碼，最主要的問題是來自接口過于簡陋，對各種情況估計不足，出現bug的時候廠商就只能見招拆招了。比如圖像緩沖和攝像頭傳回數據之間的大小不和，其結果可能是相當詭異而不是有個明確的接口甚至約定來處理這種情況（記住攝像子系統的接口也是被Android設定和限制的）。

　　內存子系統，傳統部分我沒有太多的疑問，關鍵在于設備特定內存上【3】。這部分的設計簡潔、但卻缺乏更多的考慮。比如這些特定內存是被鼓勵分門別類的管理；這種設計導致這種設備特定內存在一些機器上不夠用，以至于可能無法發揮芯片最大能力。【4】

　　多媒體子系統整體還是比較清晰和簡單的，而且似乎也沒簡單到了不夠用的地步（我對什么是好的多媒體子系統毫無經驗）。不過默認下掛的OpenCore多媒體框架，前面已經提到過了，深惡痛絕。不知道Google自己的那個框架現在成熟了沒有，什么時候換上，還有....會不會更糟糕，T_T

　　Camera子系統第一個版本接口及定義就很差勁，說它將將夠用都是夸它了，第二版也沒好到哪兒去，跟內存子系統、圖形子系統和多媒體子系統真可以說是分庭抗禮對著干。一些配合設計的也是莫名其妙，比如一些數據不是由上層邏輯完全控制的，而是由底層某個接口暴露出去然后直接在臺面底下轉帳給別的子系統。這不，第三版又來了。

　　聲音子系統呢，我個人沒碰到過什么麻煩，最基本的應用本身也比較簡單，就是從中間層走到內核去；有硬解碼什么的在高通方案里轉內核給硬件負責了；不過我想這個子系統的內行一定不滿意，因為首先用戶就有不滿意的：聲音有延遲。

　　我覺得最好的應該是傳感器子系統，為什么這么說？因為我從來沒感覺到來自這方面的問題 :)。不知道以后傳感器種類進一步增加的話會怎么樣，想必Google現在也更有經驗了吧。

　　總結

　　把所有方面總結一下的話，基本上稍微有有復雜性的部分Google都是繞著走的，湊在一起以后也不好好適配，很多地方缺乏一致性。然后無論是買還是拿來或者自己決定的事情，拍板經常拍的缺乏仔細考慮。大不了永遠的beta慢慢改唄..真是服了。

　　當然，整個系統有幾個子系統的接口無論好壞畢竟需要用腦子設計，還有整合、除錯、周邊工具的工作量，如果想達到能推出、廣泛使用的地步，光一個十來人的小組肯定不夠的。但作為這樣一個眾口稱贊的大型企業，動用那么多人力物力，弄出這樣一個“操作系統”，真有點對不起Google一貫給自己渲染的光輝形象了。

　　其實Android本來就不是“從頭”來的項目，我想倒是因為Google實際上有一切大公司的弊病還缺乏傳統操作系統開發公司的優勢，所以在Google介入后設計合理程度和質量才這么差。

　　注【1】：顧名思義，這東西是防止手機進入休眠狀態的一個鎖，即便是官方ROM都曾經出現耗電量劇增的現象，大多都是這個鎖的使用導致的問題。

　　注【2】：事實上整個電源管理這塊，在Android剛推出時就被這方面資深的第三方開發人員痛罵不是沒有道理的。

　　注【3】：雖然原因不同，但為這個內存設備驅動，Linux的一個核心人員幾次拒絕了Android提交的代碼，屬于Android最終被Linux掃地出門的導火線之一吧。（在這個問題上我并不完全支持內核小組）

　　注【4】：想想看本來能用的內存在Android下卻只能閑置，就能理解這個問題了。比如在MSM7200a方案上，分配給Camera和DSP的空間在大多時候被浪費，而mdp操作卻只能使用非常有限的物理內存；反過來DSP也不能使用本來設計使用的空間，于是VGA視頻壓縮就徹底被取消了。

　　P.S. 沒想到能寫出這么多，其實最近時間有限，好久沒有碰Android了。寫下的基本上都是我印象比較深的，肯定還有其他問題沒有提到。不過Android的意義，不僅僅是因為它本身是開放的，更多的它讓手機開始開放。雖然這和BootLoader加密加得不夠好也有莫大關系，但無論如何這也是一件好事。