實現方案

直接依賴

這種方式實現簡單，但是耦合太嚴重，不方便維護與開發，當工程逐漸增大模塊逐漸增多，依賴關系會非常複雜，不推薦這種方式。

事件或廣播通信

EventBus：?我們非常熟悉的事件總線型的通信框架，非常靈活，采用注解方式實現，但是難以追溯事件。廣播：?安卓的四大組件之一，在一個模塊中發送廣播設置數據，在另一個模塊中注册廣播接收數據，使用廣播進行數據傳遞方式廣播相對於其他的方式而言消耗資源較多。

總結：?BroadcastReceiver、EventBus，非常靈活，模塊之間沒有任何的耦合，但是代碼的可讀性差，難以追溯事件，不是很推薦。

路由通信

模塊與模塊之間不存在依賴關系，而是各自運作，簡單的來說就是映射關系的路由通信，也是目前比較主流的一種方案，比較常用的開源框架是阿裏的ARouter。

ARouter典型應用

從外部URL映射到內部頁面，以及參數傳遞與解析跨模塊頁面跳轉，模塊間解耦攔截跳轉過程處理登陸、埋點等邏輯跨模塊API調用，通過控制反轉來做組件解耦。

面向接口通信

以上幾種方式只是簡單的介紹，下面就具體說下通過接口解耦通信的方式，首先先看幾個問題。

什麼是面向接口編程？

接口大家都很熟悉，這裏所說的面向接口編程，並不只是所謂的 java 中的 interface，而是指超類型，可以是接口也可以是抽象類。

面向接口比面向對象編程是更先進一步編程思想，而是附屬於面向對象編程的體系，屬於其中一部分，它是面向對象編程體系中的思想精髓之一。面向接口編程它的核心思想是將抽象與實現分離，從組件的級別來設計代碼，達到高內聚低耦合的目的。面向接口編程方法是，先定義底層接口模塊，也就是?通信的協議與功能約定?，是提供方實現對應的功能與能力。在架構中層次分明，不需要關注具體實現，開發中可以通過接口快速制定協議，與提供能力api，對於上層通過接口顯露能力，對於下層只需要依賴接口層相當於依賴api。

面向接口編程的好處？

靈活性高沒有依賴具體的實體，實現層可以任意的更改與切換。在模塊化中可以相互依賴service(接口層)或依賴多個。?

?在模塊化中的使用下面對於接口（interface）或api層統稱為service，其含義為服務提供者。

對於，每一個 module 都一個獨立的工程結構，每個 module 都有自己的 Service ,來統一暴露當前 module 所擁有能力與向外提供的服務。

對於 module 是在同一個工程裏的項目結構，service 可以放到統一的一個 Module 下，我們統稱為 Mediator，這樣做的目的是為了减少 Module 創建與維護。假設你的工程有20個業務 Module 如果都同時增加一個 service 層就會造成 Module 數量翻一倍。由於這裏存入的都一些接口類，也是每個業務 Module 向外提供的服務其體量不會太大，這裏並只是一個建議並沒有標准的做法。

當然也有更複雜的設計，一個 Module 又分不同的 service 實現如圖，這裏不在展開細說。

實際工程中使用與設計

在實際項目中有很多項目都同時開發兩版本Pad與Phone，有的是兩獨立的工程，有的是在同一個工程內用 flavor 切換不同的工程，下面我就以通過 flavor 切換的工程結構舉例。先看下工程的包的結構圖：

可以看到 module 結構是分為三個部分，common, pad, phone, 如果每個service 都獨立將增加3倍的 Module 數量。

使用一個 Mediator Module 統一管理這這些 service 就很好控制了 module 數量。

Service 創建

在 module_mediator 業務 module 下 common，pad、pone 下分別創建ICommonService, IService(pad), IService(phone)。ICommonService：公共服務。IService(pad)：pad服務並繼承CommonService。IService(phone)：phone服務並繼承CommonService。

注：這裏為什麼不用，PadService與PhoneService，是因為pad與phone版本同時只會存在一個，使用方只需要關心你提供的Service不用在區分版本，而且這裏是一個繼承關系也可以獲取到共用的部分。

Service 實現

依賴 Mediator :

在業務 common\pad\phone module 下分別實現，ICommonService, Service(pad), IService(phone) ，在 common module 創建 CommonServiceImpl 實現 ICommonService，在 pad、phone module 分別創建 ServiceImpl 對應實現 IService 並繼承與 CommonServiceImpl。

