摘要：原文地址前言起源組件化方案分析業務組件的劃分和代碼隔離路由框架基礎庫的優勢簡介什么是組件化為什么要組件化分析現有的組件化方案如何選擇組件化方案組件化方案描述架構圖一覽架構圖詳解宿主層業務層業務模塊的拆分基礎層核心基礎業務公共服務基礎組件其他

原文地址: https://www.jianshu.com/p/f67...

0 前言

0.1 起源

0.2 組件化方案分析

0.2.1 業務組件的劃分和代碼隔離

0.2.2 路由框架

0.2.3 基礎庫

0.3 ArmsComponent 的優勢

1 簡介

1.1 什么是組件化?

1.2 為什么要組件化?

1.3 分析現有的組件化方案

1.4 如何選擇組件化方案?

2 組件化方案描述

2.1 架構圖一覽

2.2 架構圖詳解

2.2.1 宿主層

2.2.2 業務層

2.2.2.1 業務模塊的拆分

2.2.3 基礎層

2.2.3.1 核心基礎業務

2.2.3.2 公共服務

2.2.3.3 基礎 SDK

2.2.3.3.1 MVPArms

2.2.3.3.2 UI 組件

2.2.3.3.3 其他 SDK

2.3 跨組件通信

2.3.1 為什么需要跨組件化通信?

2.3.2 跨組件通信場景

2.3.3 跨組件通信方案

2.3.4 跨組件通信方案分析

2.3.5 跨組件傳遞復雜數據格式

2.4 組件的生命周期

2.4.1 問題分析

2.4.2 可行方案分析

2.4.3 最終執行方案

3 項目講解

3.1 如何讓組件獨立運行?

3.2 配置 AndroidManifest

3.3 配置 ConfigModule

3.4 RouterHub

3.5 EventBusHub

3.6 在項目中使用多個不同的域名

MVPArms 從兩年前開源至今, 已經累積了近 5k star, 獲得了上千個商業項目的信賴和認可

回顧兩年前, 那時 MVPArms 還沒誕生, MVP、Dagger2、Rxjava、Retrofit 這些技術在國內才剛剛開始流行, 在網上能搜索到的中文學習資料遠沒有現在這么豐富, 特別是 Dagger, 在網上能搜索到的文章甚至有很多講的是 Square 的 Dagger1, 學習資料的匱乏加上 Dagger2 本身就是塊硬骨頭, 讓本人在學習的道路上不知道多走了多少彎路

從那時開始, 讓初學者都能夠快速搭建一個 MVP + Dagger2 + Retrofit + Rxjava 項目的種子就已經深埋在心中, 后面經過不懈的努力, MVPArms 終于誕生并開源了, 開源以后只是一直堅持將 代碼, 注釋 和 文檔 做到極致, 沒想到的是, MVPArms 能發展到如今的體量, 感謝開源!

這是 MVPArms 的起源, ArmsComponent 的起源同樣相似, 從去年開始, 組件化逐漸火熱起來, 本人也在去年年初開始在公司項目中進行組件化, 一切還算順利

那時同樣的種子繼續埋在了心中, 我想讓剛剛接觸組件化的初學者也能快速搭建一個中小型的組件化項目, 經過一年的不斷優化, 終于決定將其開源(MVPArms 官方組件化方案 ArmsComponent)

Github : 您的 Star 是我堅持的動力 ?

看了很多組件化方案, 所以總結了在組件化中很重要的三個大點:

基礎庫(網絡請求、圖片加載等)的封裝

路由框架(頁面跳轉, 服務提供)

業務組件的劃分和代碼隔離

先說第三點 業務組件的劃分和代碼隔離, 現在大部分的文章都圍繞著這點, 我這里發表下個人的觀點, 第三點確實是很重要的一點, 不管是大廠的方案還是小廠的方案都有借鑒之處, 但是這點也是最不可能討論出最終結果和統一解決方案的一點

每個公司、每個項目的情況都不一樣, 大廠的方案真的適合您嗎? 不一定, 大廠幾十個業務群, 幾百號開發人員, 他們的組織結構和項目規模都不是普通公司能比擬的, 如果伸拉硬套他們的方案, 進行更嚴格更細粒度的代碼隔離, 可能產出的價值還不及您先前付出的代價, 帶來效率的降低, 所以根據項目的實際情況做出靈活的調整才是項目負責人最應該干的事, 這點我在后面會有詳細的介紹

