[译]使用MVI打造响应式APP(五):轻而易举地Debug

[qingmei2]

[译]使用MVI打造响应式APP(五):轻而易举地Debug

原文：REACTIVE APPS WITH MODEL-VIEW-INTENT - PART5 - DEBUGGING WITH EASE
作者：Hannes Dorfmann
译者：却把清梅嗅

前文我们探讨了Model-View-Intent (MVI) 架构模式及其相关特性，在 第一篇文章 中，我们谈到了 单项数据流的重要性 和 应用状态应该被业务逻辑驱动。本文我们将展示这种架构模式会怎样回报开发者，它可以让开发者在开发过程中更轻而易举进行debug。

遇到过这样的情况嘛？你得到了一个崩溃的报告，但是你无法复现这个BUG。听起来似曾相识？我也是！在花了很多时间查看堆栈跟踪和项目的源码后，最终我选择了放弃——关闭了这个issue，并提交了一个类似 无法复现 或者 某个Android生产商的某种特定的机型导致的特殊错误 的备注。

以我们的购物App举例来说，在Home界面，用户以某种方式进行下拉刷新，但不知道为什么，崩溃报告告诉我，当用户执行下拉刷新获取最新数据的操作时，应用抛出了一个NullPointerException。

因此，作为开发人员，您启动App并尝试在Home界面进行下拉刷新，但App并没有崩溃, 它按照预期正常地运行。然后您开始仔细检查自己的代码，但是就是找不到哪里会导致NullPointerException的发生。你打开了debug模式，一行一行逐步执行该界面相关的代码，但App仍然正常的运行—— 到底怎么样才能让它在下拉刷新时崩溃？

问题的根本在于你不能在App崩溃发生之前复现状态，如果遇到崩溃的用户可以在崩溃报告中提供他App的状态（在崩溃发生之前）以及堆栈跟踪，那不是很棒吗？

通过 单向数据流 和 Model-View-Intent ，这简直轻而易举。

在 用户执行所有Intent 和 界面对Model进行渲染时，我们很方便地能够将它们进行打印，让我们通过在HomePresenter中添加Log来为Home界面执行这样的操作（具体代码请参考 第三节，该小节我们针对状态折叠器进行了探讨）。

在以下代码片段中，我们使用Crashlytics（译者注：一种崩溃报告工具），使用其它的崩溃报告工具也是一样的：

class HomePresenter extends MviBasePresenter<HomeView, HomeViewState> {

  private final HomeViewState initialState; // Show loading indicator

  public HomePresenter(HomeViewState initialState){
    this.initialState = initialState;
  }

  @Override protected void bindIntents() {

    Observable<PartialState> loadFirstPage = intent(HomeView::loadFirstPageIntent)
          .doOnNext(intent -> Crashlytics.log("Intent: load first page"))
          .flatmap(...); // 加载数据的业务逻辑

    Observable<PartialState> pullToRefresh = intent(HomeView::pullToRefreshIntent)
          .doOnNext(intent -> Crashlytics.log("Intent: pull-to-refresh"))
          .flatmap(...); // 加载数据的业务逻辑

    Observable<PartialState> nextPage = intent(HomeView::loadNextPageIntent)
          .doOnNext(intent -> Crashlytics.log("Intent: load next page"))
          .flatmap(...); // 加载数据的业务逻辑

    Observable<PartialState> allIntents = Observable.merge(loadFirstPage, pullToRefresh, nextPage);
    Observable<HomeViewState> stateObservable = allIntents
          .scan(initialState, this::viewStateReducer) // 对状态进行折叠
          .doOnNext(newViewState -> Crashlytics.log( "State: "+gson.toJson(newViewState) ));

    subscribeViewState(stateObservable, HomeView::render); // 展示新的状态
  }

  private HomeViewState viewStateReducer(HomeViewState previousState, PartialState changes){
    ...
  }
}

通过RxJava的 .doOnNext() 操作符，我们可以很轻松将每个intent和每个intent的result——也就是即将渲染在view层上的状态进行打印。

我们将view的状态序列化为json字符串，现在，我们的崩溃报告变成了这样：

现在来看看这些日志，我们不仅能看到崩溃发生之前的最后一个状态，而且还能看到用户达到这个状态所经历的完整历史记录——为了保证可读性，我将data字段内的内容替换为了[...]：

• 1.用户启动了App，通过加载首页数据的intent,这样loadingFirstPage的值为true，使得加载指示器展示了出来，同时数据也被加载完毕（data[…]）。