Service 注册

注册的方式有一般是通過代碼用去注册，或通過注解進行注册。可以在 Application 注册也可以在業務 Module 下自己注册，如果使用注解則可以自動注册，具體要看項目怎樣實現。例：

解釋下 MediatorServiceFacator，它只是一個服務工廠也是一個接口類，作用是負責管理各業務方的 Service 主要功能是注册與獲取 Service。上面的代碼就是往裏注册了一個會員的 Service。

可以看出這個函數只有兩個參數，一個是接口class一個是實現類class，第一個參數cls：它會作為 key 來使用，第二個參數implClass：它會作為 value 來使用。

Service 使用

通過 MediatorServiceFacator 懶加載獲取service對象，如果業務方沒有注册則獲取一個空的對象。

注册有 service 沒有使用時是不會創建的，如果使用過則會緩存下來，下次調用則直接返回。（第一次是通過反射創建）例：

1. 在 mediator 模塊下會員 CommonService 中 定義了一個模糊查詢會員的方法。

2. 在會員模塊下 common 中實現了該功能。

3. 在會員模塊下 pad 中繼承了這個實現。

4. 在其他模塊 pad 下使用這個功能。

可以看到獲取 Service 只要傳對應接口就即可，對於使用方是不用關心實現方，在開發過程中只要先定義好接口，合作的同學就可以進入正常開發了。細心的同學可以看出，返回的數據類型也是一個接口類，為什麼不直接返回一個普通 java 類呢？主要原因是通過接口方法達到雙方 api 約定，例如 getName() :String 方法是通過方法名返回值達到約定效果，這樣不依賴具體實現。

從上面的例子可以看出主要分為三個部分：1、定義接口。2、提供方實現接口。3、使用方都通過服務工廠獲取服務使用。對於使用者來是很簡單的，不需要關心實現，通過接口可以直接獲取到實現，並且獲取到結果可以直接使用，不需要做序列化處理。

有了路由通信我們為什麼還使用面向接口編程？

路由模式雖然很好的解决了耦合的問題，但他的方法調用都是靜態的，對於傳參與返回值只能是基本類型，如果是對象需要做序列化與反序列化處理，對性能有一定影響。類似在調後臺接口一樣，同時降低了代碼的可讀性， 對於 app 而言所有 Module 都是在同一個應用下，沒有必要做這些序列化操作。

對於複雜業務不好處理，例如一個業務需要多次通信，路由模式則不好處理，而通過接口通信則可以容易解决。例如：一個讀卡的操作，業務方需要對它有開啟、關閉、暫停等多個狀態的操作。通過接口則可以直接返回一個讀卡的 service 控制器， 這樣可以直接進行相應的控制操作。

從上面代碼中可以看出，上層回調結果的同時並回調了一個控制接口，這樣就提供使用方一個反向操作的能力。

尾聲

評論裏面有些同學有疑問關於如何學習material design控件，我的建議是去GitHub搜，有很多同行給的例子，這些栗子足够入門。

有朋友說要是動真格的話，需要NDK以及JVM等的知識，首現**NDK並不是神秘的東西，**你跟著官方的步驟走一遍就知道什麼回事了，無非就是一些代碼格式以及原生/JAVA內存交互，進階一點的有原生/JAVA線程交互，線程交互確實有點蛋疼，但平常避免用就好了，再說對於初學者來說關心NDK幹嘛，據鄙人以前的經曆，只在音視頻通信和一個嵌入式信號處理（離線）的兩個項目中用過，嵌入式信號處理是JAVA->NDK->.SO->MATLAB這樣調用的我原來MATLAB的代碼，其他的大多就用在遊戲上了吧，一般的互聯網公司會有人給你公司的SO包的。
至於JVM,該掌握的那部分，相信我，你會掌握的，不該你掌握的，有那些專門研究JVM的人來做，不如省省心有空看看計算機系統，編譯原理。

一句話，平常多寫多練，這是最基本的程序員的素質，盡量擠時間，讀理論基礎書籍，JVM不是未來30年唯一的虛擬機，JAVA也不一定再風靡未來30年工業界，其他的系統和語言也會雨後春笋冒出來，但你理論紮實會讓你很快理解學會一個語言或者框架，你平常寫的多會讓你很快熟練的將新學的東西應用到實際中。
初學者，一句話，多練。

 CodeChina開源項目：《Android學習筆記總結+移動架構視頻+大廠面試真題+項目實戰源碼》