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

[TOC]

模塊化場景

為什么需要模塊化?

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

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

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

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

架構(gòu)演變

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

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

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

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

 

 

技術(shù)要點(diǎn)

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

Library module

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

如圖所示，我把各個(gè)模塊單獨(dú)分為一個(gè)獨(dú)立的項(xiàng)目。

在主項(xiàng)目中使用gradle添加代碼依賴。

 

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

Library module開發(fā)問題

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

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

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

解決方案有下面幾種：

1. 重新一個(gè)Gradle插件，生成一個(gè)R2.java文件，這個(gè)文件中各個(gè)id都是靜態(tài)常量，這樣就可以正常使用了。
2. 使用Android系統(tǒng)提供的最原始的方式，直接用 findViewById 以及 setOnClickListener 方式。
3. 設(shè)置項(xiàng)目支持Databinding，然后使用Binding中的對(duì)象，但是會(huì)增加不少方法數(shù)，同時(shí)Databinding也會(huì)有編譯問題和學(xué)習(xí)成本，但是這些也是小問題，個(gè)人覺的問題不大。

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

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

依賴管理

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

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

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

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

舉個(gè)例子，比如進(jìn)行某一版本迭代，這個(gè)版本叫1.0.0，那么各個(gè)模塊的版本也叫同樣的版本，當(dāng)版本完成測(cè)試發(fā)布后，對(duì)各個(gè)模塊打?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' 

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

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

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

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

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

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

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

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

頁面路由跳轉(zhuǎn)

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

 

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

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

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

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

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

例如：

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

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

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

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

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

Router方式:

• 有點(diǎn)：不需要高難度的技術(shù)點(diǎn)，使用方便，直接使用字符串定義跳轉(zhuǎn)，可以好的往后兼容
• 缺點(diǎn)：因?yàn)槭褂玫氖亲址渲?，如果字符輸入字符，則很難發(fā)現(xiàn)bug，同時(shí)也很難知道某個(gè)參數(shù)對(duì)應(yīng)的含義

仿Retrofit方式:

• 因?yàn)槭荍ava接口定義，所以可以很簡單找到對(duì)應(yīng)的跳轉(zhuǎn)方法，參數(shù)定義也很明確，可以直接寫在接口定義處，方便查閱。
• 同樣因?yàn)槭荍ava接口定義，那么如果需要擴(kuò)展參數(shù)，只能重新定義新方法，這樣會(huì)出現(xiàn)多個(gè)方法重載，如果在原先接口上修改，對(duì)應(yīng)的原先調(diào)用方也要做響應(yīng)的修改，比較麻煩。

上面是兩種實(shí)現(xiàn)方式，如果有相應(yīng)同學(xué)要實(shí)現(xiàn)模塊化，可以根據(jù)實(shí)際情況做出選擇。

Interface和Implement

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

下面是簡單的代碼示例

接口定義

 

public interface IUserService { 
 
    String getUserName(); 
} 

實(shí)現(xiàn)類

 

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

反射生成對(duì)象

 

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; 
    } 
} 

實(shí)際調(diào)用

 

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

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

EventBus

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

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

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

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

映射匹配

上面的介紹的各個(gè)模塊之間通信，都運(yùn)涉及到映射匹配問題，在此我總結(jié)了一下，主要涉及到一下三種方式。

Map register

Map register是這樣的，全局定義一個(gè)Map，各個(gè)模塊在初始化的時(shí)候，分別在初始化的時(shí)候注冊(cè)映射關(guān)系。

下面是簡單的代碼示例，比如我們定義一個(gè)模塊生命周期，用于初始化各個(gè)模塊。

 

public interface IModuleLifeCycle { 
 
    void onCreate(IModuleConfig config); 
 
    void onTerminate(); 
} 

User模塊初始化

 

public class UserModuleLifeCycle extends SimpleModuleLifeCycle { 
 
    public UserModuleLifeCycle(@NonNull Application application) { 
        super(application); 
    } 
 
    @Override 
    public void onCreate(@NonNull IModuleConfig config) { 
        config.registerService(IUserService.class, UserServiceImpl.class); 
        config.registerRouter("app://user", UserActivity.class); 
    } 
} 

在Application中完成初始化

 

public class AppContext extends Application { 
 
    private ModuleLifeCycleManager lifeCycleManager; 
 
    @Override 
    public void onCreate() { 
        super.onCreate(); 
 
        lifeCycleManager = new ModuleLifeCycleManager(this); 
        lifeCycleManager.onCreate(); 
    } 
 
