uni-app:从运行原理上面解决性能优化问题从运行原理上面解决性能优化问题
前言
Uni-App,从了解到开发,相信大家都会觉得Uni-App性能不好,其实也这是非原生的弊病。React Native、Flutter等,非原生
框架,性能上都会或多或少的折损。但各个框架,都会做出性能提升建议,所以开发者在开发前,多了解一下,后面维护升级
等就会更方便一点,否则项目越来越大,后续开发就会越来越难。
现在我们就从uni-app运行原理上,了解一下,在哪些方面存在性能折损问题?
运行原理
逻辑层和视图层分离,非H5端通信有折损
uni-app 在非H5端运行时,从架构上分为逻辑层和视图层两个部分。逻辑层负责储存数据和执行业务逻辑,视图层负责页面渲
染。
页面加载时,联网和逻辑运算在逻辑层(Android是v8,iOS是jscore),然后会传递数据给视图层渲染。这种通信有损耗。同
样,在视图层操作时,比如拖动页面,要实时传递事件给逻辑层接收,也是有损耗的。
App端渲染引擎可切换
在App端,nvue 页面的视图层是由原生引擎渲染的,vue 页面的视图层是os的 webview 渲染的。 uni-app 的 webview 渲染经
过优化,性能也足够好。它比 nvue 弱的地方主要在于启动速度和可左右拖动的长列表。
app-vue和小程序的数据更新,分页面级和组件级
对于复杂页面,更新某个区域的数据时,需要把这个区域做成组件,这样更新数据时就只更新这个组件,否则会整个页面的数
据更新,造成点击延迟卡顿。 这就是自定义组件编译模式的特点。
比如微博长列表页面,点击一个点赞图标,赞数要立即+1,此时这个点赞图标一定要做成组件。否则这个+1会引发页面级所