这个回答让我错失offer！成功收获美团，小米安卓offer

前言

我们移动开发程序员应该首先明白一个要点，能够学习的东西可以区分为『知识』和『技能』。

知识，就是你知道就知道、不知道就不知道的东西，比如『计算机系统中一个字节是包含8个bit』，你知道了之后就算掌握了。

技能，是需要练习的东西，不是知道不知道的区别，只有熟练还是不熟练的区分，比如『写代码要用有意义的命名规则』，你知道了这一点，不代表你掌握了这个写代码命名的技巧，你需要去写代码练习，但是练习还不够，你需要反复练习，还需要别人给你反馈，你才能练习得更好。

是的，知乎上有些内容全都是『知识』（有的还只是伪知识），不是技能，记住，知识只需要记忆力，技能需要反复练习。

此次手写架构，解决的问题是：

1、让 App内各个功能模块能够独立开发单元测试，也可以所有模块集成打包，统一测试

独立开发
更改gradle.properties的配置，使得每个功能模块都成为application，可以独立打包成apk，单独运行。单个模块，独立测试。

集成打包
更改gradle.properties的配置，使得原先每个单独模块，都变成library，被主模块引用，这时候只有主模块能够打包apk，所有功能都集成在这个apk内。

2、实现功能模块的整体移植，灵活拔插

故事背景
当你们公司有多个安卓开发人员，开发出核心业务相同，但是UI不同，其他业务不同的一系列App时（如果核心业务是X，你们有5个开发人员，做出了A,B,C,D,E 5个app，都包含核心业务X，但是除了X之外，其他的业务模块各不相同）这时候，如果领导要把A里面的一个非核心功能，挪到B里面…

现状
开发B的程序猿可能要骂娘，因为他在从移植A的代码中剥离代码遇到了很多高耦合，低内聚的类结构，挪过来之后，牵一发而动全身，动一点小地方，整个代码满江红。

理想
如果这个时候，我们通过代码框架的配置，能够把A里面的一个模块，作为一个module 移植到工程内部，然后主module 来引用这个module，略微写一些代码来使得这个功能模块在app中生效。那么无论是多少个功能模块，都可以作为整体来给其他app复用。这样开发人员也不用相互骂娘了，如果挪过来的模块存在bug或者其他问题，也不用甩锅，模块原本是谁开发的，找谁就好了。

3、保证App内业务模块的相互隔离，但是又不妨碍业务模块之间的数据交互

我们开发app的功能模块，一个业务，可能是通过一个Activity或者一个Fragment 作为对外的窗口,也可能是。***所谓窗口，就是这个业务，相对于其他模块，"有且只有"一个入口，没有任何其他可以触达到这个业务的途径。***业务代码之间相互隔离，绝对不可以有相互引用。那么，既然相互不会引用，那A模块一定要用到B模块的数据，怎么办呢？下文提供解决方案。

正文大纲

1、代码结构现状以及理想状态一览

2、功能组件化的实现思路，实现组件移植拔插

3、参考ARouter源码，写出自己的Router框架，统一通过Router来进行模块的切换以及组件之间数据的交互

4、使用组件api化，在模块很多的情况下优化公共模块的结构

正文

1、代码结构现状以及理想状态一览

现状；

代码有模块化的迹象，但是没有对业务模块进行非常明显的模块化（不明白啥意思是吧？不明白就对了，app这个module里面其实还有很多东西没有展示出来，请看下图：试想，把所有的模块集中到一个module的一个包里面，当你要移植某一个功能的时候，想想那酸爽…当然如果你口味别致，那当我没说）

理想：

理想化的话，参照：理想.png; 项目结构层次分明，脉络清晰

按照图中的分层，详细解释一下：

外壳层：app module

内部代码只写 app的骨骼框架，比如说，你的app是这个样子的结构：

下方有N个TAB，通过Fragment来进行切换模块。这种架构肯定不少见。

这个时候，外壳层 app module，就只需要写上上面这种UI架构的框架代码就行了，至于有多少个模块，需要代码去读取配置进行显示。你问我怎么写这种UI框架吗？网上一大把的，如果实在找不到，来我的 github

业务层

我们的业务模块，对外接口可能是一个Activity* *（**比如说，登录模块，只对外提供一个LoginActivity,有且仅有这一个窗口）或者 是一个Fragment，就像上图（典型的app架构.png）, 如果app的UI框架是通过切换Fragment来却换业务模块的话。用business**这个目录，将所有的业务模块包含进去，每个模块又是独立的module，这样既实现了业务代码隔离，又能一眼看到所有的业务模块，正所谓，一目了然。

功能组件层