關(guān)于Android模塊化我有一些話不知當(dāng)講不當(dāng)講

最近公司一個項目使用了模塊化設(shè)計，本人參與其中的一個小模塊開發(fā)，但是整體的設(shè)計并不是我架構(gòu)設(shè)計的，開發(fā)半年有余，在此記錄下來我的想法。

模塊化場景

為什么需要模塊化?

當(dāng)一個App用戶量增多，業(yè)務(wù)量增長以后，就會有很多開發(fā)工程師參與同一個項目，人員增加了，原先小團隊的開發(fā)方式已經(jīng)不合適了。

原先的一份代碼，現(xiàn)在需要多個人來維護，每個人的代碼質(zhì)量也不相同，在進行代碼Review的時候，也是比較困難的，同時也容易會產(chǎn)生代碼沖突的問題。

同時隨著業(yè)務(wù)的增多，代碼變的越來越復(fù)雜，每個模塊之間的代碼耦合變得越來越嚴(yán)重，解耦問題急需解決，同時編譯時間也會越來越長。

人員增多，每個業(yè)務(wù)的組件各自實現(xiàn)一套，導(dǎo)致同一個App的UI風(fēng)格不一樣，技術(shù)實現(xiàn)也不一樣，團隊技術(shù)無法得到沉淀。

架構(gòu)演變

在剛剛開始的時候，項目架構(gòu)使用的是MVP模式，這也是最近幾年很流行的一個架構(gòu)方式，下面是項目的原始設(shè)計。

隨著業(yè)務(wù)的增多，我們添加了Domain的概念，Domain從Data中獲取數(shù)據(jù)，Data可能會是Net，F(xiàn)ile，Cache各種IO等，然后項目架構(gòu)變成了這樣。

再然后隨著人員增多，各種基礎(chǔ)組件也變的越來越多，業(yè)務(wù)也很復(fù)雜，業(yè)務(wù)與業(yè)務(wù)之間還有很強的耦合，就變成了這樣的。

使用模塊化技術(shù)以后，架構(gòu)變成了這樣。

技術(shù)要點

這里簡單介紹下Android項目實現(xiàn)模塊化需要使用的技術(shù)以及技術(shù)難點。

Library module

在開始開始進行模塊化之前，需要把各個業(yè)務(wù)單獨抽取成Android Library Module,這個是Android Studio自帶一個功能，可以把依賴較少的，作為基本組件的抽取成一個單獨模塊。

如圖所示，我把各個模塊單獨分為一個獨立的項目。

在主項目中使用gradle添加代碼依賴。

// common 
compile project(':ModuleBase') 
compile project(':ModuleComponent') 
compile project(':ModuleService') 
 
// biz 
compile project(':ModuleUser') 
compile project(':ModuleOrder') 
compile project(':ModuleShopping') 

 Library module開發(fā)問題

在把代碼抽取到各個單獨的Library Module中，會遇到各種問題。最常見的就是R文件問題，Android開發(fā)中，各個資源文件都是放在res目錄中，在編譯過程中，會生成R.java文件。R文件中包含有各個資源文件對應(yīng)的id，這個id是靜態(tài)常量，但是在Library Module中，這個id不是靜態(tài)常量，那么在開發(fā)時候就要避開這樣的問題。

舉個常見的例子，同一個方法處理多個view的點擊事件，有時候會使用switch(view.getId())這樣的方式，然后用case R.id.btnLogin這樣進行判斷，這時候就會出現(xiàn)問題，因為id不是經(jīng)常常量，那么這種方式就用不了。

同樣開發(fā)時候，用的最多的一個第三方庫就是ButterKnife，ButterKnife也是不可以用的，在使用ButterKnife的時候，需要用到注解配置一個id來找到對應(yīng)view，或者綁定對應(yīng)的各種事件處理，但是注解中的各個字段的賦值也是需要靜態(tài)常量，那么就不能夠使用ButterKnife了。

解決方案有下面幾種：

1.重新一個Gradle插件，生成一個R2.java文件，這個文件中各個id都是靜態(tài)常量，這樣就可以正常使用了。

2.使用Android系統(tǒng)提供的最原始的方式，直接用findViewById以及setOnClickListener方式。

3.設(shè)置項目支持Databinding，然后使用Binding中的對象，但是會增加不少方法數(shù)，同時Databinding也會有編譯問題和學(xué)習(xí)成本，但是這些也是小問題，個人覺的問題不大。

上面是主流的解決方法，個人推薦的使用優(yōu)先級為 3 > 2 > 1。

