阅读 4602

组件化开花,就问你香不香

从2017年只有几个大厂在做组件化,到今天已经繁花似锦。

越来越多的团队,越来越多的项目都做了组件化。

大叔相信即使你没有做过组件化项目,但是,对组件化也早就听烂了。

但是,组件化开发多少有些技术门槛。

有很多大神写过相关文章,通俗易懂的不多。深入浅出的更不多。

大叔不才,愿意冒着不要脸的风险一试,通俗易懂、深深浅浅的来聊聊组件化开发,如果对你有一点点启发,请记得回来给大叔点个

这篇blog,大叔酝酿了很长长长长长长长长长长长长长长时间。

一、单工程开发 -> 多module分层开发

image.png 这种分层架构,有什么用呢?

分解成多module的项目结构,就是组件化开发了吗?

当然不是,多module分层的项目结构,只是组件化开发的一部分。只是组件化开发的基础。

大叔,搜索了很多资料,发现,对于组件化开发,并没有很严格的定义。

当然,我们没有必要,过于纠结 ”组件化开发的定义“;

我们更关注这种开发思想对项目带来的好处以及在团队中如何运用。

二、组件化的思想&优势

下面是我的理解,如有出入,欢迎提出来一起讨论。

1、将一个大型项目分解成多个module,拆解的过程就是一个化繁为简的过程。

尤其在大团队,大项目上,组件化的优势会更加凸显。

大项目分解成一个个小型项目,相当于将一个复杂的问题拆解成一个个相对简单的问题。

每个成员,可以专注在自己相关业务的module上。

2、分层的module结构,同一层的module间存在代码隔离,这种隔离是编译上的隔离。

同层的代码不能相互调用。底层的代码也不能调用上层。

这种编译隔离,带来了,模块间的高度解耦。

让模块的依赖关系清晰。

3、更高的可重用性

如果构建正确)组件化设计的系统,比传统的整体设计具有更高的可重用性。

什么是组件?什么是模块?

组件强调复用,模块强调职责划分。 他们没有非常严格的划分。

达到可复用要求的模块,那么这个模块就是组件。

base层的module必须是可复用的,如果项目设计的好,business层都能被复用,每个module都能成为组件。

可重用性是组件化思想的核心。

如此架构,是否也适合技术中台的架构?

4、每个组件都具有可替代性如果构建正确

如果我们要为某个已经存在的组件,重新开发一个新组件,将变得非常可行。

组件内的重构也将变得非常可行。

新的组件的设计只要保证对外提供的接口,完全符合,旧组件对外提供的接口

