1. Start the optimization plan

In the previous article “Startup optimization, we have a little” good “theory”, we introduced the background and challenges of startup optimization, in the optimization scheme elaborated the general performance optimization process needs to comply with several principles, finally to the industry’s startup optimization scheme did a simple overview.

In this article, we will start to optimize the actual combat plan to do a more detailed elaboration. Is the so-called “people lose virtue, do phoneme to trespass; “When we optimize, we also learn from some industry solutions, and do a little innovation on this basis. In the specific process of starting the optimization of actual combat, although the things seem to be complicated, it is difficult to use a set of systematic, universal solutions. But in the abstract, the whole thing that startup optimization does can be summarized as follows:

  • Optimize before main

  • Optimize after main

  • Business process optimization

  • Interactive optimization

  • Initiator development

  • Start dynamic retraction

  • Start time to prevent corruption

The following points are described respectively.

Optimize before main

Optimization before the main function involves a lot of knowledge about the underlying principles of the operating system. While it may seem complicated, the optimizations made in terms of startup are not very complicated. The process leading up to the main function and the optimization methods used for each are described in detail in Optimizing App Startup Time and Optimizing App Launch, so I won’t go into the details here.

Based on past experience, most of the ports that take time to launch apps are not here. However, it’s best to check before you start your App to optimize. If you find that the main function is taking too long, you can follow WWDC’s advice and optimize accordingly. During optimization, we detected that several load functions were time-consuming, so we made targeted optimization.

Optimize after main

Compared with the main function before it, the main function after it does not have so much complex underlying principle knowledge, nor is it particularly advanced technical content, but it is the most complicated optimization with the highest ROI. Here we need to make targeted optimization according to App business requirements, interactive features, basic library usage, etc. Developers need to pay attention, carefully comb the startup process of their App, discuss the business process with product students, and combine various performance evaluation tools to optimize the startup.

Here we will not introduce the effective optimization methods for our App too much, but will list the common problems that the App may encounter in the startup optimization, for your reference. Similarly, the optimization scheme after main can be abstracted into the following categories:

1. Start tasks in advance

Some time-consuming operations such as network I/O and disk I/O that can be performed asynchronously in child threads can be executed in advance according to service characteristics. This can be used quickly when it is used and avoids blocking the startup process. Here are some common tasks that can be done ahead of time:

  • Home page service data. Home page data cache, or home page network request, can be performed in advance during startup to speed up home page rendering.

  • Image resource preloading. Load the home page, splash screen, multi-tab images, etc. You can also pre-load the images in advance.

  • Geographic location. Some home strongly rely on the location of the App, can be positioned in advance of the timing.

  • Other tasks that can be advanced…

2. Delay starting the task

Some tasks that are not necessary during startup can be run after startup. Most apps are iterated over many years, and without good architectural constraints, a lot of unnecessary startup tasks such as three-party SDK initialization will pile up in the startup phase. Historically, this section has the highest ROI for startup optimizations. Here are some common tasks that can be put off:

  • Start the irrelevant three-party SDK initialization

  • Non-startup pages are loaded lazily with multiple tabs

  • Start irrelevant disk I/O and network I/O management. Since we use unified middleware for disk I/O and network I/O, we implement unified management and control at the middleware level and configure a whitelist. The disk I/O and network I/O in the non-whitelist are suspended first during startup and executed on a selected machine after the startup is complete. This not only achieves the purpose of startup optimization, but also reduces the complexity of the development of the upper-level middleware.

  • Other startup tasks unrelated to startup…

3. Start tasks in parallel

The current iPhone is a multi-core processor, and at startup it is possible to take some concurrent, time-consuming tasks off the main thread and put them in sub-threads, and set the priority of the sub-queues according to the importance of the task. Based on the characteristics of your App startup, you can use tools such as Instruments or flame graph to locate tasks that are time-consuming on the main thread or block the main thread, and split them into sub-threads to optimize startup performance.

4. Optimize the start task

