誰阻礙了你作組件化開發？

前言

以前寫了一篇關於總結一波安卓組件化開源方案的文章，反響還不錯，很高興可以對你們總體瞭解android組件化技術有所幫助。

有些開發者在瞭解組件化開發的好處及相關開源框架後，想要對本身所負責的項目進行組件化改造以解決多人（多團隊）協同開發困難及單工程開發編譯時間過長等問題，但一直難如下決心真正開始實施，停留在瞭解階段或僅僅寫個demo體驗一把的階段，其中很大一部分緣由是迭代開發任務排的很緊，很難空出一段時間來實施，並且組件化改造是純技術上的優化，產品經理和業務部門並不太關心。

爲此，本文將介紹一下如何用 CC 框架來破解android組件化不易上手的難題（想要了解CC實現原理的細節，請戳這裏）

1、誰阻礙了你

先來解決幾個可能阻擋咱們下決心實施組件化改造的攔路石：

1. 怕配置複雜，容易遺漏或出錯
   • CC將配置封裝到了一個cc-settings.gradle文件，在須要組件化的module的build.gradle中添加一行依賴cc-settings.gradle文件的代碼便可
2. 怕一開始就須要很大的改動
   • 使用CC能夠先不改變當前項目中現有的代碼，無需添加註解，只需新增一個接口的實現類便可定義一個組件，將其服務暴露給其它組件調用，後續有空的時候再逐步拆分
3. 怕組件化開發框架學習成本高，團隊內每一個人都瞭解須要較長時間
   • CC提供了統一的調用方式和實現方式
   • 定義組件僅需實現1個接口類，並確保經過調用CC.sendCCResult(callId, cCResult)將組件調用的執行結果發送給調用者便可
   • 調用組件僅需瞭解一下CC鏈式調用便可，例如：（CC.obtainBuilder("demo.ComponentA").setActionName("login").addParam("id", 12345).build().callAsync(callback)）
   • 另外library模式切換成application的方式簡化爲在local.properties中配置一行module名稱=true便可，並且local.properties不會被提交到代碼倉庫中，不會由於誤操做致使在jenkins上編譯出錯的狀況
   • 幾乎零門檻就能夠進行組件化開發
4. 怕增長項目的維護成本
   • CC採用了編譯時自動註冊插件AutoRegister來自動維護組件的註冊工做，無需手動維護
   • 組件化框架下進行開發跟普通的開發同樣，未使用hook等黑科技
   • 組件將業務隔離在內部，而且可單獨調試，能下降項目維護成本
5. 剛開始組件化時若是調用其它組件必需要打包一塊兒運行，則享受不到單組件運行的便利
   • CC支持跨app調用
   • CC支持一個module中包含多個組件類，即便沒有進行拆分，也能夠在主工程中定義這些組件類（在主app moudle或在被調用功能所在的module均可以），暴露調用入口給其它組件調用，後續在進行組件拆分時將組件類一同拆分出去便可
   • 因此，能夠將須要被調用到的功能先定義好組件，供新建的組件跨app調用，無需與主工程一塊兒打包，從一開始就能夠單獨運行組件
6. Fragment很差組件化
   • 其它組件化方案採用下沉接口的方式提供組件間調用，但只是獲取了Fragment對象，難以進行後續的通訊
   • CC框架下，獲取Fragment對象的方式跟其它組件調用徹底同樣，而且後續能夠將此Fragment對象做爲參數回傳給原組件進行Fragment內部功能的調用，真正作到業務隔離在組件內部進行處理
7. 有自定義View或者第三方View的功能很差組件化，例如將第三方地圖SDK封裝成組件，因爲其它組件頁面中要用到MapView控件，是否須要強依賴？
   • CC一樣支持View的組件化，詳情請戳Fragment和View的組件化

2、推薦的組件化實施步驟

設想一下，在作組件化改造以前，若是按照以下步驟來實施，是否是可行性更高一些，讓咱們更快地享受到組件化給咱們帶來的便利和好處，不至於由於迭代任務節奏快而遲遲不能落實：

2.1 快速上手

• 先不用修改當前項目中現有的代碼（最大程度地下降工做量及出錯機率）
• 能夠選擇將新的業務按照組件化的方式來進行開發，單獨以apk的方式編譯運行&調試（也能夠選擇一個耦合度較低且相對獨立的業務來進行這一步）
• 在主工程中建立新組件所須要調用到的主工程業務的組件類
• 在這些組件類在組件還沒有完整拆分以前便可按照組件化的方式對其它組件暴露調用入口
• 恭喜，組件化改造的第一步已經成功邁出。

2.2 全局規劃

因爲組件化是全局的架構，提早規劃好整個工程的組件劃分並明確各自的業務邊界，會讓咱們實施組件化改造的過程更加有章法，項目結構更加清晰，責任更加明確，組件的可複用性更強。

