Introduction

uni-app App has a built-in native rendering engine based on weex, which provides native rendering capabilities.

On the App side, if vue page is used, webview rendering will be used; If nvue page (abbreviation of native vue) is used, native rendering will be used. You can use two kinds of pages in an App at the same time, for example, the home page uses nvue, and the second page uses vue page, as is the case with the hello uni-app example.

Although nvue can also be compiled with multiple terminals and output H5, the css writing of nvue is limited. If you don not develop an App, nvue is not needed.

The previous weex had a big problem that it was only a high-performance renderer, and it didn't have enough API capabilities (such as various push sdk integration, Bluetooth and other capability to call), which made the development heavily dependent on the collaboration of native engineers. Developers are intended to save costs, but as a result, they need front-end, iOS and Android 3 groups of people to develop, which is counterproductive. nvue solves this problem by allowing front-end engineers to directly develop a complete App and provide rich plug-in ecosystem and cloud packaging. These combination schemes help developers to effectively improve efficiency and reduce costs.

At the same time, uni-app expands many typesetting capabilities of weex's native rendering engine and fixes many bugs. For example

• The Android side supports border shadows well, Details
• IOS supports Gaussian blur, Details
• It can realize the complex typesetting effect of area scrolling long list+left and right dragging list+ceiling
• Optimize the rendering performance of border-radius
• Extend more css

Applicable scene

nvue's components and API are written in the same way as the vue page, and its built-in components are more than the built-in components of the vue page. See details (opens new window).

If you are familiar with weex or react native development, nvue is your better choice, which can effectively improve your development efficiency and reduce costs.

If you are a web front-end unfamiliar with native typesetting, it is recommended that you still use vue pages as the main method, and use nvue as an enhancement supplement in the case of poor performance of some vue pages on the App side. These scenarios are as follows:

1. Long lists or waterfall scrolling in areas that require high perlistance. There is no perlistance problem in webview's page-level long list scrolling (i.e., the scroll bar covers the overall height of webview), but for a long list scrolling in a certain area of the page, you need to use nvue's list, recycle-list, waterfall and other components (See details (opens new window)). The performance of these components is higher than that of the area scroll component scroll-view in the vue page.
2. Complex high-performance custom pull-down refresh. Native pull-down refresh can be configured in uni-app's pages.json, but the built-in pull-down refresh style of the engine only has two styles: snowflake and circle. If you need to generate a complex pull-down refresh yourself, nvue's refresh component is recommended. Of course, there are many custom pull-down refresh plug-ins under Vue in the Plug-in market (opens new window). As long as they are based on renderjs or wxs, the performance can also be commercialized, but it is not more extreme than the refresh component of nvue.
3. Long list that can be dragged left and right. In the webview, the perlistance of the solution that implements a long list of dragging left and right through swiper+scroll-view and the front end simulates pull-down refresh is not good. At this time, nvue is recommended. For example, the news sample template (opens new window) used in the new uni-app project achieved smooth switching by using nvue.
4. Realize the complex typesetting effect of scrolling long list in area + dragging list left and right + sticky. For the effect, please refer to swiper-list in the hello uni-app template. See details (opens new window)
5. If you need to change the button text in the lower right corner of the soft keyboard to "Send", you need to use nvue. For example, the chat scenario, besides the button text processing in the lower right corner of the soft keyboard, also involves the area long list scrolling of the chat record, for which nvue is suitable.
6. Solve the layer problem that the front-end controls fail to cover the native controls. When you use native components such as map, video, and live-pusher, you will find that the components such as view written on the front end cannot cover the native components, and it is troublesome to deal with the level problems. It's better to use nvue at this time. Or you can also overlay a subnvue on the vue page (a non-full screen nvue page overlaid on webview) to solve the problem of native control hierarchy on App. See details (opens new window)
7. If you use the map component deeply, nvue is recommended. In addition to the hierarchy problem, the map function of the nvue file on the App side is more complete.
8. If you use video deeply, nvue is recommended. Take the following two scenarios as an example: video is embedded in the swiper to achieve the same video sliding switch as Tik Tok, for example, see plug-in market (opens new window); After the nvue video is full screen, use cover-view to achieve content coverage, such as adding text titles and sharing buttons.
9. Live streaming: There is an live-pusher component under nvue, which has more complete functions and no level issues.
10. Extreme requirements for App startup speed. On the App side, if the home page uses nvue and fast mode is configured in manifest, the startup speed of the App can be controlled to about 1 second. When using vue page, the startup speed of the App usually costs more than 3 seconds, depending on your code performance and volume.

