深度 | Android 整體設計及背後意義

阿里妹導讀：現實工作中經常可以聽到這樣的說法：框架的升級帶來協議效能的提升、程式設計模式的變革帶來業務的飛躍...... 姑且不論這些表述是否有問題，實際上如果系統地看待事物整體，可能會有不一樣的發現。以LINUX為例，儘管其核心大獲成功，但如果不是遵循POSIX、併成為一個開源、精簡的UNIX實現，很難想象其最終會有何種發展。因此，對事物進行全域性和一定深入的探究有時會有更多啟發。

今天，阿里高階無線開發專家所為將結合自己多年的經驗，為你深入闡述整個 Android 技術域及移動研發生態，期待與大家共同探討。

1. Android設計的現實意義

架構的工程意義在於：定義並解決一類問題，為需求到實現的平穩過渡提供保障。傳統意義的Android架構（圖1）已被人熟知，但不同角色的視角不同，例如認為Runtime和框架是其核心、或者將Android看做是一種特異性JVM平臺、還有從嵌入式出發將其看做是Linux…… 實際上，Android是極少數幾個用設計來解決自身發展問題的系統，其核心在於通過硬體抽象、元件化、介面層三種能力來為發展提供基礎，併為諸多變數預留大量可操作、斡旋的空間。

圖1. Android傳統架構

1.1 發展的前提：硬體抽象

2008年，我國邁入3G時代前夜，基礎設施的變革讓移動領域充滿變數，無論裝置、硬體還是軟體都均未定型。擅長架構和軟體的Google在這一領域要獲得生存和長足發展，需要團結一切可能的、甚至是未知的力量，取得移動運營商、晶片供應商、手機制造商的支援則是生存的第一步。

硬體抽象層（HAL）在一定程度上起到這樣的目的：它為移動領域五花八門、標準不統一的硬體驅動定義標準介面，避免Android過分依賴Linux，讓後續的擴充套件和整機整合更加高效，滿足了手機制造商的重要訴求；同時還起到隔離Linux核心的作用，避免廠商充滿硬體祕密的驅動原始碼受GPL協議影響而開源，保障了晶片等硬體製造商的核心利益。傳統手機OS的定製和整合流程需要修改大量程式碼，負擔不少，從這個角度來看Android HAL其設計是領先的。結合AOSP優良的程式碼分支、模組管理，加上基於GNU automake巨集形成的Android build system，廠商享受到超越以往的便捷。

然而HAL並無固定做法（如圖2所示），Android 8.0之前，最初大量採用HAL舊版方式，表現為framework直接載入*.so並依賴，主要集中在網路、藍芽等模組；舊版方式導致framework與具體驅動介面耦合過緊，後來形成HAL傳統方式，即提供一定規範和介面進行改進，從而減少直接耦合，但每次廠商支援新版Android依舊有大量改動和適配；為更有效地解決這一問題，Android 8.0開啟Treble專案，從此晶片廠商能通過基於Binder的HIDL提供穩定介面，製造商則可不受晶片廠商影響而直接更新Framework，甚至獲得無需重新編譯HAL即可O他的能力。

圖2. Android對硬體驅動的設計

受益於HAL這一設計，Google在全球獲得更廣泛的支撐，尤其是Android 8.0在國內廠商的迅速適配可見一斑。HAL為Android裝置量的持續增長提供了基礎，並促進有實力的廠商向裝置上層及基礎設施兩個領域縱深發展（圖3），體現在掌握核心技術的廠商（如高通、華為、MTK），通過不斷建設系統能力來強化競爭力（支援5G標準、硬體能力、軟硬結合以及系統能力的深度定製等），而具備渠道和資源整合優勢的手機制造商（華為、OPPO、小米、VIVO等），則立足OS持續構建更高效的應用來擴充版圖（UI、推送、商店、輕應用等），這都體現出Android HAL對整個產業的凝聚和影響，間接彌補Android自身的諸多不足。

圖3. 具備核心競爭力的廠商的發展趨勢

1.2 能力的樞紐：元件化

對能力進行如何組織和複用是架構的最大挑戰，借鑑現有能力是發展的捷徑。無論是Mircosoft的COM，還是OMG的CORBA，或是從EJB到Spring、從SOA到Serverless，隨著基礎設施如網路、終端裝置的能力提升，這些技術的發展呈現出從重量到輕量、從對中心(匯流排)的重度依賴到輕量級依賴的趨勢。Android充分結合各領域先進技術，並基於移動端資源受限這一最大特色，形成了自身的技術特色：AIDL衍生自複雜的CORBA IDL，元件由SOA精簡而來，各獨立生老病死的System Service類似一個個微服務，Binder可以看做是對一種弱化匯流排、效能更好、可點對點通訊的DBUS，UI佈局系統則極大程度受到SWING的影響、manifest實際上就是APP與系統通訊所必須的元件介面描述檔案......

