端上H5的性能优化
# 端上H5的性能优化
# 背景
在端上H5页面点击到首屏展示的一般需要3-4秒时间，页面的加载时间过长，导致用户的使用体验不佳
# 测试问题所在
通过在页面上添加埋点，对加载H5的流程进行埋点处理，统计加载时间
通过分析：
大部分的图片还是存在与API端的，但是在展现的过程中，图片往往可能出现图片展示比较慢甚至展示不出来的问题
首屏的渲染上，在部分页面会出现加载loading一直在等待的情况，也就是说，这时候调用了请求数据的接口，存在一个点是服务端的信息返回的不是很及时，另外一点，在数据请求之后，端上h5渲染的过程也是一个时间的消耗
大致分类
服务器方向：增加服务器的数量，事实表明，在线下测试的一台服务器的情况下，加载的速度是很慢的
信息传递方向：在请求和响应数据上，对必要的数据做请求，避免没必要的请求
前端层面：在前端的整体架构上，避免不需要的状态维护，通过过多的状态逻辑的处理导致前端的计算过多，容易出现问题且代码的性能不佳，在动画上，加载数据
# 浏览器（webview）渲染过程
渲染引擎：
第一步：解析HTML构建DOM树，从HTML标签解析开始，将各个标签解析为DOM树中的节点，标签与节点一一对应
第二步：构建渲染树，将CSS和style标签中的样式信息解析为渲染树，渲染树由一些有颜色大小的矩形组成
第三步：渲染树布局，确定每个节点在屏幕上的确切的位置
第四步：渲染树绘制，遍历渲染树并用UI后端层将每一个节点绘制出来
执行过程：
- 1.解析HTML结构
- 2.加载外部脚本和样式表文件。
- 3.解析并执行脚本代码。//部分脚本会阻塞页面的加载。
- 4.DOM树构建完成。//DOMContentLoaded事件。
- 5.加载图片等外部文件。
- 6.页面加载完毕。//load事件
测试相关指标：
- HTTP相关
http请求个数。解决方案：CSS精灵、图片地图、js css合并。
2.组件是否压缩。解决方案：压缩方法、压缩对象、图片格式和大小是否合适、CSS放在顶部、JS放在底部、js & CSS压缩、是否添加缓存、避免非200返回值、使用CDN。
- 时间相关[耗时]
1.白屏时间：用户首次看到网页有内容的时间，即第一次渲染流程完成时间。
2.首屏时间：用户看到第一屏，即整个网页顶部大小为当前窗口的区域，显示完整的时间。尽量让它满足一秒钟法则。
3.首资源下载时间：从开始下载到第一个资源均下载完成的时间，不包括页面绘制时间。
4.总资源下载时间：从开始下载到所有资源均下载完成的时间，不包括页面绘制时间。
5.用户可操作时间：从页面开始加载到用户操作可响应的时间。
- WebView相关[内存/流量、CPU]
在android和IOS上测试H5性能，测试员还应该关注因加载H5而引起的app常规性能指标。
1.内存：加载页面前后内存变化，可间接反映H5中资源数量和大小，如dom数量，图片大小。
2.CPU：当页面中资源样式复杂，强调视觉效果时，测试员可观察CPU占用率来反映H5绘制质量。如果CPU长期处于高占用率，可考虑降低高计算量的视觉效果等手段。
3.FPS(流畅度)：帧率尤其在有视频和动画效果的H5中，测试员应该重点关注，防止严重的卡顿流出。
# 处理方式
**提前做：**预创建WebView和预加载数据
并行做：
**轻量化：**减少不要的JS和CSS，可以缩短网络请求时间，提升内核解析时间
**简单化：**减少HTTP请求数，图片优化，
https://www.cnblogs.com/wendyw/p/12443529.html
# 关于Hybird开发
# Hybrid开发模式
Hybrid开发模式，即混合开发，也就是采用半原生和半Web的开发形式，介于Web app和Native App两者之间的app，页面中的主流成采用端的处理能力，调用原生的bridge实现，成本低，在开发过程中的灵活性比较好，在Android和IOS的开发上，原本需要两套开发的成本处理成本（兼具native app良好的用户交互体验优势和web app跨平台开发的优势）
目前这边大致情况是：程序的底层核心框架、核心逻辑、界面整体框架交给Native，H5用于实现业务逻辑，用到vue框架加上端上的bridge，H5界面使用动态地址，大到可以配置的效果
代码层面需要关注的事：分辨率，兼容性，性能和浏览器的支持问题，性能的问题相较于native来说较差了