uni-app 性能优化建议
初期学习开发 项目,我们一般不会在意项目的问题,项目较少或者数据较少的时候,不会对项目的重要性有很大的感受。
但如果开发大型项目,或者数据量比较大的时候,项目的问题就显得尤为重要。一种需求的不同实现方式,的加载速度会差几倍甚至上百倍。
所以我们在开发项目之前,最好先了解一下项目优化的几种方式,在项目初期就打好基础,以免后期维护过于麻烦。
这节课我们主要讲解一些优化的小建议,在项目开发之前最好看一看,知道开发的重点需要注意哪些地方。
项目的视图层和逻辑层是分离开的,虽然我们在开发项目过程中,将 html、js 都写在同中,但是实际运行的时候是分离开的。
视图层负责进行渲染,也就是能看到的,用来展示数据的,结构 <template>
部分、样式 <style>
部分。
逻辑层负责执行后端的业务逻辑,看不到这部分的逻辑,用来处理数据的,逻辑 <script>
部分,以及其他 .js 。
视图层和逻辑层分离,减少了项目的耦合程度,并且逻辑层的运算不会影响到视图层的渲染,窗体动画会比较稳。而两层分离也有缺点,就是这两层互相通信会有损耗。
我们下面进行的优化,都是基于 运行原理来操作的,下面来具体看一下。
我们开发项目时,我们经常会循环长列表,将长列表中的数据逐一展示在项目中,但是你开发过程中,有没有出现过一旦数据过多项目加载会变得很慢的问题呢?
长列表的应用有许多需要我们注意的地方,或许你在开发过程中没有注意下面几个问题造成长列表加载过慢,我们来具体看看。
如果你长列表的数据中,每个列表都有可能差量更新,则需要将长列表中的每个 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:
};
},
methods: {
// 每次触发 thumb ,点赞数 thumbs 变量就加 1
thumb(){
this.thumbs +=
}
}
}
</script>
如果长列表中,每个 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 中的数据每次发生变化,视图层都要重新渲染。这样做可以尽量避免资源的浪费,这条建议同样也适用于其他变量。
初始化时,逻辑层如果一次性向视图层传递很多数据,不仅会造成逻辑层和视图层之通讯变化,由于视图层一次渲染的数据过多,还会造成的卡顿。
所以如果数据过多,建议进行加载。比如:服务端要返回1000条数据,可以一次加载100条,500ms 后再进行下一次加载。
上面我们提到过,逻辑层与视图层分离会造成缺点,就是两层之间通讯的损耗,如果两层之间频繁通信,可能会造成通讯阻塞,影响项目的正常运行,如果尽量避免两层之频繁通信呢?主要有以下几点:
因为 nvue 开发限制比较多,我们前面建议大家尽量不要使用 nvue 来开发项目,但是如果更加看重项目问题,可以使用nvue 来代替 vue。
因为 nvue 是基于 weex 的原生渲染,可以有效提高的流畅程度。
如果对项目启动速度有更高的要求,如果项目的话,甚至可以将项目设置为纯 nvue 项目,这样整个应用都使用原生渲染,不加载 webview 框架,这样项目的启动速度会更快。
优化问题,在项目开发过程中,会变得越来越重要,最好在开发之前就了解各种优化的小技巧,这样后期开发也会更加得心应手一些。
本小节可以先浏览一遍项目开发中优化的这几个建议,大体记得哪些方面需要注意。等项目用到的时候,再来结合课程应用到实际项目中,这样也会理解的更加深刻。