上面提到的領域技術的確有利於Android發展，但遠遠不夠。回想之前談到的HAL以及整體架構，我們看到Android實際上就是個大雜燴，使用的是諸多技術的混合。過去除Palm等Web OS外，無論是基於Linux/Unix構建的系統如Meego，還是Symbian、MTK、UCOS、WindowsCE，無論是實時系統還是非實時系統，這些移動端系統都以C/C++為主且小巧精悍，對記憶體使用和要求極為考究，雖然滿足了資源受限裝置的使用訴求但帶來了門檻；虛擬機器類的平臺如KJava、.NET on Windows Phone雖然記憶體使用和能耗方面比較大方，卻勝在研發效率和容錯性，因而受到不少開發者歡迎。

所以選擇混合架構對於缺乏完整移動領域產業鏈支撐的Google既符合其自身技術理念、又勝算最大，於是量身定製的元件化能力便肩負起這一使命，使得各元件得到有機組合、應用之間以及應用和系統的溝通更為明確和有約束，最終幫助整個系統靈活運轉，能力被迅速放大。

觀察Android系統的啟動執行流程（圖4）以及APP對系統能力的使用（圖5），可以發現其各類能力已按照元件化標準和粒度進行組織（能力的註冊發現、介面和通訊的標準化、執行空間的隔離等），讓快速迭代的手機硬體和持續升級的系統能力以最小代價透出，將複用的價值在移動裝置系統上具體化並最大化，從而具備更高的靈活性和相容性；其背後軟體工程的意義在於為軟體需求、設計之間架起一座橋樑，解決了系統結構和研發需求向實現平坦過渡的問題。

圖4. Android系統程式架構概要

圖5. 使用裝置能力的典型呼叫路徑

當然，歷史上其他公司面臨這類挑戰時也有不一樣的想法，例如Windows Phone 8.0選擇了另外一條路，無論是提供媲美JAVA的C#及VB.NET框架、還是基於Sliverlight Dependency Property + XAML的UI系統、甚至是為了支援C++研發出來的C++/CX及一套執行時，都彷彿無時無刻標榜著其系統技術的多樣化與複雜性，算得上是一場技術盛宴。

Meego則是另外一個例子，被期待救Nokia於危難，並由Intel聯袂推出，通過各種開源能力的組合來完成系統的建設，如Linux核心+QEMU模擬器+QT+QML介面，但實際上曇花一現。

1.3 應用的基礎-介面層

系統能力基本就緒，如何迎來更多開發者對Android長遠發展至關重要。選擇JAVA作為上層語言，既需要勇氣又足夠彰顯其野心；為迎合資源受限這一移動領域過去、現在也是未來的最大客觀事實，其設計了基於暫存器架構、可執行檔案更小的Dalvik虛擬機器，並通過淨室工程來高質量實現，同時結合諸多工具對外提供了流暢的JAVA程式設計方式，擺脫類似MTK feature phone只能用KJava寫些小遊戲的侷限，使得Android研發兼具JAVA的便利和不錯的效能。

天有不測風雲，SUN在09年4月被Oracle收購，距離Android 1.0釋出還不到一年。雖然最初選擇Apache Harmony來提供JAVA API十分明智，但卻遭遇到技術上不支援JAVA 7/8、版權上Oracle訴訟紛至沓來等諸多挑戰。為應對這一切，Google從Android N開始，將JAVA的支援變更為OpenJDK。另外，Kotlin因為特性相近、又可被編譯為class或者dx位元組碼，也獲得了Google青睞和收編（圖6）。

圖6. Android介面層的過去和未來

實際上，之所以Android敢這麼做，還是因為有其設計基礎的支撐，根據個人的一點粗鄙瞭解，從Android API的呼叫鏈路（圖7）上能發現端倪：無論底層依賴、實現和流程如何變化，上層的使用形式並不會改變。

圖7. Android內部對呼叫鏈路的3種實現

這意味著幾乎所有系統能力的核心，已在native library被實現殆盡，並結合上層提供良好遮蔽。這為其他語言實現Framework提供了可能，尤其是一門特性與JAVA相近的語言。所以是什麼語言、是不是kotlin都只事先設計規範下的一種合適的選擇。