• 2.接下来用户滚动列表，并达到了列表的底部，这触发了加载下一页数据的intent，并开始加载更多的数据（分页），这也导致了loadingNextPage状态的改变，它的值变成了true。

• 3.一旦分页数据被加载成功，loadingNextPage状态改变成了false,用户再次重复操作达到了列表的底部，并又一次出发了触发了加载下一页数据的intent。

• 4.接下来用户开始尝试下拉刷新的intent,这导致loadingPullToRefresh状态变更为了true，然后，App突然发生了崩溃—— 这之后就没有更多日志了。

这些信息如何帮助我们解决这个bug呢？显然，我们知道用户触发了哪些操作，因此我们完全可以手动复现这个崩溃。此外，因为我们将App的状态用json进行表现，因此我们可以简单地使用最后一个状态，反序列化json并将此状态作为我们的初始状态来修复该错误：

String json ="  {\"data\":[...],\"loadingFirstPage\":false,\"loadingNextPage\":false,\"loadingPullToRefresh\":false} ";
HomeViewState stateBeforeCrash = gson.fromJson(json, HomeViewState.class);
HomePresenter homePresenter = new HomePresenter(stateBeforeCrash);

接下来我们打开了Debug调试工具，并尝试触发下拉刷新的intent,事实证明，如果用户向下滚动页面2次，则没有更多数据可用，并且我们的App并没有进行相应的处理，因此后续的下拉刷新操作导致了崩溃。

结语

一个应用状态随时随地 可快照 的App可以使我们开发人员的生活更加轻松。我们不仅能够轻松的 复现崩溃，而且可以将状态进行序列化来 编写回归测试，并且这几乎没有什么成本。

请记住，这些便利只有在App的状态遵循 单项数据流 、不可变、纯函数 的原则的情况下才能享受到（即被业务逻辑驱动），Model-View-Intent让我们偏向了这种思想流派，而这个架构模式中有一个非常棒并且有效的额外的效果，那就是本文所提到的构建了一个 可快照 的App。

可快照 的应用有什么缺陷呢？显然我们正在将App的状态序列化（比如通过Gson）.这增加了一些额外的计算资源的负荷，平均来算的话，状态第一次被Gson序列化大约需要30毫秒，因为Gson必须使用反射来扫描类，以确定必须序列化的字段。

在Nexus 4上，状态的连续序列化平均需要大约6毫秒。由于序列化在.doOnNext()中运行，虽然这通常在后台线程上运行，但的确是这样：我的App用户必须比其它应用的用户多等待6毫秒，才能在屏幕上看到新的状态。

我的观点是，这对于用户来说也许并不明显，但是对状态进行 快照 的一个问题是，在崩溃时，崩溃报告工具从用户设备上传到其服务器的数据量要大得多—— 如果用户通过wifi连接，这无关痛痒，但如果用户处于移动网络下则可能会有一定的争议。

最后，将状态附加在崩溃报告中时，您可能会泄漏用户的一些敏感的数据。针对这个问题，一个方案是不序列化敏感数据，但这可能导致连接到崩溃报告的状态不完整（因此这些报告可能几乎无用），另外一个方案则是将敏感数据进行加密——但这可能需要一些额外的CPU占用。

总结一下：我个人认为这样 可快照 的App有很多优点，但是，你可能需要做出一些权衡。也许您开始为内部版本或beta版本启用App快照，以衡量它其产生的作用。

---

系列目录

《使用MVI打造响应式APP》原文

• Part 1: Model
  
• Part 2: View and Intent
• Part 3: State Reducer
• Part 4: Independent UI Components
  
• Part 5: Debugging with ease
  
• Part 6: Restoring State
  
• Part 7: Timing (SingleLiveEvent problem)
  
• Part 8: In-App Navigation
  

《使用MVI打造响应式APP》译文

• [译]使用MVI打造响应式APP(一):Model到底是什么
• [译]使用MVI打造响应式APP[二]:View层和Intent层
• [译]使用MVI打造响应式APP[三]:状态折叠器
• [译]使用MVI打造响应式APP[四]:独立性UI组件
• [译]使用MVI打造响应式APP[五]:轻而易举地Debug
• [译]使用MVI打造响应式APP[六]:恢复状态
• [译]使用MVI打造响应式APP[七]:掌握时机(SingleLiveEvent问题)
• [译]使用MVI打造响应式APP[八]:导航

《使用MVI打造响应式APP》实战

• 实战：使用MVI打造响应式&函数式的Github客户端

---

关于我

Hello，我是却把清梅嗅，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的博客或者Github。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费