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

　　1. 內(nèi)核

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

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

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

　　2. 中間層

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　聲音子系統(tǒng)呢，我個(gè)人沒碰到過什么麻煩，最基本的應(yīng)用本身也比較簡單，就是從中間層走到內(nèi)核去；有硬解碼什么的在高通方案里轉(zhuǎn)內(nèi)核給硬件負(fù)責(zé)了；不過我想這個(gè)子系統(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)然，整個(gè)系統(tǒng)有幾個(gè)子系統(tǒng)的接口無論好壞畢竟需要用腦子設(shè)計(jì)，還有整合、除錯(cuò)、周邊工具的工作量，如果想達(dá)到能推出、廣泛使用的地步，光一個(gè)十來人的小組肯定不夠的。但作為這樣一個(gè)眾口稱贊的大型企業(yè)，動用那么多人力物力，弄出這樣一個(gè)“操作系統(tǒng)”，真有點(diǎn)對不起Google一貫給自己渲染的光輝形象了。

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

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

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

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

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

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

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

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