MiniApp Standardization White Paper

2019-09-17 admin

<bdi>2.1</bdi> Core Features

<bdi>2.1.1</bdi> Separate the View Layer from the Logic Layer

In a miniapp, the view layer is usually separated from the logic layer.

logic layer and view layer

<figcaption>Figure <bdi>4</bdi> General Architecture of MiniApp</figcaption>

The View Layer is responsible for rendering MiniApp pages, including Web components rendering and native components rendering, which can be considered as hybrid rendering. For example, Web components rendering can be handled by WebView, but some of the Web components rendering aren’t supported by WebView or have performance limitation, MiniApp also relies on some native components, such as map, video, etc.

Logic Layer is implemented with JS Worker. The Worker is responsible for MiniApp’s event processing, API calling and lifecycle management.

Extended native capabilities usually come from the hosting Native App or OS, including payment, file processing, scanning, phone call, etc. These capabilities are called through certain APIs. When a Mini App calls a native API, it transfers the API calling to Extended Native Capabilities for further processing via JS Bridge, and obtains the result from Extended Native Capabilities via JS Bridge.

data flow of MiniApp when an API is called

<figcaption>Figure <bdi>5</bdi> Data flow of MiniApp when an API is called</figcaption>

Worker establishes connection for each Render, transferring the need-to-be-rendered data to render for further processing.

If an event is triggered by a component in a MiniApp page, this page’s Render will send the event to worker for further processing. At the same time, the Render will wait for the data sent from worker to re-render the MiniApp page.

The rendering can be considered as stateless, and all the states will be stored in the worker.

The benefits of separating the View Layer and the Logic Layer include:

  • Very handy for data sharing and interaction among multiple MiniApp pages.
  • Having the same context within a lifecycle of MiniApp can provide a similar coding experience for those developers coming from native app developement background.
  • Separation and parallel implementation of Render and JS worker can prevent the situation where a JS execution impacts or slows down the page rendering, which can help enhance the performance of rendering.

<bdi>2.1.2</bdi> Rich APIs and Components

MiniApp platform provides many components to help developers build a fancy UI, including basic components like View, Form, Image, and high-level component like Maps.

MiniApp venders also offer a number of APIs for developers to get access to capabilities of both the Web and the native, including basic APIs such as UI display APIs, Image API, and those advanced ones like Account API, Map API, Payment API.

APIs usually work together with components. When user clicks certain component on a MiniApp page, it will call the related API to complete user’s interaction and refresh the current MiniApp page if needed.

<bdi>2.1.3</bdi> MiniApp Constructor

In order to obtain similar user experiences to native apps, MiniApp resources are usually packaged together. After downloading and installing a MiniApp package, all static page templates/CSS/JavaScript files need to present app pages already exist on users’ machines. These resources are always available without any redundant downloads until next update.

A MiniApp package is a compressed format (e.g. zip) archive, including:

  • one configuration document, located at the root directory of the package. The config file should include:
    • general description of the entire MiniApp.
    • description of pages and their corresponding paths, for the purpose of page locating and opening.
  • one app-level logic file, containing JavaScript codes, deals with app-level lifecycle callbacks.
  • one or multi page files, containing templates codes for page structure, CSS codes for page style, and JavaScript codes for page logic.
  • support digital signature for validation.

For the purpose of locating a specific MiniApp while searching and executing, a MiniApp must have a package name or an ID on the platform. An icon is also required for user recognization.

In addition to being presented in the form of an MiniApp page, MiniApp can also be displayed in the form of information fragment, that is, a MiniApp widget. In this form, developers can put their service and/or content to various host scenarios, called host environment, such as assistants, search page, etc… This feature connects services of the MiniApp with the scenario, providing users with more convenience.

For example, when a user purchases a train ticket for trip, the MiniApp widget on smart assistant shows the train’s latest status immediately. The user can click on this widget and jump to a full-screen MiniApp page for more detailed information.

Widget from home screen to MiniApp

<figcaption>Figure <bdi>6</bdi> Widget from home screen to MiniApp</figcaption>

