一個關於組件化的念頭

項目經歷了歲月的洗禮，通過公司業務上的變化，開發人員的來來每每，代碼愈來愈臃腫和複雜難懂，這時候就必須進行拆分，不然就是一場災難。就像咱們公司的老項目同樣，耦合度極高，已經停掉的業務，如今還在項目裏面留存着，徹底不敢刪。新功能上線，由於要回歸測試，測試時間有時候比開發時間還長。android

組件化這個詞，咱們應該在各個地方，經過各類渠道，看到過無數次，並且通常會給配上下面這張圖，小機器人，綠油油的色彩，很是的鮮豔奪目有調性。編程

組件化和插件化同屬於模塊化編程，只是兩種不一樣的展示模式。二者的區別，只有一個：插件化支持動態增長和修改線上的模塊，組件化只能對現有模塊進行增長和刪除。微信

項目線上功能動態很頻繁的電商類APP，適合使用插件化。變更需求不強烈的工具類APP，適合採用組件化。咱們公司對靈活性要求不高，所以採用組件化方案。markdown

組件化的幾個要點

組件化的要點不算少，下面準備就我認爲主要的部分，用提問和解答的方式，梳理大概的思路。網絡

01.如何將一個龐大的工程拆分紅有機的總體？架構

我認爲應該分三個部分，主項目，基礎公共庫和業務組件。先抽出基礎公共庫，供其餘組件調用，剩餘部分按照業務邏輯去分組件，利於後期業務的迭代開發，主項目負責裝載組件。app

02.組件能夠單獨運行嗎？如何作到？模塊化

分離開的每一個組件，都應支持獨立運行，這樣咱們才能單獨在某個模塊開發和測試。能夠經過 apply plugin: 'com.android.application' 和 apply plugin: 'com.android.library' 去實現兩個身份的轉換。工具

這裏不要被圖給誤解到，組件化中的胳膊腿離開了身體，其實仍是能獨立存活的個體。oop

03.如何作到組件與組件之間的獨立？

組件與組件之間相互獨立，纔是下降耦合，主要表如今資源隔離和代碼隔離。代碼隔離可經過gradle3.0 以後 runtimeOnly 依賴語法實現編譯期隔離。資源隔離，目前官方沒有現成的隔離方案，暫時能夠先使用 resourcePrefix 屬性，人爲維護。

04.組件之間互相獨立，數據如何傳遞？

考慮路由方案，目前已經有很成熟的路由庫 ARouter。

除以上問題，還有組件的集成調試，組件生命週期等問題，我認爲前期能夠先不考慮，留待後期優化。

組件化改造的過程是很是痛苦的，可是完成後的開發體驗真的超超超超幸福！由於業務模塊邏輯分離，代碼耦合度下降，因此會帶來如下好處：

下面是我司項目組件化過程當中的解耦的業務模塊：

Android 綠色小機器人坐成兩排，十分乖巧可愛。

第一步，少年，你須要自行去搜索獲取關於組件化的知識，在腦海中有它有個清楚的認識。

第二步，針對你的目標項目，梳理總體的業務邏輯和代碼架構，作出可行的組件化方案。這一步很是重要，必須提早探好底，讓更多的問題暴露在執行前。否則，想象下，你一個模塊感受都要挪過來80%了，發現業務邏輯上分離不開，或者技術上實現有障礙，這就很浪費時間和精力了，還影響心情。

第三步，方案遞交給技術 leader ,贊成以後，申請排期開發。

第四步，沐浴焚香，拜好代碼大神，就開始吧。

友情提示，最好單獨拉一個新分支，由於這很是可能持久戰，不要所以影響了項目的正常迭代。