One, foreword

Industry trends and industry conditions

The combination of the current mobile terminal and the front is more and more closely, boundary is more and more is not obvious, in recent years, along with the equipment performance get improved, such as network environment factors, which restrict the development of the H5 low performance and experience the difference of two problems got obvious improvement, H5 flexible distribution, low development cost advantage at the same time, promote the H5 in the use of Native more and more. Last year’s (2020) Alibaba Mobile Shopping Double 11 Event also verified the feasibility of H5 in complex scenarios from Weex’s full embrace of PHA (Progressive Hybrid App).

Pratt & Whitney four-wheel travel business demands

At present, The business of Pratt & Whitney (free ride, taxi-hailing, car service, kuai-delivery, etc.) is developing rapidly. Facing the demands of rapid iteration, it is necessary to derive a more reasonable architecture to ensure efficient and rapid iteration, rather than relying on additional manpower. Cross-end technology and container technology are the focus of this architecture upgrade.

Hybrid Container Status & Upgrade goals

The original H5 container only had a simple JSbridge channel. Due to the low performance of H5 rendering, poor interactive experience, low stability and low security, it could not meet the appeal of Pratt & Whitney for large-scale use. Therefore, we started the technical upgrade of Hybrid container in terms of improving performance and experience, stability and security. The goal is to “ensure the wide and stable use of Hybrid technology in pratt & Whitney’s four-wheel travel business”.

Main context of this paper

This paper will introduce the whole practice process and thinking from problem discovery, solution and online effect, and the main veins are as follows:

  • Current problems encountered by Hybrid containers
  • Problem analysis and solution
  • Detailed schemes and online effects for each point
  • Online effect after overall optimization
  • Follow-up planning and further exploration

2. Problems encountered by Hybrid containers

Fault 1. The o&M monitoring alarm is missing

The monitoring data of network errors, blank screen rate and other indicators are inaccurate. As the currently monitored data is placed on the H5 page by the front-end team, the running status of the H5 page can be sensed only after entering the H5 page, and the anomalies occurring when not entering the H5 page cannot be sensed, resulting in incomplete abnormal data and cardinal data.

There is no data monitoring for abnormalities occurring in the container, such as OOM, Crash in the container, and failure to enter the page due to poor network. Therefore, when online abnormalities occur in the container, it is difficult for the development and operation students to detect them, and they can only perceive the information through manual feedback (customer service feedback, colleagues/family feedback, etc.). In the travel industry, the complexity of the network in the process of rerunning of passenger equipment and the diversity of equipment lead to the above problems becoming more obvious.

Problem 2. Low performance

Before this, Hybrid container has launched a version of offline solution, but there is deviation in performance data. Currently, the average time of the first screen is 2800ms, and the opening rate of 1s is only 12%, and that of 2s is 59%.

Problem 3. Poor stability

Frequent online failures (white screen failure of the offline package 20200910 of The Pratt & Whitney Service) led to the offline package optimization offline. The page logic is complicated. Even after the package is offline, the online H5 page blank screen rate still reaches 7%. Poor system compatibility, especially the fragmentation of Android models, a lot of ROM use non-system WebView or do a lot of magic operations on it, resulting in compatibility deviation.

Problem 4. Poor interactive experience

The Loading style is ugly and there is a white screen during Loading, which has been ridiculed by the design product team. When a normal page is opened, the navigation Title of the page will blink several times, and the interaction details are a little rough.

Problem analysis and solutions

In view of a series of problems currently encountered by Hybrid containers, some things can be done after analyzing each point to complete the defects and greatly optimize the current situation.

The operation and maintenance monitoring alarm is missing

For The user’s intuitive sense of body, The statistical statistics of rendering time should be from The client’s click jump time to The H5 page visible LCP(The Largest Contentful Paint), including The client’s page jump and WebView startup time. Closer to the user are measured in order to make the experience real body feeling, we buried the united front in the whole link points, the consumption of the client time spent together with the H5, unified data back into the front que in the system, a complete analysis of the performance data by bian que system and rendering, such data caliber get uniform results at the same time also more in line with the user’s true sense of entity. The performance report on Bian Que is presented in a timeline, as shown below

According to the diagram, the time consuming can be roughly divided into three stages

Phase 1: Container preparation phase. In this phase, container creation, page hopping, and container LoadRequest initialization are performed. The time of this stage is roughly 300ms, and the analysis shows that most of the time is spent on initialization. We optimize the time through container reuse and container preloading.