But note that in some scenarios, nvue is not as good as vue page, as follows:

1. canvas. nvue's canvas performance is not high, especially in the Android App platform. Therefore, canvas is not built in this component, but needs to be introduced separately. The highest performance way to operate canvas animation is to use the renderjs technology of vue page, as shown in the canvas example in hello uni-app.
2. Dynamic horizontal and vertical screens. The css of nvue page does not support media query, so it is very difficult to dynamically switch between landscape and portrait screens and dynamically adapt the screens.

Pure native rendering mode

uni-app supports mixing and jumping between vue pages and nvue pages on the App side. It also supports pure nvue native rendering.

Enabling the pure native rendering mode can reduce the package size and memory usage of the App side. Because the relevant modules of webview rendering mode will be removed.

Configure "renderer":"native" under "app-plus" in the source view of manifest.json, which means that the pure native rendering mode is enabled on the App side. At this time, the vue page registered by pages.json will be ignored, and the vue component will be rendered by the native rendering engine.

If this value is not specified, pure native rendering will not be started by default.

	// manifest.json    
	{    
	     // ...    
		/* App platform-specific configuration */    
	    "app-plus": {    
	        //App side pure native rendering mode
	        "renderer": "native",
	    }    
	}

Compilation mode

weex compilation mode and uni-app compilation mode

If you used to be a weex developer, you can continue to refer to this section. Otherwise, you can skip to the next section Quick Start.

weex's components and JS API are different from uni-app.

Considering the migration of weex users, uni-app also supports weex coding. You can configure to use weex compilation mode or uni-app compilation mode in manifest.json. When choosing weex compilation mode, the components of uni-app and jsapi will not be supported, and developers need to refer to the writing of weex official documents to write codes. For example, use <div> for weex compilation mode. For uni-app compilation mode, use <view>.

It is generally recommended to use the uni-app mode, unless there are many historical weex codes that requires a gradual transition. At the same time, note that the switching of weex compilation mode is project level, and it is not supported to use weex mode for one nvue page and uni-app mode for another nvue page under the same project.

	weex compiled mode	uni-app compilation mode
Platform	App only	All sides, including H5
Component	weex components such as div	uni-app components such as view
Lifecycle	Only weex lifecycle is supported	All uni-app lifecycles are supported
JS API	weex API、uni API	weex API、uni API
Unit	750px is the screen width and wx is the fixed pixel unit	750rpx is the screen width and px is the fixed pixel unit
Global style	Manual introduction	The style of app.vue is the global style
Page scrolling	Page nesting or components are necessary	Page scrolling is supported by default

Modify the two compilation modes in manifest.json, manifest.json -> app-plus -> nvueCompiler switch the compilation mode.

nvueCompiler has two values:

• weex
• uni-app

// manifest.json    
{    
	// ...    
	/* App platform-specific configuration */    
	"app-plus": {    
	    //whether to enable uni-app mode  
	    "nvueCompiler":"uni-app" 
	}    
}

In the manifest.json configuration file, the default value of HBuilderX2.4+ is weex mode, but the default value of HBuilderX2.4+ is changed to uni-app mode.

weex compilation mode does not support the writing of onNavigationBarButtonTap life cycle functions. listen to the native title bar button click event in nvue, see: uni.onNavigationBarButtonTap (opens new window) for details.

The weex compilation mode does not support the onShow lifecycle.

weex compilation mode does not support vuex.

Unlike weex, the page jump of nvue still follows the routing model of uni-app. The model is followed no matter how you jump between vue page and nvue page. Including nvue page jumping to nvue page. Each page needs to be registered in pages.json and call uni-app's route API (opens new window) to jump.

