The essence is that (mixed) app is between Web app and native app, which has rich interfaces for calling various functions of mobile phones, but also has flexibility and cross-platform

Scan code to view small program:

1. The operating environment is different

Wechat mini programs run on three terminals: iOS, Android and developer tools for debugging.

The script execution environment on the three ends and the environment used to render non-native components are different:

• On iOS, the javascript code of the small program is run in the JavaScriptCore, which is rendered by WKWebView, and the environment is iOS8, iOS9, iOS10
• On Android, the javascript code for the applet is parsed by X5 JSCore, which is rendered by X5 based on the Mobile Chrome 53/57 kernel
• On the development tool, the mini program’s javascript code runs in NWJS and is rendered by Chrome Webview from the official documentation

Project ├ ─ ─ pages | ├ ─ ─ index | | ├ ─ ─ index. The json configuration index page | | ├ ─ ─ index. The js index page logic | | ├ ─ ─ but WXML | index page structure | └ ─ ─ index. WXSS index page stylesheet | └ ─ ─log| ├ ─ ─ the jsonlogConfiguration page | ├ ─ ─ the WXMLlogPage logic | ├ ─ ─ the jslogPage structure | └ ─ ─ the WXSSlogPage style sheet ├── App.js Applet Logic ├── app.json applet public Setup ├─ app.wxss Applet public style sheetCopy the code

The framework of wechat small program consists of two parts: View layer (there may be multiple) and AppService logical layer (one). The View layer is used to render the page structure, and the AppService layer is used for logical processing, data request and interface invocation. They run in two threads.

The view layer is rendered using WebView and the logical layer is run using JSCore.

The view layer communicates with the logical layer through WeixinJsBridage of the system layer. The logical layer notifies the data changes to the view layer and triggers the page update of the view layer. The view layer notifies the triggered events to the logical layer for business processing.

Focus on WXS:

< WXS Module =”tools”> < WXS Module =”tools”> < WXS Module =”tools”

index.js

GetApp () Page({data: {motto: {motto:'Hello World',
    userInfo: {},
    hasUserInfo: false}, // Event handlerbindViewTap: function() {
  },
  onLoad: function() {}})Copy the code

<! --index.wxml--> <view class="container">
  <view class="usermotto">
    <text class="user-motto">{{tools.bar(motto)}}</text>
    <text class="user-motto">{{tools.foo}}</text>
  </view>
  <wxs module="tools">
  var foo = "'hello world' from comm.wxs";
  var bar = function(d) {
    return 'What the hell?'+d;
  }
  module.exports = {
    foo: foo,
    bar: bar
  };
  </wxs>
</view>
Copy the code

Three, small program start loading

Operation mechanism

There are two kinds of small program start, one is “cold start”, the other is “hot start”. If the user has opened a small program, and then open the small program again in a certain period of time, at this time do not need to restart, just the background state of the small program to switch to the foreground, this process is hot start; Cold start refers to the user opened for the first time or the small program was actively destroyed by wechat to open again, at this time the small program needs to reload and start.

Update mechanism

If a new version of the applet is found during cold startup, the applet asynchronously downloads the code package of the new version and starts with the local package on the client at the same time. That is, the applet of the new version cannot be applied until the next cold startup. If you need to apply the latest version immediately, you can use the WX. getUpdateManager API.

Operation mechanism

• Applets have no concept of restarts
• When the small program enters the background, the client will maintain the running state for a period of time, and after a certain time (currently 5 minutes) will be actively destroyed by wechat
• If the system receives more than two memory alarms in a short period of time (5s), the mini program is destroyed

View (page View)

The view layer is written in WXML and WXSS and presented by components.

The data of the logical layer is reflected as a view and the events of the view layer are sent to the logical layer.

1. View-wxml

WXML compiler: WCC to WXML files into JS execution mode: WCC index.wxml

2. View-wxss

• WXSS(WeiXin Style Sheets)
  
  
• WXSS compiler: WCSC to convert WXSS files to JS execution: WCSC index. WXSS

3, view-component

• The components of the applet are based on the Web Component standard

• Implement the Web Component using the Polymer framework

4, View-native Component

• The Native component layer is on top of the WebView layer

5. WebView preloading

Each time the applet enters the current page,Native preloads an extra WebView

When the specified page is opened, the default data is directly rendered. When the data is returned, the local update is returned to the display history. View exits the miniprogram, and the View state is not destroyed

Vi. App Service(Logical layer)

The logical layer sends the data to the view layer after processing and receives the event feedback from the view layer

1. Entry of App() small program; Page() The entry to the Page

3, provide rich API, such as wechat user data, scan, pay and other wechat unique capabilities.

Each page has its own scope and provides modularity capabilities.

5. Data binding, event distribution, life cycle management, route management

Runtime environment

IOS – JSCore

Android-x5 JS parser

DevTool – NWJS Chrome kernel

1. App service-binding

• Data binding wraps variables with Mustache syntax (double curly braces). The dynamic data comes from the data of the corresponding Page and can be modified with the setData method.
• Key starts with a bind or catch, and then follows the event type, such as bindtap, catchTouchStart. Value is a string, and you need to define a function with the same name in the corresponding Page.

2. App service-life Cylce

3. App service-api

The API communicates with Native via WeixinJSBridge

4. App service-router

• navigateTo(OBJECT)
  
  

Keep the current page, jump to a page in the app, and use the navigateBack to return to the original page. The page path can only be five layers

• redirectTo(OBJECT)
  
  

The current page is closed and a page in the application is displayed.

• navigateBack(OBJECT)
  
  