The second stage: HTML resource download stage, this stage mainly do domain name resolution -> create links -> download HTML document operations. This phase takes about 850ms and is mainly used to download HTML resources. Therefore, resources in H5 application can be downloaded to the local computer in the form of offline package in advance. When the user enters the H5 page, the request for loading the resources can be intercepted and the resources can be directly read from the local computer. In this way, the time-consuming network request operations can be replaced by the local I/O operations that take a short time.

The third stage: H5 page processing stage, after getting the HTML document, enter the H5 page, then H5 js execution, page rendering, Onload and other operations. This phase takes about 1070ms. It mainly downloads CSS js resources, executes js, initiates network requests, and renders pages. Therefore, the optimization of this stage can use offline package, request preloading, image resource optimization technology, as far as possible in this stage of network dependency.

Modifying performance Data

As shown in figure: When a user opens an H5 page, The visual body sense of The loading time of The page is from user operation to The completion of visual LCP(The Largest Contentful Paint) rendering of The H5 page. This period includes events such as container creation, client page jump, page resource request and H5 page rendering. However, Native statistics cannot calculate the time of H5 rendering completion, and H5 statistics cannot calculate the time before requesting page resources, resulting in inaccurate performance measurement data. In order to get performance data closer to users’ real sense of entity, we cooperated with the front end team to carry out full-link buried point, connecting the time consumed by the client in series with the time consumed by H5, and uniformly returning the data to the Bian Que system, which made multi-dimensional presentation.

Detailed scheme:

H5 calls the bridge method when it needs to get the performance time. The client reads the JS method name of callback, calls the JS method, and puts the performance time (WebViewInitTime, PageStartTime) into the method parameters, and sends the callback to H5

{ classMap: 'UBTBridge', method: 'getNativePerformanceTime', callbackId: '1', params: { callbackName: 'tianQiApmEasyBikeWebviewCallback'}} / / JS method: Format of tianQiApmEasyBikeWebviewCallback parameters window. TianQiApmEasyBikeWebviewCallback ({" code ": 0," data ": { "nativePageRenderStartTime" : "1605598621744", "nativePageNavigationStartTime" : "1605598621743" }, "callbackId" : "1"});Copy the code

Output results:

The following figure shows the bianque performance statistics after data modification. The yellow and cyan parts indicate the time taken for container creation and container loadRequest initialization.

Bian Que page data interpretation

Ios-easybike-offline is iOS offline data, ios-easybike-online is iOS online data. Android-easybike-offline is Android offline data, android-easybike-online is Android online data. In the time analysis chart of bianque statistics, each time period is divided by different colors, so that what is done in each time period and how long it takes are clearly displayed.

Stability Monitoring alarm

The stability of Hybrid container will be affected by the container implementation logic, the implementation logic of the opened H5 page and the usage of system resources (memory, CPU, etc.), which may eventually lead to App Crash or the blank screen of THE H5 page. Therefore, the stability monitoring of Hybrid container includes two indicators, Crash anomaly and white screen rate. In addition, the container layer can easily sense the JS Bridge invocation error, network error, and memory alarm error scenarios, and also monitor the errors in these three specific scenarios.

Detailed scheme:

For the anomalies on the container side, we sorted out and refined the anomalous points, and gave early warning after rapid aggregation analysis in the company’s listening system (App stability monitoring platform). The white screen monitoring technical scheme and the implementation process are relatively complicated. Separately, the scenario monitoring of JS Bridge call error, network error and memory alarm needs to collect data, add monitoring charts, add alarms and add buried points where specific errors occur to collect data. The Argus system configures customized indicators. Add an alarm policy to the Argus system’s custom metrics to trigger an alarm when an exception occurs

Output results:

  1. Monitoring chart:

2. Alarm information:

White screen monitoring alarms

The front-end team has a monitoring system to check the blank screen rate of H5 pages in the container, but the method to calculate the blank screen rate is limited (the dom node with text or images is not opened for 6 seconds is judged as blank screen). This method has obvious disadvantages: The background image set by the CSS cannot be detected, the image loading failure cannot be detected, and the detection cannot cover the blank screen caused by container exceptions or resource loading exceptions. As a result, the statistical blank screen rate is lower than the actual online situation. In this regard, we upgraded the scheme of white screen detection, and analyzed the color proportion of white pixels by taking screen shots on the client. When the proportion of white pixels reaches a certain proportion, it is judged as white screen state, and white screen monitoring is carried out based on this determination technology. At present, it has been applied in the home page of car service and obtained more accurate online data of blank screen.

