之前寫過一篇關于Android組件化的文章，《Android組件化框架設計與實踐》，之前沒看過的小伙伴可以先點擊閱讀。那篇文章是從實戰中進行總結得來，是公司的一個真實項目進行組件化架構改造，粒度會分的更粗些，是對整體架構實踐進行相應的總結，里面說了要打造一個組件化框架的話，需要從以下7個方面入手：

1. 代碼解耦。如何將一個龐大的工程分成有機的整體？
2. 組件單獨運行。因為每個組件都是高度內聚的，是一個完整的整體，如何讓其單獨運行和調試？
3. 組件間通信。由于每個組件具體實現細節都互相不了解，但每個組件都需要給其他調用方提供服務，那么主項目與組件、組件與組件之間如何通信就變成關鍵？
4. UI 跳轉。UI 跳轉指的是特殊的數據傳遞，跟組件間通信區別有什么不同？
5. 組件生命周期。這里的生命周期指的是組件在應用中存在的時間，組件是否可以做到按需、動態使用、因此就會涉及到組件加載、卸載等管理問題。
6. 集成調試。在開發階段如何做到按需編譯組件？一次調試中可能有一兩個組件參與集成，這樣編譯時間就會大大降低，提高開發效率。
7. 代碼隔離。組件之間的交互如果還是直接引用的話，那么組件之間根本沒有做到解耦，如何從根本上避免組件之間的直接引用，也就是如何從根本上杜絕耦合的產生？

今天則會從更小細粒度入手，主要講講在組件化架構下組件與組件之間通信機制是如何、包括所謂的UI跳轉，其實也是組件化通信，只不過它稍微特殊點，單獨抽取出來而已。學習知識的過程很常見的一個思路就是從整體概況入手，首先對整體有個粗略的印象，然后再深入細節，抽絲剝繭般去挖掘其中的內在原理，一個點一個不斷去突破，這樣就能建立起自己整個知識樹，所以今天我們就從通信機制這個點入手，看看其中內在玄機有哪些。

思維導圖

同樣，在每寫一篇文章之前，放個思維導圖，這樣做的好處對于想寫的內容有很好的梳理，邏輯和結構上顯得清晰點。

主流方式

總所周知，Android提供了很多不同的信息的傳遞方式，比如在四大組件中本地廣播、進程間的AIDL、匿名間的內存共享、Intent Bundle傳遞等等，那么在這么多傳遞方式，哪種類型是比較適合組件與組件直接的傳遞呢。

• 本地廣播，也就是LoacalBroadcastRecevier。更多是用在同一個應用內的不同系統規定的組件進行通信，好處在于：發送的廣播只會在自己的APP內傳播，不會泄漏給其他的APP，其他APP無法向自己的APP發送廣播，不用被其他APP干擾。本地廣播好比對講通信，成本低，效率高，但有個缺點就是兩者通信機制全部委托與系統負責，我們無法干預傳輸途中的任何步驟，不可控制，一般在組件化通信過程中采用比例不高。
• 進程間的AIDL。這個粒度在于進程，而我們組件化通信過程往往是在線程中，況且AIDL通信也是屬于系統級通信，底層以Binder機制，雖說Android提供模板供我們實現，但往往使用者不好理解，交互比較復雜，往往也不適用應用于組件化通信過程中。
• 匿名的內存共享。比如用Sharedpreferences，在處于多線程場景下，往往會線程不安全，這種更多是存儲一一些變化很少的信息，比如說組件里的配置信息等等。
• Intent Bundle傳遞。包括顯性和隱性傳遞，顯性傳遞需要明確包名路徑，組件與組件往往是需要互相依賴，這背離組件化中SOP（關注點分離原則），如果走隱性的話，不僅包名路徑不能重復，需要定義一套規則，只有一個包名路徑出錯，排查起來也稍顯麻煩，這個方式往往在組件間內部傳遞會比較合適，組件外與其他組件打交道則使用場景不多。

說了這么多，那組件化通信什么機制比較適合呢？既然組件層中的模塊是相互獨立的，它們之間并不存在任何依賴。沒有依賴就無法產生關系，沒有關系，就無法傳遞消息，那要如何才能完成這種交流？

目前主流做法之一就是引入第三者，比如圖中的Base Module。

組件層的模塊都依賴于基礎層，從而產生第三者聯系，這種第三者聯系最終會編譯在APP Module中，那時將不會有這種隔閡，那么其中的Base Module就是跨越組件化層級的關鍵，也是模塊間信息交流的基礎。比較有代表性的組件化開源框架有得到DDComponentForAndroid、阿里Arouter、聚美Router 等等。

除了這種以通過引入第三者方式，還有一種解決方式是以事件總線方式，但這種方式目前開源的框架中使用比例不高，如圖：

