This article is from alibaba Technology Association (ATA) selected articles.

IO optimization

Today, App 5.1.1 has been released, and the aero Hybrid architecture has been further implemented. This round of optimization aims to achieve the true “seamless second generation” of H5.

To see the effect first, go to App 2G network to buy international air tickets, 30 seconds to complete, except for the search entry Page, the list down to the front of the payment Page is H5 Page, everyone feel:



Visual performance is impressive. Although the offline H5 package is isolated from the interference of weak network on second output, the local IO time of the device can not be ignored, including the decompression of ZIP, only a complete HTML (including the resource file carried by it) in the local IO of the device will reach the second level of time, and there will be about 0.5 seconds of white screen time on iphone5.

In addition, the optimization of HTML itself still cannot be bypassed, the efficiency of JS in WebView is usually one quarter of that in Mobile Browser. So JS must intervene in rendering as far back as possible, and CSS must intervene in rendering as far forward as possible. In current front-end development practices, pages usually block loading at least one seed file (such as Kissy), and on Mobile devices, even a NON-DOM blocking JS run can result in a white screen delay of around 0.3 seconds.

Therefore, the IO optimization and HTML rendering of H5 container are the focus of this issue, namely:

  1. IO optimization of H5 container loading resources: eliminating immediate decompression of ZIP packages, decompressing hashes to SD cards immediately after offline package updates, reading files directly from the device every time you create a View, local file management is still based on the standard H5 package specification.
  2. Page optimization of HTML itself, CSS in advance, JS after.

The “CSS forward and JS backward” action is done by tools. As long as the build tools are unified, developers do not need to worry about how to optimally place scripts, but only need to focus on implementing business logic. For example, after JS is done, it looks like this:

All it really does is change the script from synchronous to asynchronous. Make sure the styled page frame comes out in seconds, and then execute JS. You don’t even see the difference in performance numbers, but the sensory improvement is so noticeable that I’d rather you see the interface first than the blank screen.

IO Optimization (continued)

Strategically, this is enough for most scenarios to ensure that the page comes out in seconds at any time. But throughout our Hybrid architecture, we designed a flexible H5 offline, which USES virtual domain to ensure that the online offline, such as hotel group purchase H5 page, the browser and open code page is an online, used to sweep the App code in is an offline page, the same code, a network load, a walk local load:

This design is mainly for the switch between online and offline. Emergency problems can be configured to the online page at any time. The online page can be deployed at any time, and the offline page involves pushing packets. In order to do this layer of switching, there is the problem of determining whether the file is online or offline.

Because the proxy layer of the H5 container virtual domain directs the WebView to read files locally rather than over the network. If the local file cannot be read, create another HTTP request to the corresponding online request file. If you use I/O to check whether there are files in the local area, the actual I/O count still cannot be reduced (all resource file requests must be sent to the hard disk of the mobile phone once). To reduce the actual I/O count, Json for each H5 offline package we generate a list of local resource files (cache_info.json) and a Map of both the domain and file paths. This Map is read into memory for future use and is used to filter H5 access files directly. If the Map does not match, create HTTP to fetch the file from the network. This can avoid unnecessary IO.

AngularJS acceleration on mobile

Hybrid has a lot of list pages, like the group purchase and international airfare examples above, and AngularJS is best suited for this scenario. But AngularJS is not currently optimized for Mobile. On Mobile devices, Hashchange drives changes to the data-model that are rendered via View. The first rendering is a bit slower because the Model is not ready for view, and the interface doesn’t come out in a second in any case (at least 0.8 seconds from hashchange). The data structure is slightly more complex and immediately breaks 1 second, of course with the interference of building the DOM when it is first loaded.

Several changes:

  1. AngularJS seed files load asynchronously
  2. Non-data-associated HTML is preinstalled on the page
  3. The first load eliminates any HashChange that affects page jitter
  4. Offline of basic data (such as city lists)

All this is to get the first rendering out as quickly as possible, and then programming in OPOA is what AngularJS is good at.

How do I load TMS in an offline package

We know that AWP only supports static HTML publishing. There is no explanation for this. After all, high performance requires a simpler, more robust and efficient cache. We all know that the AWP platform provides a
tag (instructions), after THE TMS changes, a new HTML is generated and pushed to the CDN.

So the question is, what do you do in an offline bag?

My classmates wrote offline-TMS-Parser module, and Clam
tag construction:

<! --HTTP:http://abc.php,gbk:HTTP-->Copy the code

Built as follows:

<script 
    src="http://trip.taobao.com/market/trip/h5_offline_service.php? callback=handle_tms_fragment&src=http%3A%2F%2Fabc.php " 
    charset="gbk "></script>