陸續也有很多組件化方案開源自己的 路由框架, 是個很不錯的開始, 我覺得大家寫的都不錯, 各有各的優勢, 本方案也決定用別人的 路由框架, 自己寫的原理也差不多, 還不一定比別人考慮的完善, 還要自己維護, 為什么不選擇一個成熟穩定的呢？

很多組件化文章只是在講如何拆分以及封裝基礎庫, 但是至今沒看到有哪個組件化方案開源過完整的基礎庫的, 我猜測原因可能是, 組件化方案都是從商業項目不斷的業務迭代中逐漸完善的, 基礎庫也屬于公司的核心機密, 所以不可能開源

但是基礎庫尤其重要, 特別是兼容組件化的基礎庫, 這關乎到組件化方案的根基, 根基都沒有, 何談其他更高級的功能? 但是從封裝到完善一個兼容組件化的基礎庫是需要很長時間的, 大多數中小公司是不愿意投入這個成本的

MVPArms 是一個開源兩年, 成熟穩定, 涵蓋大量主流技術且兼容組件化的基礎庫, MVPArms 使得 ArmsComponent 成為了唯一提供完整基礎庫的組件化方案, 這就是 ArmsComponent 相對于其他組件化方案最大的優勢

因為有了 基礎庫 的存在, 再加上已有的 路由框架, 組件化中的三個大點就已經占有兩個(業務組件的劃分和代碼隔離 在后面會有介紹), 因此使用 ArmsComponent 啟動一個新項目, 即可快速進行組件化, 將 Demo (組件化項目雛形) 克隆下來后, 稍作修改, 馬上就可以投入到業務的開發之中

ArmsComponent 對于新項目以及已經開始使用 MVPArms 的項目將會更加便捷, 有著優于其他組件化方案的體驗, 對于那些網絡請求, 圖片加載等基礎功能亂七八糟散落到項目各處, 沒有統一抽離出來的舊項目, 建議直接使用 MVPArms, 開始組件化

如果您不想使用 MVPArms, 覺得接入成本太大, 沒關系, 借鑒下 MVPArms 和 ArmsComponent 的代碼, 嘗試改造自己的項目, 也是個不錯的選擇

好了, 進入正題!

組件化簡單概括就是把一個功能完整的 App 或模塊拆分成多個子模塊, 每個子模塊可以獨立編譯和運行, 也可以任意組合成另一個新的 App 或模塊, 每個模塊即不相互依賴但又可以相互交互, 遇到某些特殊情況甚至可以升級或者降級

現在的項目隨著需求的增加規模變得越來越大, 規模的增大帶來了很多煩惱, 各種業務錯中復雜的交織在一起, 每個業務模塊之間, 代碼沒有約束, 帶來了代碼邊界的模糊, 代碼沖突時有發生, 更改一個小問題可能引起一些新的問題, 牽一發而動全身, 增加一個新需求, 瞻前顧后的熟悉了大量前輩們寫的代碼后才敢動手, 編譯時間也不在斷增加, 開發效率極度的下降, 在這種情況下組件化的出現就是為了解決以上的煩惱

很多大廠的組件化方案是以 多工程 + 多 Module 的結構(微信, 美團等超級 App 更是以 多工程 + 多 Module + 多 P 工程(以頁面為單元的代碼隔離方式) 的三級工程結構), 使用 Git Submodule 創建多個子倉庫管理各個模塊的代碼, 并將各個模塊的代碼打包成 AAR 上傳至私有 Maven 倉庫使用遠程版本號依賴的方式進行模塊間代碼的隔離

按照康威定律, 系統架構的設計需要根據組織間的溝通結構, 因為現在大部分項目的規模和開發人員的數量以及結構還不足以需要某些大廠發布的組件化方案支撐(大廠的組織結構和項目規模都非常龐大, 他們的方案不一定完全適合所有公司的項目), 進行更嚴格更細粒度的代碼間以及模塊間的隔離, 盲目的使用某些組件化方案, 可能會帶來開發效率降低, 開發成本遠大于收益等情況, 性價比變低, 作為項目負責人, 應該根據項目目前的規模以及開發人員的組織結構去選擇目前最適合的組件化方案, 做到以項目實際情況去制定技術方案, 而不是盲目跟隨某些大廠的技術方案讓項目和開發人員花費大量時間去調整和適應