Detailed scheme:

  1. Flow chart of detecting white screen solution

2. Dynamic configuration: There are several important parameters in the white screen detection algorithm, which can be dynamically configured to ensure the accuracy of on-line detection. Related parameters are as follows:

Screenshots to do image detection is the operation of the memory consumption, the consumption of CPU, we want to get bad rate, only need to sample, so the sampling rate to make configurable parameters In order to avoid bad detection of memory and CPU consumption, before we calculate, the original image compression, but if the amount of compression is too big, can not guarantee the accuracy of the calculation results, the compression quantity is too small, It will consume a lot of memory and CPU, so we added a configuration to control the image compression amount and dynamically adjust it to ensure accurate calculation results and consume as little memory and CPU resources as possible. Pixel tolerance. Many pages use a color like #F9F9F9 instead of a pure white background color. We configure a tolerance value, and when the color with the largest proportion is within this tolerance, it is considered white. If the proportion of white pixels reaches a certain value, it is judged as a white screen, which can be configured.

Shortcomings & Improvement scheme: pixel detection method also has some drawbacks

  1. Pixel analysis cannot be accurately matched and cannot adapt to complex business scenarios (front-end customized Preload page, business customized background or background diagram, etc.) without versatility and business elasticity

  2. Error burying point: There are many blank screen scenarios (such as network exceptions, service exceptions, resource exceptions, OOM exceptions, and environment startup exceptions), and the callback time of some errors is not accurate. Therefore, we can only monitor major errors and cannot obtain all exceptions. As a result, some data is missed

In the future, we hope to use AI algorithm to cover more scene types. At present, AI image recognition and white screen detection are under development and will be online soon. In the future, we hope to use AI algorithm to cover more scene types. At present, AI image recognition and white screen detection are under development and will be online soon. The following figure shows a screenshot of the blank screen and loading state in current services.

Optimization for performance

According to the loading process of H5, we adopted a divide-and-rule strategy and optimized each stage separately.

Stage 1: Container load optimization (reuse & preload)

It is well known that WebView container itself is a large memory consumption, and the initialization process takes an average of 146ms in Android system and 381ms in iOS system. We draw on the concept of thread pool to pre-create WebView object pool and pre-load the container in memory by taking advantage of the idle time of the system. If you need to use WebView, you can directly obtain objects from the object pool. You can create multiple object pools at a time to avoid time-consuming and memory jitter caused by frequent creation. Container preloading and reuse are shown as follows:

Optimization of container reuse and preloading during initialization

Stage 2: Image loading optimization

One of the topics of H5 performance optimization is image resource optimization, especially for image-oriented pages. Through the way of container Hook, with the help of the CDN OSS format conversion function, we aimed at the format of the Webp upgrades the picture page and at the same time cooperate with load end side of the picture library, through the WebView and native border, realize the unity of the image cache and broadband, both to reduce the network request, save resources and has saved the data space.

Image optimization effect recovery

Phase 3: H5 resource optimization

For ordinary H5 applications, users need to wait for the completion of the Loading of resources required by the page and the initialization of the frame before starting to render the first screen page, before which the page is in a blank screen or Loading

We optimized H5 resource loading using offline package and pre-render respectively

H5 Resource optimization 1, offline package

The offline package uses the static resource caching solution provided by the end to deliver resources such as HTML and Common JS to the client. When the App opens the H5 page through WebView, it intercepts the network request for loading resources, matches the corresponding cached offline resource according to the domain name, and directly reads the corresponding resource from the local cache after the match is successful, reducing the corresponding request network and shortening the initialization time of the page.

Offline package file distribution:

H5 PreRender

Pre-render is a performance optimization for the first time opening a front-end single-page application:

Conventional front-end single-page applications dynamically generate HTML/CSS rendering pages through JS codes, but the page is blank when waiting for JS execution, and the performance index of rendering complex pages is poor for the first time. Pre-render is a performance optimization solution for the first opening of front-end single-page applications: in addition, in SEO, page data capture (shared cards) and other scenarios, pre-rendered pages are significantly better than conventional single-page applications. Flowchart for offline package and page preloading:

Phase 4: Interface prerequest

Except for the optimization of resource files, such as static data, we also take advantage of the App itself, in view of the dynamic data acquisition has been optimized, normal open a page, starting from the user action, the time renders the page as shown in figure, which depend on the part of the network interface in the page rendering of return data, so the network request in advance can save the page rendering time, The diagram is as follows:

We route the WebView requests to the APP’s network library components. In addition to reusing many low-level optimizations of the network library itself, we also change the original serial into parallel. Before entering the H5 page, we make the network requests in the H5 page in advance during the jump animation of the page, so as to shorten the loading time of H5.

Inject JS intercepting Ajax request to H5 page for Ajax request interception, and map the intercepted request to the local pre-request interface, and send the local pre-request data back to the Ajax request object through JS Bridge.

Interface prerequest benefits

Optimized for interactive experience

NavigationBar interaction optimization

Previously, when Hybrid containers entered the H5 page, the title would flicker, resulting in poor opening experience of H5. At the same time, the design team also promoted the visual revision of App, so we redesigned a highly available and easily extensible NavigationBar. The new NavigationBar supports custom backgrounds, custom back and close buttons, and custom buttons on the right. Applying the new NavigationBar to Hybrid containers solves the Title flicker problem while also providing the ability to customize the Hybrid container NavigationBar.

Loading interaction layer optimization

In order to solve the problem that the UI display and interaction style was very simple and the details were rough in the page Loading process, we provided unified UI display and custom styles, such as navigation bar style, page Loading state, progress bar style, etc. Loading interaction of Hybrid containers supports service customization, and supports resources in the form of dynamic pictures, static pictures, and Lottie animations.

Weak network/no network optimization

Resources have been offline for the H5 page has support WebP images, and cache data, static page has been theoretically support weak net/net free to open the page, but in the business use of H5 page contains business logic for the most part, rely on the API interface of the data returned, if the API interface request cannot succeed, H5 is still unable to open and use. We cache API data to ensure that users can use the cache data to open pages in the weak network/no-network environment, and avoid service “opening” to the maximum extent.

Iv. Overall effect after optimization

1. Reclaim the front-screen time-consuming data after optimization

2. Data recovery of 1s open rate and 2S open rate after optimization

4. Access traffic

As of press time, the total PV inclusive business of H5 page has accounted for more than 80%. Including car service home page, personal center page, price details page and other 7 high PV pages.

5. Future prospects

The container’s next challenge

Although the container optimization has achieved initial results, human resources are limited after all. In the first phase of optimization, we mainly focus on performance and stability, and we still have many things to optimize in the future:

  • Inject a unified WebView kernel to solve the adaptation problem of various magic system under android fragmentation
  • Container security issues, authentication interception jump black and white gray name single machine
  • SSR, Prefetch, map components of the same layer rendering depth of performance optimization
  • Unified JSBridge standards to reduce service access and maintenance costs
  • Self-healing H5 link degraded service
  • Improve the R&D operation and maintenance platform
  • Optimize offline resource download usage

App Architecture Evolution

Currently, mature mobile App architectures tend to be containerized, which can support rapid degradation between containers and ensure stability while improving research and development efficiency. Based on the idea of architecture layering, we designed the architecture evolution of Halo App Containerization 2.0.

On the right is the internal architecture of App, which mainly uses the idea of layers to decouple the logic of each layer. The business implementation of the entire App is carried by the container layer. Each page jumps and transfers data through a unified route. Events in the container are distributed to the corresponding handler through the protocol bus layer for processing. The following capability layer is the encapsulated basic components and business components, which can be directly used by businesses in the container. The bottom layer of App is the platform foundation, which can be used by all businesses. On the left is the App operation and maintenance support platform, including release and construction, operation and maintenance platform, performance measurement, and alarm monitoring. Responsibilities are clear, escorting the healthy operation of online APPS.

Smooth experience & Security & High stability

For users, stability and silky experience are only the most basic requirements, and we will continue to optimize safety and performance in the future to bring users a real silky experience.

Author’s brief introduction

Yi Book (Hu Feng) mobile terminal development expert

Tang Yongxiang senior mobile engineering development engineer

Ren Zeqiang senior mobile terminal development engineer

All from pratt & Whitney vehicle R&D – business governance team

Make an advertisement

We are the big front-end efficiency improvement technical team responsible for the four-wheel travel business of Pratt & Whitney, where there are rich business scenarios and technical challenges. We will continue to build and improve the stability of Hybrid containers and improve user experience. If you are interested or someone around you is looking for a job (no limitation on mobile terminal), you can send your resume to [email protected], looking forward to your joining!