# uni-app composition and cross-terminal principle

# Basic language and development specifications

uni-app code writing, the basic language includes js, vue, css. And css precompilers such as ts and scss.

在app端,还支持原生渲染的nvue,以及可以编译为kotlin和swift的uts

DCloud also provides the uniCloud cloud engine that uses js to write server code. So as long as you master js, you can develop full-stack applications such as web, Android, iOS, various MiniApp, and servers.

In order to achieve multi-terminal compatibility, considering factors such as compilation speed and running performance, ``uni-app``` stipulates the following development specifications:

uni-app is divided into compiler and runtime (runtime). uni-app can realize a set of code and multi-terminal operation, which is completed through the cooperation of these two parts.

The compiler compiles the developer's code, and the compiled output is analyzed by the runtime of each terminal. Each platform (Web, Android App, iOS App, and various MiniApp) has its own runtime.

# translater

  • The compiler runs in the computer development environment. Generally, it is built into the HBuilderX tool, or you can use the independent cli version.
  • The developer writes the code according to the uni-app specification, and the compiler compiles the developer's code to generate the unique code supported by each platform
    • On the web platform, compile the .vue file into js code. Similar to normal vue cli project
    • On the WeChat MiniApp platform, the compiler splits the .vue file to generate wxml, wxss, js and other codes
    • On the app platform, compile the .vue file into js code. Further, if uts codes are involved:
      • On the Android platform, compile .uts files into kotlin code
      • On iOS platform, compile .uts files into swift code
  • 编译器分vue2版和vue3版
    • vue2版:基于webpack实现
    • vue3版:基于Vite实现,性能更快
  • The compiler supports conditional compilation, that is, you can specify that a certain part of the code is only compiled to a specific terminal platform. Thereby combining public and personalization in one project.
// #ifdef  App
console.log("这段代码只有在App平台才会被编译进去。非App平台编译后没有这段代码")
// #endif

For more compiler introductions, see: Compiler

# runtime

The runtime does not run in the computer development environment, but runs on a real terminal.

uni-app has its own runtime on each platform (Web, Android App, iOS App, various MiniApp). This is a relatively large project.

  • On the MiniApp side, the runtime of uni-app is mainly a vue runtime of the MiniApp version, and page routing, components, api, etc. are basically escaped.
  • On the web side, the runtime of uni-app has an additional set of ui libraries, page routing frameworks, and uni objects (that is, common API encapsulation) compared to ordinary vue projects.
  • On the App side, the runtime of uni-app is more complicated. It can be simply understood that DCloud also has a MiniApp engine. When packaging the app, the developer's code and DCloud's MiniApp are packaged into apk or ipa. Of course, in fact DCloud does have a MiniApp engine product for native applications to realize MiniApp, see for details

uni-app runtime includes 3 parts: basic framework, components, and API.

  1. Basic framework:
    • Including syntax, data-driven, global files, application management, page management, js engine, rendering and typesetting engine, etc.
    • On the web and MiniApp, there is no need for uni-app to provide js engine and typesetting engine, just use browsers and MiniApp directly. But the app requires uni-app to provide
    • App's js engine: App-Android, uni-app's js engine is v8, App-iOS is jscore
    • App rendering engine: 2 sets of rendering engines are provided at the same time. The .vue page file is rendered by webview, the principle is the same as that of the MiniApp; the .nvue page file is rendered natively, and the principle is the same as react native. Developers can choose the rendering engine independently according to their needs.
  2. 组件:
    • runtime中包括的组件只有基础组件,如<view><button>等。扩展组件不包含在uni-app的runtime中,而是下载到用户的项目代码中。(这些组件都是vue组件)
    • 为了降低开发者的学习成本,uni-app的内置基础组件命名规范与小程序基本相同。
    • 这几十个组件不管在哪个平台,已被处理为均有一致表现。
    • 在小程序端,uni-app基础组件会直接转义为小程序自己的内置组件。在小程序的runtime中不占体积。
    • On the web, android, and iOS side, these dozens of components are all in the runtime of uni-app, which will occupy a certain volume, which is equivalent to a built-in ui library.
    • Component extensions:
      • With dozens of basic components, most extension components are also packaged based on these basic components. For example, the official extended ui library uni ui.
      • On the web platform, various ui libraries (such as elementUI) for the web can also be used, but these libraries cannot be used in apps and MiniApp across terminals because they operate on dom.
      • 在App平台,uni-app也支持使用原生编程语言来自行扩展原生组件,比如原生的地图、ar等。
  3. API:
    • uni-app runtime has built-in a lot of common and cross-end API, such as networking (uni.request), reading storage (uni.getStorage)
    • At the same time, uni-app does not limit the API calls of the native platforms of each end. Developers can call all available APIs of the platform without restriction in the uni-app framework. That is, on the MiniApp platform, all APIs of the MiniApp can be used; on the web platform, all APIs of the browser can be used; on the iOS and Android platforms, all APIs of the os can be used.
    • In other words, using the standard API of uni-app, it can be used across terminals. But for the part that does not cross the end, the proprietary API of the end can still be called. Since common APIs have been packaged and built-in, developers only need to pay attention to uni standard APIs during daily development, and write special API call codes in conditional compilation when they need to call special end capabilities.
    • ext API: The runtime size of web and app is not small. If all the APIs of the MiniApp are built in, the developer's final application will become larger. So some uncommon APIs are stripped as ext APIs. Although it still starts with uni., you need to download the plugin separately to the project
    • MiniApp platform: the uni object will be converted into its own object of the MiniApp. For example, on the WeChat MiniApp platform, writing uni.request is equivalent to wx.request. Then all wx. APIs can be used in this way.
    • web platform: browser-specific APIs such as window and dom can still be used
    • app platform: In addition to uni.’s API, you can also use plus.’s API, Native.js, And write native plug-ins through uts, or use java and objectC to write native plug-ins. These native plug-ins call the API of os and encapsulate them for js to use.
    • Due to the historical evolution, DCloud has three modes when developing apps: 5+App, wap2app, and uni-app. The runtimes of these three methods are common in underlying capabilities, and all uni-apps can call 5+ (that is, plus.xxx) APIs. Although all 5+ system capabilities can be used, the logic layer of uni-app runs on the js layer, and the rendering layer is a double choice of webview and native nvue. And 5+ does not distinguish between logic layer and rendering layer, all run in webview, 5+ is not as good as uni-app in terms of performance.

DCloud also provides plug-in market, and most useful components and APIs already have ready-made plug-ins.

# Separation of logic layer and rendering layer

On the web platform, the logic layer (js) and rendering layer (html, css) all run in a unified webview.

But on the MiniApp and app side, the logic layer and rendering layer are separated.

The core reason for separation is performance. In the past, many developers complained about the poor performance of webview-based apps. The main reason was the lag caused by js operations and interface rendering.

Regardless of the MiniApp or the app, the logic layer is independent as a separate js engine, and the rendering layer is still webview (pure native rendering is also supported on the app).

So note that the logic layer of MiniApp and apps does not support browser-specific window, dom and other APIs. The app can only operate window and dom in the rendering layer, namely renderjs.

For the precautions brought by the separation of logic layer and rendering layer, please read in detail