Mobile Platform as a Service:Deep Analysis of the Technical Architecture of mPaaS Mini Program

As Mini Program technology becomes more mature, the advantages and typical scenarios of different platforms have their own emphasis. At the same time, more and more developers can combine their own business characteristics and use Mini Programs as business carriers to form a single platform or multi-platform collaborative relationship. Today, with the opening of Mini Program technology, mPaaS Mini Program framework, as a general framework for App, helps developers to implement Mini Program delivery for their own App. Not only that, the Mini Program code only needs to be written once, and can be multi-terminal delivered to its own App, Alipay, DingTalk and even other Mini Program open platforms.

This article focuses on the evolution of Alipay's mobile architecture and shares our thoughts and practices on App dynamics and improving R&D efficiency. At the same time, in view of the opening of mPaaS Mini Program capability, we will also introduce how to realize "write Mini Program code only once, multi-terminal delivery", which will bring developers a completely different development experience.

Alipay App Development History

First of all, let's review the specific development process of Alipay App in recent years.

At first, Alipay was only a tool App for single application, allowing users to complete Alipay-related business inquiries and operations on their mobile phones. After 2013, Alipay has gradually transformed into a platform-based App, which has the characteristics of "service, modularization and tool componentization". At this time, Alipay's business is not only to pay, but also to provide customers with a lot of life-related services, such as Yu'E Bao, pay electricity bills and so on. After 2015, Alipay has grown into a super App. At this time, Alipay needs to support a large number of complex businesses. In 2018, with the launch of Mini Programs, Alipay began to open up its business capabilities and use its own traffic to help partners. Therefore, the entire App faces the challenges of openness, dynamics, and high availability. Facing these challenges, we summarize it into the following three aspects:

Dynamics and Experience

• In the face of diverse requirements, how to ensure the rapid iteration of the business?

• On the premise of ensuring the dynamic update of App, how to ensure the user experience?

R&D efficiency

• How to write code once and reuse it in multiple terminals?

• Without client development experience, how can I improve development efficiency?

Open ecology

• How can we open up our capabilities to more developers?

• How to connect more ecological platforms and enrich your App scenarios?

If there are problems, we will solve these problems through technical means. We will proceed from the above three directions to select technology.

First of all, from the perspective of business development costs:

• As the most basic development mode, native development needs to be carried out at both ends, which is undoubtedly the highest cost.

• 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 actual operation because JS is converted into Native component rendering. As a result, when developers write business interfaces, some differences need to be resolved through Native side custom development. Overall, ReactNative/Weex has helped businesses significantly reduce development costs, but there is still a lot of end-to-end adaptation work.

• Next is Flutter. From the perspective of business development, Flutter has really made great efforts for double-end alignment. In most scenarios, Android can run seamlessly on iOS after development, which is of course related to its self-developed engine. However, Flutter needs to be developed based on the Dart language, so for developers, the workload of porting some old businesses must be considered;

• Finally, HTML5, with mature language, mature development mode, double-end almost the same performance and other characteristics show that HTML5 is still the lowest development cost scheme that we can provide at present.

Let's talk about the user experience:

• First of all, the native experience is undoubtedly the best;

• The second is Flutter with its own rendering engine, which can be said to be no less than the native experience in terms of performance and display of controls.

• The next step is the ReactNative/Weex solution, which renders the front-end code into the local Natvie control. In the earlier version, App stuck due to the inadequate optimization of some controls, so the performance of user experience was insufficient;

• Finally, HTML5 is completely rendered through the browser kernel. With technologies such as preset resources and kernel optimization, HTML5 can achieve a close-to-native experience, but the overall performance is still different.

Next is dynamic support:

• First of all, the best dynamic is the HTML5 solution: you can access the online page, the server takes effect immediately, or you can dynamically update it by sending resources.

• The second is the ReactNative/Weex solution. Through certain customization, developers can hot deploy and hot update the front-end package. However, compared with the dynamic nature of "online + offline" in HTML5, there is still a certain gap in the scheme.

• Next is Flutter. Although there is a powerful hot reload mechanism, due to Google's limitations, the official version of iOS cannot be hot updated. Currently, iOS can be hot updated by modifying the engine, JIT and AOT, or by adopting run time parsing rendering to achieve dynamic. However, compared with the above two schemes, Flutter is slightly less dynamic.

• Finally, the native Android/iOS both ends can be dynamically updated through some technology means. However, due to the prohibition of iOS policy, the native scheme is not recommend for the time being in terms of dynamics.

After analyzing the different directions of the four schemes, the answer brought by mPaaS is: "A Hybrid architecture solution that takes into account dynamics, experience, development efficiency, and openness, that is, the mPaaS Mini Program."

Technical analysis of mPaaS Mini Programs

What is a Mini Program?

According to the definition of Mini Programs in the w3c Mini Program white paper, Mini Program is a new mobile application program format that relies on Web technology and integrates native capabilities. It has the four characteristics of "convenient access, stable connection, safe and reliable, and excellent performance."

mPaaS Mini Program, based on Web technology, low learning cost. A set of Mini Program code, which supports both iOS and Android, close to the native experience. It also provides a wide range of components and APIs, such as obtaining user information, local storage, and payment functions.

Next, let's disassemble the complete technical architecture of the Mini Program and try to expand the overall architecture of the Mini Program through the "operation phase, development phase, and release phase".

Operation phase The Mini Program uses a 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 Mini Program business logic runs on a separate worker thread and is responsible for event processing, API calling and lifecycle management. The two threads exchange data through postMessage and onMessage. Data can be passed from the worker thread to the render re-rendering interface, and the renderer can also pass the event to the corresponding worker for processing. A worker can correspond to multiple renderers to facilitate data sharing and interaction between pages.

