Android架构模式／性能优化

①现行中Android MVC模式

优点：

• 代码与设计书的匹配度更高，易于理解，不同级别的程序员更容易中途参加到项目开发中来。

• 现行有e*Bank项目中，将耗时的数据处理逻辑交给异步task处理，缓解Activity的压力，在这些异步task中只要关心当前task要做什么，入力是什么，出力是什么。在Activity中只需要调用异步的execute方法来执行异步任务，回调时处理异步结果，Activity关心的只是总体的业务流。

缺点：

• 现在使用的XML，Activity，Model模式其实就是传统意义上的MVC模式，其中Activity（Fragment, Adatper）做的事情包括了View（用setText,setVisible等方式来控制画面），和Controller（控制业务逻辑，和Model交互的操作）。这样使Activity越来越大，导致FatActivity形成。
• 类的职责分类不明确，V和C的耦合严重。
• 在项目的扩展性方面也很欠缺，例如，当你需要将画面上的TextView修改成EditText时，需要修改XML以及Activity对控件的引用。
• Adapter适配器们在管闲事：它们应该只负责View的那些事儿。比如：判断入出金Flag，if出金，then字体颜色为绿色，if入金，字体颜色为红色。再比如：判断口座状态，显示不同的badge，显示不同的银行卡背景颜色。getView越写越大，逻辑越写越多。

关于Adapter我的想法：

• 如果ListView等的item异常简单，尽量使用ArrayAdapter,SimpleAdapter，而不是随意创建继承BaseAdpater的新类。
• getCount,getItem,getItemId这种每个Adapter中内容都一样的处理可以提取到抽象类中。
• 在需要调用NotifyDataSetChanged时，请考虑，是否想要重绘所有的可见View，如果不是，最好创建一个单独更新某一个Item的方法updateItemView(int postion)。
• getView方法，在每次滑动时，将不可见item移入我们的视野的时候会被调用到，所以在getView中做了业务的判断，对性能是有所影响的。来回的滑动，虽然利用了ViewHolder来降低内存开销，但是反反复复的判断逻辑也未尝不可避免。

②MVVM：[Model View ViewModel]

View	对应于Activity和xml，负责View的绘制以及与用户交互。 View层不做任何业务逻辑、不涉及操作数据、不处理数据、UI和数据严格的分开。
Model	实体模型层 ViewModel 可以根据Model 获取一个Bean的Observable<Bean>( RxJava ),然后做一些数据转换操作和映射到ViewModel 中的一些字段。
ViewModel	负责完成View于Model间的交互,负责业务逻辑 ViewModel 只做和业务逻辑和业务数据相关的事，不做任何和UI、控件相关的事，ViewModel 层不会持有任何控件的引用，更不会在ViewModel中通过UI控件的引用去做更新UI的事情。

1. 利用谷歌提供的DataBinding，实现数据的单向绑定和双向绑定。
2.  MVVM Light Toolkit是一个Android MVVM 轻量级工具库https://www.jianshu.com/p/43ea7a531700
3. 关于DataBinding讲解 点我，推荐ObserveField的方式，双向绑定。点我
4. POJO和JavaBean有差异

   //POJO
   
   public final String firstName;
      public final String lastName;
      public User(String firstName, String lastName) {
          this.firstName = firstName;
          this.lastName = lastName;
      }

   //JavaBean
   public class User {
      private final String firstName;
      private final String lastName;
      public User(String firstName, String lastName) {
          this.firstName = firstName;
          this.lastName = lastName;
      }
      public String getFirstName() {
          return this.firstName;
      }
      public String getLastName() {
          return this.lastName;
      }
   }
   
   

    

优点：

• ViewModel：绝对不持有UI的引用，不考虑UI的变化，只专心处理数据，准备数据。onClick等UI listener不在这里管理。耦合度很低。
• 可复用性：一个View Model复用到多个View中，同样的一份数据，用不同的UI去做展示，对于版本迭代频繁的UI改动，只要更换View层就行。
• 单元测试：View Model里面是数据和业务逻辑，View中关注的是UI，这样的做测试是很方便的，完全没有彼此的依赖，不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。

