Android组件化架构（二）
项目多Module会带来一些问题，比如：如何在Module之间传递事件通知？不同的Module如何存储共享数据？权限请求如何更好的和组件化配合？
1.事件传递
关于组件之间事件传递，最容易想到的就是Android的原生组件---广播。当然无论是xml中注册广播还是动态注册广播，都会稍显麻烦。值得替代的方案是EventBus。在Base Module中引入EventBus，来传递事件。传递的Event如果放在BaseModule中不仅BaseModule会显得很臃肿，而且再次移植的时候会带来很多麻烦。所以值得参考的方案是将需要传递的事件放到EventModule 中。再在BaseModule中引入EventModule。结构如下：
架构
这样baseModule就可以更好的解耦。
2.保存到数据库
同样的道理，对于保存到数据库的内容，也采取相似的策略。将数据库的需要保存的内容单独的做一个Module，来解耦baseModule的内容。那么调整后的架构如下图所示：
架构
至于数据库的保存是用GreenDAO还是Room，这个仁者见仁智者见智，根据自己需要和使用习惯来选择。SP的保存要更加灵活些，每个Module里面都有这样的需求，分散在每个Module里面问题不大。
3.权限管理
关于权限管理，考虑到国产Rom的复杂性和框架本身的易用性，推荐的第三方框架是AndPermission。突然窜出来一个权限管理，似乎有点突然，这和组件化架构有什么关系？进一步说，如果使用的是ARouter，如何配合使用呢？
假象一个场景，就是跳转到某个自定义的拍摄界面，需要相机权限，通常采取的方案是点击某个控件在clickListener里面判断权限，这样一来如果有多个地方可以跳转这个界面，那么就会需要在多个地方写相同的权限请求代码，又回到了老问题：怎样消除这种代码的重复？答案：在跳转过程中拦截跳转请求，对请求作处理后再判断处 理。第一篇文章里面提到的可以对路由作处理的作用就体现出来了。
ARouter可以通过拦截机制对跳转请求作相应的处理。在跳转前会遍历Intercept，通过判断是否符合相应的路径来判断是否需要处理跳转。这有点像OKHttp的Interceptor。下面的代码就是ARouter和AndPermission配合做一个简单的跳转拦截示例：
public class CameraInterceptor implements IIntercetpor{
private Context context;
private Postcard postcard;
private InterceptorCallbakc callback;
private static final int CAMERA_PERMISSION_RESULT = 100;
@Override
public void init(Context context){
//this is application context
this.context =context;
}
@Override
public void process(Postcard postcard,InterceptorCallback callback){
this.postcard = postcard;
this.callback =callback;
//判断需要相机权限并拦截处理
if(postcard.getPath().equals("/login/camera_scan")){
AnderPermission.with(context).requestCode(CAMERA_PERMISSION_RESULT).permission(Manifest.permission.CAMERA).callback(this).rational(new RationaleListener(){
@Override
public void showRequestPermissionRationale(int requestCode,Rational ratioal){
AndPermission
.rationalDialog(BaseApplication.getTopActivity(),rational).show();
}}).start();
} else{
callback.onContinue(postcard);//不需要拦截
}
}
}
@PermissionYes(CAMERA_PERMISSION_RESULT)
public void grantee(List<String> permissions){
callback.onContinue(postcard);
}
@PermissionNo(CAMERA_PERMISSION_RESULT)
public void deny(List<String> permissions){
//todo 跳转设置页或者弹出解释dialog
callback.onInterrupt(new RuntimeException("权限被拒绝！！！"));
}
权限请求和弹出弹窗，必须使用栈顶Activity context，如何获取这个Activity Context呢？第一篇文章中有介绍，这边详细展开来说下：
application.registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks(){
@Override
public void onActivityCreated(Activity activity,Bundle bundle){
mTopActivity = activity;
}
@Override
public void onActivityResumed(Activity activity){
mTopActivity = activity;
}
})
public Activity getTopActivity(){
return mTopActivity;
}
4.组件化资源冲突
- 包冲突
当出现包冲突的时候，可以先检查依赖报告。使用gradle dependencies查看依赖目录：
+--- project : Gank
| +--- com.android.supprot:support-v4:22.2.1 ->23.1.1
....
| | | \ --- com.andoird.supprot:support-v4:23.1.1(*)
| | | |---com.facebook.fresco.fbcore:0.10.0
依赖标注了（*）的表示这个依赖被忽略了，这是因为其他顶级的依赖也依赖于这个依赖。support-v4:22.2.1 ->23.1.1表示会使用其他依赖中版本较高的依赖取代当前依赖。
- 资源冲突
多Module开发中，可能会有多个Module中资源出现名称相同的情况，这样就有可能造成资源引用错误的问题。解决这个问题的方法有两种：
一、在不同的Module资源添加时，在资源前添加Module的名称前缀。
二、使用Gradle的命名提示机制。使用resourcePerfix字段：
android{
resourcePrefix "组件名_"
}
但是这个自定字符串作为资源前缀的方法，仅对xml资源有效，并不能对图片资源产生效果。所以为了消除问题，还是得采用一中的方法。
5.组件化混淆
- 资源混淆
推荐的方案有微信的AndResGuard混淆机制。详细的用法参考官方文档Wiki。 - 代码混淆
有三种方案：
一、在Application Module中设置混淆，其余Module中关闭混淆。这个方法的弊端就是如果移除了一些Module，那么剩余的混淆文件也需要手动去清除，虽然不清除也没什么问题，但是可能会对编译效率产生影响。
二、混淆时启动一个命令，引用多个Module的Proguard-rule.pro文件合成，然后再覆盖Application module中的混淆文件。这种方案将混淆条件解耦到每个module中，但是需要编写Gradle命令来配置，而且每次生成都会导致合成操作，对编译效率产生影响。
三、Library Module将proguard-rule.pro文件打包到aar中。混淆时自动采用该混淆文件。这需要在Library Module的build.gradle文件中添加一个属性：
defaultConfig{
consumerProguardFiles `progurad-rules.pro`
}
将需要的混淆文件添加到当前Module的proguard文件中，这个方法可以最大限度的解耦混淆工作，推荐采用此方案。
这篇文章总结了组件化中一些细碎的点，可以帮助我们更好的完成组件化。接下来将会介绍组件化中优化方法，帮助我们更好的组件化。