圖8. 一種未來用kotlin代替java的極端可能

2. 對於我們的象徵意義和實踐

綜上所述，Android從三個方面來解決其發展的關鍵問題：

• 硬體驅動：形成廠商的合作基礎，並反過來對整個產業施加影響。

• 元件化：高效組織各種內部能力，尋求自身的更快發展。

• 介面層：滿足上層對系統和硬體能力的各種使用訴求。

移動網際網路產業巨頭髮展因為起點以及執行理念不同而有所不同，Apple圍繞著其App Store構建其整個體系並精心維護，而且在現代化API程式設計、整機體驗、垂直領域技術如網路/演算法等各縱深領域走在前列；Google則用Android帶路，需要在各個層面維護和團結不同力量來形成自己的發展特色。所以，Android為系統如何發展提供了另外一種答案：除關注系統自身能力的發展，如何維護好系統不斷髮展的基礎和前提、如何更好地暴露和讓外界使用系統能力也至關重要（見圖九）。

圖9. Android設計對解決問題的啟示

回到我們自身，在重使用者、重互動、手機即人的今天，我們的產品有理由也有必要用其內涵延展並放大服務的價值。要做到這一點並非易事。首先，業務迭代越來越快，各種應用層出不窮對中介軟體意味著廣泛的需求；其次，環境在改變，無論是執行硬體和裝置的五花八門、還是對接叢集的複雜多樣，都對阿里原有端側中介軟體帶來巨大沖擊；再次，在基礎技術發展變緩的今天，技術的價值需要被持續放大，我們希望基於自身能力來構建服務和業務的泛連線基礎,並將其作為發展願景。這要求我們基於集團背景以及核心APP發展的主要目標下，來綜合思考這個發展問題（圖10）。

圖10. 對泛連線能力建設的思考

通過Android的啟發，結合環境和現狀，在滿足業務目標的同時我們從三個層面不斷演進網路能力（圖11）。

• 首先，通過覆蓋線上線下、各類場景、形態各異的裝置，不斷打造高效私有、支援通用標準的協議，並提供部分其他端側網路不能或者及其難以提供的特殊能力，來幫助我們構建裝置和服務、使用者與業務的泛連線基礎。

• 其次，自底向上地抽象，將非阻塞的IO複用、使用者態網路棧支援、通道能力擴充套件以及可支援混合叢集的多例項架構進行高效組織，從而保障了資料在不通層面的流轉和管理訴求。

• 最後，基於SDK矩陣和接入能力的建設，我們實現了服務接入到業務、業務透出給使用者的目的，並通過提供豐富的資料帶來更多價值。

  
  

圖11. 泛連線能力的系統性建設

基於以上的不斷沉澱，目前我們已能觸達海量裝置和使用者，成為接入阿里內外各服務和平臺的介面，併為終端和服務分別遮蔽叢集的多元化及裝置的多樣性，實現新零售系統能力與使用者的泛連線（圖12）。

圖12.團隊能力在集團中所處的位置

3. 小結

結合傳統的C/S觀念，服務端獲取的資訊來源於各網路終端，網路+協議遮蔽或規範了外界對服務輸入的多樣性，使得服務端過去關注的是叢集和高併發，但現在無論是上雲還是利用率，背後都是業務、成本規模和邊際效應在驅動，這裡面發展的代際主旨鮮明。但回到客戶端，由於受到環境和互動等多樣性直接影響，即便是動態性的技術也難以代表端側的全部甚至是主流。所以在某種區域性技術比拼武功，成為過去客戶端的一種行業“潮流”。

在區域性技術和單點深入的確有其意義，筆者也曾有過一些班門弄斧，如非輪詢方式獲取手機棧頂Activity、面向阿里特有複雜叢集的SDK多例項設計、Sophix熱修復及雲上產品等。但結合過往經驗及Android設計，可以更系統性地看待這一現象：即除了滿足業務核心訴求（因為投入大量資源，必須、肯定要成，至少小成），更應該關注技術如何更好地服務業務以及如何持續挖掘能力護城河這兩頭的問題。所以要打造和發展好一個系統，除構建系統各中堅能力外，還需維護好系統發展的前提、組織好各系統能力的內聚、滿足好外部對系統的訴求。

以上是個人從Android系統設計到技術支撐系統發展的一點淺薄看法，期待和業界同仁共同探討。

你可能還喜歡

點選下方圖片即可閱讀

為了30分鐘配送，盒馬工程師都有哪些“神操作”？

Serverless 風暴來襲，前端工程師如何應對？

阿里巴巴2019實習生招聘正式啟動！