事件總線通過記錄對象，使用監聽者模式來通知對象各種事件，比如在現實生活中，我們要去找房子，一般都去看小區的公告欄，因為那邊會經常發布一些出租信息，我們去查看的過程中就形成了訂閱的關系，只不過這種是被動去訂閱，因為只有自己需要找房子了才去看，平時一般不會去看。小區中的公告欄可以想象成一個事件總線發布點，監聽者則是哪些想要找房子的人，當有房東在公告欄上貼上出租房信息時，如果公告欄有訂閱信息功能，比如引入門衛保安，已經把之前來這個公告欄要查看的找房子人一一進行電話登記，那么一旦有新出租消息產生，則門衛會把這條消息一一進行短信群發，那么找房子人則會收到這條消息進行后續的操作，是馬上過來看，還是延遲過來，則根據自己的實際情況進行處理。在目前開源庫中，有EventBus、RxBus就是采用這種發布/訂閱模式，優點是簡化了Android組件之間的通信方式，實現解耦，讓業務代碼更加簡潔，可以動態設置事件處理線程和優先級，缺點則是每個事件需要維護一個事件類，造成事件類太多，無形中加大了維護成本。那么在組件化開源框架中有ModuleBus、CC 等等。

這兩者模式更詳細的對比，可以查看這篇文章多個維度對比一些有代表性的開源android組件化開發方案

實現方案

事件總線，又可以叫做組件總線，路由+接口，則相對好理解點，今天從閱讀它們框架源碼，我們來對比這兩種實現方案的不同之處。

組件總線

這邊選取的是ModuleBus框架，這個方案特別之處在于其借鑒了EventBus的思想，組件的注冊/注銷和組件調用的事件發送都跟EventBus類似，能夠傳遞一些基礎類型的數據，而并不需要在Base Moudel中添加額外的類。所以不會影響Base模塊的架構，但是無法動態移除信息接收端的代碼，而自定義的事件信息類型還是需要添加到Base Module中才能讓其他功能模塊索引。

其中的核心代碼是在與 ModuleBus 類，其內部維護了兩個ArrayMap鍵對值列表，如下：

/**
     * Object methodClass
     * String methodName；
     * MethodInfo method info
     */
    private static ArrayMap<Object,ArrayMap<String,MethodInfo>> moduleEventMethods = new ArrayMap<>();

    /**
     * Class IBaseClient.class
     * String methodName
     * Object methodClass
     */
    private static ArrayMap<Class<?>,ArrayMap<String,ArrayList<Object>>> moduleMethodClient = new ArrayMap<>();

在使用方法上，在onCreate()和onDestroy()中需要注冊和解綁，比如

ModuleBus.getInstance().register(this);
ModuleBus.getInstance().unregister(this);

最終使用類似EventBus 中 post 方法一樣，進行兩個組件間的通信。這個框架的封裝的post 方法如下

public void post(Class<?> clientClass,String methodName,Object...args){
        if(clientClass == null || methodName == null ||methodName.length() == 0) return;

        ArrayList<Object> clientList = getClient(clientClass,methodName);

        if(clientList == null) return;

        try{
            for(Object c: clientList){
                try{
                    ArrayMap<String,MethodInfo> methods = moduleEventMethods.get(c);
                    Method method = methods.get(methodName).m;
                    if(method == null){
                        Log.e(TAG,"cannot find client method"+methodName +"for args["+args.length+"]" + Arrays.toString(args));
                        return;
                    }else if(method.getParameterTypes() == null){
                        Log.e(TAG,"cannot find client method param:"+method.getParameterTypes() +"for args["+args.length+"]" + Arrays.toString(args));
                        return;
                    }else if(method.getParameterTypes().length != args.length){
                        Log.e(TAG,"method "+methodName +" param number not matched:method("+method.getParameterTypes().length+"), args(" + args.length+")");
                        return;
                    }
                    method.invoke(c,args);
                }catch (Throwable e){
                    Log.e(TAG,"Notifiy client method invoke error.",e);
                }
            }

        }catch (Throwable e){
            Log.e(TAG,"Notify client error",e);
        }
    }

可以看到，它是通過遍歷之前內部的ArrayMap，把注冊在里面的方法找出，根據傳入的參數進行匹配，使用反射調用。

接口+路由

接口+路由實現方式則相對容易理解點，我之前實踐的一個項目就是通過這種方式實現的。具體地址如下：DemoComponent 實現思路是專門抽取一個LibModule作為路由服務，每個組件聲明自己提供的服務 Service API，這些 Service 都是一些接口，組件負責將這些 Service 實現并注冊到一個統一的路由 Router 中去，如果要使用某個組件的功能，只需要向Router 請求這個 Service 的實現，具體的實現細節我們全然不關心，只要能返回我們需要的結果就可以了。

比如定義兩個路由地址，一個登陸組件，一個設置組件，核心代碼：

public class RouterPath {

    //注意路由的命名，路徑第一個開頭需要不一致，保證唯一性
    //Login Service
    public static final String ROUTER_PATH_TO_LOGIN_SERVICE = "/login/service";