Same as MiniApp page, widget is also described by URI scheme. The host environment specifies the MiniApp package and the corresponding widget to be loaded through URI path, and passes data to the widget through URI query params. After the widget is loaded, it is displayed and rendered in the host environment. Data from the host and widget, as well as data from different widgets are isolated to ensure security and independence.

In many scenarios, a widget can open a MiniApp page for more complicated operations. In such cases, widgets often need to share data with its corresponding MiniApp, e.g. maintain a consistent login status. Therefore, the data of the widget and the MiniApp can be accessed from each side. In other word, MiniApp widget and page have same data access rights.

widget interaction

<figcaption>Figure <bdi>7</bdi> MiniApp widget interaction</figcaption>

One of the goals of the widget is to let the user forget the traditional app concept and truly meet the user’s needs in the form of service. So in addition to all app invocation paths, widgets can also be triggered by different methods on different scenarios, such as text keywords, voice analysis, picture recognition, scan code, event intent.

<bdi>2.1.5</bdi> Single-Instance, Multi-Entries

There are multiple entrances to discover, open and access MiniApps. Unlike Web in multi WebView, only one instance will be created for the same MiniApp, so MiniApp keeps its status and data in a consistent manner globally. For example, after one user opens and logs in a MiniApp through the entrance of QR code for the first time, the user will remain logged in next time when the user returns from another entrance like MiniApp store.

The entries for MiniApps include, but not limit to:

  • MiniApp store
  • Search Engine
  • Smart Assistant
  • QR code
  • SMS/text
  • Physical Object(with AI)
  • Browser
  • Calender items
  • Voice message(with AI)

<bdi>2.1.6</bdi> Performance and User Experience

MiniApps try to improve their performance and user experience with a few mechanisms that have been proved to be effective through practice.




With MiniApp’s constructor, user only needs to download the package when the MiniApp is first opened, and then the static resources(pages/JavaScript/CSS) in the MiniApp needn’t be downloaded again, so that the loading and jumping of the following pages can be more quickly responded. This feature improves user operation experience and save network traffic.

Meanwhile, the MiniApp has a pre-download mechanism, which can download the MiniApp packages in advance, or pre-downloads separately for the first page, and perform streaming decompression in parallel during download to minimize the time-consuming of MiniApp startup phase and balance the loss of the first page performance when openning first time.


<dt>Multiple Rendering Views</dt>


The MiniApp uses native page stack management between render views, and the page switching is driving by native code. Therefore, the gesture operation in the page, the switching between pages can achieve the exactly same smooth experience as Native.

Becase of the isolation of View layer and Logic layer, the View layer can be rendered independently. Without being blocked by JavaScript logic code, the rendering speed of the page can be greatly improved.


<dt>Pre-built and reuse of runtime environments</dt>


MiniApp’s runtime environment is usually pre-built before launching a mini-app, thus reducing the time to launch a MiniApp. Pre-built content includes rendering views, static resources, developer defined prefetch requests, and MiniApps runtime container. After a MiniApp is activated, it will take over the pre-built rendering view, then we continue to pre-built a new render view into the cache pool for the next one. There is a limit on render view quantity, when any render view gets closed or the quantity limit is exceeded, the oldest opened render view will be destroyed. When the MiniApp application exit, the runtime will be destroyed and the application environment and resources can be reused.


<dt>Pre-defined Component and API</dt>


MiniApp platforms provides very rich components and APIs, these components and APIs are usually well designed and able to help ensure the performance of the general work from developers.


<dt>JavaScript framework presets and hot reload</dt>


MiniApp’s runtime environment contains two major parts, the basic capabilities provided by Native code, and a framework, include developer API and some components, implemented by JavaScript. The JavaScript framework is built in native Apps, and will be loaded into the MiniApp runtime environment in advance before executing MiniApp. The JavaScript framework can be hot reloaded (reload during usage), which brings lots of possibilities to improve performance.





转载请注明:文章转载自 JavaScript中文网 []


文章标题:MiniApp Standardization White Paper