ArmsComponent 目前采用的是 單工程 + 多 Module 的結構, 由于 Demo 較小僅僅為了展示基本規范, 所以也只是采用源碼依賴并沒有做到遠程版本號依賴組件, 代碼管理也只是采用 單倉庫 + 多分支 的方式, 這樣也是對于開發初期, 項目規模還較小, 開發人員也較少時, 開發效率較高的方案, 如果您的項目規模較大, 開發人員眾多, 就可以采用上面提到的 多工程 + 多 Module, 并使用私有 Maven 倉庫管理組件版本

世界上沒有一個方案可以完美到兼顧所有情況, 并且還滿足所有人, 所有項目的需求, 所以項目負責人必須按照項目實際情況做出靈活的調整, 才能做出最適合自家項目的方案

ArmsComponent 組件化架構圖

目前架構一共分為三層, 從低到高依次是基礎層, 業務層和宿主層, 由于目前項目較小人員較少所以三層都集中在一個工程中, 但您可以根據項目的規模和開發人員的數量拆分成多個工程協同開發

宿主層位于最上層, 主要作用是作為一個 App 殼, 將需要的模塊組裝成一個完整的 App, 這一層可以管理整個 App 的生命周期(比如 Application 的初始化和各種組件以及三方庫的初始化)

業務層位于中層, 里面主要是根據業務需求和應用場景拆分過后的業務模塊, 每個模塊之間互不依賴, 但又可以相互交互, 比如一個商城 App 由 搜索, 訂單, 購物車, 支付 等業務模塊組成

Tips: 每個業務模塊都可以擁有自己獨有的 SDK 依賴和自己獨有的 UI 資源 (如果是其他業務模塊都可以通用的 SDK 依賴 和 UI 資源 就可以將它們抽離到 基礎 SDK(CommonSDK 2.2.3.3) 和 UI 組件(CommonRes 2.2.3.3.2) 中)

寫業務之前先不要急著動手敲碼, 應該先根據初期的產品需求到后期的運營規劃結合起來清晰的梳理一下業務在未來可能會發生的發展, 確定業務之間的邊界, 以及可能會發生的變化, 最后再確定下來真正需要拆分出來的業務模塊再進行拆分

基礎層位于最底層, 里面又包括 核心基礎業務模塊、公共服務模塊、 基礎 SDK 模塊, 核心基礎業務模塊 和 公共服務模塊 主要為業務層的每個模塊服務, 基礎 SDK 模塊 含有各種功能強大的團隊自行封裝的 SDK 以及第三方 SDK, 為整個平臺的基礎設施建設提供動力

核心基礎業務 為 業務層 的每個業務模塊提供一些與業務有關的基礎服務, 比如在項目中以用戶角色分為 2 個端口, 用戶可以扮演多個角色, 但是在線上只能同時操作一個端口的業務, 這時每個端口都必須提供一個角色切換的功能, 以供用戶隨時在多個角色中切換,
這時在項目中就需要提供一個用于用戶自由切換角色的管理類作為 核心基礎業務 被這 2 個端口所依賴(類似 拉勾, Boss 直聘等 App 可以在招聘者和應聘者之間切換)

核心基礎業務 的劃分應該遵循是否為業務層大部分模塊都需要的基礎業務, 以及一些需要在各個業務模塊之間交互的業務, 都可以劃分為 核心基礎業務

公共服務 是一個名為 CommonService 的 Module, 主要的作用是用于 業務層 各個模塊之間的交互(自定義方法和類的調用), 包含自定義 Service 接口, 和可用于跨模塊傳遞的自定義類

主要流程是:

提供服務的業務模塊:

在公共服務(CommonService) 中聲明 Service 接口 (含有需要被調用的自定義方法), 然后在自己的模塊中實現這個 Service 接口, 再通過 ARouter API 暴露實現類

使用服務的業務模塊:

通過 ARouter 的 API 拿到這個 Service 接口(多態持有, 實際持有實現類), 即可調用 Service 接口中聲明的自定義方法, 這樣就可以達到模塊之間的交互

跨模塊傳遞的自定義類:

在 公共服務 中定義需要跨模塊傳遞的自定義類后 (Service 中的自定義方法和 EventBus 中的事件實體類都可能需要用到自定義類), 就可以通過 ARouter API, 在各個模塊的頁面之間跨模塊傳遞這個自定義對象 (ARouter 要求傳遞自定義對象必須實現 SerializationService 接口)

Tips: 建議在 CommonService 中給每個需要提供服務的業務模塊都建立一個多帶帶的包, 然后在這個包下放 Service 接口 和 需要跨模塊傳遞的自定義類, 這樣更好管理