當(dāng)把個模塊分開以后，每個人就可以單獨分組對應(yīng)的模塊就行了，不過會有資源沖突問題，個人建議是對各個模塊的資源名字添加前綴，比如user模塊中的登錄界面布局為activity_login.xml，那么可以寫成這樣us_activity_login.xml。這樣就可以避免資源沖突問題。同時Gradle也提供的一個字段resourcePrefix，確保各個資源名字正確，具體用法可以參考官方文檔。

依賴管理

當(dāng)完成了Library module后，代碼基本上已經(jīng)很清晰了，跟我們上面的最終架構(gòu)已經(jīng)很相似了，有了最基本的骨架，但是還是沒有完成，因為還是多個人操作同一個git倉庫，各個開發(fā)小伙伴還是需要對同一個倉庫進行各種fork和pr。

隨著對代碼的分割，但是主項目app的依賴變多了，如果修改了lib中的代碼，那么編譯時間是很恐怖的，大概統(tǒng)計了一下，原先在同一個模塊的時候，編譯時間大概需要2-3min，但是分開以后大概需要5-6min，這個是絕對無法忍受的。

上面的***問題，可以這樣解決，把各個子module分別使用單獨的一個git倉庫，這樣每個人也只需要關(guān)注自己需要的git倉庫即可，主倉庫使用git submodule的方式，分別依賴各個子模塊。

但是這樣還是無法解決編譯時間過長的問題，我們把各個模塊也單獨打包，每次子模塊開發(fā)完成以后，發(fā)布到maven倉庫中，然后在主項目中使用版本進行依賴。

舉個例子，比如進行某一版本迭代，這個版本叫1.0.0，那么各個模塊的版本也叫同樣的版本，當(dāng)版本完成測試發(fā)布后，對各個模塊打?qū)?yīng)版本的tag，然后就很清楚的了解各模塊的代碼分布。

gradle依賴如下。

// common 
   compile 'cn.mycommons:base:1.0.0' 
   compile 'cn.mycommons:component:1.0.0' 
   compile 'cn.mycommons:service:1.0.0' 
 
   // biz 
   compile 'cn.mycommons:user:1.0.0' 
   compile 'cn.mycommons:order:1.0.0' 
   compile 'cn.mycommons:shopping:1.0.0'  

可能有人會問，既然各個模塊已經(jīng)分開開發(fā)，那么如果進行開發(fā)聯(lián)調(diào)，別急，這個問題暫時保留，后面會對這個問題后面再表。

數(shù)據(jù)通信

當(dāng)一個大項目拆成若干小項目時候，調(diào)用的姿勢發(fā)生了少許改變。我這邊總結(jié)了App各個模塊之間的數(shù)據(jù)通信幾種方式。

• 頁面跳轉(zhuǎn)，比如在訂單頁面下單時候，需要判斷用戶是否登錄，如果沒有則需要跳到登錄界面。
• 主動獲取數(shù)據(jù)，比如在下單時候，用戶已經(jīng)登錄，下單需要傳遞用戶的基本信息。
• 被動獲得數(shù)據(jù)，比如在切換用戶的時候，有時候需要更新數(shù)據(jù)，如訂單頁面，需要把原先用戶的購物車數(shù)據(jù)給清空。

再來看下App的架構(gòu)。

***個問題，原先的方式，直接指定某個頁面的ActivityClass，然后通過intent跳轉(zhuǎn)即可，但是在新的架構(gòu)中，由于shopping模塊不直接依賴user，那么則不能使用原始的進行跳轉(zhuǎn)，我們解決方式使用Router路由跳轉(zhuǎn)。

第二個問題，原先的方式有個專門的業(yè)務(wù)單利，比如UserManager，直接可以調(diào)用即可，同樣由于依賴發(fā)生了改變，不能夠進行調(diào)用。解決方案是所有的需要的操作，定義成接口放在Service中。

第三個問題，原先的方式，可以針對事件變化提供回調(diào)接口，當(dāng)我需要監(jiān)聽某個事件時候，設(shè)置回調(diào)即可。

頁面路由跳轉(zhuǎn)

如上分析，原先方式代碼如下。

Intent intent = new Intent(this, UserActivity.class); 
 
startActivity(intent); 

但是使用Router后，調(diào)用方式改變了。

RouterHelper.dispatch(getContext(), "app://user"); 

具體的原理是什么，很簡單的，做一個簡單的映射匹配即可，把"app://user"與UserActivity.class配對，具體的就是定義一個Map，key是對應(yīng)的Router字符，value是Activity的class。在跳轉(zhuǎn)時候從map中獲取對應(yīng)的ActivityClass，然后在使用原始的方式。