    @Override 
    public void onTerminate() { 
        super.onTerminate(); 
 
        lifeCycleManager.onTerminate(); 
    } 
 
    @NonNull 
    public IModuleConfig getModuleConfig() { 
        return lifeCycleManager.getModuleConfig(); 
    } 
} 
 
public class ModuleLifeCycleManager { 
 
    @NonNull 
    private ModuleConfig moduleConfig; 
    @NonNull 
    private final List<IModuleLifeCycle> moduleLifeCycleList; 
 
    ModuleLifeCycleManager(@NonNull Application application) { 
        moduleConfig = new ModuleConfig(); 
        moduleLifeCycleList = new ArrayList<>(); 
        moduleLifeCycleList.add(new UserModuleLifeCycle(application)); 
        moduleLifeCycleList.add(new OrderModuleLifeCycle(application)); 
        moduleLifeCycleList.add(new ShoppingModuleLifeCycle(application)); 
    } 
 
    void onCreate() { 
        for (IModuleLifeCycle lifeCycle : moduleLifeCycleList) { 
            lifeCycle.onCreate(moduleConfig); 
        } 
    } 
 
    void onTerminate() { 
        for (IModuleLifeCycle lifeCycle : moduleLifeCycleList) { 
            lifeCycle.onTerminate(); 
        } 
    } 
 
    @NonNull 
    IModuleConfig getModuleConfig() { 
        return moduleConfig; 
    } 
} 

APT

使用注解的方式配置映射信息，然后生成一個(gè)類似Database一樣的文件，然后Database文件中包含一個(gè)Map字段，Map中記錄各個(gè)映射信息。

首先需要定義個(gè)Annotation。

如：

 

@Target(ElementType.TYPE) 
@Retention(RetentionPolicy.CLASS) 
public @interface Implements { 
 
    Class parent(); 
} 

需要實(shí)現(xiàn)一個(gè) Annotation Process Tool，來解析自己定義的Annotation。

代碼略，此代碼有點(diǎn)復(fù)雜，暫時(shí)不貼了。

編譯產(chǎn)生的文件，大概如下所示。

 

public class Implement_$$_Database { 
 
    @NonNull 
    private final Map<Class<?>, Class<?>> serviceConfig; 
 
    public Implement_$$_Database() { 
 
        serviceConfig = new HashMap<>(); 
        serviceConfig.put(IUserService.class, UserServiceImpl.class); 
    } 
 
    public <T> Class<? extends T> getServiceImplementClass(Class<T> serviceClass) { 
        return (Class<? extends T>) serviceConfig.get(serviceClass); 
    } 
} 

然后利用反射找到 Implement_$$_Database 這個(gè)類，然后從方法中找到配對(duì)。

 

public class InjectHelper { 
 
    @Nullable 
    public static <T> T getInstanceByDatabase(Class<T> tClass) { 
        Implement_$$_Database database = new Implement_$$_Database(); 
        Class<? extends T> implementClass = database.getServiceImplementClass(tClass); 
        if (implementClass != null) { 
            try { 
                return implementClass.newInstance(); 
            } catch (Exception e) { 
                e.printStackTrace(); 
            } 
        } 
        return null; 
    } 
} 

然后在需要配置的地方添加注解即可。

 

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

調(diào)用姿勢(shì)。

 

binding.button.setOnClickListener(new View.OnClickListener() { 
        @Override 
        public void onClick(View v) { 
            IUserService userService = InjectHelper.getInstanceByDatabase(IUserService.class); 
            if (userService != null) { 
                Toast.makeText(getContext(), userService.getUserName(), Toast.LENGTH_SHORT).show(); 
            } 
        } 
    }); 

注意點(diǎn)：

有時(shí)候，在生成最終的配置文件的時(shí)候，文件的名字是固定的，比如上面的 Implement_$$_Database ,最終的路徑是這樣的 cn.mycommons.implements.database.Implement_$$_Database.java ，然后通過編譯到apk中或則是aar中。

但是有個(gè)問題，如果各個(gè)子模塊都使用了這樣的插件，那么每個(gè)子模塊的就會(huì)有這個(gè)Implement_$$_Database.class，那么就會(huì)編譯出錯(cuò)。

因?yàn)閍ar中包含的時(shí)候class文件，不是java文件，不能在使用APT做處理了。下面有2中解決方案。