掌握公共服務層的用法最好要了解 ARouter 的 API

點擊查閱 ARouter 文檔

基礎 SDK 是一個名為 CommonSDK 的 Module, 其中包含了大量功能強大的 SDK, 提供給整個架構中的所有模塊

2.2.3.3.1 MVPArms

MVPArms 是整個基礎層中最重要的模塊, 可謂是整個組件化架構中的心臟, 里面提供了開發一個完整項目所必須的一整套 API 和 SDK, 是整個項目的腳手架, 我用它來統一整個組件化方案的基礎設施, 使每一個模塊更加健壯, 因為有了 MVPArms, 使得 ArmsComponent 成為了唯一提供完整基礎框架的組件化方案, 所以學習 ArmsComponent 之前必須先學會 MVPArms

學習 MVPArms 時請按以下排列順序依次學習:

1.點擊學習 Demo

2.點擊查閱 詳細文檔

3.點擊下載 一鍵生成代碼插件

2.2.3.3.2 UI 組件

基礎 SDK 中的 UI 組件 是一個名為 CommonRes 的 Module, 主要放置一些業務層可以通用的與 UI 有關的資源供所有業務層模塊使用, 便于重用、管理和規范已有的資源

Tips: 值得注意的是, 業務層的某些模塊如果出現有資源名命名相同的情況 (如兩個圖片命名相同), 當在宿主層集成所有模塊時就會出現資源沖突的問題, 這時注意在每個模塊的 build.gradle 中使用 resourcePrefix 標簽給每個模塊下的資源名統一加上不同的前綴即可解決此類問題

android {
    defaultConfig {
        minSdkVersion rootProject.ext.android["minSdkVersion"]
        ...
    }
    resourcePrefix "public_"
}

可以放置的資源類型有:

通用的 Style, Theme

通用的 Layout

通用的 Color, Dimen, String

通用的 Shape, Selector, Interpolator

通用的 圖片資源

通用的 動畫資源

通用的 自定義 View

通用的第三方 自定義 View

2.2.3.3.3 其他 SDK

其他 SDK 主要是 基礎 SDK 依賴的一些業務層可以通用的 第三方庫 和 第三方 SDK (比如 ARouter, 騰訊 X5 內核), 便于重用、管理和規范已有的 SDK 依賴

因為各個業務模塊之間是各自獨立的, 并不會存在相互依賴的關系, 所以一個業務模塊是訪問不了其他業務模塊的代碼的, 如果想從 A 業務模塊的 A 頁面跳轉到 B 業務模塊的 B 頁面, 光靠模塊自身是不能實現的, 所以這時必須依靠外界的其他媒介提供這個跨組件通信的服務

跨組件通信主要有以下兩種場景:

第一種是組件之間的頁面跳轉 (Activity 到 Activity, Fragment 到 Fragment, Activity 到 Fragment, Fragment 到 Activity) 以及跳轉時的數據傳遞 (基礎數據類型和可序列化的自定義類類型)

第二種是組件之間的自定義類和自定義方法的調用(組件向外提供服務)

其實以上兩種通信場景甚至其他更高階的功能在 ARouter 中都已經被實現, ARouter 是 Alibaba 開源的一個 Android 路由中間件, 可以滿足很多組件化的需求, 也是作為本方案中比較重要的一環, 需要認真看下文檔, 了解下基本使用

關于跨組件通信框架, 本方案不做封裝, 專業的事交給專業的人做, 此類優秀框架為數眾多, 各有特點, 可以根據您的需求選擇您喜歡的框架, 不一定非得是 ARouter, 選擇 ARouter 也是因為 Alibaba 出品, 開源時間較長, 使用者眾多, 相對穩定, 出現問題比較好溝通

第一種組件之間的頁面跳轉不需要過多描述了, 算是 ARouter 中最基礎的功能, API 也比較簡單, 跳轉時想傳遞不同類型的數據也提供有相應的 API (傳遞自定義對象, 需要實現 SerializationService, 詳情請查閱 ARouter 文檔);

第二種組件之間的自定義類和自定義方法的調用要稍微復雜點, 需要 ARouter 配合架構中的 公共服務(CommonService) 實現, 主要流程在 公共服務(2.2.3.2) 中已有介紹, 這里我畫了個示意圖, 以便大家更好理解

跨組件通信示意圖

此種服務提供方式叫作 接口下沉, 看圖的同時請配合閱讀 公共服務(2.2.3.2) 中的主要流程便于理解