Copy the code

In this way, the TMS content in the offline package is completely separate from the H5 page. After all, TMS cannot be directly offline due to frequent changes. The above script obviously blocks page rendering, so offline-TMS-Parser provides an asynchronous version that will:

<! --HTTP:http://abc.php? async,gbk:HTTP-->Copy the code

Built as follows:

<script id="tms_fragment_1
                                                            ">
get_tms_fragment("http://abc.php ", "gbk ", "tms_fragment_1 ");
</script>
Copy the code

Then slip an implementation of get_tMS_fragment at the top of the H5 page.

This way, the AWP platform development business will not be affected, the tools help us handle the TMS and H5 page 100 % decoupling, can also be used in offline packages TMS.

However, TMS must not be abused, and decoupling of views and Data at the logic level of the code must still be done.

Grunt – KMB

This installment focuses on those, but there’s one more exciting change: Grunt – KMB, and yes, the build process needs to be slimmed down and simplified.

Grunt – KMB is an alternative to the Grunt – KMC being developed by another member of the team. In contrast to grunt KMC’s module parsing based on regular matching, Grunt KMC is completely based on JavaScript syntax parsing tree (AST) provided by Ugliy-JS.

Grunt – KMC speed:

Grunt – KMB speed:

Double the speed. It’s so mouth-watering.

What’s Next

The optimization of this issue does not have many high-tech things, mostly physical work, the technology is done thoroughly. Good experiences are really incremental and take time to hone.

In fact, it has been more than half a year since App Hybrid just started to design and optimize the first version, which is inseparable from the dedication of students on the client side, because the optimization of H5 must use high-performance WebView container, but it cannot be achieved in a second by H5 or Web technology itself. Coupled with the fragmented optimization techniques in the “Guide to High-performance Website Construction”, H5 can fully achieve the second out in Hybrid, and equipped with offline package dynamic push and buried point collection and other infrastructure, the bottleneck of Web technology can achieve a certain breakthrough in Mobile.

In my presentation at the Group’s Front-end Technology Summit, I mentioned the challenges we face:

Go ah App is between the tool wallet App and the operation of the mobile App, both marketing activities, but also tool, process PageFlow. Standardized PageFlow performance to achieve the ultimate, the next challenge is how to operate activities also do intelligent push, complete the offline deployment of such pages.

Of course, the offline deployment of active pages is not the most urgent problem we are facing at present, but the most difficult problem is the problem of data access:

Look at this scene, in the wallet App made a diversion entrance, evoked go ah App, and positioned to the ticket search results page:

At present, it is difficult to track the effect of evocation. The App in the phone is an island of information, and it is difficult to connect the PageFlow across the App by simply passing the reference. Even if parameters can be brought in, can identity information, login status and account association be brought in as well, each of which is challenging.

Two days ago, I shared my understanding of “Mobile First” in the training for new recruits of airline travel. This paragraph is worth sharing with everyone.

Cohesive apps and hashed Web seem to be an irreconcilable contradiction. Companies tend to think that providing more and more features is the only way to meet the ever-expanding needs of users, while breaking the ease of use of existing applications. When the two are irreconcilable and the information swells to the point where it must be hashed to different ends, it becomes critical to associate these islands of information through Web technology.

Therefore, All the technical optimization we have done before is to lay a solid foundation for the construction of wireless “front-end/terminal” technology system. Therefore, this round of wireless All In is a kind of original accumulation In a sense, and the second round of wireless All In will usher In the real personalized and diversified era of non-standard products. At this time, our technical system will focus on solving these types of problems:

  1. Thousands of people, focusing on solving the problem of customized functions in mobile phones for different groups of people
  2. Wireless big data focuses on breaking the information island between apps and making cross-terminal data operation more efficient and reliable
  3. Wireless open source, let B businesses involved, like a hand for a (Native) commodities details page loaded all the time will soon be more personality and various non-standard break goods, at that time, a large number of products in the field of vertical pattern design more depends on businesses to participate in, not ourselves that a few product managers, therefore, more open source and free mobile phone shops, Closed loop service is king.

Speaking of closed loop, the air ticket purchase process of Go ah is a classic case of wireless closed loop:

This example starts from the entry of the wallet to purchase air tickets, and through SMS, Push, download, call up and other operations, the user is moved into the App (the whole process is smooth experience, it is probably difficult for you to tell which Page is H5 and which is Native).

So, open source + closed loop is the ultimate state of wireless Hybrid technology in my ideal, and the accumulation of Hybrid technology has just begun.