为何会选择clean+mvp架构

在了解代码架构以前，先普及一下软件开发周期，由于有着软件不是一层不变的，它也有着周期的循环，因此做为开发者而言，代码架构的搭建，应该考虑后续的扩展性，易测性等。 常见的软件周期： 瀑布模型、快速原型、迭代开发、螺旋模型 瀑布模型 瀑布模型如今看来是比较老旧的方式了，一条龙下来的模型，是典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。

瀑布模型强调文档的做用，并要求每一个阶段都要仔细验证。可是，这种模型的线性过程太理想化，已再也不适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1） 各个阶段的划分彻底固定，阶段之间产生大量的文档，极大地增长了工做量； （2） 因为开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增长了开发的风险； （3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

快速原型： 快速原型模型的第一步是建造一个快速原型，实现客户或将来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。经过逐步调整原型使其知足客户的要求，开发人员能够肯定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 快速原型的关键在于尽量快速地建造出软件原型，一旦肯定了客户的真正需求，所建造的原型将被丢弃。所以，原型系统的内部结构并不重要，重要的是必须迅速创建原型，随之迅速修改原型，以反映客户的需求。 螺旋模型 螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量做为特殊目标融入产品开发之中。可是，螺旋模型也有必定的限制条件，具体以下：

（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并作出相关反应是不容易的，所以，这种模型每每适应于内部的大规模软件开发。 （2） 若是执行风险分析将大大影响项目的利润，那么进行风险分析毫无心义，所以，[螺旋模型]只适合于大规模软件项目。 （3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，不然将会带来更大的风险 一个阶段首先是肯定该阶段的目标，完成这些目标的选择方案及其约束条件，而后从风险角度分析方案的开发策略，努力排除各类潜在的风险，有时须要经过建造原型来完成。若是某些风险不能排除，该方案当即终止，不然启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

迭代开发 每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫作一个迭代，第一个增量每每是实现基本需求的核心产品。核心产品交付用户使用后，通过评价造成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。 迭代开发模型也存在如下缺陷： （1） 因为各个构件是逐渐并入已有的软件体系结构中的，因此加入构件必须不破坏已构造好的系统部分，这须要软件具有开放式的体系结构。 （2） 在开发过程当中，需求的变化是不可避免的增量模型的灵活性可使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边作边改模型，从而使软件过程的控制失去总体性

各自特色： 瀑布模型 文档驱动 系统可能不知足客户的需求 快速原型模型 关注知足客户需求 可能致使系统设计差、效率低，难于维护 迭代模型 开发早期反馈及时，易于维护 。可是须要开放式体系结构，易扩展。可能会致使效率低下 螺旋模型风险驱动 风险分析人员须要有经验且通过充分训练

咱们在作app开发的时候，如今大部分的状况都是敏捷性的迭代开发，团队较小沟通效率高，相对灵活，周期也短，从而下降风险，这就要求咱们对于框架的选型须要合理，不能为了完成迭代任务而加代码，致使后期的须要一次次的重构。那怎样的架构相对来讲比较合理性，如今介绍一种叫clean干净架构的代码特色：

上图来自https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 介绍意思是大致的源码依赖项只能向内指向，内环里的全部项不能了解外环所发生的东西，而后clean架构的目的是： 框架独立，不依赖其余库包，以避免受到约束 可测试。能够在没有UI，数据库，Web服务器或任何其余外部元素的状况下测试业务规则。 UI独立。UI能够轻松更改，而无需更改系统的其他部分。例如，可使用控制台UI替换Web UI，而无需更改业务规则。 数据源独立，业​​务规则未绑定到数据库。 外部代理模块独立，即框架内部不了解外部的状况

如下内容是来自该做者的翻译文档： zhuanlan.zhihu.com/p/20001838 如下是更好地理解和熟悉本方法的一些相关词汇：

• Entities：是指一款应用的业务对象
• Use cases：是指结合数据流和实体中的用例，也称为Interactor
• Interface Adapters： 这一组适配器，是负责以最合理的格式转换用例（use cases）和实体（entities）之间的数据，表现层（Presenters ）和控制层（Controllers ），就属于这一块的。
• Frameworks and Drivers: 这里是全部具体的实现了：好比：UI，工具类，基础框架，等等。

Android应用架构 这一对象遵循关注分离原则，也就是经过业务规则让内环操做对外环事物一无所知，这样一来，在测试时它们就不会依赖任何的外部元素了。  要达到这个目的，个人建议就是把一个项目分红三个层次，每一个层次拥有本身的目的而且各自独立于堆放运做。  值得一提的是，每一层次使用其自有的数据模型以达到独立性的目的（你们能够看到，在代码中须要一个数据映射器来完成数据转换。若是你不想把你的模型和整个应用交叉使用，这是你要付出的代价）。

如下是图解，你们感觉下：

表现层 (Presentation Layer) 表现层在此，表现的是与视图和动画相关的逻辑。这里仅用了一个Model View Presenter（下文简称MVP），可是你们也能够用MVC或MVVM等模式。这里我再也不赘述细节，可是须要强调的是，这里的fragment和activity都是View,其内部除了UI逻辑之外没有其余逻辑，这也是全部渲染的东西发生的地方。 本层次的Presenter由多个interactor（用例）组成，Presenter在 android UI 线程之外的新线程里工做，并经过回调将要渲染到View上的数据传递回来。

** 领域层 (Domain Layer)** 这里的业务规则是指全部在本层发生的逻辑。对于Android项目来讲，你们还能够看到全部的interactor（用例）实施。这一层是纯粹的java模块，没有任何的Android依赖性。当涉及到业务对象时，全部的外部组件都使用接口。

数据层 (Data Layer) 应用所需的全部数据都来自这一层中的UserRepository实现（接口在领域层）。这一实现采用了Repository Pattern，主要策略是经过一个工厂根据必定的条件选取不一样的数据来源。  好比，经过ID获取一个用户时，若是这个用户在缓存中已经存在，则硬盘缓存数据源会被选中，不然会经过向云端发起请求获取数据，而后存储到硬盘缓存。  这一切背后的原理是因为原始数据对于客户端是透明的，客户端并不关心数据是来源于内存、硬盘仍是云端，它须要关心的是数据能够正确地获取到。

最后附上另一个博客地址，也写的挺好 www.jianshu.com/p/66e749e19… 好了，总结一下：无论项目采起什么形式的架构，都是一种代码的规范的基本原则前提下，寻找一种对于业务实现的最优解，如java中代码设计原则主要有单一职责、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则。目的也是提升程序的可维护性，扩展性，实现高内聚，低耦合结果。 好比说，最开始先后端是一个系统的时候就已经强调ui分离了，如今前端可经过npm独立搭建前端项目了，在在这个前端项目自己也不只仅是ui了，也包含了前端的业务，同时也应该用上诉的代码设计原则，对代码进行调整而达到可维护，解耦的可测性的效果。

app的项目调整也是如此，考虑到不一样基础功能的复用，也依然能够用组件化的形式搭建项目，相似后台系统的组件化，微服务的发展。到必定程度app也能够用插件化进行扩展。因此怎么说呢，最重要的仍是代码设计的规范吧。 附上本身的clean+mvp的“番茄工做”项目地址https://github.com/liangzs/tomatoTodo