架構——android架構演進概述

2019 年 10 月 6 日
筆記

隨著業務的發展和技術的變更，Android開發也經歷了以下幾個發展階段：

看似高大上的名詞，其實遵循著最簡單的原則：分而治之（如何劃分就是「架構」，簡單的事情如何串在一起就是「介面協議」，CS領域太多這樣的例子了。）

我的理解是，模組化/組件化/插件化都是一種廣義的模組化，只是它們的實現方式不同而已。

模組化系統案例：

智慧android設備：Launcher, Lock Screen, Live Wallpaper,AppStore,BatteryManager

Hadoop生態系統：HDFS,YARN,MapReduce等

單體應用

業務程式碼 + 數據存儲 + 介面請求 + 日誌等各個模組雜糅在一個module中。
這種結構基本上已經不適用任何項目，只能作為個人的測試或者demo。

優點：

編譯構建簡單

缺點：

無法適用與複雜的業務結構

廣義的模組化

「Modular hardware lead to modular software」

模組化特點：

模組間耦合小（模組間一般通過介面進行通訊/調用）
模組可替換(介面不變底層實現可替換)

模組化代價：

模組間調用複雜
需要擬定介面協議
兼容性問題（不同的module可能依賴不同的版本）

為什麼需要模組化：

實現高內聚低耦合的程式碼
不同module可以並行開發和測試
靈活的集成/部署/升級

模組化的方式：

1. 分包
1. Android studio中分module
1. 應用拆分（一個應用拆分成多個應用）

俠義的模組話

android開發時，狹義的模組話就是在project中建立多個module。比如將資料庫的處理建立一個module，業務程式碼建立一個module（業務很複雜的化也可以根據業務場景進行拆分），日誌埋點作為一個module等

組件化

組件化是在狹義模組化思想上的一次演進，一個變種。

組件化的核心是角色的轉換。在打包時，是library; 在調試時，是application。

A在開發測試業務1時就可以把「業務1」作為一個Application，進行構建測試。當需要構建整個App時，「業務1」又是一個library，構建腳本就能控制這一切。

看似很簡單，但是業務場景千奇百怪，還有很多問題需要解決：

業務模組之間的通訊：如果時統一進程直接定義介面即可，跨進程可考慮使用AIDL
Main Activity入口問題：腳本控制使用不同的AndroidManifest文件
activity跳轉問題：