H5 Crash 研究

我们知道,支撑页面在 webview 上良好运转的前提是具备一个高效并且稳定的 webview 容器,而容器的高效稳定不仅仅由容器提供方来保障,也需要容器使用者遵守一些基本准则,否则就有可能出现页面 Crash 的情况,这些准则是什么?什么样的上层代码会引起容器异常退出?这是本文需要阐述的内容。

H5 Crash 问题概况

下图是 H5 Crash 的大致流程图:

H5 Crash 流程图

由于前端没办法捕捉到页面 Crash 的状态和堆栈,但是 H5 页面上发生的错误会传递到 Java 和更底层的 Native 直到容器异常退出,在退出的那一刻,容器会将堆栈写入到日志中,当下次打开容器时(也可能是定时上报)就会上报这些堆栈信息。

H5 Crash 原因初探

测试代码 仓库地址

注意: 代码需要在 Webview 容器中测试,PC 浏览器下不会出现异常。

H5 Crash 的原因不太明显,但是从经验上判断和摸索,大致归类为以下三种:

1. 内存问题

  • 测试方法:使用闭包,不断增加内存量,看看增加到哪个区间大小, webview 容器会出现异常
  • 测试地址:https://rawgit.com/barretlee/h5crash/master/demo/crash-memory.html(微信、微博或者其他客户端打开该页面的用户,可以点进去测试下,选择 100M 内存,不出意外,你的客户端会闪退。)

存在的干扰:这种测试存在比较多的干扰,比如设备类型、系统类型(iOS/Android)、和设备内存运行状态等。

2. Layers 数问题

Layers 数的获取比较麻烦,Chrome Driver 没有提供该数据的接口,目前也没有比较好的办法拿到这个数据。

  • 实际上,创建多个层,也是对内存的巨大消耗,页面 Crash 可能还是因为内存消耗过大

3. 并发过多问题

  • 存在的干扰:设备的种类、设备的 CPU 使用情况和网络状况等。

H5 Crash 测试结果

测试结果:

  • 通过 opacity、animation、positon 等方式创建层,即便是 1w 个,页面也没有明显变化;但是使用 transform 创建 2k~5k 个层,页面会卡顿几秒后立即闪退;
  • 内存是条红线,测试发现,一次性消耗 20M 的内存,会导致客户端立即闪退;
  • 并发请求也是存在响应问题的,Fetch API 和 CSS Resource 并发 1k 请求没有出现问题,但是 XHR 和 Script Resource 请求,问题特别明显,虽然没有导致页面闪退,但是页面已经进入了假死状态。

以上临界值还可以继续精确。

小结

本文主要是对 H5 Crash 做了一个预研,测试可能存在诸多误差,测试方法也需要改进,不过沿着这些的思路考究会比较容易找到结论。

后续会给出比较有意义的边界数据以及探测工具。

 

1 3 收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部