The architecture of doumi client

Time:2020-6-30

background

With the rise of mobile Internet industry, various kinds of apps emerge in endlessly, and the technical solutions are various. Similarly, we also face a variety of problems, such as how to develop products more quickly and iteratively online, how to make operation and promotion more flexible, how to reduce R & D costs, and improve R & D efficiency and quality. With the development of random products, we are more and more eager to seek solutions to these problems.

After years of research and development experience in app, browser kernel, H5 and server, in 2015, I first proposed it on the client product of doumiThe idea of client platform architecture based on URD driving weboxAfter two years of exploration and practice of several products, I think the architecture idea of the app can be formally shared with the outside world. Due to the space, today I only share from the architecture ideas and principles, not the implementation of sharing, hoping to bring some thoughts and inspiration to friends who are exploring the same problem.

At present, APP in the industry can be divided into three categories: web app, native app and hybrid app. Next, I will share the architecture ideas of hybrid app. As for why hybrid app is used to share, the advantages and disadvantages of these three apps will be described later. Of course, this architecture idea is also suitable for pure native apps.

In order to better understand this article, welcome to download doumi part-time client experience, doumi client H5 has reached more than 90%.

Overview of Architecture

The architecture of doumi client

Let’s briefly explain the concepts of URD and webox

  • URD is a unified resource scheduler, and its English name is uniform resource dispatcher. It is a string used for cross platform and cross end resource scheduling, which allows users to interact with any resource (including local and Internet) through a specific protocol.
  • Web box is used to carry the content of the page, collectively known as the web box, the full name of the web box. Webox contains blockbox and browser

Problem solved

Cross platform, architecture consistency

At present, the mainstream mobile OS are Android and IOS, and most products will cover these two platforms. Due to the platform mechanism of Android and IOS, there are differences in the technical architecture of the two platforms. Gradually, the apps of the two platforms are relatively independent, and the implementation schemes are also greatly different. The systematic technical solutions are not easy to implement, and the communication and maintenance costs are gradually increasing, which is also a headache for architects.

Have you encountered such a scenario

  • Human resources are insufficient. We hope to implement it on one platform and then run it on other platforms
  • A new platform, such as wechat applet, needs to be redeveloped. If only the business could be reused
  • If the company has multiple products, we need to reuse basic services, consistent architecture, and reduce communication costs
  • IOS and Android are not consistent in product technology implementation. At this time, the server needs to be compatible with the two platforms.
  • Sometimes, the interface of external operation promotion is not unified, so the market needs to promote the two platforms separately

As a result, we realize how important cross platform, architecturally consistent solutions are to us.

Product iteration fast, fast release

We all know that app release is not an easy thing, we need to pass the package to various channels. If there is an emergency major bug, we need to re type all channel packages and go through the release process again. This is a painful thing for each team.

The product can be released quickly, and even only needs hot update. This is a sharp sword for quick trial and error of products and cracking down on competitive products.
In each client of doumi, DEK can be used to publish the app without publishing. DEK is a kind of package for hot update, which can be launched quickly and cross platform (shared by IOS and Android). It is as simple and flexible as web online.
The release rhythm of app is generally about three or four weeks. For DEK, if it is only fix bug, it can be released in one or two days. If it needs to be released, it can be completed within one week,

More flexible operation and promotion

URD is the core driving force of this framework, and it is also an important tool for operation and promotion.

  • Scenario 1: in end operation
    1. The landing page of general operation activities is a web page implementation. If you want to click from the activity landing to jump to a product details page of app (or any other app page), after the URD mechanism is in place, the operation and promotion department does not need to provide the client team with requirements for implementation, it only needs to use URD to jump to any page of app.

2. When the web is embedded into the client, when there are pages related to the implementation of our client (such as the details page), 302 will automatically jump to the app page to improve the user experience.

Of course, if we use the cookie mechanism, the login state of the end and the web will be synchronized with each other

  • Scenario 2: off end operation

    When we cooperate with a third party, we can provide URD to the third party app or third-party Web site. URD has the ability to transfer the app and jump to a page of the app

Decoupling and expansion capability

The combination of URD and webox makes app have strong decoupling and expansion ability. URD is the driving force, which can achieve cross platform page scheduling, such as H5 scheduling webox, native scheduling webox, server scheduling webox, external scheduling webox, and the content in the webox can also jump to the outside of the end; and webox is the container for carrying pages and content, and the content is deployed by DEK, and the DEK can be hot updated. The whole mechanism is cross platform with high flexibility and strong decoupling and expansion ability.

cost reduction

The reduction of R & D cost is more obvious in this framework. Business development is mainly based on JS language, and native is mainly responsible for framework and performance related support. JS is a cross platform and extensible language, which can reduce the development manpower of hybrid app by half compared with that of pure native app

App classification

At present, app is roughly divided into three categories

The architecture of doumi client

Web App

definition:All functions are displayed on the web and run based on local browser. In this paper, the application that sets a layer of APP shell to the web is also classified as web app. It is fully written in HTML / CSS / JS and optimized for touch operation. Currently, IOS has banned simple shell app from being put on the shelf.