5、组件的热插拔,成为可能(如果构建正确

我们想象下,在APP运行时,business中的组件可以动态加载,也可动态卸载。

那么我们可以轻松实现组件的懒加载:用户用到的组件,那么就加载进来。用完之后便可以卸载。

6、组件的独立编译、测试,成为可能(如果构建正确

大的android工程项目,build一次要到5分钟左右,太浪费时间了。

拆成多个组件之后,如果每个组件都能单独build,单独测试,那么将大大提升开发效率。

上面讨论的这些优势,并不是将简单将 单工程 拆分成 分层的多module工程结构 就能获得这些优势。

想要获得这些优势,还任重道远,我们还需要解决很多问题,才能让我们的项目具备上面的说的优势。

二、组件化后,将面临哪些问题?如何解决?

1、module之间如何优雅的通信

通过ARouter通信。

ARouter是阿里开源的一个项目。github.com/alibaba/ARo…

通过ARouter跨module跳转Activity

@Route(path = "/test/activity")//申明路由
public class YourActivity extend Activity {
    ...
}

//通过路由启动Activity
ARouter.getInstance().build("/test/activity").withLong("key1", 666L).navigation();
复制代码

通过ARouter在module间共享对象,实现module间通信。

比如:我们有一个账号模块 business:account ,提供了登录、登出、用户信息查询等业务。

同级的其他模块,如何跟账号模块通信?获取用户的登录状态以及用户相关信息?

public class AccountBean {
    private String name;
    private int age;
    //....
}

public interface IAccountService extends IProvider {
    void login(Context context);//登录
    void logout(Context context);//登出
    AccountBean getAccountBean();//获取账号信息
}
复制代码

对外的数据结构和接口定义。

@Route(path = BusinessRoutePath.ModuleAccount.ACCOUNT)
public class AccountServiceImpl implements IAccountService {
    //.....
}
复制代码

bussiness:account模块中的实现。

IAccountService accountService = ARouter.getInstance().navigation(IAccountService.class);
accountService.login(activity);
AccountBean bean = accountService.getAccountBean();    
复制代码

但是问题来了:

同层的其他模块,如何,能拿到ARouter的path?

同层的其他模块编译时,如何,共享AccountBean类、IAccountService接口?

这就是模块之间的编译隔离,带来的问题。

我们很自然的想到了framework模块,或者base层的其他模块。

我们只要将这些path定义、AccountBean类、IAccountService接口,下沉到base层,就可以实现编译上的代码共享。

如此一来,就带来了,另一个问题:代码的中心化问题

2、代码的中心化

简单的path字符串定义,放在framework倒是还好。

如果所有business模块对外提供的接口和数据结构,都定义到framework的话,问题就有点严峻。

将会破坏:组件的 可替代性可重用性组件间耦合度

因为framework是基础模块嘛,所有business模块都依赖的模块,如此,不管你的business1模块是否依赖business2模块的对外接口,都会存在这一层依赖。

模块间的代码边界出现一些劣化。缺少了编译上的隔离。许多模块将会变得不够“独立”了。

可替代性可重用性 越来越弱,想要替换或者复用某个business组件将变得越来越难。

将会导致,我们很难知道,哪些business对哪些business 接口有依赖。

同时,framework模块随着功能迭代,会不断膨胀。

这就是,中心化的问题。

于是我们很自然的想到了一个解决方案:

实现了另一种接口暴露的形式——“.api化”。

将 business模块 对外提供的接口单独抽到 business-api 模块中。其他依赖他的模块只需要依赖他的business-api即可。

image-20201218110524940

这个方案如何实践下去呢?

微信的api化方案

微信团队出了一个很巧妙的方案,这个方案对android的组件化开发,产生了非常深远的影响。

后面很多做组件化开发的团队,在解决中心化问题基本都会用到类似的方案。

mp.weixin.qq.com/s/6Q818XA5F…

以下为,微信官方博客的原文引用:

使用方式和思路都很简单。对于java文件,将工程里想要暴露出去的接口类后缀名从“.java”改成“.api”,就可以了。

而且并不只是java文件,其他文件如果也想暴露,在文件名后增加".api”,也一样可以。

image.png

当然,要让工程支持这样的方式,gradle文件肯定会有一点改变。

image.png image.png

它的实现原理也相当简单:自动生成一个“SDK”工程,拷贝.api后缀文件到工程中就行了,后面其他工程依赖编译的只是这个生成的工程。简单好用。

api方案有点类似于android的AIDL的思路。

微信API方案的变种

image.png

gradle 根据src/api文件来,自动生成{moduleName}-api模块。
如果,src/api文件不存在,将不会自动生成 {moduleName}-api 模块。
复制代码

通过API模块来解决代码中心化问题带来的好处:

  1. 让各个business的之间的依赖明确
  2. 让business对外提供的接口明确。

从而加强了模块的:可替代性

只要两个business对外提供的API一致,就可以相互替换。

3、单独编译、测试 business的单个模块

模块变多了,项目变大了,整个项目的编译速度变慢了。

业内有两种常用做法。

  • 方案一:动态配置 build.gradle。

    只要让单个的组建能编译成APP就能单独测试。

    image.png

  • 方案二:多壳APP

    image-20201219144148575

    方案来自,在聚美优品。

    这里需要注意:假如,Demo1是business1的壳APP。那么Demo1还需要依赖哪些businessXXX呢?

    刚好,前面做的api化,能排上用场。

    business1依赖的businessXXX-api模块对应的businessXXX模块,Demo1也需要依赖。

    为甚?因为,business1依赖的businessXXX-api模块,意味着,business1需要依赖 businessXXX提供的功能,比如要跳转到businessXXX的activity?或者,要获取businessXXX的对象。

4、模块变多了,gradle代码同比增长,gradle 代码复用
  • 版本号统一管理,依赖的统一管理
    • 方案一:Extra properties

      developer.android.com/studio/buil…

      docs.gradle.org/current/use…

      在项目跟目录的build.gradle文件中配置Extra属性

      image.png

      如此可以实现统一管理版本号,和依赖。

      但是,但是,但是,这个方案存在明显的缺陷。

      • 不支持,自动补全

      • 不支持Find Usages,查找所有应用的地方

        image.png

      • 使用时,不支持点击跳转

      严重影响开发体验。

    • 方案二:buildSrc

      image.png

      • 支持,自动补全
    • 支持,Find Usages

      • 支持,点击跳转
    • 更完美的语法高亮

    • gradle文件复用

      版本和依赖做到了统一管理,但是每个module都有各自的build.gradle,重复的build.gradle代码依然没有复用。

      我们可以通过apply from:"xxx.gradle"的方式来复用gradle代码。

      如下图

      image.png

      如上,我们可以在base.gradle中为每一个项目添加配置统一的编译逻辑,如:kotlin的支持,java版本的修改,maven库上场的逻辑等等

5、模块间:string、drawable、value、layout等,资源名冲突问题

如何防止资源名冲突?

比如businessA 和 businessB都在drawable目录下,都有一张同名的图片。

这两张图片只有一张会被打包到apk中,被使用。

这样就容易出现混乱。

这个问题比较好解决。让每个模块的资源名固定一个前缀。只要模块之间的前缀不一样就不会冲突。

gradle的resourcePrefix配置,刚好符合我们的需求。

如下配置,如果module中存在资源不以app_开头,**lint走查会报warnning。**注意不会编译失败。

android {
    resourcePrefix 'app_'
}
复制代码

如下截图的warning:

image.png

6、由于多module分层的项目结构,导致 R.class 冗余

image.png

可以通过booster的资源内联工具解决,R类的冗余。

详细可以自己查看booster官网,booster是didi开源的一个插件。booster.johnsonlee.io/feature/shr…

7、模块间,公共资源string、drawable、layout等如何共享?

没有找到很好的解决方案。

每个方案都有缺陷

比如说,business1和business2都要用到同一张图片。

那么这张图片该放到哪里呢?

  • 1、把他放到api模块里来共享

    资源这种,并非功能依赖,放到api模块也不太合适。

    因为这样可能造成business1和business2模块原本没有关联也没有依赖;

    但因为共用同一个资源,却导致存在了依赖。

  • 2、在business1和business2中都放一个图片

    如此会增大包体

  • 3、在business1和business2中都放文件名同名的图片,让编译时资源合并的时候只使用同一张图片。

    如此一来,放开各个模块资源命名,也容易导致开发时发生冲突。

    自定义lint规则,让存在common和{moduleName}两种前缀?

  • 4、将这张图片下沉到base层,如:framework模块,或者,单开一个lib-resource

    如此一来,将会出现资源中心化问题。

上面的方法多少都有些缺陷,大叔还没有找到一个优雅的方式。如果你有什么好想法,一定要留言告诉大叔,大叔在此谢过你了。

8、各个business 模块 之间能不能有直接依赖?

千万不能这么操作。

假如:在 business/setting 中直接在gradle配置中依赖,business:account。

那么编译上的代码隔离就彻底被毁。就跟不要谈组件的可重用性可替代性了。

implementation project(":business:account")
复制代码
9、Application生命周期如何派发

各个组件如何获得Application.attach()、Application.onCreate()、Application.onTerminate()等的回调。

未完待续

10、组件生命周期管理

未完待续,待大叔踩过坑,实现了,再来写。

11、组件实现热插拔

未完待续,待大叔踩过坑,实现了,再来写。

12、等等,未完待续

待大叔继续探索

三、升华

最后我们再回到,组件化本身上来。

组件化开发不仅仅是一种多module分层的项目结构;他不仅仅是一种架构;他更是一种架构思想,一种追求模块复用精神。

有人说小项目没有必要做组件化开发。大叔不这么认为,小项目依然适合做组件化,除非你们团队只有一个项目,并且项目几乎不需要迭代。组件跨项目的复用也是一件让人十分兴奋的优势。

前几年听烂了的技术中台,跟组件化的架构也不谋而合。

最后,十分感谢,前辈们将他们的组件化经验分享到互联网,为我们这些组件化的后来者提供了宝贵的资料。

感谢!感谢!感谢!感谢!感谢!大叔给你们一个么么哒

微信Android模块化架构重构实践

聚美组件化实践之路

Is there a difference between a component and a module

架构设计 组件和模块的区别

Android 组件化最佳实践

Android 模块化探索与实践

为了组件化改造学习十几家大厂的技术博客

en.wikipedia.org/wiki/Modula…

en.wikipedia.org/wiki/Compon…

最后的最后,如果这篇文章对你有一点点启发,请一定要点个再走。这对一个草根原创技术博主很重要……

文章分类
Android
文章标签