Native development does not have the concept of page scrolling. When the page content is higher than the screen height, the content will not automatically scroll; Only the content of the page is placed under the components of list, waterfall, and scroll-view/scroller can be scrolled. This is not in line with the custom of front-end development, so when nvue is compiled into the uni-app mode, the uni-app framework will automatically nest an scroller in the outer layer of the nvue page, so as to realize the automatic scrolling of the page content.

Notice:

• The uni-app frame only nests the scroller container for the nvue page, and does not automatically nest the scroller container for the component;
• If there is an recycle-list component on the nvue page, the uni-app frame will not automatically nest the scroller container on the page.
• If you don't want to automatically nest the scroller container, you can turn it off in pages.json with the following configuration:

{
    "path": "",
    "style": {
        // scroller is not nested
        "disableScroll": true
    }
}

weex ui is supported in weex compilation mode. For example, See details (opens new window). But compared to the uni-app plug-in market and official uni ui (opens new window), the component ecology of weex syntax is still relatively lacking.

From HBuilderX 3.1.0+, new style compilation mode is supported

• weex compilation mode: the old mode, with the same style support as ordinary weex
• uni-app compilation mode: a new mode, which supports combination selectors (adjacent brother selector, common brother selector, child selector and descendant selector) based on the original weex style. See details (opens new window)

  // manifest.json  
  {        
      // ...        
       /* App platform-specific configuration */        
      "app-plus":  {  
          "nvueStyleCompiler": "uni-app"  
      }  
  }

Quick Start

1. Creating a new nvue page

In the uni-app project of HBuilderX, create a new page and pop up the upper right corner of the interface, you can choose whether to create the vue page or the nvue page, or both at the same time.

Both vue page and nvue page need to be registered in pages.json. If you create a new page in HBuilderX, it will be registered automatically, if you use other editors, you need to register it in pages.json.

If there are both vue pages and nvue pages under a page route, there will be the vue and nvue files with the same name. Then on the App side, only nvue pages will be used, and the vue file with the same name will not be compiled to the App side. While on the non-App side, the vue page is preferred.

If there are different names and there are only nvue pages, on non-app sides, only the nvue files in uni-app compilation mode will be compiled.

2. Developing nvue page

nvue is the same as vue in terms of the page structure, which is composed of template, style, and script.

• template: The template writing method and data binding are the same as vue. The component supports 2 modes,
  • weex component, written as weex, refer to: weex built-in components (opens new window);
  • uni-app component, written in the same way as uni-app.
  • For the nvue dedicated component on the App side, see https://uniapp.dcloud.io/component/barcode (opens new window) for details.
• style: Due to the use of native rendering, Not all browsers support css, and the layout model only supports flex layout. Although it will not cause some interface layouts to be unachievable, special attention should be paid to the writing. For details, see: Style
• script: written in the same way as vue, and supports two kinds of APIs:
  • nvue API: only the App side is supported, and the uni-app compilation mode can also be used. The corresponding module must be introduced prior to use, please refer to: Introduction of module API
  • uni API：https://uniapp.dcloud.io/api/README (opens new window)

3. Debugging nvue page

HBuilderX has built-in an enhanced version of the weex debugging tool, including reviewing interface elements, watching log, and debugging breakpoints. See details (opens new window)

render-whole

From HBuilder X 3.1.0+, nvue has added the render-wholeattribute and typeBoolean.

• When render-whole="true" is set, the view layer communicates the information structure of components and subcomponents with the native layer at one time, and the rendering performance of typesetting is improved by redrawing the whole node.
• When render-whole="false" is set, the view layer will be redrawn by communicating with the native layer one by one with child nodes. The overall rendering time may be longer.

Enable render-whole as a component list of true by default

• text
• cell
• header
• cell-slot
• recycle-list

Usage

<swiper :render-whole="true"></swiper>

Demo

The effect of this demonstration on Android version 5.1 mobile phone is not so obvious in higher version mobile phone

For the sample project, Click to download (opens new window)

Common differences between nvue development and vue development

Rendering based on native engine is still a front-end technology stack, but it is definitely different from web development.

