前言
这是今年GMTC北京场之后回来分享的一个ppt
背景&场景
- app原⽣开发投⼊资源成本⾼
- iOS审核难
- 需要版本升级才可以使新功能触达到⽤户
- …
以上种种问题引发了 Hybrid APP 出现，且h5页面越来越多，从补充式到基本替代
当占有率提高了，该考虑 白屏 的问题了
渲染的方式&过程
优化方向
native耗时，主要体现在webview壳子的准备上
- 提前准备WebView
- 复用WebView
- …
webview耗时，主要体现在前端资源的准备上
- CDN
- 分包，只加载核⼼的
- ⾸屏拆接⼝
- 接⼝数据缓存，对于⽐较稳定的⻚⾯进来，先展示上次的数据，再请求接⼝做替换
- 接⼝PreFetch
- 甚⾄前端资源离线化，file://
- …
渲染耗时
前端渲染方式
- CSR
SSR
麻烦，要伸⼿到服务端，项⽬也多，并且不能对标Native渲染
PWA
3.1 http cache；https；
3.2 启动保活（分派进程，加载SW.js，启动线程）
3.3 在不同启动场景（浏览器重启，后台，锁屏…）
3.4 耗时100 - 1000ms
3.5 是⼀种优化，不是⽅式，不同维度
…?
前端渲染新方式
借助native的能⼒，模仿SSR的⼀种⽅式，也具备CSR的优点
模板 + 数据 = 页面
- 对于⾼流量⻚⾯，⽐如⻋辆详情⻚，制作模板，结构拿来复⽤
- 甚⾄数据也可以借助native来prefetch
- 把⽣成html string的动作交给native
NSR - 模板
对native的诉求
- 凡有native参与的动作，都需要考虑动态性，模板可以内置or下载
- data prefetch的策略，提⾼命中率
- 在要渲染的h5⻚⾯中，约定占位符标记，native render后替换
- 最⼩化模板，可以抽离出最⼩化的没有vdom但保留最⼩组件周期的库来⽀持渲染
- ⾸屏仅使⽤兼容ES5的语，避免引⼊polyfill，⾮⾸屏不限制
- ⾸屏只做渲染，所包含事件绑定、统计上报等逻辑全部移到异步chunk中
- …
总结
三种渲染方式的区别
预渲染的延伸
最后
整个优化过程，论写代码的话基本是native的同学在写，但是思考的角度却是从前端的角度出发的。