一個關於元件化的念頭
專案經歷了歲月的洗禮，經過公司業務上的變化，開發人員的來來往往，程式碼越來越臃腫和複雜難懂，這時候就必須進行拆分，否則就是一場災難。就像我們公司的老專案一樣，耦合度極高，已經停掉的業務，現在還在專案裡面留存著，完全不敢刪。新功能上線，因為要回歸測試，測試時間有時候比開發時間還長。
元件化這個詞，我們應該在各個地方，通過各種渠道，看到過無數次，而且一般會給配上下面這張圖，小機器人，綠油油的色彩，非常的鮮豔奪目有調性。
元件化和外掛化同屬於模組化程式設計，只是兩種不同的展現模式。兩者的區別，只有一個：外掛化支援動態增加和修改線上的模組，元件化只能對現有模組進行增加和刪除。
專案線上功能動態很頻繁的電商類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。
相關推薦
元件化的概念，已經提出相當長時間，因為有很多優秀的文章可供參考，以下是我的推薦：
得到APP的前技術負責人張明慶大神的系列文章，我的元件化思路也來源於此。
這篇文章，從多個維度對目前網上一些有代表性的開源元件化開發方案進行對比，適合大家能快速對android元件化有個整體的認識。
最後是我自己的元件化系列文章，內容簡單易懂，希望對你能有所幫助：