元件化與外掛化的學習（一）

隨著業務越來越多，參與人員越來越多，相互之間任務不明確，開發耦合，程式碼重疊修改，協調效率低下，動一發牽全身。

**問題：**上述情景在APP的迭代開發，人員變更是必然存在的~，~這就給了我們理由去重構我們的程式碼了，畢竟一個好的程式猿是為了解決問題而生，而不是單純碼程式碼。

**解決方案：**面前主流的做法解決思路一般都是：元件化和外掛化 ####1. 元件化開發就是將一個app分成多個模組，每個模組都是一個元件（Module），開發的過程中我們可以讓這些元件相互依賴或者單獨除錯部分元件等，但是最終釋出的時候是將這些元件合併統一成一個apk，這就是元件化開發。 ####2. 外掛化開發和元件化開發略有不用，外掛化開發時將整個app拆分成很多模組，這些模組包括一個宿主和多個外掛，每個模組都是一個apk（元件化的每個模組是個lib），最終打包的時候將宿主apk和外掛apk分開或者聯合打包。 一圖看懂元件化和外掛化

---

###元件化###

---

首先先來了解元件化 定義：元件化就是基於可重用的目的，將一個大的軟體系統按照分離關注點的形式，拆分成多個獨立的元件。 簡單點：不同功能做成一個元件，達到可重用目的。再不懂看上面的圖。 講道理~

1. 首先看看年輕時候寫的程式碼

   

   這種程式碼相信很多猿年少輕狂都會寫過吧，複製貼上。但是作為一個會進化的猿，是誰給你的勇氣再寫這樣的程式碼的？梁靜茹嗎？
2. 那好，我們再來看看可重用的做法

   

   這種應該很常見，層級分明。但是轉身一想，還記得我們文章的開頭嗎？ 隨著業務越來越多，參與人員越來越多，相互之間任務不明確，開發耦合，程式碼重疊修改，協調效率低下，動一發牽全身。
3. 行，產品是爸爸，你說加就加。你有張良計我有過牆梯。你不逼我我都不進步。 回看元件化的思想，不同功能做成一個元件，可重用

   

   APP有一個殼工程（主工程），然後有著各種功能的基礎元件（網路、資料庫、圖片載入等）。然後負責登入元件的開發童鞋只需要在主工程和基礎元件的基礎上開發登入元件即可，達到了程式碼重用、解耦。可開發可測試。其他業務元件同理。 但是現實是這樣嗎？想多了吧。 舉個栗子：使用者操作元件需要什麼？使用者。使用者哪裡來？登入來的。那好，登入元件和使用者元件就存在了一定的耦合，使用者元件必須依賴登入元件。 或許你會說：“這還不簡單，一個殼工程和基礎元件加上登入元件、使用者操作元件一起開發就行。” 想法是好，那假如業務元件需要依賴多個業務元件呢？這個業務元件也需要依賴另一個業務元件呢？不同模組下跳轉？隱式跳轉？

   

4. 接下啦要掏出我們的大寶劍。要解決上面的耦合，隆重介紹主角——路由（Router）。對路由的瞭解可以看這篇文章Android架構思考(模組化、多程式)