1. 子工程的插件生成的文件包含一定的規(guī)則，比如包含模塊名字，如 User_Implement_$$_Database.java ，同時(shí)修改編譯過程，把java文件也打包到aar中，主工程的插件在編譯時(shí)候，提取aar中的文件，然后合并子工程的所有的代碼，這個(gè)思路是可行的，不過技術(shù)實(shí)現(xiàn)起來比較麻煩。
2. 同一的方式類似，也是生成有一定規(guī)則的的文件，或者在特地package下生成class，這些class再通過接下來的所講的Gradle Transform方式，生成一個(gè)新的Database.class文件。

Gradle Transform

這是Android Gradle編譯提供的一個(gè)接口，可以供開發(fā)自定義一些功能，而我們就可以根據(jù)這個(gè)功能生成映射匹配，這種方式和APT類似，APT是運(yùn)行在代碼編譯時(shí)期，而且Transform是直接掃描class，然后再生成新的class，class中包含Map映射信息。修改class文件，使用的是 javassist 一個(gè)第三方庫。

下面簡單講述代碼實(shí)現(xiàn)，后面有機(jī)會(huì)單獨(dú)寫一篇文章講解。

首先定義一個(gè)注解，這個(gè)注解用于標(biāo)注一個(gè)實(shí)現(xiàn)類的接口。

 

package cn.mycommons.modulebase.annotations; 
 
@Target(ElementType.TYPE) 
@Retention(RetentionPolicy.CLASS) 
public @interface Implements { 
    Class parent(); 
} 

一個(gè)測(cè)試用的接口以及實(shí)現(xiàn)類。

 

public interface ITest { 
} 
 
 
@Implements(parent = ITest.class) 
public class TestImpl implements ITest { 
 
} 

定義一個(gè)靜態(tài)方法，用于獲取某個(gè)接口的實(shí)現(xiàn)類。

 

package cn.mycommons.modulebase.annotations;  
public class ImplementsManager {  
    private static final Map<Class, Class> CONFIG = new HashMap<>();  
    public static Class getImplementsClass(Class parent) { 
        return CONFIG.get(parent); 
    } 
} 

如果不使用任何黑科技，直接使用Java技術(shù)，那么在定義時(shí)候需要主動(dòng)的往CONFIG這個(gè)map中添加配置，但是這里我們利用transform，直接動(dòng)態(tài)的添加。

定義一個(gè) ImplementsPlugin gradle插件。

 

public class ImplementsPlugin implements Plugin<Project> { 
 
    @Override 
    public void apply(Project project) { 
        AppExtension app = project.getExtensions().getByType(AppExtension.class); 
        app.registerTransform(new ImplementsTransform(project)); 
    } 
} 

自定義的Transform實(shí)現(xiàn)。

 

public class ImplementsTransform extends Transform { 
 
    static final String IMPLEMENTS_MANAGER = "cn/mycommons/modulebase/annotations/ImplementsManager.class" 
    static final String IMPLEMENTS_MANAGER_NAME = "cn.mycommons.modulebase.annotations.ImplementsManager" 
    Project project 
 
    ImplementsTransform(Project project) { 
        this.project = project 
    } 
 
    void log(String msg, Object... args) { 
        String text = String.format(msg, args) 
 
        project.getLogger().error("[ImplementsPlugin]:${text}") 
    } 
 
    @Override 
    public String getName() { 
        return "ImplementsTransform" 
    } 
 
    @Override 
    public Set<QualifiedContent.ContentType> getInputTypes() { 
        return ImmutableSet.of(QualifiedContent.DefaultContentType.CLASSES) 
    } 
 
    @Override 
    public Set<? super QualifiedContent.Scope> getScopes() { 
        return ImmutableSet.of( 
                QualifiedContent.Scope.PROJECT, 
                QualifiedContent.Scope.PROJECT_LOCAL_DEPS, 
                QualifiedContent.Scope.SUB_PROJECTS, 
                QualifiedContent.Scope.SUB_PROJECTS_LOCAL_DEPS, 
                QualifiedContent.Scope.EXTERNAL_LIBRARIES 
        ) 
    } 
 
    @Override 
    boolean isIncremental() { 
        return false 
    } 
 
