19.. MPaaS Small program New Release Conference


With the increasing maturity of small program technology, the advantages and typical application scenarios of different platforms have different focuses. At the same time, more and more developers can combine their own business characteristics and use small programs as business carriers to form a single platform or multi-platform collaborative relationship.


Today, with the opening of small program technology, mPaaS small program framework, as a general framework of App, helps developers to implement small programs for their own APPS. Not only that, small program code only need to write once, can be put into the own App, Alipay, Dingding and even other small program open platform.


This paper will focus on the evolution of Alipay’s mobile terminal architecture, and share our thoughts and specific practices on “App dynamics” and “improving R&D efficiency”.


At the same time, in view of the opening of mPaaS small program capability, we will also introduce how to achieve “small program code only write once, multi-end delivery”, which will bring completely different development experience to developers.


Development history of Alipay App

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


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 App, which is characterized by “service-oriented, modular and componentized tools”. 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 grew into a super App. At this time, alipay needed to support a large number of complex businesses.


In 2018, with the launch of mini program, Alipay began to open its business capabilities and help partners with its own traffic. Therefore, the whole App faces challenges of openness, dynamic and high availability. Facing these challenges, we summarize it into the following three aspects:



1. Dynamic and experience

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

  • How to ensure user experience under the premise of dynamic update of App?



2. R&d efficiency

  • How to write code once, multiplex?

  • Without client development experience, how to improve development efficiency?



3. Open ecology


  • How to open up capabilities to more developers?

  • How to connect more ecological platforms and enrich App scenes?



There are problems, we will solve these problems through technical means, we start from the above three directions, to carry out the technology selection.


First we start from business
Development costsPerspective:
  • 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, but there is still a significant amount of end adaptation;

  • 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.



So let’s talk about
The 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 is
dynamicSupport:
  • 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.

  • There is a powerful hot reload mechanism for Flutter. However, due to Google’s restrictions, hot update cannot be implemented in the official iOS version. Currently, iOS hot update can be implemented by modifying the engine, JIT and AOT methods, or by using runtime parsing rendering to make it dynamic. However, FLUTTER is slightly less dynamic than the above two schemes.

  • Finally, 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 solution is not recommended for the time being in terms of dynamics.



After analyzing the different directions of the four schemes, the answer brought by mPaaS is as follows:
“Hybrid architecture solution that combines dynamism, experience, development efficiency and openness, i.e
MPaaS applet“.


MPaaS small program technical analysis

What are applets?
According to the W3C Applets White Paper,
Applets are a dependency
Web
Technology that integrates native capabilities into new mobile application formats.It has access”
Convenient, stable connection, safe and reliable, excellent performance“These four characteristics.


mPaaS
Small program, based on
Web
Technology,
Low learning cost
.
A small program code,
At the same time support
iOS
and
Android
Close to the native experience.
At the same time provide
Rich components and
API
, such as access to user information, local storage, payment functions, etc.


Next, we will disassemble the complete technical architecture of the small program and try to expand the overall architecture of the small program through the “running stage, development stage and release stage”.

  • Operation phase

The small program uses the dual-thread mode to place the page rendering and business logic in two separate threads. Renderer runs in the 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.


For scenes requiring high rendering speed and interactive response, such as maps, the applet inserts native map components into WebView, which is faster and more efficient than rendering maps on Canvas.


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 downloaded only 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.


  • Development and release phases

Application development must not lack the support of a complete tool chain, small program IDE is a collection of coding, debugging, preview and release capabilities. After simple adaptation, the client can preview and debug small programs in real time in the real application.


With an initial understanding of the applets architecture, let’s look at how mPaaS applets implement dynamic publishing. This is exactly the highlight of mPaaS small program core. With the ability of “package release and management”, the efficiency of App development and iteration can be deeply optimized.

As you can see above, we have redefined the development model and release process so that each applet can be a standalone product with its own release process without waiting for other teams. Each business team is completely split, and each business evolves independently and is released independently.


During the release process, follow the following procedures:
  1. Indicators are linear, defining service and performance indicators for each release.

  2. Intelligent gray scale, internal gray scale, external gray scale, designated gray scale;

  3. Real-time monitoring, repair cycle;

  4. Online transportation and maintenance means of technical support.