可能有人的會問，要向另外一個頁面?zhèn)鬟f參數(shù)怎么辦，沒事我們可以在router后面直接添加參數(shù)，如果是一個復(fù)雜的對象那么可以把對象序列化成json字符串，然后再從對應(yīng)的頁面通過反序列化的方式，得到對應(yīng)的對象。

例如：

RouterHelper.dispatch(getContext(), "app://user?id=123&obj={"name":"admin"}"); 

注： 上面的router中json字符串是需要url編碼的，不然會有問題的，這里只是做個示例。

除了使用Router進行跳轉(zhuǎn)外，我想了一下，可以參考Retrofit方式，直接定義跳轉(zhuǎn)Java接口，如果需要傳遞額外參數(shù)，則以函數(shù)參數(shù)的方式定義。

這個Java接口是沒有實現(xiàn)類的，可以使用動態(tài)代理方式，然后接下來的方式，和使用Router的方式一樣。

那么這總兩種方式有什么優(yōu)缺點呢。

Router方式:

• 有點：不需要高難度的技術(shù)點，使用方便，直接使用字符串定義跳轉(zhuǎn)，可以好的往后兼容
• 缺點：因為使用的是字符串配置，如果字符輸入字符，則很難發(fā)現(xiàn)bug，同時也很難知道某個參數(shù)對應(yīng)的含義

仿Retrofit方式:

• 因為是Java接口定義，所以可以很簡單找到對應(yīng)的跳轉(zhuǎn)方法，參數(shù)定義也很明確，可以直接寫在接口定義處，方便查閱。
• 同樣因為是Java接口定義，那么如果需要擴展參數(shù)，只能重新定義新方法，這樣會出現(xiàn)多個方法重載，如果在原先接口上修改，對應(yīng)的原先調(diào)用方也要做響應(yīng)的修改，比較麻煩。上面是兩種實現(xiàn)方式，如果有相應(yīng)同學(xué)要實現(xiàn)模塊化，可以根據(jù)實際情況做出選擇。

Interface和Implement

如上分析，如果需要從某個業(yè)務(wù)中獲取數(shù)據(jù)，我們分別需要定義接口以及實現(xiàn)類，然在獲取的時候在通過反射來實例化對象。

下面是簡單的代碼示例

接口定義

public interface IUserService { 
 
    String getUserName(); 
} 

 實現(xiàn)類

class UserServiceImpl implements IUserService { 
 
    @Override 
    public String getUserName() { 
        return "UserServiceImpl.getUserName"; 
    } 
} 

反射生成對象

public class InjectHelper { 
 
    @NonNull 
    public static AppContext getAppContext() { 
        return AppContext.getAppContext(); 
    } 
 
    @NonNull 
    public static IModuleConfig getIModuleConfig() { 
        return getAppContext().getModuleConfig(); 
    } 
 
    @Nullable 
    public static <T> T getInstance(Class<T> tClass) { 
        IModuleConfig config = getIModuleConfig(); 
        Class<? extends T> implementClass = config.getServiceImplementClass(tClass); 
        if (implementClass != null) { 
            try { 
                return implementClass.newInstance(); 
            } catch (Exception e) { 
                e.printStackTrace(); 
            } 
        } 
        return null; 
    } 
}  

實際調(diào)用

IUserService userService = InjectHelper.getInstance(IUserService.class); 
 if (userService != null) { 
     Toast.makeText(getContext(), userService.getUserName(), Toast.LENGTH_SHORT).show(); 
 }  

本示例中每次調(diào)用都是用反射生成新的對象，實際應(yīng)用中可能與IoC工具結(jié)合使用，比如Dagger2.

EventBus

針對上面的第三個問題，原先設(shè)計的使用方式也是可以的，只需要把回調(diào)接口定義到對應(yīng)的service接口中，然后調(diào)用方就可以使用。

但是我建議可以使用另外一個方式——EventBus，EventBus也是利用觀察者模式，對事件進行監(jiān)聽，是設(shè)置回調(diào)更優(yōu)雅方式的實現(xiàn)。

優(yōu)點：不需要定義很多個回調(diào)接口，只需要定義事件Class，然后通過Claas的***性來進行事件匹配。

缺點：需要定義很多額外的類來表示事件，同時也需要關(guān)注EventBus的生命周期，在不需要使用事件時候，需要注銷事件綁定，不然容易發(fā)生內(nèi)存泄漏。