vue

介绍

uni-app是逻辑和渲染分离的。渲染层,在app端提供了两套排版引擎:小程序方式的webview渲染和weex方式的原生渲染。 两种渲染引擎可以自己根据需要选。vue文件走的webview渲染,nvue走的原生渲染,二者可以混用,根据需要采用不同的渲染引擎。 组件和JavaScript写法是一样的,css不一样,原生排版的能用的css必须是flex布局,这是web的css的子集。

uni-appApp端内置了一个基于weex改进的原生渲染引擎,因此可以使用nvue,但是nvue的css写法受限,所以如果不开发APP,可以不使用nvue,下面有些正确和错误的css写法示例对比:

选择器仅支持class 选择器

/* 错误 */
#id {}
.a .b .c {}
.a > .b {}

/* 正确 */
.class {}

border 不支持简写

/* 错误 */
.class {
   border: 1px red solid;
}

/* 正确 */
.class {
   border-width: 1px;
   border-style: solid;
   border-color: red;
}

background 不支持简写

/* 错误 */
.class {
   background: red;
}

/* 正确 */
.class {
   background-color: red;
}

nvue优势

需要高性能的区域长列表或瀑布流滚动。webview的页面级长列表滚动时没有性能问题的(就是滚动条覆盖webview整体高度),但页面中某个区域做长列表滚动,则需要使用nvue的list、recycle-list、waterfall等组件。这些组件的性能要高于vue页面里的区域滚动组件scroll-view。

复杂高性能的自定义下拉刷新。uni-app的pages.json里可以配置原生下拉刷新,但引擎内置的下拉刷新样式只有雪花和circle圈2种样式。如果你需要自己做复杂的下拉刷新,推荐使用nvue的refresh组件。当然插件市场里也有很多vue下的自定义下拉刷新插件,只要是基于renderjs或wxs的,性能也可以商用,只是没有nvue的refresh组件更极致。

左右拖动的长列表。在webview里,通过swiper+scroll-view实现左右拖动的长列表,前端模拟下拉刷新,这套方案的性能不好。此时推荐使用nvue,比如新建uni-app项目时的新闻示例模板,就采用了nvue,切换很流畅。

实现区域滚动长列表+左右拖动列表+吸顶的复杂排版效果,效果可参考hello uni-app模板里的swiper-list

如需要将软键盘右下角按钮文字改为“发送”,则需要使用nvue。比如聊天场景,除了软键盘右下角的按钮文字处理外,还涉及聊天记录区域长列表滚动,适合nvue来做。

解决前端控件无法覆盖原生控件的层级问题。当你使用map、video、live-pusher等原生组件时,会发现前端写的view等组件无法覆盖原生组件,层级问题处理比较麻烦,此时使用nvue更好。或者在vue页面上也可以覆盖一个subnvue(一种非全屏的nvue页面覆盖在webview上),以解决App上的原生控件层级问题。

如深度使用map组件,建议使用nvue。除了层级问题,App端nvue文件的map功能更完善,和小程序拉齐度更高,多端一致性更好。

如深度使用video,建议使用nvue。比如如下2个场景:video内嵌到swiper中,以实现抖音式视频滑动切换;nvue的视频全屏后,通过cover-view实现内容覆盖,比如增加文字标题、分享按钮。

直播推流:nvue下有live-pusher组件,和小程序对齐,功能更完善,也没有层级问题。

对App启动速度要求极致化。App端v3编译器模式下,如果首页使用nvue且在manifest里配置fast模式,那么App的启动速度可以控制在1秒左右。而使用vue页面的话,App的启动速度一般是3秒起,取决于你的代码性能和体积。

vue优势

canvas。nvue的canvas性能不高,尤其是Android App平台,所以这个组件干脆没有内置,而是需要单独引入。操作canvas动画,最高性能的方式是使用vue页面的renderjs技术,在hello uni-app里的canvas示例就是如此。

动态横竖屏。nvue页面的css不支持媒体查询,所以横竖屏动态切换、动态适配屏幕是很困难的。