uni-app 性能优化建议

1. 前言

初期学习开发 uni-app 项目，我们一般不会在意项目的性能问题，项目功能较少或者数据较少的时候，不会对项目性能的重要性有很大的感受。

但如果开发大型项目，或者数据量比较大的时候，项目性能的问题就显得尤为重要。一种需求的不同实现方式，页面的加载速度会差几倍甚至上百倍。

所以我们在开发项目之前，最好先了解一下项目性能优化的几种方式，在项目初期就打好基础，以免后期维护过于麻烦。

这节课我们主要讲解一些性能优化的小建议，在项目开发之前最好看一看，知道开发的重点需要注意哪些地方。

2. uni-app 运行原理

uni-app 项目的视图层和逻辑层是分离开的，虽然我们在开发项目过程中，将 html、js 代码都写在同一个文件中，但是实际运行的时候是分离开的。

视图层负责进行页面渲染，也就是用户能看到的页面，用来展示数据的，包括页面结构代码 <template> 部分、页面样式代码 <style> 部分。

逻辑层负责执行后端的业务逻辑，用户看不到这部分的逻辑，用来处理数据的，包括页面逻辑代码 <script> 部分，以及其他 .js 文件。

视图层和逻辑层分离，减少了项目的耦合程度，并且逻辑层的运算不会影响到视图层的渲染，窗体动画会比较稳。而两层分离也有一个缺点，就是这两层互相通信会有损耗。

我们下面进行的性能优化，都是基于uni-app 运行原理来操作的，下面来具体看一下。

3. 性能优化建议

3.1 长列表优化

我们开发项目时，我们经常会循环长列表，将长列表中的数据逐一展示在项目中，但是你开发过程中，有没有出现过一旦数据过多项目加载会变得很慢的问题呢？

长列表的应用有许多需要我们注意的地方，或许你在开发过程中没有注意下面几个问题造成长列表加载过慢，我们来具体看看。

3.1.1 长列表差量数据更新

如果你长列表的数据中，每个列表都有可能差量更新，则需要将长列表中的每个 item 都做成一个组件。不然其中每个 item 更新，都会造成整个长列表的重新加载，严重良妃系统资源，我们来举个例子。

比如我们加载博文的100条评论，每条评论都有一个点赞功能。

如果每条评论没有做成单独的组件，用户每次给其中一条评论点赞一次，系统都会重新加载这100条评论。

如果每条评论都做成了单独的组件，用户给其中一条评论点赞，系统只会重新加载点赞的这一条评论，其他评论不受影响，合理利用系统资源。

实例：

<template>
    <view>
        <view class="thumb" v-for="item in testdata">
            <view>{{item}}</view>
        </view>
    </view>
</template>

<script>
    export default {    
        data() {
            return {
                testdata: ["评价1","评价2","评价3","评价4","评价5"]
            }
        }
    }
</script>

<style>
    .thumb{
        text-align: center;
        margin-top: 20px;
    }
</style>

// thumbitem.vue 将每个 item 包装成组件
<template>
    <view>
        <!-- 显示 item 信息 -->
        <view>{{item}}</view>
        <!-- 点赞按钮，点击触发 thumb 方法 -->
        <button @click="thumb(index)">点赞数：{{thumbs}}</button>
    </view>
</template>

<script>
    export default {
        props:['item'],
        data() {
            return {
                thumbs:0
            };
        },
        methods: {
            // 每次触发 thumb 方法,点赞数 thumbs 变量就加 1
            thumb(){
                this.thumbs += 1
            }   
        }
    }
</script>

3.1.2 长列表无差量数据更新

如果长列表中，每个 item 不会单独去更新，那我们就没有必要去将每个 item 都做成一个组件了，直接循环长列表显示 item 就可以。

实例：

// index.vue 循环加载长列表
<template>
    <view>
        <view class="thumb" v-for="item in testdata">
            <ThumbItem :item='item'></ThumbItem>    
        </view>
    </view>
