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。比如

nvue的组件和API写法与vue页面一致，其内置组件还比vue页面内置组件增加了更多，详见。但nvue在css的写法限制较多，具体如下：

如果你熟悉 weex或react native 开发，那么 nvue 是你的更优选择，能切实提升你的开发效率，降低成本。

如果你是web前端，不熟悉原生排版，那么建议你仍然以使用vue页面为主，在App端某些vue页面表现不佳的场景下使用 nvue 作为强化补充。这些场景如下：

但注意，在某些场景下，nvue不如vue页面，如下：

uni-app在App端，支持vue页面和nvue页面混搭、互相跳转。也支持纯nvue原生渲染。

启用纯原生渲染模式，可以减少App端的包体积、减少使用时的内存占用。因为webview渲染模式的相关模块将被移除。

在manifest.json源码视图的"app-plus"下配置"renderer":"native"，即代表App端启用纯原生渲染模式。此时pages.json注册的vue页面将被忽略，vue组件也将被原生渲染引擎来渲染。

如果不指定该值，默认是不启动纯原生渲染的。

如你之前是weex开发者，可以继续查阅本章节，否则可以跳过看下一节快速上手。

weex的组件和jsapi，与uni-app不同。uni-app与微信小程序相同。

考虑到weex用户的迁移，uni-app 也支持weex的代码写法。在manifest.json中可以配置使用weex编译模式或uni-app编译模式。选择weex编译模式时将不支持uni-app的组件和jsapi，需要开发者参考weex官方文档的写法来写代码。 比如 weex 编译模式用。uni-app 编译模式则使用。

一般情况建议使用uni-app模式，除非历史weex代码较多，需要逐步过渡。同时注意weex编译模式的切换是项目级的，不支持同项目下某个nvue页面使用weex模式，另一个nvue页面使用uni-app模式。

在 manifest.json 中修改2种编译模式，manifest.json -> app-plus -> nvueCompiler 切换编译模式。

nvueCompiler 有两个值：

如果没有在manifest里明确配置，默认是weex模式。这是为了向下兼容。

weex 编译模式不支持 onNavigationBarButtonTap 生命周期函数的写法。在 nvue 中监听原生标题栏按钮点击事件，详见：uni.onNavigationBarButtonTap。

weex编译模式不支持onShow生命周期，但熟悉5+的话，可利用监听webview的addEventListener show事件实现onShow效果。

weex 编译模式不支持vuex。

nvue 的页面跳转，与 weex 不同，仍然遵循 uni-app 的路由模型。vue 页面和 nvue 页面之间不管怎么跳转，都遵循这个模型。包括 nvue 页面跳向 nvue 页面。每个页面都需要在 pages.json 中注册，调用 uni-app 的 路由 API 进行跳转。

原生开发没有页面滚动的概念，页面内容高过屏幕高度并不会自动滚动，只有部分组件可滚动（list、waterfall、scroll-view/scroller），要滚得内容需要套在可滚动组件下。这不符合前端开发的习惯，所以在 nvue 编译为 uni-app模式时，给页面外层自动套了一个 scroller，页面内容过高会自动滚动。（组件不会套，页面有recycle-list时也不会套）。 可以设置不自动套。

weex 编译模式下支持使用 weex ui ，例子见：https://ext.dcloud.net.cn/plugin?id=442。但相比uni-app插件市场及官方uni ui而言，weex语法的组件生态还是比较欠缺的。

在HBuilderX的 uni-app 项目中，新建页面，弹出界面右上角可以选择是建立vue页面还是nvue页面，或者2个同时建。

不管是vue页面还是nvue页面，都需要在pages.json中注册。如果在HBuilderX中新建页面是会自动注册的，如果使用其他编辑器，则需要自行在pages.json里注册。

如果一个页面路由下同时有vue页面和nvue页面，即出现同名的vue和nvue文件。那么在App端，会仅使用nvue页面，同名的vue文件将不会被编译到App端。而在非App端，会优先使用vue页面。

如果不同名，只有nvue页面，则在非app端，只有uni-app编译模式的nvue文件才会编译。

nvue 页面结构同 vue, 由 template、style、script 构成。

HBuilderX内置了weex调试工具的强化版，包括审查界面元素、看log、debug打断点，详见

在 uni-app 中，nvue 和 vue 页面可以混搭使用。

推荐使用uni.$on,uni.$emit的方式进行页面通讯，旧的通讯方式（uni.postMessage及plus.webview.postMessageToUniNView）不再推荐使用。

通讯实现方式

使用此页面通讯时注意事项：要在页面卸载前，使用 uni.$off 移除事件监听器。参考

步骤：

代码示例:

步骤：

代码示例：

除了通信事件，vue 和 nvue 页面之间还可以共享变量和存储。 uni-app提供的共享变量和数据的方案如下：

1. vuex:

自HBuilderX 2.2.5起，nvue支持vuex。这是vue官方的状态管理工具。

注意：

2. uni.storage:

vue和nvue页面可以使用相同的uni.storage存储。这个存储是持久化的。 比如登陆状态可以保存在这里。

App端还支持plus.sqlite，也是共享通用的。

3. globalData:

小程序有globalData机制，这套机制在uni-app里也可以使用，全端通用。 在App.vue文件里定义globalData，如下：

js中操作globalData的方式如下： getApp().globalData.text = 'test'

如果需要把globalData的数据绑定到页面上，可在页面的onShow声明周期里进行变量重赋值。

uni-app是逻辑层和视图层分离的。此时会产生两层通信成本。比如拖动视图层的元素，如果在逻辑层不停接收事件，因为通信损耗会产生不顺滑的体验。

BindingX是weex提供的一种预描述交互语法。由原生解析BindingX规则，按此规则处理视图层的交互和动效。不再实时去js逻辑层运行和通信。

BindingX类似一种强化版的css，运行性能高，但没有js那样足够强的编程灵活性。

uni-app 内置了 BindingX，可在 nvue 中使用 BindingX 完成复杂的动画效果。

代码示例