advantage:Fast development, cross platform, low cost, real-time iteration, users do not need to update

Disadvantages:High network speed requirements, server pressure, system level API call difficulty, poor user experience, low user retention

Native App

definition:Native app is based on the local operating system of mobile phone and written in native language. Because it is located above the platform layer, the ability of downward access and compatibility will be better. It can support online or offline access, message push or local resource access, and camera dial-up function. However, due to the fragmentation of the device, the development cost of app is much higher. It is more troublesome to maintain the update and upgrade of multiple versions, and the installation threshold of users is also relatively high.

advantage:User experience is good, interactive style is consistent with the system, save traffic, access to local resources, fast speed, high user retention

Disadvantages:High cost, slow version iteration, need to be reviewed

Hybrid App

definition:A compromise between web app and native app, the bottom (framework) part is handled by IOS / Android developers, and the upper layer (content presentation) is handled by web front-end personnel. The user interface operation logic and some static resources reside locally, which makes web app respond to operations quickly and realize offline access to a large extent.
Hybrid apps are divided into four types: single view hybrid, multi view hybrid, web based and multi agent coexistence (flexible). Click here to see the encyclopedia

The multi-agent coexistence hybrid app can realize the experience similar to the native app.
The advantages and disadvantages of the multi-agent coexistence hybrid app are described below.

advantage:With cross platform, good user experience, good scalability, strong flexibility, easy maintenance, standardization, with debug environment, thoroughly solve cross domain problems.

Disadvantages:If there are more interfaces with the server, there will be more communication costs with the team

Architecture analysis

