從事Adroid開發幾年來，逐漸對Android應用架構和發展趨勢有一點點認識，總結為三個詞：“元件化，模組化，外掛化”。下面以一張圖為基礎，分別從這個三個方面進行闡述。

元件化

為什麼需要元件化？

Android的原生控制元件，基本上都沒法直接拿來用，太醜了。另外一方面，原生控制元件在不同的Android版本上可能有不同風格，Holo，Material Design等。而從應用開發者角度來講，他們需要一個拿來可用的，統一併且可延續的風格。在這種背景下，他們開始自定義系統控制元件，逐漸形成了自己的風格。比如，微信，支付寶，高德地圖等。這樣之後，我們就需要將這種風格應用於TextView，Button，ImageView等標準化控制元件。元件化後，我們開發新功能，只需要直接引用帶有自己風格的標準化控制元件，再稍微調整寬度，高度，字型大小等，就可以應付大多數情況了。

不元件化會怎麼樣？

如果沒有形成自己的風格，又或者是形成固定風格後，不去進行元件化，會有什麼後果呢？那大概的情況可能是這樣，整個應用風格不統一。給你的整體印象可能是，你一會是在用蘋果應用，一會是在用Android應用。打個不恰當的比方，一個男人，上身西裝筆挺，下身大褲衩，腳上又是厚厚的棉鞋。

模組化

為什麼需要模組化？

起初，一個應用幾個人搞定，並不需要模組化這些事情。

但隨著業務的發展，應用的迭代，可能出現人員越來越多，業務模組越來越多，越來越複雜的情況。在產品快速迭代過程中，假設某個業務的某個需求，由於外部原因等無法按時開發完成怎麼辦？或者由於其他原因，導致這部分功能有嚴重BUG怎麼辦？下掉這部分功能，又進行全量測試？划不來。硬著頭皮修復BUG？萬一來不及，錯過釋出日期怎麼辦？

這種情況下，應該按照業務，將業務模組分成幾大塊，同時按照業務模組對人員進行分組。

模組化建議遵循以下原則：

1. 模組之間鬆耦合。 如果模組之間耦合度很高，應該考慮是不是應該將兩個模組合併在一起。

2. 模組之間的約定/介面應該保持穩定。 模組化後，如果由於人員更替，導致模組之間的約定被破壞，或者介面被修改，沒有及時同步，可能會造成模組之間的調用出現BUG。所以，這部分約定/介面應該保持穩定。萬一要修改，確保通知到其他人，做相應調整。

3. 模組定義清晰。不要為了模組化而強行進行模組化。

怎樣進行模組化？

參考上面的圖片。我的建議是這樣的，分層進行。

底層

包含，基礎庫和底層庫。

*** 基礎庫 ***

1. Http，封裝了常用的網路操作，例如： okhttp

2. Image，封裝了圖片相關的網路操作。（其中，如何防止記憶體溢位OOM問題尤其重要。） 例如： Fresco

3. SQLITE,封裝了資料庫相關操作，也就是我們常說的ORM。例如： greenDAO

4. 其他就不一一列舉了。

*** 底層庫 ***底層庫，主要是使用C/C++開發的跨平臺的引擎或者庫，以so的形式存在。例如：遊戲引擎cocos2d

中間層

每個公司根據業務不同，分成不同的業務模組。在底層的基礎上，實現相應的業務功能。

上層

將所有業務模組聚合在一起，加上配置，形成主應用。一個模組化做的好的應用，主應用應該很簡單，並且非常的穩定。

外掛化

為什麼需要外掛化？

1. 方法數限制的需要 大家都知道，一個dex的最大的方法數是固定的，65536.如果方法數超過這個數目，你根本無法正常的打包了。你可以採用MultiDex方案，但是看起來外掛化的方案更靠譜一點。

2. 安裝包大小控制的需要 對於大部分應用來說，應用安裝包越小，使用者越容易安裝。安裝包越大，使用者下載，安裝，升級時，需要等待的時間越長，放棄應用的概率也就越高。通過外掛化，可以將較小眾的功能/模組進行外掛化，使用者需要時，點選下載，安裝外掛。

3. 靈活性的需要 外掛化之前，我們釋出patch包總是要針對整個應用。而現在，我們只需要釋出某個外掛的更新即可。

怎麼進行外掛化？

並沒有一個官方的外掛化方案。各個大的網際網路公司內部通常會搞一個外掛化方案。慶幸的時，有一部分外掛化方案被開源出來，供大家參考，使用。具體怎麼進行外掛化，超出了本人的討論範圍。如果大家有興趣的話，可以到這裡瞭解。 awesome-android

哪些模組需要外掛化？

對於核心底層模組，不建議進行外掛化。即使要進行外掛化，也要在最初的安裝時，給全部安裝完畢。

對於核心業務模組，可以進行外掛化。要在最初的安裝時，給全部安裝完畢。

對於非核心業務模組，建議進行外掛化。使用者從網路下載，按需安裝。

PS：facebook推出react native之後，移動應用又颳起了一陣Web風。苦於對Android平臺和Windows開發環境的支援不足，暫時沒法緊跟時代步伐了。