關於組件如何劃分，不一樣的團隊有不一樣的理解，不一樣的業務應用場景下也有不一樣的要求。通常經常使用的劃分方式如下2種，能夠結合起來使用：

• 按UI(Activity/Fragment/View)劃分，每一個頁面或控件都做爲獨立的組件。
  • 優勢是粒度較細，方便複用，某個頁面發生變化不會影響其餘頁面
  • 缺點是若是頁面多，會致使組件太多，而且若是一個業務有多個頁面，這種方式致使業務內部太鬆散，不方便管理。
  • 另外須要將非頁面性的一些服務封裝爲組件
• 按業務/功能來劃分，將同一個業務下的不一樣功能和頁面劃分在同一個組件中
  • 優勢是能夠統一管理本業務下的全部功能（包括頁面和服務），提升了內聚性，改造方便
  • 缺點是若是掌控很差粒度可能會比較粗

無論具體如何劃分，有一點是相通的：單一職責。即須要肯定好業務邊界，將組件的業務隔離在本身內部，只暴露調用協議給外部。

舉個栗子：

與用戶帳號相關的業務，根據業務複雜程度及組件在不一樣app中複用的需求等不一樣狀況，能夠將其總體劃分爲1個組件，也能夠劃分爲登陸組件、設置組件、地址管理組件等各類更細粒度的組件，若是你願意，也能夠每一個頁面1個組件再加上帳號相關的服務組件。

但須要注意的是必須有明確的業務邊界。好比其中的登陸組件，就只負責用戶的帳號登陸/註冊等功能，不能將各類登陸後的頁面跳轉業務需求耦合到登陸組件中，能夠採用這種方式來實現：實現登陸成功再進入目標界面功能

再舉個JsBridge的栗子：

因爲每一個組件的業務都內聚在自身內部，因此JsBridge能夠封裝得十分優雅，迴歸其本質:僅做爲js與java通訊的橋樑，與其它組件徹底解耦，不須要下沉業務BridgePlugin接口

• js調用java時，在JsBridge組件中直接將參數轉發給對應的組件
• java調用js時，在JsBridge組件中根據調用參數調用對應頁面的js
• 作好對應業務組件找不到時的降級處理

不再須要在application中註冊一系列的Plugin

詳情請戳讓jsBridge更優雅

2.3 有空再弄

組件化改造中工做量最大的是要進行業務隔離，逐個組件抽離、解耦，這是一個比較長的過程，不能一蹴而就，能夠在迭代任務有空閒的時候一個個進行拆分，拆分的難度取決於原來項目中代碼的耦合程度：

• 已封裝無缺的業務module，只暴露一個或多個入口給別的module調用
  • 這種最簡單，僅需建立一個IComponent實現類，並將原來直接類調用的代碼改爲組件調用便可
• 耦合度比較高的業務
  • 這種業務的拆分須要必定的時間，能夠安排在迭代任務沒那麼繁忙的時間段來作。若是正好有改版的需求就更好了，能夠藉着改版的機會用組件化的方式來開發，替換原來的代碼。
  • 也能夠暫時先粗粒度地拆分，但按照全局的規劃建立多個IComponent接口實現類，至關於一個module中包含多個組件，後續有時間再進一步拆分
• 各類Base類、工具類
  • 這種module建議仍然下沉做爲公共庫的形式供其它組件依賴

3、常見問題

3.1 自定義類型如何在組件間傳遞？

• 下沉到公共庫中，做爲公共類型
  • 適用於使用頻次高或對性能要求特別敏感的場景
• json傳遞 & bean冗餘：即在每一個用到此類型的組件，經過冗餘bean的方式來傳遞
  • 適用於使用頻次較低且對性能要求不是十分敏感的場景

3.2 如何肯定一個module究竟是該做爲組件提供服務仍是下沉爲base基礎庫供其它組件依賴？

因爲組件有可單獨運行調試、無強類型耦合、AOP等優勢，除非有特殊狀況，原則上絕大多數的業務module都應該做爲組件來封裝。

這些特殊狀況有：

• 各類Base類、工具類
• 在組件間傳遞的公共自定義類型

其它諸如Fragment/View的組件化CC都已經支持了，若是有您須要的功能CC還未支持歡迎給我提issue

4、總結

本文主要介紹瞭如何更方便地使用CC框架來進行組件化改造，看完這篇文章後，對老項目進行組件化改造所需的成本應該有個比較直觀的認識。

若是您雖然很想在本身負責的項目中實施組件化改造，渴望組件化開發帶來的便利，但還有本文中未涉及到的其它顧慮致使還沒有開始執行，歡迎在評論中給我留言！

QQ交流羣

或者掃描下方二維碼加羣聊