    @Override 
    void transform(TransformInvocation transformInvocation) 
            throws TransformException, InterruptedException, IOException { 
        super.transform(transformInvocation) 
        long time1 = System.currentTimeMillis(); 
        log(this.toString() + ".....transform") 
 
        TransformOutputProvider outputProvider = transformInvocation.outputProvider 
        outputProvider.deleteAll() 
 
        def classPool = new ClassPool() 
        classPool.appendSystemPath() 
 
        // 記錄所有的符合掃描條件的記錄 
        List<Entry> implementsList = [] 
        // ImplementsManager 注解所在的jar文件 
        JarInput implementsManagerJar = null 
 
        // 掃描所有的文件 
        transformInvocation.inputs.each { 
            it.directoryInputs.each { 
                classPool.appendClassPath(it.file.absolutePath) 
                def dst = outputProvider.getContentLocation(it.name, it.contentTypes, it.scopes, Format.DIRECTORY) 
                FileUtils.copyDirectory(it.file, dst) 
 
                project.fileTree(dst).each { 
                    String clazzPath = it.absolutePath.replace(dst.absolutePath, "") 
                    clazzPath = clazzPath.replace("/", ".").substring(1) 
                    if (clazzPath.endsWith(".class")) { 
                        clazzPath = clazzPath.substring(0, clazzPath.size() - 6) 
                        CtClass clazz = classPool.get(clazzPath) 
                        // 如果class中的類包含注解則先收集起來 
                        Implements annotation = clazz.getAnnotation(Implements.class) 
                        if (annotation != null) { 
                            implementsList.add(new Entry(annotation, clazz)) 
                        } 
                    } 
                } 
            } 
            it.jarInputs.each { 
                classPool.appendClassPath(it.file.absolutePath) 
 
                if (implementsManagerJar == null && isImplementsManager(it.file)) { 
                    implementsManagerJar = it 
                } else { 
                    def dst = outputProvider.getContentLocation(it.name, it.contentTypes, it.scopes, Format.JAR) 
                    FileUtils.copyFile(it.file, dst) 
 
                    def jarFile = new JarFile(it.file) 
                    def entries = jarFile.entries() 
 
                    // 如果jar中的class中的類包含注解則先收集起來 
                    while (entries.hasMoreElements()) { 
                        def jarEntry = entries.nextElement() 
                        String clazzPath = jarEntry.getName() 
                        clazzPath = clazzPath.replace("/", ".") 
                        if (clazzPath.endsWith(".class")) { 
                            clazzPath = clazzPath.substring(0, clazzPath.size() - 6) 
                            def clazz = classPool.get(clazzPath) 
                            Implements annotation = clazz.getAnnotation(Implements.class) 
                            if (annotation != null) { 
                                implementsList.add(new Entry(annotation, clazz)) 
                            } 
                        } 
                    } 
                } 
            } 
        } 
 
        log("implementsManagerJar = " + implementsManagerJar) 
 
        Map<String, String> config = new LinkedHashMap<>() 
 
        implementsList.each { 
            def str = it.anImplements.toString(); 
            log("anImplements =" + it.anImplements) 
            def parent = str.substring(str.indexOf("(") + 1, str.indexOf(")")).replace("parent=", "").replace(".class", "") 
            log("parent =" + parent) 
            log("sub =" + it.ctClass.name) 
 
            // 收集所有的接口以及實(shí)現(xiàn)類的路徑 
            config.put(parent, it.ctClass.name) 
        } 
 
        log("config = " + config) 
 
        long time2 = System.currentTimeMillis(); 
 
        if (implementsManagerJar != null) { 
            def implementsManagerCtClass = classPool.get(IMPLEMENTS_MANAGER_NAME) 
            log("implementsManagerCtClass = " + implementsManagerCtClass) 
 
            // 修改class，在class中插入靜態(tài)代碼塊，做初始化 
            def body = "{\n" 
            body += "CONFIG = new java.util.HashMap();\n" 
 
            for (Map.Entry<String, String> entry : config.entrySet()) { 
                body += "CONFIG.put(${entry.key}.class, ${entry.value}.class);\n" 
            } 
 
            body += "}\n" 
            log("body = " + body) 
 
            implementsManagerCtClass.makeClassInitializer().body = body 
 
            def jar = implementsManagerJar 
            def dst = outputProvider.getContentLocation(jar.name, jar.contentTypes, jar.scopes, Format.JAR) 
            println dst.absolutePath 
 
            // 修改完成后，完成后再寫入到j(luò)ar文件中 
            rewriteJar(implementsManagerJar.file, dst, IMPLEMENTS_MANAGER, implementsManagerCtClass.toBytecode()) 
        } 
 
        log("time = " + (time2 - time1) / 1000) 
    } 
 
