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

　　1. 內(nèi)核

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

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

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

　　2. 中間層

　　能把這么多不同的開源項(xiàng)目粘一起確實(shí)是個費(fèi)心的工作；不過說到具體的活兒，基本上就是因?yàn)閘icense和手機(jī)環(huán)境的設(shè)置，照著別人代碼抄一遍，掏空一些邏輯，換上一些邏輯。這一塊主要是麻煩事兒很多：從總體上來看，這些麻煩還是被Google較好地控制住了的。

　　但一些組成部分的選擇還是存在不小的疑問：如媒體框架，我不知道Google怎么想的，非去買PacketVideo的。估計是這公司和Qualcomm有傳統(tǒng)友誼？總而言之自己沒信心做也就算了，買也不買個好點(diǎn)的；弄這么個偽面向?qū)ο蟮某舐凝嬋淮笪?，基本上每次新?a href=/yidongkaifa/android/ target=_blank class=infotextkey>Android推出都是讓手機(jī)能正常運(yùn)轉(zhuǎn)的障礙：太難挑bug了，以至于Google自己都懶的調(diào)好。

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

　　3. 運(yùn)行時引擎

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

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

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

　　4. 整體運(yùn)行時環(huán)境

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

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

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

　　5. 縱觀各子系統(tǒng)

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

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

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

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

　　內(nèi)存子系統(tǒng)，傳統(tǒng)部分我沒有太多的疑問，關(guān)鍵在于設(shè)備特定內(nèi)存上【3】。這部分的設(shè)計簡潔、但卻缺乏更多的考慮。比如這些特定內(nèi)存是被鼓勵分門別類的管理；這種設(shè)計導(dǎo)致這種設(shè)備特定內(nèi)存在一些機(jī)器上不夠用，以至于可能無法發(fā)揮芯片最大能力?！?】

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

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

　　聲音子系統(tǒng)呢，我個人沒碰到過什么麻煩，最基本的應(yīng)用本身也比較簡單，就是從中間層走到內(nèi)核去；有硬解碼什么的在高通方案里轉(zhuǎn)內(nèi)核給硬件負(fù)責(zé)了；不過我想這個子系統(tǒng)的內(nèi)行一定不滿意，因?yàn)槭紫扔脩艟陀胁粷M意的：聲音有延遲。

　　我覺得最好的應(yīng)該是傳感器子系統(tǒng)，為什么這么說？因?yàn)槲覐膩頉]感覺到來自這方面的問題 :)。不知道以后傳感器種類進(jìn)一步增加的話會怎么樣，想必Google現(xiàn)在也更有經(jīng)驗(yàn)了吧。

　　總結(jié)

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

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

　　其實(shí)Android本來就不是“從頭”來的項(xiàng)目，我想倒是因?yàn)镚oogle實(shí)際上有一切大公司的弊病還缺乏傳統(tǒng)操作系統(tǒng)開發(fā)公司的優(yōu)勢，所以在Google介入后設(shè)計合理程度和質(zhì)量才這么差。

　　注【1】：顧名思義，這東西是防止手機(jī)進(jìn)入休眠狀態(tài)的一個鎖，即便是官方ROM都曾經(jīng)出現(xiàn)耗電量劇增的現(xiàn)象，大多都是這個鎖的使用導(dǎo)致的問題。

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

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

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

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

it知識庫：Android整體印象，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。