是什么決定了物種的生存方式和形態？

環境

從08年HTC T-Mobile G1開始，我國算是掀開了Android智能機的時代，13年12月4日我國正式向三大運營商發放4G牌照。
4G時代的到來，給移動端帶來了蓬勃發展。

---

第一階段：業務探索階段。

這個階段的產品邏輯

一般有幾個特點，產品邏輯，展示，交互簡介，業務復雜度低，以商品的搜索、展示、購買等核心流程為主。

發布模式

以 需求收集、評審->測試用例生成、評審->開發設計、編碼、評審->測試->發布->運營，單團隊單線發布 為主。

• 這個階段最主要的問題是 如何提高開發者的編碼質量。

策略

資深人力資源對核心技術進行封裝、高內聚、低耦合；
以最精簡的API對外，降低使用復雜度，讓開發人員專心于業務邏輯的開發。

最基本的軟件設計理念：分層+解耦。

分層：數據流轉處理采用責任鏈模式，保證各個環節的邏輯清晰明了
解耦：隔層之間添加標準的API代理，確保被依賴層可以正常的維護、升級。

---

第二階段：業務拓展期。

這個階段的產品邏輯

一般有幾個特點，除了核心的商品搜索、展示、交易、評價，增加 社交、導購、物流 等 產品線，以滿足用戶使用過程的各種需求。

那么這個階段

單線發布已經無法滿足產品線的快速迭代，敏捷開發應運而生，多團隊多線發布；

app的技術方面

插件化、熱更新、APK加固，當然也包括DNS劫持，HTTP請求加速等訴求。這個階段的App最艱辛。用戶量暴增、機型多樣化、網絡環境更復雜、產品運營需求更多。就會有很多的什么 功能合并，接口升級等一系列需求。

體現在代碼上

就是 代碼復用，代碼冗余，測試難度復雜，工程體量變大，測試面變大（在電商方面的體現，舉個例子 商品變動居然 需要 用戶相關場景通測一遍，這就是典型的耦合過大），還有各種閃退。

我們就需要

• App監控(比如說bugly之類，不過現在來看，這些三方監控手段也有很大的局限性)
• 完善的用戶反饋機制，讓用戶可以便捷的反饋，讓開發者可以第一時間收到反饋并解決問題
• MAA 做http加速，dns防劫持
• H5做混合
• 熱更新，做動態修復等。

策略

在架構設計上，就必須要增加路由、消息機制，來實現業務模塊間的解耦。
模塊化、插件化，物理隔離不同性質的業務代碼，一方面滿足產品快速迭代的需求，另一方面減少蝴蝶效應，同時，責任明確，促進高效開發
對通用UI，抽離形成 高獨立的控件，形成一套UI服務；對數據獲取、處理、存儲 也抽離出可方便拓展的單獨庫，這些數據相關內容也形成 服務。
還需要增加代理層，將adk層的數據進一步隔離，為日后的基礎框架替換做準備。

---

第三階段：業務爆發期。

這個階段產品邏輯上

會增加 現在流行的人工智能、AR/VR、直播，商品銷售定位更加精細。很多的商品的定向推送就是基于這些做法。

這個時候，app的體量會變大

更多的會關注 數據安全、網絡速度、消息推送、前端頁面更強體驗；
甚至 產品獨立(公司可能會 將部分產品功能 做大做強，形成獨立App)，組織結構會不斷拓展邊界。

對技術上來說，

• 徹底落實模塊化、插件化，所有產品線開辟獨立工程，業務代碼完全物理隔離，說白了就是用aar+plugin(apk)的方式對外提供，要不要上插件化，需要是研發團隊體量決定的，一般來說，一個App 10人的開發團隊是不需要上插件化，但是模塊化，路由一定要做好，業務耦合必須解決掉。
• UI控件、數據服務精細化，業務研發，對這些服務的使用，必須達到自由取舍的程度。
• 基礎的adk標準化，這就需要收集公司 所有app的技術需求，集中優秀人力資源打造超高性能adk，生成開發文檔并推廣，促進各產業app高效研發。

---

Android架構演變

基礎組件化

從上往下依次是：
應用App層：統籌全部組件，并輸出App
組件層：包含一些簡單的業務
Base：基礎庫及對基礎庫的封裝

模塊化

從上往下依次是：
App應用層：加載初始化操作，并輸出App
Module模塊層：每個模塊相當于一個業務，通過module來分隔每個業務的邏輯，一個模塊由多個不同的頁面a
Base基礎層：對組件庫的整合，提供給Module層使用
組件層：對Lib庫的一些封裝，整合Image、Network等基礎功能
Lib庫層：基礎Lib庫，會引入RxJava、RxBus、Retrofit供組件層二次封裝，或者一些Util工具類等；這里可以 并入組件層（筆者是這么干的）

多模板化

這是在模板化的基礎上，增加了 模板層，用于多個分發業務的組裝。甚至多種客戶、多種渠道

插件化

從上往下依次是：
應用層：對應插件化宿主App，也包含一些非常基礎的業務功能：登陸、支付等賬戶模塊的。
模塊層：以獨立業務為條件劃分
組件層：添加 插件框架

基本上，到了這個層面，一般公司的業務都可以cover。

進程化

巨無霸App：支付寶、微信、淘寶這種，一個App動輒幾百M內存。那么就需要多個進程使App獲取更多的內存，運行更加流程。

小結

App框架的選擇，并非越大越好。選擇適合你現階段需求、并充分考慮到未來3個月可能的需求的框架模式，才是最合理的。

一個初創團隊，往往達到模塊化就足矣；

項目是不斷成長，架構也會不斷改進，以使用項目的金華。

架構最重要的是對未來的思考、對未來的把控。

這需要非常長時間的迭代。

總結

以上是生活随笔為你收集整理的移动端的架构演化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。