</template>

<script>
    Import ThumbItem from "components/thumbitem/thumbitem.vue"
    export default {    
        components: {
            ThumbItem
        },
        data() {
            return {
                testdata: ["评价1","评价2","评价3","评价4","评价5"]
            }
        }
    }
</script>

<style>
    .thumb{
        text-align: center;
        margin-top: 20px;
    }
</style>

我们在开发过程中，不需要每次都将长列表的 item 包装成组件，每个 item 需要差量数据更新的时候，才需要包装成组件。

组件在页面初始化时会占用更多的内存，并且遍历节点也会更慢，每个组件渲染时都会触发一次通信，太多组件就会阻塞通信。所以我们要将好刀用在刀刃上，不分情况到处使用反而会适得其反。深层节点的嵌套也是同样的道理，我们开发的时候要注意尽量避免深层节点嵌套。

在实际项目开发中，长列表一般是由逻辑层处理后返回的，数据是变化的，如果长列表中的数据需要展示在页面上，那么我们就将长列表定义在 data 中，如果变量不需要展示在视图中，我们尽量将变量定于在 data 外部。

因为data 中的数据每次发生变化，视图层都要重新渲染页面。这样做可以尽量避免资源的浪费，这条建议同样也适用于其他变量。

3.2 减少一次性加载的节点数量

页面初始化时，逻辑层如果一次性向视图层传递很多数据，不仅会造成逻辑层和视图层之间的通讯变化，由于视图层一次渲染的数据过多，还会造成页面的卡顿。

所以如果数据过多，建议进行分页加载。比如：服务端要返回1000条数据，可以一次加载100条，500ms 后再进行下一次加载。

3.3 尽量避免两层频繁通信

上面我们提到过，逻辑层与视图层分离会造成一个缺点，就是两层之间通讯的损耗，如果两层之间频繁通信，可能会造成通讯阻塞，影响项目的正常运行，如果尽量避免两层之间的频繁通信呢？主要有以下几点：

3.3.1 scroll-view 组件的使用

• 使用scroll-view 组件时，要尽量减少监听滚动事件，因为在监听 scroll-view 的滚动事件时，视图层会频繁的向逻辑层发送数据；
• 不要实时的改变 scroll-top、scroll-left 属性，可能造成通讯卡顿；
• 如果要实现下拉刷新的功能，建议使用页面的滚动，而不是 scroll-view；
• 不要在 scroll-view 组件中放长列表，会导致性能问题。

3.3.2 图片、动画加载问题

• 尽量使用压缩图片；
• 尽量使用css 动画，而不是通过 js 的定时器操作界面做动画；
• 如果项目中不可避免的需要加载大量的动画和图片，建议加载时进行延时处理，分批进行大量数据通讯，提高页面的流畅性。否则会造成页面切换卡顿、掉帧等问题；
• App-nvue 和 H5 项目总，还支持页面预载，使用API uni.preloadPage，开发时可以使用提高用户的操作体验。

3.4 使用nvue代替vue

因为 nvue 页面开发限制比较多，我们前面建议大家尽量不要使用 nvue 来开发项目，但是如果更加看重项目性能问题，可以使用nvue 来代替 vue。

因为 nvue 是基于 weex 的原生渲染，可以有效提高页面的流畅程度。

如果对项目启动速度有更高的要求，如果项目支持的话，甚至可以将项目设置为纯 nvue 项目，这样整个应用都使用原生渲染，不加载 webview 框架，这样项目的启动速度会更快。

4. 小结

性能优化问题，在项目开发过程中，会变得越来越重要，最好在开发之前就了解各种优化性能的小技巧，这样后期开发也会更加得心应手一些。

本小节可以先浏览一遍项目开发中性能优化的这几个建议，大体记得哪些方面需要注意。等项目用到的时候，再来结合课程应用到实际项目中，这样也会理解的更加深刻。