Android组件化架构(二)

0.46字数 1444阅读 311

项目多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文件中,这个方法可以最大限度的解耦混淆工作,推荐采用此方案。

这篇文章总结了组件化中一些细碎的点,可以帮助我们更好的完成组件化。接下来将会介绍组件化中优化方法,帮助我们更好的组件化。

推荐阅读更多精彩内容