我们知道，支撑页面在 webview 上良好运转的前提是具备一个高效并且稳定的 webview 容器，而容器的高效稳定不仅仅由容器提供方来保障，也需要容器使用者遵守一些基本准则，否则就有可能出现页面 crash 的情况，这些准则是什么？什么样的上层代码会引起容器异常退出？这是本文需要阐述的内容。
h5 crash 问题概况 下图是 h5 crash 的大致流程图：
由于前端没办法捕捉到页面 crash 的状态和堆栈，但是 h5 页面上发生的错误会传递到 java 和更底层的 native 直到容器异常退出，在退出的那一刻，容器会将堆栈写入到日志中，当下次打开容器时（也可能是定时上报）就会上报这些堆栈信息。
h5 crash 原因初探 测试代码 仓库地址 ：
git clone https://github.com/barretlee/h5crash.git;cd demo;
注意：代码需要在 webview 容器中测试，pc 浏览器下不会出现异常。
h5 crash 的原因不太明显，但是从经验上判断和摸索，大致归类为以下三种：
1. 内存问题 测试方法：使用闭包，不断增加内存量，看看增加到哪个区间大小， webview 容器会出现异常 测试地址： https://rawgit.com/barretlee/h5crash/master/demo/crash-memory.html （微信、微博或者其他客户端打开该页面的用户，可以点进去测试下，选择 100m 内存，不出意外，你的客户端会闪退。） 增加 1m 内存消耗增加 10m 内存消耗增加 20m 内存消耗增加 50m 内存消耗增加 100m 内存消耗内存消耗：0 m

存在的干扰：这种测试存在比较多的干扰，比如设备类型、系统类型（ios/android)、和设备内存运行状态等。 2. layers 数问题 layers 数的获取比较麻烦，chrome driver 没有提供该数据的接口，目前也没有比较好的办法拿到这个数据。
测试方法：通过不同的方式创建层，观察页面的 crash 情况 测试地址： https://rawgit.com/barretlee/h5crash/master/demo/crash-layer.html 层类型: 通过 opacity 创建层 通过 transforms 创建层 通过 animation 创建层 通过绝对定位分层创建 1 个层创建 10 个层创建 20 个层创建 50 个层创建 100 个层创建 200 个层创建 500 个层创建 1000 个层创建 2000 个层创建 5000 个层创建 10000 个层
实际上，创建多个层，也是对内存的巨大消耗，页面 crash 可能还是因为内存消耗过大 3. 并发过多问题 测试方法：尝试并发发出多种不同的请求（fetch请求、xhr 请求、script/css 资源请求），观察页面 crash 情况 测试地址： https://rawgit.com/barretlee/h5crash/master/demo/crash-request.html 请求类型: 使用 fetch 发送请求 使用 xhr 发送请求 并发请求脚本资源 并发请求样式资源并发 1 个请求并发 10 个请求并发 20 个请求并发 50 个请求并发 100 个请求并发 500 个请求并发 1000 个请求
存在的干扰：设备的种类、设备的 cpu 使用情况和网络状况等。 h5 crash 测试结果 测试结果： 通过 opacity、animation、positon 等方式创建层，即便是 1w 个，页面也没有明显变化；但是使用 transform 创建 2k~5k 个层，页面会卡顿几秒后立即闪退； 内存是条红线，测试发现，一次性消耗 20m 的内存，会导致客户端立即闪退； 并发请求也是存在响应问题的，fetch api 和 css resource 并发 1k 请求没有出现问题，但是 xhr 和 script resource 请求，问题特别明显，虽然没有导致页面闪退，但是页面已经进入了假死状态。 以上临界值还可以继续精确。
小结 本文主要是对 h5 crash 做了一个预研，测试可能存在诸多误差，测试方法也需要改进，不过沿着这些的思路考究会比较容易找到结论。
后续会给出比较有意义的边界数据以及探测工具。