nVue

uni-app App 端内置了一个基于 weex 改进的原生渲染引擎,提供了原生渲染能力。

在App端,如果使用 vue 页面,则使用 webview 渲染;如果使用 nvue(native vue) 页面,则使用原生渲染。一个 App 中可以同时使用两种页面,比如首页使用 nvue,二级页使用 vue 页面,hello uni-app 示例就是如此。

虽然 nvue 也可以多端编译,输出 H5 和小程序,但 nvue 的 css 写法受限,所以如果不开发 App,那么不需要使用 nvue。

以往的 weex ,有个很大的问题是它只是一个高性能的渲染器,没有足够的 API 能力(比如各种 push sdk 集成、蓝牙等能力调用),使得开发时非常依赖原生工程师协作,开发者本来想节约成本,结果需要前端、iOS、Android 3 拨人开发,适得其反。 nvue 解决了这个问题,让前端工程师可以直接开发完整 App,并提供丰富的插件生态和云打包。这些组合方案,帮助开发者切实的提高效率、降低成本。

同时 uni-app 扩展了 weex 原生渲染引擎的很多排版能力,修复了很多 bug。比如:

  • Android 端良好支持边框阴影。
  • iOS 端支持高斯模糊。
  • 可实现区域滚动长列表 + 左右拖动列表 + 吸顶的复杂排版效果。
  • 优化圆角边框绘制性能。

适用场景

nvue 的组件和 API 写法与 vue 页面一致,其内置组件还比 vue 页面内置组件增加了更多。如果熟悉 weex 或 react native 开发,那么 nvue 是更优选择,能切实提升开发效率,降低成本。

如果是 web 前端,不熟悉原生排版,那么建议仍然以使用 vue 页面为主,在 App 端某些 vue 页面表现不佳的场景下使用 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。