關於Android模塊化我有一些話不知當講不當講
最近公司一個項目使用了模塊化設計，本人參與其中的一個小模塊開發，但是整體的設計並不是我架構設計的，開發半年有余，在此記錄下來我的想法。
關於Android模塊化我有一些話不知當講不當講
模塊化場景
架構演變
技術要點
Library module
Library module開發問題
依賴管理
數據通信
頁面路由跳轉
Interface和Implement
EventBus
映射匹配
Map register
APT
Gradle Transform
映射匹配總結
開發調試技巧
Debug
容器設計
CI
總結
相關資料
模塊化場景
為什么需要模塊化？
當一個App用戶量增多，業務量增長以后，就會有很多開發工程師參與同一個項目，人員增加了，原先小團隊的開發方式已經不合適了。
原先的一份代碼，現在需要多個人來維護，每個人的代碼質量也不相同，在進行代碼Review的時候，也是比較困難的，同時也容易會產生代碼沖突的問題。
同時隨着業務的增多，代碼變的越來越復雜，每個模塊之間的代碼耦合變得越來越嚴重，解耦問題急需解決，同時編譯時間也會越來越長。
人員增多，每個業務的組件各自實現一套，導致同一個App的UI風格不一樣，技術實現也不一樣，團隊技術無法得到沉淀。
架構演變
在剛剛開始的時候，項目架構使用的是MVP模式，這也是最近幾年很流行的一個架構方式，下面是項目的原始設計。
MVP
隨着業務的增多，我們添加了Domain的概念，Domain從Data中獲取數據，Data可能會是Net，File，Cache各種IO等，然后項目架構變成了這樣。
MVP2
再然后隨着人員增多，各種基礎組件也變的越來越多，業務也很復雜，業務與業務之間還有很強的耦合，就變成了這樣的。
使用模塊化技術以后，架構變成了這樣。
組件化架構
技術要點
這里簡單介紹下Android項目實現模塊化需要使用的技術以及技術難點。
Library module
在開始開始進行模塊化之前，需要把各個業務單獨抽取成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')
1
2
3
4
5
6
7
8
9
Library module開發問題
在把代碼抽取到各個單獨的Library Module中，會遇到各種問題。最常見的就是R文件問題，Android開發中，各個資源文件都是放在res目錄中，在編譯過程中，會生成R.java文件。R文件中包含有各個資源文件對應的id，這個id是靜態常量，但是在Library Module中，這個id不是靜態常量，那么在開發時候就要避開這樣的問題。
舉個常見的例子，同一個方法處理多個view的點擊事件，有時候會使用switch(view.getId())這樣的方式，然后用case R.id.btnLogin這樣進行判斷，這時候就會出現問題，因為id不是經常常量，那么這種方式就用不了。
同樣開發時候，用的最多的一個第三方庫就是ButterKnife，ButterKnife也是不可以用的，在使用ButterKnife的時候，需要用到注解配置一個id來找到對應view，或者綁定對應的各種事件處理，但是注解中的各個字段的賦值也是需要靜態常量，那么就不能夠使用ButterKnife了。
解決方案有下面幾種：
1.重新一個Gradle插件，生成一個R2.java文件，這個文件中各個id都是靜態常量，這樣就可以正常使用了。
2.使用Android系統提供的最原始的方式，直接用findViewById以及setOnClickListener方式。
3.設置項目支持Databinding，然后使用Binding中的對象，但是會增加不少方法數，同時Databinding也會有編譯問題和學習成本，但是這些也是小問題，個人覺的問題不大。
上面是主流的解決方法，個人推薦的使用優先級為 3 > 2 > 1。
當把個模塊分開以后，每個人就可以單獨分組對應的模塊就行了，不過會有資源沖突問題，個人建議是對各個模塊的資源名字添加前綴，比如user模塊中的登錄界面布局為activity_login.xml，那么可以寫成這樣us_activity_login.xml。這樣就可以避免資源沖突問題。同時Gradle也提供的一個字段resourcePrefix，確保各個資源名字正確，具體用法可以參考官方文檔。
依賴管理
當完成了Library module后，代碼基本上已經很清晰了，跟我們上面的最終架構已經很相似了，有了最基本的骨架，但是還是沒有完成，因為還是多個人操作同一個git倉庫，各個開發小伙伴還是需要對同一個倉庫進行各種fork和pr。
隨着對代碼的分割，但是主項目app的依賴變多了，如果修改了lib中的代碼，那么編譯時間是很恐怖的，大概統計了一下，原先在同一個模塊的時候，編譯時間大概需要2-3min，但是分開以后大概需要5-6min，這個是絕對無法忍受的。
上面的第一問題，可以這樣解決，把各個子module分別使用單獨的一個git倉庫，這樣每個人也只需要關注自己需要的git倉庫即可，主倉庫使用git submodule的方式，分別依賴各個子模塊。
但是這樣還是無法解決編譯時間過長的問題，我們把各個模塊也單獨打包，每次子模塊開發完成以后，發布到maven倉庫中，然后在主項目中使用版本進行依賴。
舉個例子，比如進行某一版本迭代，這個版本叫1.0.0，那么各個模塊的版本也叫同樣的版本，當版本完成測試發布后，對各個模塊打對應版本的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'
1
2
3
4
5
6
7
8
9
可能有人會問，既然各個模塊已經分開開發，那么如果進行開發聯調，別急，這個問題暫時保留，后面會對這個問題后面再表。
數據通信
當一個大項目拆成若干小項目時候，調用的姿勢發生了少許改變。我這邊總結了App各個模塊之間的數據通信幾種方式。
頁面跳轉，比如在訂單頁面下單時候，需要判斷用戶是否登錄，如果沒有則需要跳到登錄界面。
主動獲取數據，比如在下單時候，用戶已經登錄，下單需要傳遞用戶的基本信息。
被動獲得數據，比如在切換用戶的時候，有時候需要更新數據，如訂單頁面，需要把原先用戶的購物車數據給清空。
再來看下App的架構。
App架構
第一個問題，原先的方式，直接指定某個頁面的ActivityClass，然后通過intent跳轉即可，但是在新的架構中，由於shopping模塊不直接依賴user，那么則不能使用原始的進行跳轉，我們解決方式使用Router路由跳轉。
第二個問題，原先的方式有個專門的業務單利，比如UserManager，直接可以調用即可，同樣由於依賴發生了改變，不能夠進行調用。解決方案是所有的需要的操作，定義成接口放在Service中。
第三個問題，原先的方式，可以針對事件變化提供回調接口，當我需要監聽某個事件時候，設置回調即可。
頁面路由跳轉
如上分析，原先方式代碼如下。
Intent intent = new Intent(this, UserActivity.class);
startActivity(intent);
1
2
但是使用Router后，調用方式改變了。
RouterHelper.dispatch(getContext(), "app://user");
1
具體的原理是什么，很簡單的，做一個簡單的映射匹配即可，把"app://user"與UserActivity.class配對，具體的就是定義一個Map，key是對應的Router字符，value是Activity的class。在跳轉時候從map中獲取對應的ActivityClass，然后在使用原始的方式。
可能有人的會問，要向另外一個頁面傳遞參數怎么辦，沒事我們可以在router后面直接添加參數，如果是一個復雜的對象那么可以把對象序列化成json字符串，然后再從對應的頁面通過反序列化的方式，得到對應的對象。
例如：
RouterHelper.dispatch(getContext(), "app://user?id=123&obj={"name":"admin"}");
1
注： 上面的router中json字符串是需要url編碼的，不然會有問題的，這里只是做個示例。
除了使用Router進行跳轉外，我想了一下，可以參考Retrofit方式，直接定義跳轉Java接口，如果需要傳遞額外參數，則以函數參數的方式定義。
這個Java接口是沒有實現類的，可以使用動態代理方式，然后接下來的方式，和使用Router的方式一樣。
那么這總兩種方式有什么優缺點呢。
Router方式:
有點：不需要高難度的技術點，使用方便，直接使用字符串定義跳轉，可以好的往后兼容
缺點：因為使用的是字符串配置，如果字符輸入字符，則很難發現bug，同時也很難知道某個參數對應的含義
仿Retrofit方式:
因為是Java接口定義，所以可以很簡單找到對應的跳轉方法，參數定義也很明確，可以直接寫在接口定義處，方便查閱。
同樣因為是Java接口定義，那么如果需要擴展參數，只能重新定義新方法，這樣會出現多個方法重載，如果在原先接口上修改，對應的原先調用方也要做響應的修改，比較麻煩。
上面是兩種實現方式，如果有相應同學要實現模塊化，可以根據實際情況做出選擇。
Interface和Implement
如上分析，如果需要從某個業務中獲取數據，我們分別需要定義接口以及實現類，然在獲取的時候在通過反射來實例化對象。
下面是簡單的代碼示例
接口定義
public interface IUserService {
String getUserName();
}
1
2
3
4
實現類
class UserServiceImpl implements IUserService {
@Override
public String getUserName() {
return "UserServiceImpl.getUserName";
}
}
1
2
3
4
5
6
7
反射生成對象
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;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
實際調用
IUserService userService = InjectHelper.getInstance(IUserService.class);
if (userService != null) {
Toast.makeText(getContext(), userService.getUserName(), Toast.LENGTH_SHORT).show();
}
1
2
3
4
本示例中每次調用都是用反射生成新的對象，實際應用中可能與IoC工具結合使用，比如Dagger2.
EventBus
針對上面的第三個問題，原先設計的使用方式也是可以的，只需要把回調接口定義到對應的service接口中，然后調用方就可以使用。
但是我建議可以使用另外一個方式——EventBus，EventBus也是利用觀察者模式，對事件進行監聽，是設置回調更優雅方式的實現。
優點：不需要定義很多個回調接口，只需要定義事件Class，然后通過Claas的唯一性來進行事件匹配。
缺點：需要定義很多額外的類來表示事件，同時也需要關注EventBus的生命周期，在不需要使用事件時候，需要注銷事件綁定，不然容易發生內存泄漏。
映射匹配
上面的介紹的各個模塊之間通信，都運涉及到映射匹配問題，在此我總結了一下，主要涉及到一下三種方式。
Map register
Map register是這樣的，全局定義一個Map，各個模塊在初始化的時候，分別在初始化的時候注冊映射關系。
下面是簡單的代碼示例，比如我們定義一個模塊生命周期，用於初始化各個模塊。
public interface IModuleLifeCycle {
void onCreate(IModuleConfig config);
void onTerminate();
}
1
2
3
4
5
6
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);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
在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(www.xuancayule.com) {
for (IModuleLifeCycle lifeCycle : moduleLifeCycleList) {
lifeCycle.onTerminate(www.yuheng119.com/);
}
}
@NonNull
IModuleConfig getModuleConfig() {
return moduleConfig;
APT
使用注解的方式配置映射信息，然后生成一個類似Database一樣的文件，然后Database文件中包含一個Map字段，Map中記錄各個映射信息。
首先需要定義個Annotation。
如：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.CLASS)
public @interface Implements {
Class parent();
需要實現一個 Annotation Process Tool，來解析自己定義的Annotation。
代碼略，此代碼有點復雜，暫時不貼了。
編譯產生的文件，大概如下所示。
public class Implement_$$_Database {
@NonNull
private final Map<Class<?>, Class<?>> serviceConfig;
public Implement_$$_Database(http://www.gouyily.cn/) {
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這個類，然后從方法中找到配對。
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(www.yigouyule2.cn/);
}
}
return null;
}
然后在需要配置的地方添加注解即可。
@Implements(parent = IUserService.class)
class UserServiceImpl implements IUserService {
@Override
public String getUserName() {
return "UserServiceImpl.getUserName";
調用姿勢。
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();
}
}
});
注意點：
有時候，在生成最終的配置文件的時候，文件的名字是固定的，比如上面的Implement_$$_Database,最終的路徑是這樣的cn.mycommons.implements.database.Implement_$$_Database.java，然后通過編譯到apk中或則是aar中。
但是有個問題，如果各個子模塊都使用了這樣的插件，那么每個子模塊的就會有這個Implement_$$_Database.class，那么就會編譯出錯。
因為aar中包含的時候class文件，不是java文件，不能在使用APT做處理了。下面有2中解決方案。
子工程的插件生成的文件包含一定的規則，比如包含模塊名字，如User_Implement_$$_Database.java，同時修改編譯過程，把java文件也打包到aar中，主工程的插件在編譯時候，提取aar中的文件，然后合並子工程的所有的代碼，這個思路是可行的，不過技術實現起來比較麻煩。
同一的方式類似，也是生成有一定規則的的文件，或者在特地package下生成class，這些class再通過接下來的所講的Gradle Transform方式，生成一個新的Database.class文件。
Gradle Transform
這是Android Gradle編譯提供的一個接口，可以供開發自定義一些功能，而我們就可以根據這個功能生成映射匹配，這種方式和APT類似，APT是運行在代碼編譯時期，而且Transform是直接掃描class，然后再生成新的class，class中包含Map映射信息。修改class文件，使用的是javassist一個第三方庫。
下面簡單講述代碼實現，后面有機會單獨寫一篇文章講解。
首先定義一個注解，這個注解用於標注一個實現類的接口。
package cn.mycommons.modulebase.annotations;
@Target(ElementType.TYPE www.22yigouyule.cn)
@Retention(RetentionPolicy.CLASS)
public @interface Implements {
Class parent();
一個測試用的接口以及實現類。
public interface ITest {
}
@Implements(parent = ITest.class)
public class TestImpl implements ITest {
定義一個靜態方法，用於獲取某個接口的實現類。
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技術，那么在定義時候需要主動的往CONFIG這個map中添加配置，但是這里我們利用transform，直接動態的添加。
定義一個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));
}
}
1
2
3
4
5
6
7
8
自定義的Transform實現。
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)
// 收集所有的接口以及實現類的路徑
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中插入靜態代碼塊，做初始化
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
// 修改完成后，完成后再寫入到jar文件中
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()
}
}
具體代碼可以參考這里
映射匹配總結
優點:
Map:簡單明了，很容易入手，不會對編譯時間產生任何影響，不會隨着Gradle版本的升級而受影響，代碼混淆時候不會有影響，無需配置混淆文件。
APT：使用簡單，使用注解配置，代碼優雅，原理是用代碼生成的方式生成新的文件。
Transform：使用簡單，使用注解配置，代碼優雅，原理是用代碼生成的方式生成新的文件，不過生成的文件的時期和APT不同，會編譯時間產生少許影響。
缺點:
Map：在需要新添加映射的時候，需要手動添加，不然不會生效，代碼不優雅。
APT：在編譯時期生成文件，會編譯時間產生少許影響，同時在不同的Gradle的版本中可能會產生錯誤或者兼容問題。需要配置混淆設置，不然會丟失文件。技術實現復雜，較難維護。
Transform：在編譯時期生成文件，會編譯時間產生少許影響，同時在不同的Gradle的版本中可能會產生錯誤或者兼容問題。需要配置混淆設置，不然會丟失文件。技術實現復雜，較難維護。
從技術復雜性以及維護性來看，Map > APT = Transform
從使用復雜性以及代碼優雅性來看，Transform > APT > Map
開發調試技巧
Debug
上面介紹了很多關於模塊化的概念以及技術難題，當模塊化完成以后，再進行完成開發時候還是會遇到不少問題。不如原先代碼在一起的時候很方便的進行代碼調試。但是進行模塊化以后，直接使用的是aar依賴，不能直接修改代碼，可以使用下面技巧，可以直接進行代碼調試。
在根目錄下面創建一個module目錄以及module.gradle文件，這個目錄和文件是git ignore的，然后把對應的模塊代碼clone到里面，根目錄的setting.gradlew apply module.gradle文件，如下所示，如果需要源碼調試，則在module中添加對應的模塊。然后在app的依賴中去掉aar依賴，同時添加項目依賴即可。當不需要源碼調試好，再修改為到原先代碼即可。
try {
apply from: "./module.gradle"
} catch (e) {
module.gradle
include ':ModuleShopping'
1
比如調試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'
當然還有個更具技術挑戰性方案，使用gradle插件的形式，如果發現root項目中包含的模塊化的源碼，則不適用aar依賴，直接使用源碼依賴，當然這個想法是不錯的，不過具有技術挑戰性，同時有可能隨着Gradle版本的升級，編寫的gradle插件也要做相對於的兼容風險，這是只是簡單提示一下。
容器設計
上面講到的如果要調試代碼時候，需要完整的運行的整個項目，隨着項目的增大，編譯時間可能變得很長。
我們可以做一個簡單的，類似與主app模塊一樣，比如我是負責user模塊的開發者，那么我只要調試我這個模塊就行了，如果需要其他的模塊，我可以簡單的做一個mock，不是把其他的模塊直接依賴過來，這樣可以做到調試作用。等到再需要完整項目調試時候，我們在使用上面介紹的方式，這樣可以節省不少開發時間。
還有一種實現調試的方式，比如上面的user模塊，目錄下面的build.gradle文件是這樣的
apply plugin: 'com.android.library'
xxx
我們可以在gradle.properties中設置編譯變參數isLibModule，當需要完整調試好，設置為isLibModule=false，這樣我這個子模塊就是一個apply plugin: 'com.android.application'這樣的模塊，是可以單獨運行的一個項目
try {
if (isLibModule) {
apply from: "./build_lib.gradle"
}else{
apply from: "./build_app.gradle"
}
} catch (e) {
}
可能有時候還是需要單獨的運行環境，android編譯方式有2中，一種是debug，一種是release。當打包成aar的時候，使用的是release方式，我們可以把需要調試的代碼全部放到debug中，這樣打包的時候就不會把調試的文件發布到aar中。不過這種實現方式，需要對Android項目的目錄有較高的認識，才可以熟練使用。
CI
上面介紹的各個模塊需要單獨到獨立的git倉庫，同時打包到單獨的maven倉庫，當開發完成后，這時候就需要進行打包，但這個是一個簡單和重復的事情，所以我們需要一個工具來完成這些事情，我們可以利用CI系統來搞定這件事情，這里我推薦Jenkins，主流廠商使用jenkins作為CI服務器這個方案。
具體的步驟就是，需要對每個模塊的git倉庫做web hook，我們公司使用的是git lab，可以對git的各種操作做hook，比如push，merge，tag等。
當代碼發送了變化了，我們可以發送事件到CI服務器，CI服務器再對各個事件做處理，比如user模塊develop分支有代碼變化，這個變化可能是merge，也有可能是push。我們可以把主項目代碼和user項目的代碼單獨clone下拉，然后編譯一下，確認是否有編譯問題，如果有編譯通過，那么在使用相關gradle命令發布到maven倉庫中。
不管每次編譯結果怎樣，是成功還是失敗，我們都應該把結果回饋給開發者，常見的方式是郵件，不過這個信息郵件方式可能很頻繁，我們建議使用slack。
總結
模塊化架構主要思路就是分而治之，把依賴整理清楚，減少代碼冗余和耦合，在把代碼抽取到各自的模塊后，了解各個模塊的通信方式，以及可能發生的問題，規避問題或者解決問題。最后為了開發和調試方便，開發一些周邊工具，幫助開發更好的完成任務。