组件化项目的Java代码混淆方案采用在集成模式下集中在app壳工程中混淆，各个业务组件不配置混淆文件，原因有以下几点：

1，组件在集成模式下都被 Gradle 构建成了 release 类型的aar包，一旦业务组件的代码被混淆，而这时候代码中又出现了bug，将很难根据日志找出导致bug的原因，各个业务组件的混淆配置规则都应该在app壳工程中的混淆配置文件中添加和修改。

2，每个业务组件中都保留一份混淆配置文件非常不便于修改和管理，这也是不推荐在业务组件的 build.gradle 文件中配置 buildTypes （构建类型）的原因。

组件化和模块化的本质思想都是为了代码的重用和业务的解耦。区别在于模块化是业务导向，组件化是功能导向。

EventBus2.0使用的是运行时注解（依赖于Java的反射规则，会对性能产生一定的影响）

EventBus3.0使用的是编译时注解（提供AP注解器，在编译期间通过读取@Subscribe()注解并解析，处理其中所包含的信息，然后生成Java类来保存所有订阅者关于订阅的信息）

RxBus使用了静态内部类的单例，由于内部静态类只会被加载一次，所以实现方式是线程安全的，比double check + volatile方式加载更加优雅。

组件化通信方式：

使用隐式跳转/使用包名+类名跳转(setClassName,setComponentname)

路由跳转通过url索引，无需依赖，用注解来注册，路由使用AOP切面编程可以进行控制跳转的过滤，其非常适合组件化解耦。

路由的跳转实际上还是调用了startActivity的跳转，使用了原生的Framework机制，只是通过apt注解的形式制造出跳转规则，并人为的拦截跳转和设置跳转条件。

路由：实现跳转和拦截过滤。

现在开源软件有不少路由结构：如DeepLinkDispatch,OkDeepLink,ARouter

如果你的项目已经接入了Rxjava，考量兼容性，首推OkDeepLink路由框架。OkDeepLink就是借鉴了Retrofit的接口处理设计，OkDeepLink对跳转之后的回退会返回一个Observable的对象，可以无缝接入Rxjava。

getDeclaredMethod()获取的是类自身声明的所有方法，包含private,protected和Public方法。

构造方法无法调用父类的任何构造方法。（这句话是放在反射里去理解的）

getConstructor()/getDeclaredConstructor()

反射创建一个对象，可以使用Class.newInstance()和Constructor.newInstance()，一般建议使用后者。

反射简化：jOOR反射框架，非常轻量，并且内部封装好了异常抛出，让代码编写更加优雅。并且支持动态代理。

对于追求APP秒开体验的需求，可以通过RxJava简单地使用非UI线程实现，减少对UI线程的组赛，这种初始化操作尽量是非UI的操作。

空类索引不太明白？P45

组件化架构

results matching ""