美文网首页APP开发Android组件化路由
Android组件化架构(二)

Android组件化架构(二)

作者: From64KB | 来源:发表于2018-06-05 16:56 被阅读169次

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

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

    相关文章

      网友评论

        本文标题:Android组件化架构(二)

        本文链接:https://www.haomeiwen.com/subject/adepsftx.html