For scenarios that require high rendering speed and interactive response, such as maps, Mini Programs embed native map components into WebView. Compared with rendering maps on Canvas, Mini Programs draw more quickly and efficiently.

In terms of resource loading, the Mini Program is loaded offline, that is, when the Mini Program is opened, the offline package of the Mini Program must be downloaded locally. Since each version is downloaded only once, on the one hand, the resource overhead of each request is saved, and on the other hand, the startup speed is greatly improved. When a new version is available, the release platform automatically compares the locally installed version with the latest version to generate and distribute a difference package. The client can update the Mini Program to the latest version without downloading the entire package.

Development and release phase Application development must be without the support of a complete tool chain. The Mini Program IDE integrates coding, debugging, preview, and release capabilities. After simple adaptation, the client can preview and debug Mini Programs in real-time in real-time applications.

After we have a preliminary understanding of the Mini Program architecture, let's take a look at how mPaaS Mini Programs will be dynamically released. This is precisely the highlight of the core of the mPaaS Mini Program. With the ability of "package release and management", the R&D and iteration efficiency of App can be deeply optimized.

As shown in the preceding figure, we have redefined the R&D model and release process. Each Mini Program can be used as an independent product and has its own release process without waiting for other teams. Each business team is completely split, and each business evolves and releases independently.

During the publishing process, follow the following process:

1. Metric linearity, defining business and performance metrics for each release;

2. Intelligent grayscale, internal grayscale, external grayscale, and specified grayscale;

3. Real-time monitoring, repair cycle;

4. Online operation and maintenance repair means technical bottom.

Then we will talk about the safety of Mini Programs.

• Connection security Based on the capabilities of Alibaba's wireless bodyguard, the security of Mini Program requests is ensured. The tampered requests cannot pass verification.

• Security of package body The package body is encrypted and signed to ensure the security of the download process. Tampered Mini Program packages cannot be used.

• Permission security Complete permission management system, open different permissions for different Mini Programs, to ensure the privacy and security of users.

Then we turn to the Mini Program framework capability extension system.

The mPaaS Mini Program itself has integrated nearly hundreds of commonly used APIs, including network, media, storage, positioning, code scanning, Bluetooth, etc. These APIs can also run perfectly in Alipay. Moreover, application developers can reveal their own functional mPaaS Mini Program extension capabilities to Mini Program developers. This expansion mainly includes three aspects:

• Capability extension: provides custom event capabilities and supports "Mini Program> native" and "native> Mini Program".

• Style extension: provides a variety of native style customizations, including native styles such as navigation bar, loading animation, and startup animation.

• Component extension: provides the ability to customize components and extend the Mini Program label.

Finally, let's talk about the multi-terminal launch and ecology of Mini Programs.

Based on the mPaaS Mini Program system, we can convert a lot of Mini Program standards into standard Mini Program products through tools, such as mPaaS Mini Programs written by developers themselves, or Mini Programs in the mPaaS Mini Program market, or Alipay or other three-party Mini Programs. After the conversion is completed through IDE, we can put it on different ends through two channels. Using the mPaaS publishing platform, you can put it into your own App, using other three-party open platforms, you can put it on the corresponding end, one-time development, only a small amount of adaptation, you can put it on multiple ends.

Of course, for the relatively lack of business scenarios in its own App, based on the unified Mini Program framework capability of mPaaS, the three-party business scenarios of Ali department can realize seamless delivery, thus meeting the needs of developers to enrich their own business scenarios.

Mobile capability construction based on mPaaS Mini Programs

After introducing the technical architecture and capabilities of mPaaS Mini Programs, let's talk about the specific research and development direction based on mPaaS Mini Programs.

Mobile mid-end capacity building

The so-called mobile mid-end capacity building, we hope to integrate the entire App architecture: at the basic level, further develop common components, avoid repeated work, and standardize service interfaces to provide high-quality, stable and standard services for more upper-level businesses. Then we need to deal with this matter from two aspects.

Basic components

We may have such a problem in the development process, that is, the two teams collaborate in development. Maybe everyone has some classic components. We can further develop these components. At the same time, we can also provide services to Mini Programs through the custom component capability of Mini Programs. Core capability servitization

After the components are precipitated, we need to service some core business capabilities and abstract the standard service interfaces or Mini Program APIs for other teams or third-party ecosystems to call. For example, Alipay's payment services, sesame credit services, etc., are based on the service, and ultimately good for other businesses to provide services.

Mobile front end construction

After we complete the mobile mid-end capacity building, the overall capability is already available, and the rest is to combine the Mini Program framework to build our mobile front end capability.

• Core business experience optimization

  For some very core business logic, such as Alipay payment, as well as some performance-demanding business, such as home page, or some special interactive pages. usually, we want to implement pages by using native pages or native technologies such as Flutter. Because these pages usually do not have major changes, the requirements for dynamic capabilities are not very strict, and the native can meet the needs of a variety of user experiences on these pages.

• Transform complex business into Mini Programs

  For some complex secondary businesses, the business itself may be iterated frequently, so the native development experience will be disastrous. At this time, we need to separate this part of the business, transform the business into a Mini Program through the front-end technology, and then publish the offline package to the application through the release service. In this way, it meets the complex and changeable scenarios of our business.

• Third-party ecologicalization

  We not only provide a variety of services ourselves, but also need to introduce third-party services to serve more people. The traditional H5 page is not as good as a standardized and simple Mini Program due to its overly broad front-end standards and certain technical threshold. At the same time, using the mobile mid-end construction we introduced above, we can provide a variety of self-mid-end capabilities for third-party Mini Programs to complete the diversification of scenarios.

Around how Mini Programs can help us transform our own business modules and gradually form dynamic updates, I believe everyone has a more comprehensive understanding.