本方案中還提供有 EventBus 來作為服務提供的另一種方式, 大家知道 EventBus 因為其解耦的特性, 如果被濫用的話會使項目調用層次結構混亂, 不便于維護和調試, 所以本方案使用 AndroidEventBus 其獨有的 Tag, 可以在開發時更容易定位發送事件和接受事件的代碼, 如果以組件名來作為 Tag 的前綴進行分組, 也可以更好的統一管理和查看每個組件的事件, 當然也不建議大家過多使用 EventBus

Tips: 每個跨組件通信框架提供服務的方式都不同, 您也可以選擇其他框架的服務提供方式

在一般情況下基本數據類型就可以滿足大多數跨組件傳遞數據的需求, 但是在某些情況下也會需要傳遞復雜的自定義數據類型, 傳遞自定義類型在方案中也提供有兩種方式:

第一種在 公共服務(2.2.3.2) 中已提及, 就是在 公共服務 (CommonService) 中定義這個自定義類

第二種方式也比較簡單, 直接通過解析 Json 字符串就可以傳遞

每個組件 (模塊) 在測試階段都可以獨立運行, 在獨立運行時每個組件都可以指定自己的 Application, 這時組件自己管理生命周期就輕而易舉, 比如想在 onCreate 中初始化一些代碼都可以輕松做到, 但是當進入集成調試階段, 組件自己的 Application 已不可用, 每個組件都只能依賴于宿主的生命周期, 這時每個組件如果需要初始化自己獨有的代碼, 該怎么辦?

在集成調試階段, 宿主依賴所有組件, 但是每個組件卻不能依賴宿主, 意思是每個組件根本不知道自己的宿主是誰, 當然也就不能通過訪問代碼的方式直接調用宿主的方法, 從而在宿主的生命周期里加入自己的邏輯代碼

如果直接將每個模塊的初始化代碼直接復制進宿主的生命周期里, 這樣未免過于暴力, 不僅代碼耦合不易擴展, 而且代碼還極易沖突, 所以修改宿主源碼的方式也不可行

所以有沒有什么方法可以讓每個組件在集成調試階段都可以獨自管理自己的生命周期呢?

其實解決思路很簡單, 無非就是在開發時讓每個組件可以獨立管理自己的生命周期, 在運行時又可以讓每個組件的生命周期與宿主的生命周期進行合并 (在不修改或增加宿主代碼的情況下完成)

想在不更改宿主代碼的情況下在宿主的生命周期中動態插入每個組件的代碼, 這倒有點像 AOP 的意思

現有的解決方案大概有三種:

在基礎層中提供一個用于管理組件生命周期的管理類, 每個組件都手動將自己的生命周期實現類注冊進這個管理類, 在集成調試時, 宿主在自己的 Application 對應生命周期方法中通過管理類去遍歷調用注冊的所有生命周期實現類即可

使用 AnnotationProcessor 解析注解在編譯期間生成源代碼自動注冊所有組件的生命周期實現類, 然后宿主再在對應的生命周期方法中去調用

使用 Javassist 在編譯時動態修改 class 文件, 直接在宿主的對應生命周期方法中插入每個組件的生命周期邏輯

我最后還是選擇了第一種方法, 因為后面兩種方法雖然使用簡單, 還可以自動化的完成所有操作, 非常炫酷, 但是這兩種方法技術實現復雜, 在不同的 Gradle 版本中還會出現兼容性問題影響整個項目的開發進度, 較難維護, 還會增加編譯時間

選擇第一種方法雖然增加了幾步操作, 但是簡單明了, 便與理解和維護, 后續人員加入也可以很快上手, 不受 Gradle 版本的影響, 也不會增加編譯時間

第一種方案具體原理也沒什么好說的, 比較簡單, 大概就是在基礎層中定義有生命周期方法 (attachBaseContext(), onCreate() ...) 的接口, 每個組件實現這個接口, 然后將實現類注冊進基礎層的管理器, 宿主通過管理器在對應的生命周期方法中調用所有的接口實現類, 典型的觀察者模式, 類似注冊點擊事件

在 MVPArms 中這種方案的實現類叫作 ConfigModule, 每個組件都可以聲明一個或多個 ConfigModule 實現類, 內部實現較為復雜, 實現原理是 反射 + 代理 + 觀察者, 這個類也是整個 MVPArms 框架提供給開發者最重要的類