    static boolean isImplementsManager(File file) { 
        return new JarFile(file).getEntry(IMPLEMENTS_MANAGER) != null 
    } 
 
    static void rewriteJar(File src, File dst, String name, byte[] bytes) { 
        dst.getParentFile().mkdirs() 
 
        def jarOutput = new JarOutputStream(new FileOutputStream(dst)) 
        def rcJarFile = new JarFile(src) 
 
        jarOutput.putNextEntry(new JarEntry(name)) 
        jarOutput.write(bytes) 
 
        def buffer = new byte[1024] 
        int bytesRead 
        def entries = rcJarFile.entries() 
 
        while (entries.hasMoreElements()) { 
            def entry = entries.nextElement() 
            if (entry.name == name) continue 
            jarOutput.putNextEntry(entry) 
 
            def jarInput = rcJarFile.getInputStream(entry) 
            while ((bytesRead = jarInput.read(buffer)) != -1) { 
                jarOutput.write(buffer, 0, bytesRead) 
            } 
            jarInput.close() 
        } 
 
        jarOutput.close() 
    } 
} 

映射匹配總結(jié)

優(yōu)點(diǎn):

• Map:簡單明了，很容易入手，不會(huì)對(duì)編譯時(shí)間產(chǎn)生任何影響，不會(huì)隨著Gradle版本的升級(jí)而受影響，代碼混淆時(shí)候不會(huì)有影響，無需配置混淆文件。
• APT：使用簡單，使用注解配置，代碼優(yōu)雅，原理是用代碼生成的方式生成新的文件。
• Transform：使用簡單，使用注解配置，代碼優(yōu)雅，原理是用代碼生成的方式生成新的文件，不過生成的文件的時(shí)期和APT不同，會(huì)編譯時(shí)間產(chǎn)生少許影響。

缺點(diǎn):

• Map：在需要新添加映射的時(shí)候，需要手動(dòng)添加，不然不會(huì)生效，代碼不優(yōu)雅。
• APT：在編譯時(shí)期生成文件，會(huì)編譯時(shí)間產(chǎn)生少許影響，同時(shí)在不同的Gradle的版本中可能會(huì)產(chǎn)生錯(cuò)誤或者兼容問題。需要配置混淆設(shè)置，不然會(huì)丟失文件。技術(shù)實(shí)現(xiàn)復(fù)雜，較難維護(hù)。
• Transform：在編譯時(shí)期生成文件，會(huì)編譯時(shí)間產(chǎn)生少許影響，同時(shí)在不同的Gradle的版本中可能會(huì)產(chǎn)生錯(cuò)誤或者兼容問題。需要配置混淆設(shè)置，不然會(huì)丟失文件。技術(shù)實(shí)現(xiàn)復(fù)雜，較難維護(hù)。

從技術(shù)復(fù)雜性以及維護(hù)性來看，Map > APT = Transform

從使用復(fù)雜性以及代碼優(yōu)雅性來看，Transform > APT > Map

開發(fā)調(diào)試技巧

Debug

上面介紹了很多關(guān)于模塊化的概念以及技術(shù)難題，當(dāng)模塊化完成以后，再進(jìn)行完成開發(fā)時(shí)候還是會(huì)遇到不少問題。不如原先代碼在一起的時(shí)候很方便的進(jìn)行代碼調(diào)試。但是進(jìn)行模塊化以后，直接使用的是aar依賴，不能直接修改代碼，可以使用下面技巧，可以直接進(jìn)行代碼調(diào)試。

在根目錄下面創(chuàng)建一個(gè)module目錄以及module.gradle文件，這個(gè)目錄和文件是git ignore的，然后把對(duì)應(yīng)的模塊代碼clone到里面，根目錄的setting.gradlew apply module.gradle文件，如下所示，如果需要源碼調(diào)試，則在module中添加對(duì)應(yīng)的模塊。然后在app的依賴中去掉aar依賴，同時(shí)添加項(xiàng)目依賴即可。當(dāng)不需要源碼調(diào)試好，再修改為到原先代碼即可。

 

try { 
    apply from: "./module.gradle" 
} catch (e) { 
} 

module.gradle

include ':ModuleShopping' 

比如調(diào)試shopping模塊

 

// 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' 
    compile project(':ModuleShopping') 

