最近忙于公司项目的开发，差点荒废了这篇文章，不敢说新颖的地方，只是想搬到我的脑海里，为需要的人服务。
借用大利猫的话：好的代码结构一定是层次分明，职责分明的；而糟糕的代码结构则各有各的糟粕，自己都不愿review。所以分层思想很重要，像硬件和系统之间那也是层层关联依赖的，远的不说，就说Android应用，大体上是被分为两层：视图层和数据业务层。视图层是用户看见的，可交互的界面；数据业务层是为视图或者视图交互做准备工作的仆人。
目前Android应用主流的架构是MVC，MVP。
鉴于MVC和MVP资料如此之多，我就放张图片来诠释一下：
其实MVVM是类似于MVP的架构，只不过VM是视图和数据直接绑定，现在业务逻辑在V里面写就可以了。
Clean结构同样是基于MVP的基础之上实现的衍生，文章结尾有Bob大叔的原创说明以及我参考的一些其他优秀的文章。我主要依托于我的项目来讲解对于架构的理解，这是我的Demo ：
inner内层：主要包含三方面，数据模型，资源接口以及单个用例的实现。前两个可能比较好理解，数据模型就是常用的一些Bean类和数据使用方式，资源接口是获取数据的方式，网络获取或本地获取等等，单个用例的实现，我的理解是具体一个需求的实现，比如登录操作，需要传递一个用户名和密码，这里就写这么一个单独的类来实现这个功能，不需要担心参数和返回结果的业务逻辑，只是实现就好，具体可看我的Demo 。
middle中层：现在里面仅有presenter，如果有看其他关于Clear架构的文章，可能会问为什么没有convert（转换）和ViewModel（UI需要的数据结构）。因为我觉得这个可有可无，不一定要放在基础的架构里面，等需要的时候在添加就好了。重点是presenter包，类似于MVP中的P，处理UI和数据的业务逻辑，但是presenter在这里是只依赖于inner内层，不能直接引用外层的任何类。
outer外层：主要就是UI，网络数据或本地数据的实现。其中storage包中是对内层中repository接口的实现。
之后，我个人觉得Clean结构优缺点：
优点：1便于测试，外层依赖内层，内层完全可以自行测试，而不必等到界面写好了在一些测试；2便于维护和便于扩展，因为这种连接关系主要依赖于接口，通过接口的实现就容易修改和在原有的基础之上做扩展；3便于协同开发，个人开发很小的功能，也可以独立开发一个公共的组件，像网络请求框架等。
缺点：1太繁复，实现简单的功能，类有比较多，但是都是有一定模式的，所以我觉得这个框架比较适合大且复杂点的项目。
如有错误，感谢您的指教。同时也谢谢他们的分享：