它可以給 MVPArms 框架配置大量的自定義參數, 包括項目中所有生命周期的管理 (Application, Activity, Fragment), 項目中所有網絡請求的管理 (Retrofit, Okhttp, Glide),為框架提供了極大的擴展性, 使框架更加靈活

項目地址 : ArmsComponent

在項目根目錄的 gradle.properties 中, 改變 isBuildModule 的值即可

#isBuildModule 為 true 時可以使每個組件獨立運行, false 則可以將所有組件集成到宿主 App 中
isBuildModule=true

由于組件在獨立運行時和集成到宿主時可能需要 AndroidManifest 配置不一樣的參數, 比如組件在獨立運行時需要其中的一個 Activity 配置了 作為入口, 而當組件集成到宿主中時, 則依賴于宿主的入口, 所以不需要配置 , 這時我們就需要兩個不同的 AndroidManifest 應對不同的情況

在組件的 build.gradle 中加入以下代碼, 即可指定不同的 AndroidManifest, 具體請看項目代碼

android {
    sourceSets {
        main {
            jniLibs.srcDirs = ["libs"]
            if (isBuildModule.toBoolean()) {
                manifest.srcFile "src/main/debug/AndroidManifest.xml"
            } else {
                manifest.srcFile "src/main/release/AndroidManifest.xml"
            }
        }
    }
}

ConfigModule 在 最終執行方案(2.4.3) 中提到過, GlobalConfiguration 是實現類, 他可以給框架配置大量的自定義參數

項目 CommonSDK 中提供有一個 GlobalConfiguration 用于配置每個組件都會用到的公用配置信息, 但是每個組件可能都需要有一些私有配置, 比如初始化一些特有屬性, 所以在每個組件中也需要實現 ConfigModule, 具體請看項目代碼

需要注意的是, 在 配置 AndroidManifest(3.2) 中提到過組件在獨立運行時和集成到宿主時所需要的配置是不一樣的, 當組件在獨立運行時需要在 AndroidManifest 中聲明自己私有的 GlobalConfiguration 和 CommonSDK 公有的 GlobalConfiguration, 但在集成到宿主時, 由于宿主已經聲明了 CommonSDK 的公有 GlobalConfiguration, 所以在 AndroidManifest 只需要聲明自己私有的 GlobalConfiguration, 這里也說明了 AndroidManifest 在不同的情況需要做出不同的配置

RouterHub 用來定義路由器的路由地址, 以組件名作為前綴, 對每個組件的路由地址進行分組, 可以統一查看和管理所有分組的路由地址

路由地址的命名規則為 組件名 + 頁面名, 如訂單組件的訂單詳情頁的路由地址可以命名為 "/order/OrderDetailActivity"

ARouter 將路由地址中第一個 "/" 后面的字符叫作 Group, 比如上面的示例路由地址中 order 就是 Group, 以 order 開頭的地址都被分配該 Group 下

Tips: 切記不同的組件中不能出現名稱一樣的 Group, 否則會發生該 Group 下的部分路由地址找不到的情況!!!

所以每個組件使用自己的組件名作為 Group 是比較好的選擇, 畢竟組件不會重名

AndroidEventBus 作為本方案提供的另一種跨組件通信方式 (第一種跨組件通信方式是 公共服務(2.2.3.2)), AndroidEventBus 比 greenrobot 的 EventBus 多了一個 Tag, 在組件化中更容定位和管理事件

EventBusHub 用來定義 AndroidEventBus 的 Tag 字符串, 以組件名作為 Tag 前綴, 對每個組件的事件進行分組

Tag 的命名規則為 組件名 + 頁面名 + 動作,
比如需要使用 AndroidEventBus 通知訂單組件的訂單詳情頁進行刷新, 可以將這個刷新方法的 Tag 命名為 "order/OrderDetailActivity/refresh"

在項目中, 有 知乎 、干貨集中營、稀土掘金 三個模塊, 這三個模塊網絡接口的域名都不一樣, 但是在項目中卻可以統一使用框架提供的同一個 Retrofit 進行網絡請求, 這是怎么做到的呢? 這是采用本人的另一個庫 RetrofitUrlManager, 它可以使 Retrofit 同時支持多個 BaseUrl 以及動態改變 BaseUrl

Hello 我叫Jessyan,如果您喜歡我的文章,可以在以下平臺關注我

GitHub: https://github.com/JessYanCoding

掘金: https://gold.xitu.io/user/57a...

簡書: http://www.jianshu.com/u/1d0c...

微博: http://weibo.com/u/1786262517

-- The end