According to a published 2018 mobile Internet industry analysis report, the monthly active users of Alipay have surpassed QQ to become the second largest App in China.
At the beginning, Alipay was just a single application tool App, allowing users to complete alipay related business inquiries and operations on their mobile phones. After 2013, Alipay gradually transformed into a platform-based App, which is characterized by servitization, modularization and tool componentization. At this time, Alipay’s business is not only payment, but also to provide customers with many life-related services, such as Yu ‘ebao and electricity payment. After 2015, Alipay has grown into a super App. At this time, Alipay needs to support a large number of complex businesses, open its business capability and help partners with its own flow. Therefore, the whole App faces challenges of openness, dynamic and high availability.
- How to deal with complex business collaboration?
- How to meet the needs of rapid business iteration?
- How to build a future-oriented open ecosystem?
1. Adopt Hybrid App architecture to cope with complex business collaboration
App business is increasingly complex, not only internal business, but also a large number of external partners. It is difficult to deal with the increasingly complex business scenarios if the traditional App development method is adopted.
1.1 Selection of Hybrid technology solution
In the selection of Hybrid technology solution, we take comprehensive consideration from five aspects of “development cost, user experience, dynamics, complex business support ability, and r&d difficulty”. HTML5, ReactNative/Weex, and Flutter were selected as candidates, and native development was used as a baseline for comparison. (Considering the recent trend of the heat of Flutter, we included Flutter in our analysis.)
First, from the perspective of business development costs:
- As the most basic development mode, native development requires both ends, and the cost is undoubtedly the highest;
- The second is ReactNative/Weex. Even if it is developed once and runs on both ends at the same time, there are still some differences in the actual operation due to the conversion of JS to Native component rendering. As a result, some of the differences need to be solved by the custom development of Native end when developers write business interfaces. Overall, ReactNative/Weex has helped businesses significantly reduce development costs;
- Next up is Flutter, which has really worked hard on dual end alignment from a business development perspective. In most cases, Android will run seamlessly on iOS once it’s developed, depending on which engine it’s working on. But Flutter needs to be developed in Dart language, so some of the old business migration needs to be taken into account for developers.
- Finally, HTML5, with its mature language, mature development model, and almost identical performance on both ends, is still the least expensive solution we can implement.
Let’s talk about user experience:
- First, the native experience is undeniably the best;
- Second, Flutter, with its own rendering engine, is as good as the native experience in terms of performance and presentation of controls.
- Next comes the ReactNative/Weex solution, which renders the front-end code to native Natvie controls. In the early version, some controls were not optimized enough to cause App lag, so the performance of user experience was insufficient.
- Finally, HTML5 renders completely through the browser kernel. With the help of preset resources, kernel optimization and other technologies, HTML5 can achieve close to the native experience, but the overall performance is still different.
Then there’s dynamic support:
In the second chapter of this article, “Off-line package mechanisms + Release Platforms,” we look in depth at the importance of dynamism in supporting high-concurrency business scenarios from the perspective of rapid iteration.
- First of all, the most dynamic is the HTML5 solution: you can access online pages, the server can take effect immediately, but also through the way of resources, dynamic update;
- The second is ReactNative/Weex solution, through certain customization, developers can deploy the front-end package, hot update. However, compared with the dynamic of “online + offline” of HTML5, there is still a gap in this scheme.
- Next is native. Both Android and iOS terminals can be dynamically updated by some black technology means. However, due to the prohibition of iOS policy, the native scheme is not recommended for the time being in terms of dynamics.
- Finally, Flutter has a powerful thermal overload mechanism, but due to Google’s restrictions, the online version of iOS cannot be thermally updated, thus placing Flutter at the bottom of the dynamic assessment.
Finally, let’s talk about the r&d difficulty of realizing each scheme:
- Here we temporarily put HTML5 in the first place, because to make HTML5 Hybrid solution, kernel optimization is indispensable, and kernel optimization requires certain kernel research and development capabilities, so FROM the perspective of developers, HTML5 research and development is the most difficult. If it’s just an HTML5 container, it’s a lot easier to develop;
- The second is Flutter. Currently, in terms of practical business application cases, only Xianyu team has applied Flutter in a relatively large number of Apps in China. Meanwhile, there are still a large number of Open Issues waiting to be resolved in Flutter GitHub. In the practical development and application of Flutter, developers should pay attention to the life cycle management, view stack management, native page switching and other issues in the early selection process.
- Next is ReactNative/Weex. Because these two solutions are open source and have a large number of mature technical community support, the development difficulty of the solution is not high for developers. At the same time, the open source code is convenient to modify, which is easier to use.
- The last one is the native solution. If thermal repair is not considered, the native solution can be used directly without any changes. If you consider hotfixes, there are some mature open source hotfixes you can use directly.
To sum up, after considering the pros and cons of all parties, we decided to adopt the “HTML5 container + kernel optimization” approach to deal with the development problems of complex business. Let’s take a look at the architecture of the container.
1.2 Container Architecture
The top layer is native HTML5 code, which is the common Web development environment, including HTML, CSS, JavaScript, and so on. The next layer is offline package management, which we cover in detail in Chapter 2. Next is the HTML5 container layer. As the middle layer, THE HTML5 container organically combines the browser and the underlying framework of Alipay, and also provides various life cycle mechanisms, event mechanisms, extension plug-ins and other contents.
There is a very important concept in the HTML5 container: JSBridge. Through JSBridge, HTML5 container will connect various capabilities provided by the bottom layer of Alipay framework and middleware layer with HTML5 front-end code, including RPC (remote procedure call, used to realize communication between App and server), payment, scan, etc.
At the bottom is the underlying framework of Alipay, which provides concepts such as micro-applications and micro-services. An HTML5 application is also simulated by the framework as a microapplication, decoupled by the application ID.
1.2.1 JSBridge introduction
JSBridge is the cornerstone of HTML5 container. It Bridges JS environment and Native and realizes the two-way communication between Native code and browser environment. Native code can run JS by calling the interface provided by browser, so as to call JS functions and transfer parameters to JS environment. However, the communication between browser and JS environment is realized by intercepting the requests of Native browser, which can be network requests or calls of some internal functions.
1.2.2 H5 Container customization extension
The HTML5 container provides two extensions:
- JSAPI
JSAPI adds a Native function invocation interface to HTML5 pages. By implementing the Handler method in the customized JSAPI class, specific functions can be realized in Native form, such as calling Native encryption functions.
- The event
HTML5 container will send events when the state changes. By listening for HTML5 container-specific events, you can realize the processing of the LIFE cycle of THE HTML5 container, such as modifying the color of the loading progress bar, modifying the page navigation bar, etc. Events provide more customization and are perfectly suited to the various customization needs of HTML5 containers
1.3 Container Stability
As mentioned above in the development difficulty, THE DEVELOPMENT difficulty of HTML5 is the highest, because the kernel needs to be customized for performance and stability optimization. At present, Alipay uses the UC kernel developed by Alibaba Group, and has carried out in-depth optimization and customization for alipay’s HTML5 container. As shown in the figure, the data comparison effect of the lag rate between UC kernel and system kernel is very significant, and we can intuitively see the improvement of Webview stability.
2. Offline package mechanism + release platform, instant update, to meet the rapid business iteration
Another feature of Alipay’s current business is that it needs rapid iteration. Changing policies and emergencies require us to quickly reach users with new business requirements. But there is one issue for App developers that can’t be ignored: App Store approval. Due to the existence of audit, the business developed on the App will have a unified schedule. For example, there will be a new version at the end of the month, so all the business progress will have to consider the schedule of the App.
2.1 Offline Package Mechanism
In order to achieve a good user experience, we introduced an offline package mechanism in the container. Through the offline package mechanism, we deliver the HTML5 application originally loaded from the online to the local in advance, and render the page by reading IO or memory, so as to achieve close to the native user experience.
Through the release platform, we can deliver different HTML5 offline packages in different dimensions in the form of individual applications, so that the original all-in Native release mode can be changed into a parallel release mode in which each business line customized release plan, formulated release standard and released by itself, so as to meet the rapid iteration of business.
2.1.1 Loading mechanism
By means of memory loading in advance, periodic update, and starting preloading memory, we load the resources needed by a service package into memory, so as to make the startup process as insensitive as possible and the page opens in seconds without blank screen. At the same time, we also have Fallback to ensure 100% availability of the business in the form of an online page in case of package damage or incomplete download.
2.1.2 Common Resource pack mechanism
A common resource pack is a collection of common resources that are likely to be used by any HTML5 offline package. Common Resource packs solve the problem of redundancy caused by multiple HTML5 applications using the same resource. React applications, for example, use ReactJS framework code. You can reduce the size of your HTML5 application by putting common resources into the global resource bundle.
Through the common resource pack mechanism, the package size of each HTML5 application can be effectively reduced, so as to improve the update rate and speed up page opening.
2.2 Release Platform
To meet the need for rapid iteration, a strong release platform is also essential. The core index of the publishing platform is to release the content to the specified device efficiently and accurately. In order to achieve this goal, we have made the following efforts.
2.2.1 Offline Packet size control and differential packet mechanism
HTML5 container offline package provides an update mechanism, with a single offline package as the update dimension. Because a single offline package service is simple, the size of an offline package is controllable, usually less than 500KB. Through a lot of practice, we concluded the value of “500KB”, which can not only meet the content of a single business, but also can be published to the device more efficiently. 500KB, in the era of 4G, users can almost no perception update, even 2G/3G can ensure a high arrival rate.
This is the size of an HTML5 app. In fact, our updated package will be smaller, and the publishing platform will calculate the difference package of two different versions of the same HTML5 application through the DIff algorithm. The difference package usually ranges from a few KB to dozens of KB, which can achieve a higher download success rate, and the success rate of download means the actual arrival rate.
2.2.2 Fallback mechanism
Fallback access comes into play in extreme network scenarios where a new business resource pack update fails and we expect users to use the latest business. A copy of each offline package resource will be stored on the distribution server platform. In extreme scenarios, users will access the Fallback address of the server to obtain the resource, thus ensuring that the page is available.
2.2.3 Multi-dimensional Publishing
In addition, for the newly developed application, we can release it through the grayscale release of the release platform. Through the form of external grayscale, we can verify the business indicators. After reaching the standard, we can officially release it.
3. Superior Hybrid solution: DIFFERENTIATED parsing of HTML5 and small programs
As a super App, one of the most important characteristics is openness. Openness means sharing App traffic so that external partners’ businesses can reach users through Alipay, which is a problem of quality control. Alipay needs to ensure that these businesses are legal and compliant and protect users’ property security.
3.1 Offline packages VS applets
Offline packages are definitely a good choice if you’re developing a business. However, when it comes to opening up the ecosystem to third-party partners, pure HTML5 pages have some disadvantages.
Above is a detailed comparison of HTML5 offline packages and applets. In conclusion, for the ecosystem open to the third party, from the perspective of application experience, small programs are more unified, quality assurance; From the perspective of application security, the small program is to visit our publishing server, not directly access the third party links, safe and controllable; From the research and development threshold, small program is a simpler way of front-end development, but also provides a very rich component.
3.2 Applets parsing
Applets are essentially similar to offline packages, both Hybrid applications, but applets are based on a custom DSL language, not front-end standards, but similar. The development of small programs under DSL rules does not support direct DOM manipulation. Such freedom under DSL rules can effectively carry out quality control.
Applets as an application, he has a complete life cycle. From development to closure, developers can feel this, which HTML5 doesn’t have. In addition, each small program is completely isolated from each other in terms of runtime and persistence, and the small program runs in a specific process, so it is also isolated from Alipay.
In terms of rendering performance, the small program adopts dual-thread mode to place page rendering and business logic in two separate threads. Renderer runs in WebView and is responsible for rendering the interface. The applets business logic runs in a separate worker thread, responsible for event handling, API calls, and lifecycle management. Data can be exchanged between the two threads through postMessage and onMessage. The data can be passed from the worker thread to the render to re-render the interface, and the renderer can also pass the event to the corresponding worker for processing. One worker can correspond to multiple renderers, facilitating data sharing and interaction between pages.
In terms of resource loading, applets are loaded in offline mode, that is to say, when the applets are opened, the applets offline package must be downloaded to the local, because each version is only downloaded once, on the one hand, the resource cost of each request is saved, on the other hand, the startup speed is greatly improved. When a new version is available, the distribution platform automatically compares the locally installed version with the latest version and delivers the differential package. The client can update the small program to the latest version without downloading the entire package.
3.3 Ecological Construction
By introducing the same applets architecture, applets can be used as an ecosystem for multi-terminal interoperability. The small program put in Alipay can run in the App based on the same small program architecture only through some open interface adaptation. In the future, developers or third-party services are more oriented to small programs, while App is to provide a unified architecture, truly open ecology, the concept of “run out”.
About the HTML5 container scheme developed by Alipay
MPaaS offline package is derived from alipay’s native solution and has gone through rigorous business tests. It allows you to directly use the same set of framework layer code with Alipay, and has a unified container and kernel. Compared with the system kernel, it has lower Crash rate and ANR rate, strong adaptability and good elastic expansion ability. Customize the JSAPI according to your specific business requirements. It can help reduce App white screen, solve Hybrid App cross-platform compatibility and adaptation, improve App performance and greatly optimize package size under native development.
MPaaS offline package Demo source has been updated on GitHub, welcome to Star: github.com/alipay/mpaa…
Welcome to apply for the trial, more optimization advice and use feedback: mpaas2019.mikecrm.com/otOU1k1
Join our communication group and look forward to communicating together to output better Hybrid development solutions:
Past reading
The opening | ant gold clothes mPaaS core components of a service system overview”
Core Components of Ant Financial mPaaS Server: Analysis of Mobile End-to-end Network Access Architecture under Hundred-million-level Concurrency
MPaaS Core Components: How does Alipay build public Opinion Analysis System for Mobile Terminal Products?
“MPaaS Server Core Components: Mobile Analysis Service MAS Architecture Analysis”
Component System Design of Ant Financial facing Hundred-million-level Concurrency Scenario
Evolution of Automated Log Collection and Analysis in Alipay App
Follow our official account for first-hand mPaaS technology practices
Nail Group: Search group number “23124039” by nail group
Looking forward to your joining us