H5页面布局灵活、轻量级、跨平台，在业务中应用场景非常多。但同时，与App相比，H5的表现始终不如人意。比如打开页面经常出现白屏，滑动列表等交互场景不如Native页面流畅。针对这些白屏、卡慢等问题，我们应该测试哪些方面来进行测试分析和数据对比呢？接下来笔者将分享一些在H5前端测试实践中的心得，希望大家一起探讨探讨更多有价值的话题。1、打开：H5页面加载过程分析如下图所示，是在所选平台打开H5页面过程的几张截图。图1至图4可以简单分类。图1是App负责的，主要是初始化Webview上下文；下面三张图是一个H5页面的加载过程。其中App阶段的耗时主??要是Native代码的耗时。这里我们先不讨论，接下来的几个阶段我们会重点介绍。第四张图是用户直观看到的第一屏页面，我们通常称之为首屏。1）加载网络请求的过程主要是Webview拿到H5页面的url后，调用loadUrl方法，开始请求网络上的第一个资源文件。该阶段主要包括dns解析、网络链接建立、数据传输等耗时。2）HTML解析Webview获取回html后，需要从上到下解析html中的标签和内容，识别外部链接资源，计算页面框架的布局，渲染绘制。在这个过程中，会构建负责页面结构的DOMTree和负责页面布局展示的RenderTree，如下图：3）外链资源加载这部分主要是加载外链css，图片和js来自互联网，然后重新填充html。之后再次进行布局计算和页面渲染，此时看到的是内容完整的页面。如下图所示，页面需要等待图片和css加载完成后才能显示。JS也是一种外链资源，但一般来说，只要加载在html底部，就不会阻塞页面的渲染和显示。2.实例分析：白屏问题我们已经了解了H5页面的加载流程。接下来，如果遇到白屏，我们自然会问，如何知道页面当前处于哪个阶段，每个阶段需要多长时间，以及加载整体首屏需要多长时间？先看通过PCChrome模拟H5页面的情况。ChromeDevtool提供的Performance工具可以记录页面从第一次请求到加载完成的所有事件。这样就可以详细的看到每个阶段做了什么，具体耗时多少。最关键的两个首屏耗时指标：domContentLoaded（首屏页面可见）和onLoad（首屏加载完成），除了图中所示的方法，还可以打印控制台中的全局变量window.performance。计时，获取时间戳并计算它。但实际上，我们要的是移动设备的真机数据，能够真实反映页面性能和用户体验。获取耗时的H5真机，一种方式是上报js代码；另一种是针对Android设备，可以使用remote-debug方式远程调试真实设备页面。你只需要确保webview调试开关打开&连接到PCUSB并且打开USB调试，然后你就可以在PCChrome上访问chrome://inspect来获取调试器。然后参考PCChrome模拟H5的方法获取数据。对于传统页面，实际分析发现大部分耗时的部分还是在移动端网络请求，所以最直接有效的方式就是直接修改页面，即改变先加载html的情况，然后加载css等数据，先把首屏依赖的所有css、js和后台界面数据并行加载到后端（比如nodejs），组装成一个完整的html最后呈现，然后发送回到前端，实现瞬间打开的效果。3.实例分析：慢速问题有时候用户在页面交互的时候会遇到慢速，比如列表上下滑动，左右切换，或者轮播等等，这个过程无非就是执行js，请求资源，计算新的页面布局、渲染和绘图。通过性能分析，我们会发现卡慢并不像很多人认为的那样完全是因为“传输设备性能差”，有的时候其实是假卡顿。例如下面是热区过小的问题：在真卡的情况下，脚本错误往往占很大比例。直观的表现就是页面卡顿，而不是变慢。其他如内存问题，一般表现为页面卡顿，因为使用时间越长，资源消耗越大。比如页面使用了比较复杂的canvas动画，比较耗性能的iframe元素，或者流媒体直播，这种情况下就容易出现内存泄露。下面是dom节点导致的内存泄漏。未使用的commentList列表不释放，累积到数万长度时开始冻结。4、总结：H5前端性能测试方案当然，前端性能不仅仅表现在白屏和卡顿问题，还有可能是手机过热等问题。从用户的核心体验出发，我们认为H5前端性能最重要的参考标准是：以最轻的方式给用户最好的体验。从这个方向出发，我们积累了一些测试经验，其中最重要的是首屏速度（不仅提高了用户体验，也提高了业务的转化率），其次是流畅度、流量和CPU等等，在某些场景下也是需要考虑的一点。