And then we’ll talk about security for applets.
  • Connect the safety

Based on Alibaba’s wireless bodyguard capability, the security of small program requests is guaranteed. Tampered requests cannot pass verification.
  • Inclusions security

The package body is encrypted and signed to ensure the security of the download process. The tampered small program package cannot be used normally.
  • Access security

Complete rights management system, for different small programs open different rights, to ensure user privacy security.




Next we look at the applets framework capability extension architecture.

MPaaS mini program itself has integrated nearly hundreds of commonly used APIS, including network, media, storage, positioning, scanning code, Bluetooth and so on, and these apis can also run perfectly in Alipay.

Moreover, application developers can expose their own features of mPaaS applet extension capabilities to applet developers. This expansion mainly includes three aspects:

  • Capability expansion: Custom event capability, support for “applet -> native”, and “native -> Applet”

  • Style extension: provides a variety of native style customization, including navigation bar, loading animation, launch animation and other native styles

  • Component extension: Provides the ability to customize components and extend applets tags


Finally, we’ll talk about the multiapplication and ecology of applets.

Based on the mPaaS applet system, we can convert a large number of applet standards into standard applet artifacts, such as those written by the developers themselves, through tools
mPaaS
Small program, or
mPaaS
Small program market small program, or Alipay or other tripartite small program. Once the IDE conversion is complete, we can put it on different ends through two channels. use
mPaaS
Release platform, can be put into its own App, using other three open platforms, can be put into the corresponding terminal, one development, only a small amount of adaptation, can be put into multiple terminals.



Of course, in the case of a relatively lack of business scenes in its own App, Alibaba’s tripartite business scenes can be delivered seamlessly based on the unified small program framework of mPaaS, so as to meet the needs of developers to enrich their own business scenes.


Mobile terminal capability building based on mPaaS applets

The above introduction to the technical architecture and ability of mPaaS applet, next we talk about mPaaS applet in the specific development of thinking.


  • Mobile capacity building

In the so-called mobile Platform capacity building, we hope to integrate the entire App architecture: at the basic level, the common components will be sunken to avoid the repeated creation of wheels, and at the same time, the service interface will be standardized to provide high-quality, stable and standard services for more upper-layer businesses.

So we need to approach this from two sides.



  • Based on the component

We may have a problem in the development process, is the two teams of collaborative development, maybe people have their own precipitation of some classic components, we can precipitate these components, at the same time, also through the ability of the applets to customize components, to provide services to the applets.
  • Servitization of core competencies

After component precipitation, we need to servitize some core business capabilities, abstracting them into standard service interfaces or small program apis for other teams or third parties to call. For example, alipay’s payment service and Zhima Credit service rely on servitization and ultimately provide good services for other businesses.


  • Mobile Reception Desk Construction

After we complete the mobile platform capability building, the overall capability is already available, and the rest is to combine the small program framework to build our mobile front desk capability.


  • Core business experience optimization

For some very core business logic, such as the payment of the baby, as well as some high performance requirements of the business, such as the home page, or some special interaction pages. Usually we want to implement pages using native pages or native technologies such as Flutter. Because these pages are usually not drastically changed, they are not very dynamic and can be used natively to meet the needs of a variety of user experiences on these pages.
  • Complex business small program

For some complex secondary businesses, the business itself may be frequently iterated, which will be a disaster for the native development experience. At this time, we need to separate this part of the business, transform the business into small programs through front-end technology, and release the offline package to the application through the release of services. In this way, we can meet the complex and changeable scene of our business.
  • Tripartite ecology

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 standard and simple as a small program because of its too broad front-end standard and certain technical threshold. At the same time, in the use of the mobile platform construction we introduced above, the third party small program to provide a variety of their own capabilities, complete the diversification of the scene.


Around the small program how to help us transform their business module, and gradually form a dynamic update, I believe we have a more comprehensive understanding.


Currently, mPaaS applets are available for free trial,Welcome to the experience.


– – – – – – END – – – – – –


👉 about mPaaS applet 👈

Derived from alipay small program framework

Exercise the volume of online business of 100 million level

Security comparable to the original ability of Alipay

Not just for your own App

More quickly build packaging

Cover alipay, Taobao, Dingding and other applications