    //Setting Service
    public static final String ROUTER_PATH_TO_SETTING_SERVICE = "/setting/service";
}

那么就相應著就有兩個接口API，如下：

public interface ILoginProvider extends IProvider {

    void goToLogin(Activity activity);
}

public interface ISettingProvider extends IProvider {
    
    void goToSetting(Activity activity);
}

這兩個接口API對應著是向外暴露這兩個組件的能提供的通信能力，然后每個組件對接口進行實現，如下：

@Route(path = RouterPath.ROUTER_PATH_TO_LOGIN_SERVICE, name = "登陸頁面")
public class LoginService implements ILoginProvider {
    @Override
    public void init(Context context) {}


    @Override
    public void goToLogin(Activity activity) {
        Intent loginIntent = new Intent(activity, LoginActivity.class);
        activity.startActivity(loginIntent);
    }
}

這其中使用的到了阿里的ARouter頁面跳轉方式，內部本質也是接口+實現方式進行組件間通信。

調用則很簡單了，如下：

 ILoginProvider loginService = (ILoginProvider) ARouter.getInstance().build(RouterPath.ROUTER_PATH_TO_LOGIN_SERVICE).navigation();
if(loginService != null){
    loginService.goToLogin(MainActivity.this);
}

還有一個組件化框架，就是ModularizationArchitecture ，它本質實現方式也是接口+實現，但是封裝形式稍微不一樣點，它是每個功能模塊中需要使用注解建立Action事件，每個Action完成一個事件動作。invoke只是方法名為反射，并未用到反射，而是使用接口方式調用，參數是通過HashMap<String,String>傳遞的，無法傳遞對象。具體詳解可以看這篇文章 Android架構思考(模塊化、多進程)。

頁面跳轉

頁面跳轉也算是一種組件間的通信，只不過它相對粒度更細化點，之前我們描述的組件間通信粒度會更抽象點，頁面跳轉則是定位到某個組件的某個頁面，可能是某個Activity，或者某個Fragment，要跳轉到另外一個組件的Activity或Fragment，是這兩者之間的通信。甚至在一般沒有進行組件化架構的工程項目中，往往也會封裝頁面之間的跳轉代碼類，往往也會有路由中心的概念。不過一般 UI 跳轉基本都會單獨處理，一般通過短鏈的方式來跳轉到具體的 Activity。每個組件可以注冊自己所能處理的短鏈的 Scheme 和 Host，并定義傳輸數據的格式，然后注冊到統一的 UIRouter 中，UIRouter 通過 Scheme 和 Host 的匹配關系負責分發路由。但目前比較主流的做法是通過在每個 Activity 上添加注解，然后通過 APT 形成具體的邏輯代碼。

下面簡單介紹目前比較主流的兩個框架核心實現思路：

ARouter

ARouter 核心實現思路是，我們在代碼里加入的@Route注解，會在編譯時期通過apt生成一些存儲path和activityClass映射關系的類文件，然后app進程啟動的時候會拿到這些類文件，把保存這些映射關系的數據讀到內存里(保存在map里)，然后在進行路由跳轉的時候，通過build()方法傳入要到達頁面的路由地址，ARouter會通過它自己存儲的路由表找到路由地址對應的Activity.class(activity.class = map.get(path))，然后new Intent()，當調用ARouter的withString()方法它的內部會調用intent.putExtra(String name, String value)，調用navigation()方法，它的內部會調用startActivity(intent)進行跳轉，這樣便可以實現兩個相互沒有依賴的module順利的啟動對方的Activity了。

ActivityRouter

ActivityRouter 核心實現思路是，它是通過路由 + 靜態方法來實現，在靜態方法上加注解來暴露服務，但不支持返回值，且參數固定位(context, bundle)，基于apt技術，通過注解方式來實現URL打開Activity功能，并支持在WebView和外部瀏覽器使用，支持多級Activity跳轉，支持Bundle、Uri參數注入并轉換參數類型。它實現相對簡單點，也是比較早期比較流行的做法，不過學習它也是很有參考意義的。

小結

總的來說，組件間的通信機制在組件化編程和組件化架構中是很重要的一個環節，可能在每個組件獨自開發階段，不需要與其他組件進行通信，只需要在內部通信即可，當處于組件集成階段，那就需要大量組件進行互相通信，體現在每個業務互相協作，如果組件間設計的不好，打開一個頁面或調用一個方法，想當耗時或響應慢，那么體現的則是這個APP使用比較卡頓，僅僅打開一個頁面就是需要好幾秒才能打開，則嚴重影響使用者的體驗了，甚至一些大型APP，可能組件分化更小，種類更多，那么組件間的通信則至關重要了。所以，要打造一個良好的組件化框架，如何設計一個更適合自己本身的業務類型的通信機制，就需要多多進行思考了。

參考文章：

1，https://github.com/luckybilly/AndroidComponentizeLibs

2，http://blog.spinytech.com/2016/12/28/android_modularization/