ios webview加载 ifram_webview与跨平台框架性能差距扫盲

今天聊一个大家都知道的老话题，为什么跨平台框架比h5体验更佳？话题虽老，但是真正较为全面理解其中原委的可能也不多，今天就尝试从前端和原生角度来简单阐述阐述，扫个盲。

关键环节

为了描述简单起见，会用RN统一代替跨平台框架。

首先对于h5来说，资源文件加载永远都是第一步，如何尽可能缩短资源文件触达终端的时间以提升用户体验是每一位前端开发和官方都孜孜不倦试图解决的问题。尽可能地压缩资源文件，提升服务器性能，让首次加载更快，配合使用浏览器缓存，localstorage，甚至是乏力的离线缓存等各种缓存方案，都是为了不重复加载以提升二次进入的体验。而跨平台方案，预加载可以一次性直接地解决这个问题，即使最差的情况预加载碰上了用户更加极致的手速，最差也是打个平手。

再说js执行，一个字就是慢，虽然主流v8，jscore等等引擎都已经不仅仅是简单的解释器，引入了诸如隐藏类、內联缓存等这些方式解决动态语言类型缺失的编译速度问题，在后端生成字节码上也是操碎了心地优化编译，当然提升是显著的，尽管对比原生静态语言的执行还是慢。

以上是webview众所周知的看得见的短板，而这仅仅是冰山一角，但它真正最大的性能障碍其实隐藏于这皮囊之下。

我们把目前的跨平台分为三大类，flutter，类rn和普通h5，其中flutter底层使用了跨平台渲染引擎skia，虽然与类rn依赖各自平台原生渲染不同，但本质上是一样的，flutter 和类rn的区别不属于本文扫盲贴范畴，这里主要谈谈它们比h5牛逼在哪里。

核心渲染机制

从底层渲染机制上说，目前来说各大平台都已经全面支持gpu渲染，cpu负责视图创建，布局计算，视图渲染以及图像解码，生成图元信息，完成后提交gpu进行顶点着色，栅格化等处理，这时候才是真正将图元信息转换具体像素点信息，并对像素进行颜色填充等等。无论安卓iOS原生或者H5都差别不大，但是h5的差别在于webview渲染是使用独立的渲染进程，渲染完成后无法与gpu共享纹理资源，需要通过IPC通信将资源同步gpu进程，而对于原生渲染来说仅仅一个render线程相对于独立进程的开销来说那就好得多，对于极限的16ms刷新频率来说，任何多余的开销都有可能是对性能的雪上加霜。

页面呈现出来后，用户就要开始进行交互了，交互最终的目标往往就是触发UI更新，UI更新就可能导致体验问题。例如滑动长列表快速滚动就是常见的手势触发UI更新，而白屏是滚动过程中常见体验问题，究其原因也是可以从前面窥见一二。快速滚动需要触发界面不断刷新，每次刷新都需要经历dom树更新->render树更新->render layout->IPC同步gpu资源->gpu栅格化->渲染成像，而RN等跨平台UI更新路径短的多。除此之外还有可能需要执行一些js计算，js的过度执行可能导致主线程阻塞，导致丢帧，这也是浏览器本身机制的客观限制，我们能做的就是尽可能少做无用工。比如RN从最初的listview->flatlist，最大限度复用组件，尽可能不渲染看不见的区域，也是对这一原则的最佳实践。

H5体验问题更大在于浏览器机制以及webview的客观限制，而跨平台框架则主要是借力原生能力进行增强，作为开发者我们能做的就是更加深入理解它们，尽可能减小它们的负担，最大化其价值。