缺点：

• View：在XML中会出现过多的UI判断控制的逻辑代码（比如：android:visibility="@{user.status == 1 ? View.VISIBLE : View.GONE}"），这也是一种程度上的代码倒退，如同在jsp中写了一大堆java逻辑。如果UserBean属于一个Model对象，那么新增一个ModelAdapter对Model的值进行有利于View展示的改造，那么上述问题可以避免。

• DataBinding框架提供的不够全面，ListView等处理可能存在欠缺。

• 类和方法会增加：新建一个空的工程，统计打开 build.gradle 中 Data Binding 开关前后的 apk 文件中类数量和方法数量，类增加了 120+，方法数增加了 9k+（开启混淆后该数量减少为 3k+）。

③MVP：[Model View Presenter展示器]

View	对应于Activity和xml，负责View的绘制以及与用户交互
Model	实体模型
Presenter	负责完成View于Model间的交互和业务逻辑

1. 主要依靠创建接口达到目的。
2. Android Architecture Components
3. 用谷歌提供的应用架构库来处理本地SQLite的事情android.arch.persistence.room
4. 由于Presenter持有View的对象引用，当Activity销毁时，如果Presenter还在做异步后台任务，那么响应时需要使用View做一些画面展示时，会出现内存泄漏问题。在Presenter中做一个onDestroy方法用来销毁View的引用，并且在Activity的生命周期中调用。同时回调回来之后需要注意防止View的空指针异常。
5. 与MVC相比同样带来一个问题，和设计书的匹配难度加大了。因为设计书没有按照职能单一的方式去设计。
6. 谷歌官方提供的MVP架构示例

 

缺点：

• Activity需要实现各种跟UI相关的接口，同时要在Activity中编写大量的事件，然后在事件处理中调用presenter的业务处理方法，View和Presenter只是互相持有引用并互相做回调,代码不美观。
• 这种模式中，程序的主角是UI，通过UI事件的触发对数据进行处理，更新UI就有考虑线程的问题。而且UI改变后牵扯的逻辑耦合度太高，一旦控件更改（比较TextView 替换 EditText等）牵扯的更新UI的接口就必须得换。
• 复杂的业务同时会导致presenter层太大，无法避免代码的臃肿问题。

④VIPER:[View Interactor交互器 Presenter展示器 Entity Routing]

故事背景：MVP中的presenter变成了一个方法超多的庞大的类，使得它很难维护和理解。因为它要负责许多事情：处理UI事件，UI逻辑，业务逻辑，网络和数据库查询。这违背了单一职责原则，而 VIPER 可以解决这个问题，从根本上遵循了单一职责原则。

View 视图
Interactor 交互器	只负责业务逻辑和获取来自数据库和 API 的数据
Presenter 展示器	UI 事件处理以及为 View 准备来自Interactor的数据之类的事情
Entity 实体
Routing 路由

 

 

[参考URL]

• 【Google提供】：MVVM, MVP等架构的示例代码参照如下
• https://github.com/googlesamples/android-architecture
• Android开发架构选择MVP or MVVM
• https://www.jianshu.com/p/2fbb3fc84449
• 如何构建Android MVVM应用程序：简书
• https://www.jianshu.com/p/2fc41a310f79
• 更多精彩博客汇总
• https://www.jianshu.com/p/1f21e1d375aa
• The Clean Architecture ： 
• https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
• 一种更清晰的Android架构 ：
• https://zhuanlan.zhihu.com/p/20001838
• Android-CleanArchitecture ：
• https://github.com/android10/Android-CleanArchitecture
• 给 Android 开发者的 RxJava 详解 ：
• http://gank.io/post/560e15be2dca930e00da1083
• 浅谈 MVP in Android ：
• http://blog.csdn.net/lmj623565791/article/details/46596109
• VIPER英文博客
• https://cheesecakelabs.com/blog/using-viper-architecture-android/
• VIPER英文博客译文博客
• http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2017/0329/7754.html

转载于:https://my.oschina.net/u/3760785/blog/1633905