當(dāng)然還有個(gè)更具技術(shù)挑戰(zhàn)性方案，使用gradle插件的形式，如果發(fā)現(xiàn)root項(xiàng)目中包含的模塊化的源碼，則不適用aar依賴，直接使用源碼依賴，當(dāng)然這個(gè)想法是不錯(cuò)的，不過具有技術(shù)挑戰(zhàn)性，同時(shí)有可能隨著Gradle版本的升級(jí)，編寫的gradle插件也要做相對(duì)于的兼容風(fēng)險(xiǎn)，這是只是簡單提示一下。

容器設(shè)計(jì)

上面講到的如果要調(diào)試代碼時(shí)候，需要完整的運(yùn)行的整個(gè)項(xiàng)目，隨著項(xiàng)目的增大，編譯時(shí)間可能變得很長。

我們可以做一個(gè)簡單的，類似與主app模塊一樣，比如我是負(fù)責(zé)user模塊的開發(fā)者，那么我只要調(diào)試我這個(gè)模塊就行了，如果需要其他的模塊，我可以簡單的做一個(gè)mock，不是把其他的模塊直接依賴過來，這樣可以做到調(diào)試作用。等到再需要完整項(xiàng)目調(diào)試時(shí)候，我們?cè)谑褂蒙厦娼榻B的方式，這樣可以節(jié)省不少開發(fā)時(shí)間。

還有一種實(shí)現(xiàn)調(diào)試的方式，比如上面的user模塊，目錄下面的build.gradle文件是這樣的

 

apply plugin: 'com.android.library'  
xxx 
xxx 

我們可以在gradle.properties中設(shè)置編譯變參數(shù)isLibModule，當(dāng)需要完整調(diào)試好，設(shè)置為 isLibModule=false ，這樣我這個(gè)子模塊就是一個(gè) apply plugin: 'com.android.application' 這樣的模塊，是可以單獨(dú)運(yùn)行的一個(gè)項(xiàng)目

 

try { 
    if (isLibModule) { 
        apply from: "./build_lib.gradle" 
    }else{ 
        apply from: "./build_app.gradle" 
    } 
} catch (e) { 
} 

可能有時(shí)候還是需要單獨(dú)的運(yùn)行環(huán)境，android編譯方式有2中，一種是debug，一種是release。當(dāng)打包成aar的時(shí)候，使用的是release方式，我們可以把需要調(diào)試的代碼全部放到debug中，這樣打包的時(shí)候就不會(huì)把調(diào)試的文件發(fā)布到aar中。不過這種實(shí)現(xiàn)方式，需要對(duì)Android項(xiàng)目的目錄有較高的認(rèn)識(shí)，才可以熟練使用。

CI

上面介紹的各個(gè)模塊需要單獨(dú)到獨(dú)立的git倉庫，同時(shí)打包到單獨(dú)的maven倉庫，當(dāng)開發(fā)完成后，這時(shí)候就需要進(jìn)行打包，但這個(gè)是一個(gè)簡單和重復(fù)的事情，所以我們需要一個(gè)工具來完成這些事情，我們可以利用CI系統(tǒng)來搞定這件事情，這里我推薦Jenkins，主流廠商使用jenkins作為CI服務(wù)器這個(gè)方案。

具體的步驟就是，需要對(duì)每個(gè)模塊的git倉庫做web hook，我們公司使用的是git lab，可以對(duì)git的各種操作做hook，比如push，merge，tag等。

當(dāng)代碼發(fā)送了變化了，我們可以發(fā)送事件到CI服務(wù)器，CI服務(wù)器再對(duì)各個(gè)事件做處理，比如user模塊develop分支有代碼變化，這個(gè)變化可能是merge，也有可能是push。我們可以把主項(xiàng)目代碼和user項(xiàng)目的代碼單獨(dú)clone下拉，然后編譯一下，確認(rèn)是否有編譯問題，如果有編譯通過，那么在使用相關(guān)gradle命令發(fā)布到maven倉庫中。

不管每次編譯結(jié)果怎樣，是成功還是失敗，我們都應(yīng)該把結(jié)果回饋給開發(fā)者，常見的方式是郵件，不過這個(gè)信息郵件方式可能很頻繁，我們建議使用slack。

總結(jié)

模塊化架構(gòu)主要思路就是分而治之，把依賴整理清楚，減少代碼冗余和耦合，在把代碼抽取到各自的模塊后，了解各個(gè)模塊的通信方式，以及可能發(fā)生的問題，規(guī)避問題或者解決問題。***為了開發(fā)和調(diào)試方便，開發(fā)一些周邊工具，幫助開發(fā)更好的完成任務(wù)。