From 3437cfc00b29854fbcfa7e05694f8ad5c6f4c6bc Mon Sep 17 00:00:00 2001 From: wanganxp Date: Thu, 31 Oct 2019 00:21:44 +0800 Subject: [PATCH] Update performance.md --- docs/performance.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/performance.md b/docs/performance.md index 8e422969f..f89cb1fce 100644 --- a/docs/performance.md +++ b/docs/performance.md @@ -22,7 +22,7 @@ app-nvue和h5不存在此问题。造成差异的原因是小程序目前只提 #### 优化建议 -##### **使用自定义组件模式** +##### 使用自定义组件模式 使用自定义组件模式，在manifest中配置自定义组件模式（HBuilderX1.9起新建项目默认即为自定义组件模式）。 @@ -32,23 +32,23 @@ app-nvue和h5不存在此问题。造成差异的原因是小程序目前只提 之前的非自定义组件模式已经不再推荐，如果你的应用还是非自定义组模式，请尽快升级。 -##### **避免使用大图** +##### 避免使用大图 页面中若大量使用大图资源，会造成页面切换的卡顿，导致系统内存升高，甚至白屏崩溃。 尤其是不要把多张大图缩小后显示在一个屏幕内，比如上传图片前选了数张几M体积的照片，然后缩小在一个屏幕中展示多张几M的大图，非常容易白屏崩溃。 -##### **优化数据更新** +##### 优化数据更新 在 ``uni-app`` 中，定义在 data 里面的数据每次变化时都会通知视图层重新渲染页面。 所以如果不是视图所需要的变量，可以不定义在 data 中，可在外部定义变量或直接挂载在vue实例上，以避免造成资源浪费。 -##### **长列表** +##### 长列表 - 长列表中如果每个item有一个点赞按钮，点击后点赞数字+1，此时点赞组件必须是一个单独引用的组件，才能做到差量数据更新。否则会造成整个列表数据重载。（要求自定义组件模式） - 长列表中每个item并不一定需要做成组件，取决于你的业务中是否需要差量更新某一行item的数据，如没有此类需求则不应该引入大量组件。（点击item后背景变色，属于css调整，没有更新data数据和渲染，不涉及这个问题） - app端nvue的长列表应该使用list组件，有自动的渲染资源回收机制。vue页面使用页面滚动的性能，好于使用scroll-view的区域滚动。 - 如需要左右滑动的长列表，请在HBuilderX新建uni-app项目选新闻模板，那是一个标杆实现。自己用swiper和scroll-view做很容易引发性能问题。 -##### **减少一次性渲染的节点数量** +##### 减少一次性渲染的节点数量 页面初始化时，逻辑层如果一次性向视图层传递很大的数据，使视图层一次性渲染大量节点，可能造成通讯变慢、页面切换卡顿，所以建议以局部更新页面的方式渲染页面。如：服务端返回100条数据，可进行分批加载，一次加载50条，500ms 后进行下一次加载。 @@ -56,7 +56,7 @@ app-nvue和h5不存在此问题。造成差异的原因是小程序目前只提 深层嵌套的节点在页面初始化构建时往往需要更多的内存占用，并且在遍历节点时也会更慢些，所以建议减少深层的节点嵌套。 -##### **避免视图层和逻辑层频繁进行通讯** +##### 避免视图层和逻辑层频繁进行通讯 * 减少 scroll-view 组件的 scroll 事件监听，当监听 scroll-view 的滚动事件时，视图层会频繁的向逻辑层发送数据； * 监听 scroll-view 组件的滚动事件时，不要实时的改变 scroll-top/scroll-left 属性，因为监听滚动时，视图层向逻辑层通讯，改变 scroll-top/scroll-left 时，逻辑层又向视图层通讯，这样就可能造成通讯卡顿。 @@ -64,12 +64,12 @@ app-nvue和h5不存在此问题。造成差异的原因是小程序目前只提 * 多使用css动画，而不是通过js的定时器操作界面做动画 * 如果是canvas里做跟手操作，建议使用web-view组件。web-view里的页面没有逻辑层和视图层分离的概念，自然也不会有通信折损。 -##### **优化页面切换动画** +##### 优化页面切换动画 * 页面初始化时若存在大量图片或原生组件渲染和大量数据通讯，会发生新页面渲染和窗体进入动画抢资源，造成页面切换卡顿、掉帧。建议延时100ms~300ms渲染图片或复杂原生组件，分批进行数据通讯，以减少一次性渲染的节点数量。 * App端动画效果可以自定义。popin/popout的双窗体联动挤压动画效果对资源的消耗更大，如果动画期间页面里在执行耗时的js，可能会造成动画掉帧。此时可以使用消耗资源更小的动画效果，比如slide-in-right/slide-out-right。 -##### **优化样式渲染速度，如背景色闪白** +##### 优化背景色闪白 * 如果页面背景是深色，在vue页面中可能会发生新窗体刚开始动画时是灰白色背景，动画结束时才变为深色背景，造成闪屏。这是因为webview的背景生效太慢的问题。此时需将样式写在 ``App.vue`` 里，可以加速页面样式渲染速度。``App.vue`` 里面的样式是全局样式，每次新开页面会优先加载 ``App.vue`` 里面的样式，然后加载普通 vue 页面的样式。 * 还可以在pages.json的globalStyle->style->app-plus->background下配置全局背景色 @@ -82,18 +82,18 @@ app-nvue和h5不存在此问题。造成差异的原因是小程序目前只提 ``` * 另外nvue页面不存在此问题，也可以更改为nvue页面。 -##### **使用 nvue 代替 vue** +##### 使用nvue代替vue 在 App 端 ```uni-app``` 的 nvue 页面可是基于 [weex](https://weex.apache.org/) 定制的原生渲染引擎，实现了页面原生渲染能力、提高了页面流畅性。若对页面性能要求较高可以使用此方式开发，详见：[nvue](/use-weex)。 -##### **优化App启动速度的注意** +##### 优化启动速度 * 工程代码越多，包括背景图和本地字体文件越大，对App的启动速度有影响，应注意控制体积。组件引用的前景图不影响性能。 * App端的 splash 关闭有白屏检测机制，如果首页一直白屏或首页本身就是一个空的中转页面，可能会造成 splash 10秒才关闭，可参考此文解决[https://ask.dcloud.net.cn/article/35565](https://ask.dcloud.net.cn/article/35565) * App端使用自定义组件模式时启动速度更快，首页为nvue页面时启动速度更快 * App设置为纯nvue项目（manifest里设置app-plus下的renderer:"native"），这种项目的启动速度更快，2秒即可完成启动。因为它整个应用都使用原生渲染，不加载基于webview的那套框架。 -##### **优化包体积** +##### 优化包体积 * uni-app发行到小程序时，自带引擎只有几十K，主要是一个定制过的vue.js核心库。如果使用了es6转es5、css对齐的功能，可能会增大代码体积，可以配置这些编译功能是否开启。 * uni-app的H5端，自带了vue.js、vue-rooter及部分es6 polyfill库，这部分的体积gzip后只有92k，和web开发使用vue基本一致。而内置组件ui库（如picker、switch等）、小程序的对齐js api等，相当于一个完善的大型ui库。但大多数应用不会用到所有内置组件和API。由此uni-app提供了摇树优化机制，未摇树优化前的uni-app整体包体积约500k，服务器部署gzip后162k。开启摇树优化需在manifest配置，[详情](https://uniapp.dcloud.io/collocation/manifest?id=optimization)。 -- GitLab