[译]使用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和每个intentresult——也就是即将渲染在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》原文

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

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


关于我

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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,558评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,002评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,036评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,024评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,144评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,255评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,295评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,068评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,478评论 1 305
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,789评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,965评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,649评论 4 336
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,267评论 3 318
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,982评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,223评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,800评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,847评论 2 351

推荐阅读更多精彩内容