When it comes to the architecture of doumi client, we have to briefly introduce kerkee.
The basic framework of doumi client uses the kerkee framework( http://www.kerkee.com )Kerkee is a multi-agent coexistence hybrid framework with cross platform, good user experience, high performance, good scalability, strong flexibility, easy maintenance, standardization, integration of cloud services, with debug environment, and thoroughly solve cross domain problems.

Overall structure diagram

The architecture of doumi client

The overall structure is divided into the following parts. The doumi client will encapsulate these basic capabilities into the doumi framework to facilitate the use of other projects.

  • Application layer: mainly including URD architecture and webox container architecture, as well as some business modules. The first two versions of webox container, called multi frame browser, are not very easy to understand. At that time, the container model was not built.
    Multi frame browser is a container for loading local pages and web pages. Later, it was found that “multi frame one browser” was too arbitrary, and the definition of box was based on functions. For example, loading the home page was called the home page box, loading the details page was called the detail page box, and loading the list page was called the list box. When the types of pages were more and more, there were more and more boxes, which resulted in flooding. There was no unified type, and the cost of communication was also increasing Big. Later, we also modeled the box and established the specification, which led to today’s webox, which will be introduced later.

URD is also the core driving force of the architecture. URD is a cross platform specification based on RFC 3986. I believe that everyone can understand and use URI, but URD is not a URI, it is just the same as URI in the level of call and use.

  • API layer: this layer is very important. It is the API interface for JS to interact with native. The API in this layer can override the functions in kerkee. For example, if you see that the implementation of XMLHttpRequest (XHR) in kerkee is not well implemented, you can rewrite the XHR interface to completely replace the XHR module in kerkee. The interface of this layer can use static classes or objects. For specific usage, you can see the use of kerkee.
  • Kerkee framework: it is a hybrid app framework I implemented in my early years, which is relatively stable at present. Let’s not say much about this lib. On top of this lib, there is a kerkee plus, which encapsulates hot deployment and some functional interfaces. Specific details can be seen online http://www.kerkee.com
  • Intelligent data engine: This is the data layer, in which all data logic is circled. It defines the source of data request, the logic of data operation, and the formation of data flow.
    For example, it can be provided to the application layer, whether the data is read from the cache or from an offline database or requested from the server. The application layer does not need to care about the data source.

Generally speaking, for app development, after the business stabilizes, the data layer generally changes less, and the user experience layer (application layer) changes more. With the data layer, the structure of APP becomes clear.
The architecture of doumi client

security policy

We’ve done a lot of work on data security.

Accesstoken mechanism

First of all, let’s introduce the nouns
DEK encryption algorithm: the self-developed encryption algorithm has high stability and good security. Now the whole API interface of doumi is basically encrypted based on this
Devicetoken: device unique identification, a set of device unique identification developed by us
Accesstoken: the required and token of the access interface. It is initiated by the client and changes dynamically. Each time a request is initiated, a different accesstoken will be generated. The principle is similar to ETOKEN of the bank, which is the following picture
The architecture of doumi client

Accesstoken contains information such as devicetoken, which is processed by DEK encryption algorithm and then reported. If there is no accesstoken in the requested data or the accesstoken verification fails, the data will not be issued.
The architecture of doumi client

Additional:
We use HTTPS for all requests. For security, we lose some performance of the request interface.

Webox

Web box is used to carry content, which is called web box. Webox contains blockbox and browser.
According to the bearing blocks:The content hosted by “blockbox” can be native component or H5 component (or H5 page), while the content hosted by browser can only be H5 page
According to the path of the block:“Blockbox” supports not only relative path path, but also absolute path full path and standard URL; browser only supports URL.
The architecture of doumi client

give an example:

Blockbox: common blockbox, home page box, details box, list box, login box, etc
Browser: the box used to hold the web page

URD

What is URD

Literal URD
URD is a unified resource scheduler, and its English name is uniform resource dispatcher. It is a string used for cross platform and cross end resource scheduling, which allows users to interact with any resource (including local and Internet) through a specific protocol.
The URD protocol follows the URI specification (RFC 3986 specification), and the document address is: http://www.ietf.org/rfc/rfc39…

URD format
scheme://action/path-encoding?query#fragment

Difference between URD and URI
Uri is an abstract, high-level concept to define uniform resource identification;
The protocol defined by URD is based on URI. URD is the way to schedule specific resources and the distribution of available resources. URD is not only a representation of a URI, it can also nest URLs and other URIs.

URD on Architecture
URD is a set of client-side technology architecture and a philosophy of technology. It is the driving force of the client and the identity of webbox content.
It has the characteristics of cross platform scheduling page, multi-layer nesting, data return, one-way page dependent scheduling, urd302 and so on

Important features

Cross platform scheduling page:H5 can schedule the webox, native schedule the webox, the server can schedule the webox, the server can schedule the webox, and the content in the webox can also jump to the out of end capability

Multi level nesting:The URD page can schedule another URD page

Data return:Through URD, data can be transmitted (including transparent data) and returned data

Single page dependent scheduling:
An example is used to illustrate that, for example, a URD is initiated from a page in H5 to schedule the user’s wallet page, and the wallet page depends on login. For the caller, it does not need to know whether or not to log in to the wallet. The URD will automatically call up the login to log in, and then automatically go to the wallet page.

Support 302 jump
Urd302 jump is similar to HTTP 302. After a urd302 is launched, the initiator’s page will be destroyed.
Scenario: sometimes our client embeds a third-party Web page, but the third-party Web page does not use URD to call the page in the client. At this time, using urd302 in the web page, the browser will automatically identify the existing webbox page in the client and automatically jump to the native page. When the user clicks back, it will return to the previous web page, which can improve the user experience.
For example: aweb pages need to go to bweb pages. Bweb pages have corresponding bcclient pages in the client. The aweb page jumps to open the bweb page. In the bweb page, urd302 will be initiated. At this time, the URD will jump to the bclient page and destroy the bweb page. When the user needs to go back, he will only return to the aweb page

URD map
The architecture of doumi client

Why use URD

URD is a cross platform specification. Depending on scheme, it can adjust IOS app and android app. Moreover, cross platform page scheduling becomes more flexible, and cross platform data transmission also brings a lot of convenience. URD in the whole architecture, page scheduling decoupling, flexible, good scalability. In terms of operation and promotion, it has become more flexible.
The architecture of doumi client

Start up process of webox
As for the URD interaction process is more complex, which is not what the length of this article can tell. Here I will share the webox startup process, please see the figure.
The architecture of doumi client

DEK upgrade

This section is also more complex, I share the basic principles of implementation. The usage is not so complicated. Each webapp has an ID. when the ID is 0, it will be updated in full (including all webapps). If the ID is not 0, it will be updated incrementally. The update of webapp is determined by the manifest of webapp’s main entry.

use

The client will request the webapp list to be updated from the server, and the server will return the webapp array to be updated

for example[{id = 0, manifest = webapp entry manifest "}]

The client judges whether to update a webapp in full or only according to its ID. in this case, the total value refers to all the webapps

principle

DEK update mechanism (in the form of manifest file) follows the HTML5 offline storage specification. In H5, only the annotation function is extended, while native implements and extends the HTML 5 offline storage specification.

Format:#[name]: [value] is pound sign + space + name + colon + space + value

  • In the template architecture design of H5, each module forms an independent webapp (the framework is also webapp, each module runs in the framework), and each webapp can be updated independently (represented by DEK file)
  • Each webapp can be split into multiple deks (of course, a DEK can also be used) to facilitate incremental updating
  • Each webapp has an entry manifest, and each DEK corresponds to a manifest
  • Can achieve full update (all webapps) and incremental updates (single webapp)
  • File level update: if only webapp is updated, the cache field or network field determines the file update method in the DEK package. If the cache field is empty, it indicates that the webapp is updated in full (at this time, the total amount is the total amount of a webapp)

Manifest file format

CACHE MANIFEST

# Version: 1.0.0.1
# RequiredVersion: 1.0.0
# List: ./others/cache.manifest, is/xx.manifest, ../../xx/xx.manifest
# Dek: xx.dek

CACHE:
images/1.0/bg.jpg
musics/1.3/bg.mp3
css/xx.1.2.min.css
xx.1.1.min.js

NETWORK:
*

Format description

The architecture of doumi client

Construction system

Look at the picture! This is a diagram of the webapp build deployment.

The architecture of doumi client

summary

Webox client platform architecture driven by URDIn the actual practice, it is more flexible and operable, and has a guiding role for the team.