uni-app code writing, the basic language includes js, vue, css. And css precompilers such as ts and scss.
On the app side, it also supports nvue for native rendering, and uts that can be compiled into kotlin and swift.
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:
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
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.
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.
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.
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.
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.
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.
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