淺談Android元件化
一個關於元件化的念頭
專案經歷了歲月的洗禮，經過公司業務上的變化，開發人員的來來往往，程式碼越來越臃腫和複雜難懂，這時候就必須進行拆分，否則就是一場災難。就像我們公司的老專案一樣，耦合度極高，已經停掉的業務，現在還在專案裡面留存著，完全不敢刪。新功能上線，因為要回歸測試，測試時間有時候比開發時間還長。
元件化這個詞，我們應該在各個地方，通過各種渠道，看到過無數次，而且一般會給配上下面這張圖，小機器人，綠油油的色彩，非常的鮮豔奪目有調性。
元件化和外掛化同屬於模組化程式設計，只是兩種不同的展現模式。兩者的區別，只有一個：外掛化支援動態增加和修改線上的模組，元件化只能對現有模組進行增加和刪除。
專案線上功能動態很頻繁的電商類APP，適合使用外掛化。變動需求不強烈的工具類APP，適合採用元件化。我們公司對靈活性要求不高，因此採用元件化方案。
元件化的幾個要點
元件化的要點不算少，下面準備就我認為主要的部分，用提問和解答的方式，梳理大概的思路。
01.如何將一個龐大的工程拆分成有機的整體？
我認為應該分三個部分，主專案，基礎公共庫和業務元件。先抽出基礎公共庫，供其他元件呼叫，剩餘部分按照業務邏輯去分元件，利於後期業務的迭代開發，主專案負責裝載元件。
02.元件可以單獨執行嗎？如何做到？
分離開的每個元件，都應支援獨立執行，這樣我們才能單獨在某個模組開發和測試。可以通過 apply plugin: 'com.android.application' 和 apply plugin: 'com.android.library' 去實現兩個身份的轉換。
這裡不要被圖給誤解到，元件化中的胳膊腿離開了身體，其實還是能獨立存活的個體。
03.如何做到元件與元件之間的獨立？
元件與元件之間相互獨立，才是降低耦合，主要表現在資源隔離和程式碼隔離。程式碼隔離可通過gradle3.0 之後 runtimeOnly 依賴語法實現編譯期隔離 。資源隔離，目前官方沒有現成的隔離方案，暫時可以先使用 resourcePrefix 屬性，人為維護。
04.元件之間互相獨立，資料如何傳遞？
考慮路由方案，目前已經有很成熟的路由庫 ARouter。
除以上問題，還有元件的整合除錯，元件生命週期等問題，我認為前期可以先不考慮，留待後期優化。
元件化前 VS 元件化後
元件化改造的過程是非常痛苦的，但是完成後的開發體驗真的超超超超幸福！因為業務模組邏輯分離，程式碼耦合度降低，所以會帶來以下好處：
- 編譯時間短
- 開發週期降低
- 減少測試迴歸
- 快速定位問題
- 業務模組遷移很方便
下面是我司專案元件化過程中的解耦的業務模組：
<
Android 綠色小機器人坐成兩排，十分乖巧可愛。
如何快速開始元件化
第一步，少年，你需要自行去搜索獲取關於元件化的知識，在腦海中有它有個清楚的認識。
第二步，針對你的目標專案，梳理整體的業務邏輯和程式碼架構，做出可行的元件化方案。這一步非常重要，必須提前探好底，讓更多的問題暴露在執行前。不然，想象下，你一個模組感覺都要挪過來80%了，發現業務邏輯上分離不開，或者技術上實現有障礙，這就很浪費時間和精力了，還影響心情。
第三步，方案遞交給技術 leader ,同意之後，申請排期開發。
第四步，沐浴焚香，拜好程式碼大神，就開始吧。
友情提示，最好單獨拉一個新分支，因為這非常可能持久戰，不要因此影響了專案的正常迭代。
我的組建化步驟
-
抽出基礎工具類 BaseLib，網路封裝庫 NetWorkLib。
-
抽出基礎資源庫 BasicRes，管理公共資源，例如 BaseActivity／BaseApplication 等基類們，對話方塊，res資源。
-
分離業務邏輯，獨立為 Module。
-
選定 Arouter 作為路由方案，連線各元件 Module。
Android開發技術交流qq群；701740775