一.架构方面(android)

参考 https://www.jianshu.com/p/3edcf85539a6

早期的架构

1.Android入门要求不高，所看到的大部分app都是activity 或者fragment中加入view跟业务逻辑，项目中会抽出辅助模块(网络模块，存储模块等等), 各个业务模块中用事件通知或者广播。(Android framework不会强制要求我们去遵守一些原则:单一职责，依赖倒置原则等)，这样会导致整个项目耦合紧密，难以阅读的数据流传递和混乱的回调逻辑，不利于项目的维护及后期业务的发展。

2.万能的父类
a. 维护生命周期
b. Intent跳转
c. 数据获取(网络以及本地等)
d. 线程切换
e. 通用业务逻辑
......

3.辅助的业务类
为了减轻万能父类的压力，把一些业务逻辑抽出来做成辅助类，但随着业务的不断扩大，辅助类也臃肿，然后继续拆分，测试成本及维护成本还在继续加大。

早期架构总结：尽量避免做大而全的类，应该投入精力去实现易于测试易于维护的低耦合的类,最好不要让业务逻辑进入纯粹的Android世界。

简洁架构设计(Easy Clean architecture)

268450-8d4fe38caa574189.png

一个架构的清晰与整洁离不开下面三个原则：

1).分层原则
2).依赖原则
3).抽象原则

分层原则

按上图可以分为四层
1： Framework & Drivers: 对应的就是Android的框架层，这个地方应该是Android framework的具体实现，它应该包括所有Android的东西，也就是说这里的代码应该是解决Android问题的，是与平台特性相关的，是具体的实现细节，如，Activity的跳转，创建并加载Fragment，处理Intent或者开启Service等
2：Interface Adapters: 适配层，用来担任Android框架层与业务逻辑层的桥梁，可以通过dagger2依赖注入，降低对内层和外层的耦合
3：Use Cases:业务逻辑层，不包含Android代码，是独立性的，便于开发，维护及测试
4：Entities:实体

依赖原则

依赖规则与箭头方向保持一致，也就是说外层知道内层的存在，而内层不知道外层的存在，

微信图片_20180224140533.jpg