Android开发最佳实践—项目架构篇

   <p>项目的架构是一个项目的基础，其决定了我们项目后期的可扩展性，开发过程中的便捷性等。一个好的项目架构应该是结构清晰，可维护性好且可扩展性强的。这次我们就来探讨一下如何架构一个项目。</p>    <h2><strong>架构选择</strong></h2>    <p>目前 Android 主流的项目架构的选择其实并不少，我们可以选择看一下 android-architecture 这个项目，这是 Google 提供的架构例子，里面包括了目前 Android 项目的主流架构：</p>    <ul>     <li><a href="/misc/goto?guid=4959716812880407746" rel="nofollow,noindex">todo-mvp/</a> - 基本的 MVP 架构</li>     <li><a href="/misc/goto?guid=4959725615383796475" rel="nofollow,noindex">todo-mvp-loaders/</a> - 基于 todo-mvp, 使用 Loaders 获取数据.</li>     <li><a href="/misc/goto?guid=4959725615469839366" rel="nofollow,noindex">todo-databinding/</a> - 基于 todo-mvp, 使用 Data Binding 库.</li>     <li><a href="/misc/goto?guid=4959674201860106726" rel="nofollow,noindex">todo-mvp-clean/</a> - 基于 todo-mvp, 使用了 Clean 架构.</li>     <li><a href="/misc/goto?guid=4959714738814087366" rel="nofollow,noindex">todo-mvp-dagger/</a> - 基于 todo-mvp, 使用 Dagger2 依赖注入</li>     <li><a href="/misc/goto?guid=4959725615609440991" rel="nofollow,noindex">todo-mvp-contentproviders/</a> - 基于 todo-mvp-loaders, 使用 Loaders 和 Content Providers 获取数据</li>     <li><a href="/misc/goto?guid=4959725615688024014" rel="nofollow,noindex">todo-mvp-rxjava/</a> - 基于 todo-mvp, 使用 RxJava 处理并发并抽象数据层.</li>     <li>……</li>    </ul>    <p>另外除了 Google 列出的架构，还有 非死book 推出的 Flux 架构也值得考虑。</p>    <p>以上的架构实际上并不是互斥的，在项目中是可以同时用到的。</p>    <h2><strong>Clean or Flux</strong></h2>    <p>首先我们对比一下 Clean 和 Flux 架构的区别：</p>    <h3><strong>Clean 架构</strong></h3>    <p>Clean 架构把项目按功能分为四层，对应到 Android 项目中从底到上分别是：</p>    <ul>     <li>Repository 层(对应图中 Entities，也是 MVVM 中的 Model)</li>     <li>Domain 层(对应图中 Use Cases，如果没有复杂逻辑是可以省略的)</li>     <li>Presenter 层(其对应的是 MVVM 中的 ViewModel)</li>     <li>UI 层（即 MVVM 中的 View）</li>    </ul>    <p>其依赖一层一层向上，底部(内部)不会对外部产生依赖。</p>    <p>如果使用 Clean 架构，我还会选择以下部分实现其它功能：</p>    <ol>     <li>Databinding 实现 MVVM(Model-View-ViewModel)</li>     <li>RxJava 处理并发并抽象数据层</li>     <li>使用 Dagger2 处理依赖注入</li>    </ol>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8d35108cfa4e34a579e63b5065d1a5c4.png"></p>    <h3><strong>Flux 架构</strong></h3>    <p>在 Flux 架构中，数据永远是单向流动的(不包括 Web API 以及 Rest Helper)。当我们操作界面(View)触发一个动作时，ActionCreator 会创建一个对应的 Action，并通过 Dispatcher 发送给所有订阅了这个 Action 的 Store。在 Store 处理完这个 Action 之后就会把相对应的 UI 改变的事件发送给 View 并显示出来。</p>    <p>下面详细讲一下 Flux 架构中对应的重要成员：</p>    <p>ActionCreator是一个根据语义化的 API 来创建对应的 Action 的类，当 View 触发一个行为的时候就会调用 ActionCreator 对应的方法。</p>    <p>Action是简单的 POJO 类型，它只包含类型和数据，不可被更改，一旦 Action 被创建就会发送到 Dispatcher。</p>    <p>Dispatcher一个 Android 应用只要一个 Dispatcher，它是一个发布-订阅(又称为观察者模式)的实现，它会把 Action 分发到所有注册过的 Store 中，所有注册过的 Store 再根据需要处理 Action 即可。</p>    <p>StoreStore 有点类似于 MVP 模式中的 Presenter，但它只负责更新 UI 不负责响应 UI 事件。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6c60573b1397ee01ab6afe82c2b233f5.png"></p>    <p>如果使用 Flux 架构，我还会选择以下部分实现其它功能：</p>    <ol>     <li>RxJava 处理并发并抽象数据层</li>     <li>使用 Dagger2 处理依赖注入</li>    </ol>    <p>之后我会再写一篇博文介绍 Flux 架构的详细实现，到时候再详细探讨 Flux 架构。</p>    <h2><strong>MVP or MVVM</strong></h2>    <p>为什么不用 MVC？它过时了，可以退役了。</p>    <h3><strong>MVP</strong></h3>    <p>MVP 相比于 MVC，它从 Controller 层中抽出了一层 Presenter，来负责连接 View 和 Model，这样 View 一旦触发了一个操作，调用 Presenter 的方法去找 Model 获取数据，Presenter 获取到数据处理完毕之后通知 View 更新界面。</p>    <p>在这个过程中 View 和 Model 不直接发生联系，所有通信通过 Presenter 传递，这样 View 中只处理界面相关的东西，逻辑相关的则交由 Presenter 处理，便于后期维护。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/193f50ec2c1ad41eaf789126cf84e0e7.png"></p>    <h3><strong>MVVM</strong></h3>    <p>MVVM 其实是对 MVP 的改进，它使用了双向绑定(data-binding)，View 的变化会直接更新到 ViewModel 中，ViewModel 的变化也会直接反应在 View 上，其它和 MVP 没有区别。</p>    <p>在 Google 推出了 Databinding 库之后使用 MVVM 可以大幅减少代码量，非常方便。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/b1973f93adba97ef8f84be2922b712a4.png"></p>    <p> </p>    <p>来自：http://loshine.me/2016/11/17/android-best-practice-p3-project-architechture/</p>    <p> </p>