Android组件化和插件化

组件化开发就是将一个app分成多个模块，每个模块都是一个组件（Module），开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等，但是最终发布的时候是将这些组件合并统一成一个apk

组件化优势：

稍微改动一个模块的一点代码都要编译整个工程，耗时耗力

公共资源、业务、模块混在一起耦合度太高，不方便测试

如何划分组件：

1.新建一个lib组件，new Module—>Andorid Library，取名BaseUtilLib，我们将所有的公共的工具类、网络分装等类放在其中

2.新建一个lib组件，BaseReslLib，我们将所有的公共资源、drawable、String等类放在其中

3.将app按照自己的规则划分成多个模块，比如按业务按地区等都可以

4.逐一开发某个模块，比如Test模块，新建一个TestApp组件，TestApp组件引用[1][2]步骤的BaseUtilLib和BaseReslLib，在TestApp组件里添加并引用TestLib组件。在TestLib的activity中写代码写业务逻辑，TestApp只负责跳转和测试

5.将工程中的所有类似TestLib组件（不是TestApp组件）引入到工程的app中 

插件化开发 和组件化开发略有不用，插件化开发时将整个app拆分成很多模块，这些模块包括一个宿主和多个插件，每个模块都是一个apk（组件化的每个模块是个lib），最终打包的时候将宿主apk和插件apk分开或者联合打包。

插件化：宿主和插件分开编译，并发开发，动态更新插件，按需下载模块

4.LeakCanary原理解析

检测原理

监听

在Android中，当一个Activity走完onDestroy生命周期后，说明该页面已经被销毁了，应该被系统GC回收。通过Application.registerActivityLifecycleCallbacks()方法注册Activity生命周期的监听，每当一个Activity页面销毁时候，获取到这个Activity去检测这个Activity是否真的被系统GC。

检测

当获取了待分析的对象后，需要确定这个对象是否产生了内存泄漏。

通过WeakReference + ReferenceQueue来判断对象是否被系统GC回收，WeakReference 创建时，可以传入一个 ReferenceQueue 对象。当被 WeakReference 引用的对象的生命周期结束，一旦被 GC 检查到，GC 将会把该对象添加到 ReferenceQueue 中，待ReferenceQueue处理。当 GC 过后对象一直不被加入 ReferenceQueue，它可能存在内存泄漏。

当我们初步确定待分析对象未被GC回收时候，手动触发GC，二次确认。