1. nvue page control display and hide can only use v-if but not v-show
2. The nvue page only supports the flex layout and does not support any other layout methods. Before developing the page, you should first figure out what the vertical content of this page is and which contents are to be scrolled, then what is the horizontal axis arrangement of each vertical content, and design the interface according to flex layout.
3. The default layout direction of the nvue page is vertical (column). If you need to change the layout direction, you can modify it under the node manifest.json -> app-plus -> nvue -> flex-direction, which only takes effect in uni-app mode. Details. (opens new window)
4. When the nvue page is compiled into H5, css default value alignment will be done. Because weex rendering engine only supports flex, and the default flex direction is vertical. On the H5 side, using web rendering, the default is not flex. After setting display:flex, its flex direction is horizontal instead of vertical by default. Therefore, when nvue is compiled into H5, the default layout of the page will be set to flex and the direction will be vertical automatically. Of course, the default settings will be overridden after the developer sets them manually.
5. The text content must and can only be under the <text> component. You cannot write text directly in the text area of <div> and <view>. Otherwise, even if rendered, the variables in js cannot be bound.
6. Only the text tag can set the font size and font color.
7. Layout cannot use percentage and there is no media query.
8. When nvue switches the landscape and portrait screens, it may cause style problems, it is recommended to lock the direction of the mobile phone of the page when there is nvue.
9. Supported css is limited, but it does not affect the layout of the interface you need. flex is still very powerful. See details
10. Background images are not supported. But you can use image components and levels to achieve background effects similar to those in the web. Because in native development, there is no such concept of background map like web.
11. Fewer styles are supported by the css selector, and only the class selector can be used. See details
12. Each component of nvue is transparent by default on the Android side. If background-color is not set, ghosting problems may occur.
13. class only supports array syntax when binding.
14. Using a large number of border-radius in a page of the Android side will cause performance problems, especially if the styles of multiple borders are not the same, which will consume more performance. Such use should be avoided.
15. The nvue page does not have the bounce rebound effect, only a few list components have the bounce effect, including list, recycle-list, and waterfall.
16. Native development does not have the concept of page scrolling. When the page content is higher than the screen height, it will not automatically scroll, only some components can be scrolled (list, waterfall, scroll-view/scroller). The content to be scrolled needs to be set under the scrollable component. This is not in line with the habit of front-end development, so when nvue is compiled into uni-app mode, an scroller is automatically nested to the outer layer of the page, and the page content will automatically scroll if it is too high. (The component will not be nested, nor will it be nested when there is recycle-list on the page). Follow-up configuration will be provided, and the function can be set not to be applied automatically.
17. The global js variables defined in App.vue will not take effect on the nvue page. globalData and vuex are effective.
18. Global css defined in App.vue is valid for both nvue and vue pages. If some css in the global css is not supported under nvue, the console will give an alarm at the time of compiling. It is recommended to wrap these unsupported css in Conditional compilation (opens new window), APP-NVUE
19. You cannot import font files in style. For the use of font icons in nvue, please refer to: Load custom fonts.
20. typescript/ts is currently not supported on the nvue page.
21. When the native navigation bar is closed on the nvue page, if you want to simulate the status bar, you can refer to the article (opens new window). However, it is still strongly recommended to use native navigation bar on nvue pages. However fast nvue rendering is, it will not be as fast as the native navigation bar. Native typesetting engine analysisjson. It takes little time to draw the native navigation bar, but it takes much longer to draw the whole page by analyzing the js of nvue, especially when the new page enters the animation period. For complex pages, there is no native navigation bar that will generate the white screen or splash screen of the whole screen during the animation period.

Notes on iOS platform drop-down component refresh component

By default, when the content of the scrolling container component (such as list, waterfall components) on the iOS platform is insufficient, it will not be able to scroll up and down because the visible area of the container is not filled. At this time, the pull-down refresh function cannot be operated, and the @refresh and @pullingdown events of the refresh component cannot be triggered. At this time, you can configure the alwaysScrollableVertical property value in the container component to set the value of true to support up and down scrolling and pull-down refresh operations.

Usage

	<list class="scroll-v list" enableBackToTop="true" scroll-y alwaysScrollableVertical="true">
		<refresh class="refresh" @refresh="onrefresh()" @pullingdown="onpullingdown">
			//refresh content
		</refresh>
		<cell v-for="(newsitem,index) in list" :key="newsitem.id">
			//cell content
		</cell>
	</list>

Android platform does not have this problem