Tasks that cannot be postponed are necessary during the startup phase. The performance of these tasks can be optimized to minimize the resource usage and improve the startup performance. In general, there are several ways:

  • Space for time. This is one of the most common and effective optimization methods. Frequently used caches, for example, fall into this category. In the process of startup optimization, the home page data pulled by the last network is used as the cache to render the startup data, and then the second rendering is completed after the network pull. Due to the characteristics of our business, the two rendering home page data is not different, so the user experience is better. In addition, we will cache the size of each block on the home page into the model data. For the data newly pulled from the network, we will also cache a global size according to the rendering template, so as to avoid the time-consuming operation caused by the size calculation and accelerate the startup process.

  • Faster data structures and algorithms. In the process of development, when you encounter a large amount of data, you need to pay attention to the time complexity of processing the data algorithm, if more than O(n2), you need to start to optimize the performance of the algorithm.

  • Technology stack selection. The technology stack selection mentioned here focuses on some unofficial Native technology stacks that have become popular on the client in recent years. Such as H5, RN, Weex and Flutter. These technologies address issues such as cross-terminal consistency, development efficiency, and dynamism. However, based on previous experience, it is not recommended to use these technologies on the home page in scenarios requiring high startup performance. It can be used in non-home page scenarios according to business characteristics and team technology stack characteristics.

  • Other optimization methods…

Need to emphasize here, as the previous article to optimize the overall principle “application to locate performance bottlenecks” inside, “subjective speculation, don’t let performance evaluation data speak”, everyone in the process of optimization “to use the proper performance assessment tools and evaluation method”, “to grasp the key to targeted, the key core bottleneck problem solving”, so as to get twice the result with half the effort.

Business process optimization

Business process optimization requires students to sort out the existing business logic and implementation methods, and find out which processes can be optimized for optimization. If the optimization will modify the user interaction, we also need to communicate with the product students whether the optimization is reasonable.

This part, because each business has its own characteristics, is difficult to output a general solution. Here we can cite a case when we do startup optimization for your reference. Many apps now launch with a custom boot screen, either to display ads or platform campaigns, and 1688 is no exception. When we were combing the startup process, we found that the initialization sequence of the startup screen and the initialization sequence of multi-tab on the home page were parallel. However, from the perspective of user interaction process and business process, if there is data on the startup screen, it is more reasonable to load the startup screen first and then load the home page after the startup screen is loaded. As a result, we’ve improved the speed of the flash screens by nearly 50%, improving the user startup experience without disrupting the business process.

Interactive optimization

When we talk about performance optimization, we tend to focus more on the metrics of the objects we’re optimizing, such as startup time from 2s to 1s, page load time from 1.5s to 1s, and sliding frame rate from 40fps to 55fps. But if you dig a little deeper into the purpose behind optimization, you’ll find that performance metrics aren’t the purpose of optimization. The real purpose is to improve the user experience. Deliver higher business value through improved user experience. So in some scenarios, as technical students, we can actually take a broader view, from a business process and interaction perspective, and sometimes have a better user experience.

For example, the loading diagram or loading progress diagram commonly used in the page loading process can reduce the anxiety of users waiting for the page loading process, thus reducing the page miss rate. In recent years, many applications have also made interactive optimization for simple loading diagrams, using skeleton diagrams that are roughly similar to the page structure (and can even bring some existing data from the page before the interaction, such as pictures, titles, etc.), so as to bring users a better experience.

Interactive optimization requires technical students to take user experience as the starting point, exert creativity, and combine technical and non-technical means to bring the best user experience!

starter

The above mentioned start tasks in advance, delay, parallel and other solutions, abstract view is the start of the task management. If every application developer needs to manually manage code call order, priority, queue, etc. when adding startup tasks, development efficiency will be greatly affected. And because the development level of students and to start the process knowledge is uneven, cause as business version iteration, more and more inappropriate startup tasks pile up in the process of start, the resulting negative impact is increasingly slow start, the user experience is becoming more and more bad, may even affect the start jumping loss rate.

To manage startup tasks in a unified way, we developed our own launcher, AMLauncher. We developed our own initiator because we had previously used BeeHive to manage the decoupling of startup tasks and module services. After a long version iteration, nearly a hundred startup tasks have been accumulated. However, the arrangement of BeeHive startup tasks cannot meet our requirements. The startup tasks distributed in each module are coupled with BeeHive code and configuration protocol, so the three-party initiators cannot well adapt BeeHive. Therefore, we choose to develop AMLauncher on the basis of BeeHive compatible configuration protocol and code to meet our requirements for launch task management.

The overall architecture of AMLauncher is as follows:

Here are a few of the features

  • Scenario-based capability. The AMLauncher allows you to customize extension startup scenarios. Different startup tasks can be configured in different scenarios based on their characteristics. For example, some necessary tasks can be configured as launch, some important but not necessary tasks can be configured as HOME (after startup), and some unimportant tasks can be configured as IDLE (idle runloop). If you need other customization scenarios (such as push), you can set the following parameters: You just need to specify the scenario ID and trigger it when the scenario is triggered. In this way, the development of students can easily achieve the task of starting ahead of time, delay and other functions.

  • Concurrency capability. The AMLauncher contains main queues, serial queues and parallel queues. The queue type can be configured as required

  • Dynamic orchestration capability. The AMLauncher startup task can be delivered through the cloud, enabling dynamic choreography

  • Task monitoring. For each startup task that is added to the configuration, The AMLauncher automatically monitors its runtime and success before uploading it to the cloud. Provide support for subsequent performance optimization and online market data.

  • ** projectile shrinkage ability. ** Due to the support of the above capabilities, we can conveniently arrange the dynamic startup tasks according to the characteristics of users and models, so as to achieve the overall optimal startup effect. The following is a discussion on the startup rebound ability.

Start dynamic retraction

In Experience Optimization, We’re a little Different, we talked about ways to make experiences different. The main features are:

  • Performance optimization in container architecture

  • Performance dynamic elastic shrinkage scheme

  • Performance data is associated with business data to mine performance optimization value

  • Performance optimization for B, latent B and other different types of people to drill

We also use the performance dynamic scale-down scheme to start the optimization scheme, and at the same time, simply exploit the value of the performance optimization. The whole plan is as follows:

The general process of the whole scheme is to input the decision engine (algorithm model or fixed rules) on the client according to the different characteristics of users, combined with the configuration delivered by the remote Leihe wave platform, and then decide different performance scaling strategies. Finally, the AB experiment is introduced to verify the optimization effect and the impact of performance optimization on business indicators.

We verify the above scheme with the minimum closed loop on the initial projectile shrinkage. Based on the configuration delivered by the remote Rehoe wave platform, different startup tasks are performed based on the performance characteristics of users’ models and startup types. For example, on some models with very poor performance, in order to reduce user startup interaction time, SDK initialization such as Weex Windvane will be delayed from home scene to idle scene. In a failover startup scenario, the startup tasks required by landing pages are advanced to improve the failover startup speed.

Start time to prevent corruption

As mentioned in the previous article, performance tuning is a constant battle. Not only do we need to be able to attack in the short term, but we also need to be able to sustain the gains in the long term. Our startup time anti-corruption scheme is as follows:

  • Development stage anti-corrosion. Before main, the load function is time monitored to prevent time-consuming operations in the load function. After the main function, since initiators are used to manage startup tasks, we have made the submission permission of startup task configuration a bayonard. Every time a task is added or modified, a strict code review is required to prevent the performance of startup from being affected by the random addition of startup tasks by developers.

  • Test phase corrosion. We worked with the test students to build performance automation test assurance for each version. You want to be able to detect performance problems during the testing phase and prevent performance corruption due to version iterations.

  • Grayscale & online stage corrosion protection. In the online phase, we will monitor and warn the startup performance, timely troubleshoot when the performance warning threshold is triggered, and solve the performance problems that were not found in the development and testing phase.

2. Optimize the effect

After a period of time to start a special attack, 1688 host client client startup time has a significant progress. At present, the launch time of the full version decreased by 42.9% year on year, which also ranks among the best among the group’s many apps in horizontal comparison. With the decrease of start time, the cold start loss rate also decreased by 54%. This confirms the business value of the performance optimization time we mentioned earlier.

In addition to the market time, we have run down for the startup time of CLASS C users, latent B users and Class B users, combined with the running down of high, medium and low performance models, so as to provide the data characteristic dimension for the startup springback.

3. Summary and outlook

In this paper, we briefly describe the scheme of startup optimization, and the “initiator” and “dynamic elastic shrinkage” are introduced in relative detail. Due to the limited time, the decision scheme with fixed rules is used to start the dynamic elastic shrink scheme, and strict AB verification is not used in the optimization verification. In the follow-up project of “Page load time optimization”, we hope to use some simple algorithm models to provide the effect of elastic shrinkage in the dynamic elastic scheme, and introduce strict AB experiments to verify the effect of performance data and business data in the optimization verification.