一位Android资深工程师对移动端架构的思考( 三 ) _Android

依赖规则
同心圆代表软件的不同领域。一般来说，你走的越远，软件就越高。外圈是机制。内圈是政策。
使这种架构工作的首要规则是依赖规则。此规则表明源代码依赖项只能指向内部。内圈中没有任何东西可以对外圈中的某些东西一无所知。特别是，内圈中的代码不得提及在外圈中声明的内容的名称。这包括功能，类。变量或任何其他命名的软件实体。
外圈中使用的数据格式不应该被内圈使用，特别是如果这些格式是由外圈中的框架生成的话。我们不希望外圈中的任何东西影响内圈。
官方的话就是绕，其实就是依赖是能向里依赖，白话就是内圈向外圈提供服务，比如你去食堂吃饭，选择不同的窗口，对着里面喊到给我来一份鱼香肉丝。你不用管里面的师傅是不是昨天那一个，也不用管里面的菜是不是昨天的那个口味，你只管你的目的是来一份鱼香肉丝就可以了，里面的菜和师傅，也不用管你是谁，是不是个漂亮的MM，他们只管自己事情，对他们圈外的不依赖，反正你依赖我就可以了。

文章插图

Clean将核心业务（Domain层）、UI相关（Presenter层）以及数据加载（Data层）彼此独立开来，不同的层之间由接口依次连接起来，但却又彼此不了解彼此的具体实现。
优点：
1、代码复用性更高
2、更易于测试
3、耦合度更小
缺点：
1、学习难度大（容易懵逼）
2、代码量大（一个小Demo都够你写一壶了）
从MVC->MVP->MVVM->MVP-Clean 后者解决了前者遗留的问题，把前者的缺点优化成了优点。一代更比一代强，但是都是需要代价的，学习成本更高，更加规范，但是并不一定就谁比谁更好，只有谁更适合你的项目，都有优劣，怎么选择需要靠自己了。
其实MVX系列的本质一直未变：

关注点分离原则
高内聚低耦合原则

同时也希望适度设计，不要太过追求某一点。会得不偿失。找到最经济的方案才是王道，也可以多种方案配合一起配合。

文章插图

如何能够更好的将多种架构表现在一款App里面呢？对！组件化。
组件化

文章插图

组件化开发就是将一个app分成多个模块，每个模块都是一个组件（Module），开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等，但是最终发布的时候是将这些组件合并统一成一个apk，这就是组件化开发。
不同的Module我们根据职责划分选择不同的架构，可以最经济的开发一款APP 。

文章插图

目前成熟的方案有阿里的ARouter，通过路由的方式进行通信，感兴趣的同学可以学习下。

优点

1、低耦合
2、可以针对测试（降低测试成本）
3、复用性强
4、支持并行开发
5、适合使用多进程
6、减小编译时间

缺点

1、不适合小型应用或者独立开发
2、各组件开发人员联调，开发进度不一致等问题

应用场景

假如一个app用户量很大，业务丰富，比如某宝，很明显不是一个小团队可以开发的了的，如果不分模块的话，工程的复杂度就太大了，编译时间估计半天都完不成，维护更不用说了，简直不是人干的了。所以很适合分模块来开发。各个模块的耦合性也能降到最低，不至于一个模块有问题，牵连别的模块。编译时间也会大大减小。每个模块相当于一个小APP，更容易灵活的编译，编写。测试也只需要测试本模块，最后联调整体就可以了。所以说业务越复杂，组件化越有优势。
小结移动端架构的差异化体现在通信机制上。通信机制主要分为3种：
1）对象持有
2）接口持有
3）路由
对象持有最简单，但是解耦率最低；
接口持有较为复杂，实现解耦的需求，但是解耦不彻底，相互持有交互方的接口。
路由机制可以实现完全解耦，实现组件化
完了吗？不不不~~移动端不仅仅Android和IOS，还有前端，上面仅仅是MVX的进化史，同时还有不同分支的进化。
当下移动端的趋势，越来越向大前端靠拢了，Android的道友们也越来越瑟瑟发抖，看到RN，FLutter等等的兴起，越来越觉得仅仅学习Android是不够的，还要学习跨平台，大前端的知识。