Close the current page and return to the previous page or multilevel page. You can use getCurrentPages() to get the current stack of pages and determine how many layers you want to return.

5. Small program development experience

1, small program problems

The applet still uses WebView rendering, not native rendering

It needs to be developed independently and cannot run in non-wechat environment.

Developers cannot extend new components.

Js libraries that depend on the browser environment cannot be used because JSCore executes them without window or document objects.

Local (images, fonts, etc.) cannot be used in WXSS.

WXSS converts to JS instead of CSS.

WXSS does not support cascading selectors.

Applet cannot open page, cannot pull up APP.

2. The advantages of small programs

Create a new WebView in advance to prepare the new page for rendering.

The View layer is separated from the logical layer and is data-driven without directly manipulating the DOM.

Use the Virtual DOM to perform local updates.

Use HTTPS to ensure the security of transmission.

Add RPX unit to isolate the size of the equipment for convenient development.

RPX (Responsive Pixel) : Can be adapted according to the width of the screen. Set the screen width to 750rpx. For example, on the iPhone6, if the screen is 375px wide and there are 750 physical pixels, then 750rpx = 375px = 750 physical pixels and 1rpx = 0.5px = 1 physical pixel. IPhone5 1rpx = 0.42px 1px = 2.34 RPX iPhone6 1rpx = 0.5px 1px = 2rpx iPhone6Plus 1rpx = 0.552px 1px = 1.81rpxCopy the code

7. Code running

When the callback is called, only the first three values are passed in. Since the variables that follow are locally defined variables, these variables (window,document, etc.) are excluded.

The O is the callback on define(‘app.js’,callback). The callback value is passed in three parameters, masking the other attributes

Viii. Optimization Proposal (Official Proposal)

How setData works

The view layer of the applet currently uses WebView as the rendering carrier, while the logic layer is run by a separate JavascriptCore. In terms of architecture, WebView and JavascriptCore are independent modules with no direct data sharing channels. Currently, the data transfer between the view layer and the logical layer is actually done through the evaluateJavascript provided on both sides. That is, the data transferred by the user needs to be converted into a string form and passed. At the same time, the converted data content is pieced into a JS script, and then passed to the independent environments on both sides by executing the JS script.

While the execution of evaluateJavascript is affected in many ways, data does not arrive at the view layer in real time.

Common setData operation errors

1. Go to setData frequently

In some of the cases we have analyzed, some small programs have setData very frequently (millisecond), which has two consequences:

• Under Android, users will feel a lag when sliding, and the operation feedback delay is serious, because the JS thread has been compiling and executing rendering, and the user operation events cannot be passed to the logical layer in time, and the logical layer cannot pass the operation processing results to the view layer in time.
• There is a delay in rendering. Because the JS thread of WebView is always in a busy state, the communication time between the logical layer and the page layer increases. When the data message is received by the view layer, hundreds of milliseconds have passed before the sending time, and the rendering result is not in real time.

2. Every time setData is passed a large amount of new data

When the amount of data is too large, it will increase the compilation and execution time of the script, which will take up the WebView JS thread.

3. Perform setData on the background state page

When the page enters the background state (invisible to the user), the setData should not be continued. The rendering of the background state page cannot be felt by the user. In addition, the setData of the background state page will preempt the execution of the foreground page.

Image resources

• At present, the main performance problem of image resources lies in large images and long list images, both of which may lead to the increase of memory usage of iOS clients, triggering the system to reclaim small program pages.
• On iOS, the page of a small program is composed of multiple WkWebViews. When the system memory is tight, part of wkWebViews will be reclaimed. From the cases we analyzed in the past, the use of large images and long list images can cause WKWebView recycling.

Code package size optimization

While implementing the business logic, it is also important to minimize the size of the code package, as the size of the code package directly affects the download speed and therefore the user’s first open experience. In addition to optimizing the refactoring of the code itself, there are two ways to optimize code size:

1. Subcontracting loading Subcontracting small programs can optimize the download time of the first startup of small programs
2. Clean up unused code and resources

At present, small program packaging will put all files under the project into the code package, that is, the library files and resources that are not actually used will also be put into the code package, which affects the overall code package size.

Preloaded data

The principle of

When the applet starts, it loads all the page logic code directly into memory, even though Page2 may not even be used. Page1’s logical code Javascript data does not disappear from memory when page1 jumps to Page2. Page2 can even access the data in Page1 directly.

Small program this mechanism difference just can better achieve preloading. In general, we are used to writing the data in the onLoad event. However, the page1 of the small program jumps to Page2, and the onLoad to Page2 has a delay of 300ms ~ 400ms. The diagram below:

Because of the characteristics of the small program, it is completely possible to take the data in advance in PagE1 and then directly use the data in Page2. In this way, the 300ms ~ 400ms of redirecting can be avoided. The diagram below:

The rendering view thread and AppServcie are independent of each other, and the js running in AppServcie does not block the rendering of the view

The official example takes the same approach: first request the data in the App and use it in index.js

Specific can refer to this document (https://mp.weixin.qq.com/s/EvzQoSwWYUmShtI_MkrFuQ)

There are mistakes welcome to point out, common progress

Finally encountered related issues developer community search issues

Reference content:

• Micro channel small program architecture analysis
  
  
• Micro channel small program p bottom implementation principle
  
  
• What is Web Components
  
  
• Wechat small program development in-depth interpretation
• Cloud + Community technology salon –WeGeek Wechat small program agile development combat
  
  
• Understand the technical architecture of wechat mini program
  
  
• Analysis of wechat Small Program Architecture (I)