转载

Android 组件化实践详解（二）

在上一篇文章《组件化实践详解（一）》中我们介绍了组件化实践的目标和实践步骤，本文继续说说关于组件化实践遇到的问题及思考。

1、组件内的架构设计

这条本来我是不想写的，但是很多组件化的文章里都会费尽心思的写组件内的架构设计。

那我也谈一谈我的看法：首先回归初心，想想组件化的目的，为了各个业务组件可以单独运行。划重点：目的是单独运行，把之前在App Module的代码挪到自己单独的Module，然后能够独立运行；而不是大面积重构！！我也相信对于大部分团队，实际上并没有很多的时间去做重构，尤其是在做组件化的过程中同时大面积重构，确定做了风险评估吗？

对于组件化的整体设计，需要遵循制定的规则，但是对于组件内的架构设计，实际上不需要特殊的要求，代码你爱怎么写就可以怎么写，不管你使用MVC、MVP还是MVVM， 根据各自情况合理选择就好了 。这个话题本来就不属于组件化项目的范畴。

2、调试方式

假如之前的几步我们都顺利完成，现在整个Project已经变成了下图整个样子。

那我们的Module要怎么才能跑起来呢？

我们创建Module的时候如果选择的是Application工程，毋庸置疑肯定是能跑起来的，但是却没有办法被真正的Host宿主引用了；
创建Module的时候选择的是Library工程，可以被引用但是无法自己单独运行；

二者结合呢？借助冯大大在MDCC上的分享，将Module分为两个模式：Release模式和Debug模式，Release模式下作为Library，供宿主依赖；而在Debug模式下则作为Application工程，自己单独运行。

build.gradle中根据gradle中的一个属性值来判断处于哪种模式下：

   if (isDebug.toBoolean()) {
        apply plugin: 'com.android.application'
    } else {
        apply plugin: 'com.android.library'
    }
     sourceSets {
        main {
            if (isDebug.toBoolean()) {
                manifest.srcFile 'src/main/debug/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/release/AndroidManifest.xml'
            }
        }
    }

在Release中的AndroidManifest配置默认启动的主Activity。

这样一来调试的问题也就解决了。但是实际上这仅仅是一个Demo雏形，我们思考几个带出来的问题：

如果我这个业务组件涉及了别的好几个Module，也就是我自己使用Debug模式运行的时候别的Module需要使用Release模式，那么每个Module都需要一个单独的变量去控制，Module过多导致变量过多，出错可能性陡增；
直接的源码依赖：假如大家在一个分支上开发不同的组件，有极大可能会导致冲突或者调用异常导致影响研发效率；当然肯定有人会说一般不会在一个分支开发，确实，但做了组件化之后分支数其实是可以变少的；
如果是Host直接源码依赖子Module，那当子Module作为Application工程运行的时候一旦你Build项目，那各种美如画的报错让你苦不堪言；

如何对这个情况做优化： 各个独立Module提供稳定版本的aar ！

单独的业务组件开发完成之后，记录一个版本号同时提供一个稳定的aar；
别的依赖模块直接去compile需要的业务组件的aar即可；
Host宿主则是compile这些业务组件稳定的aar；
依赖于稳定的aar，那么自己的业务组件开发并不会影响到别人，而且Build的时候宿主也不会出错；
针对众多的aar包，最好建一个maven仓库来统一管理；
生成及上传aar包这步，可以写个脚本帮忙生成及上传；

3、工程化经验

以下介绍些关于工程化的经验

3.1 Application

部分业务组件一定会遇到依赖一些三方组件需要提前初始化的情况，正常我们的做法都是在应用的Application中做的。此时我们在独立的Module开发，没有了应用的Application，那么可以自己创建一个Module的Application， 以下提几种实现的思考 ：

Module的Application只工作在Debug模式下，而在宿主中也同样注册需要的三方组件，Release模式下没有这个Application则不会重复注册；
Module的Application同时工作于这两种模式下，但是真正打包生成Apk之后实际系统认可的只有App的Application，而别的Module Application只是被系统认为是一个没有特殊意义的普通类。那我们可以在真正的Application方法调用的时候通过反射调用Module Application的相应方法；
源于第二种方案，区别在于将Module组件中的初始化工作，延迟到组件使用的时候才去初始化，好处就是使用时才加载。

备注：而怎么判断调用业务Module呢？两个场景：UI跳转或者方法调用，这两种判断可以使用路由框架来协助。

3.2 Application与Tinker的兼容

Tinker作为热修复的可靠解决方案，想必很多App都会集成，但是Tinker集成稍繁琐的地方就在于：为了确保Application也能修复，需要改造Application，改造完成之后打的包出来真正的Application已经被修改，而写上了我们逻辑的Application实际上变成了一个普通类，只是相应方法被真正的Application调用！

那我想把Tinker这个模块也单独作为一个Module来使用，能行吗？首先来思考一个问题：Application要在哪里，Library中还是Host？

答案是Library中，因为各个Module中可能会存在不方便获取Context的场景，解决方案之一就是使用Application的Context。假设Application放在Host中，那Module肯定是无法使用的。当然刚刚我们说到Module自己的Application，但是别忘了如果Module没有呢？

把Application放到Library中也不是说移就能移：

正常情况下我们会发现Host Application中也有一大堆的逻辑或者是组件初始化，而这些组件要全被移出去还需要 a long long time；
代码中有一大堆通过Host Application拿到的Context，现在忽然移出去，必定一大堆报错；

面对如此抉择，那到底是移还是不移？一个好方法是原来Host的Application只做较小改动：并不移出来之前的各种逻辑和组件，而是作为一个普通类，在Library中的Application方法执行时去回调相应Host Application的方法；随后在组件化的过程中逐渐的移出来这些业务和组件。这样的改动成本最小又满足了当下的需要。

3.3 资源冲突

在拆分出来多个Module或者新建Module进行开发，新建资源的时候可能会有命名的冲突，对Gradle熟悉的同学可能会表示使用resourcePrefix来进行限定，但是坦白说效果一般，倒是不如在编码规范中加上一条以相应Module的标示作为命名的前缀。

3.4 ButterKnife的使用

ButterKnife——相信很多同学都用过，这是一个注解框架，一般在绑定View的时候使用，减少了很多无意义的代码。在正常开发中我们用起来也是6的飞起！然而当ButterKnife跑在Library工程中的时候各种Build失败就出现了：原因在于Android Library中的R文件字段并不是常量，Module在Debug模式下是Application工程可以开心玩耍，等真正集成的时候切换回Release模式就呵呵哒了。

在ButterKnife8.0之后也支持了在Library中使用，解决方式就是同时生成了一个R2，这个就是常量，因而可以在Library工程中使用。