Speed ​​and security are both available! Transforming asynchronous layout greatly improves client layout performance

1. Background

As the user scale of Xiaohongshu continues to grow, the impact of App performance on user experience becomes increasingly important. For example, the speed of opening a page, the speed of launching an App, etc., a few tens of milliseconds of improvement can bring significant benefits to business data. Today I will introduce the practice and optimization of an official framework. During this period, I stepped on a lot of pitfalls, but the benefits were also considerable.

AsyncLayoutInflater first appeared in the support.v4 package in 2015 and is used to inflate layouts asynchronously. Generally speaking, inflation needs to be executed on the main thread, so it is a time-consuming part of the page initialization process. This tool provides the ability to inflate asynchronously, thereby reducing main thread congestion. This article mainly introduces the use of the tool and how to improve it, as well as some problems encountered during the improvement.

2. Use

AsyncLayoutInflater is very easy to use, just add a dependency.

At the same time, the use in the code is as follows:

After asynchronous inflation is completed, there will be a callback, and the view can be used at this time.

3. Source Code Analysis

The most powerful thing about this tool is that the asynchronous inflate view does not cause any thread safety issues. Let’s take a look at how it handles thread safety issues.

First, there is a Thread singleton, which contains a thread-safe blocking queue and a thread-safe object pool.

This singleton has a method called enqueue, which calls the put method of the blocking queue to insert the request into the queue. Because it is a thread-safe queue + thread-safe object pool, this series of operations ensures thread safety.

The following is the inflation process. During inflation, a request is obtained from the object pool through mInflateThread.obtainRequest, and then the request is inserted into the queue.

The following is a simplified code. There is an infinite loop in run, which performs the inflate operation by blocking the take element of the queue.

The above simple tool has been analyzed. This part basically answers the question of how to synchronize data between threads. Adding a thread-safe container to a typical producer-consumer model can ensure this.

IV. Problems and Improvements

There are still many thread-related problems encountered during use. Here are a few relatively important issues to explain.

4.1 Single-threaded vs. multi-threaded

InflateThread is designed as a single-threaded single-instance. If you need to customize or collapse the thread, the changes will be troublesome. Here, you can provide some thread management and customization capabilities by opening a method to set the thread pool. A single-threaded thread pool can be built in by default.

Through a relatively long experiment, we found that when the main thread is relatively idle, the single-threaded effect will be better, because it is all executed on the big core and is more efficient. When the main thread is busy, such as in the cold start phase, multi-threading will have better efficiency.

4.2 ArrayMap and thread safety

We found in actual use that SimpleArrayMap or ArrayMap is used in some custom View constructors and darkmode implementations. ArrayMap is a subclass of SimpleArrayMap. SimpleArrayMap itself uses two static arrays to implement object caching, thereby playing a role in reuse. In the case of multi-threading, there will be thread safety issues, and there will be crashes caused by mismatched reused objects. A simple way to avoid this is to clear the corresponding cache array when a crash occurs.

4.3 Inflate, Locks, and Thread Safety

There is a lock in the inflate method of LayoutInflater, which means that if you want to call inflate with multiple threads, the multithreading effect will not work. If it is a single thread, you may also encounter the same problem of waiting for the lock as the main thread during inflation. Here, mConstructorArgs is a member variable. By overriding the cloneInContext method in LayoutInflater and cooperating with the object pool, you can avoid the lock problem here.

At the same time, the arrays and container types used in the inflation process are not thread-safe. If you want to remove the synchronize restriction at the beginning of the inflation method, you also need to pay special attention to these thread-unsafe container classes.

4.4 BasicInflater transformation

AsyncLayoutInflater itself has a BasicInflater. Based on the above improvements, we have made some modifications to it in practice, expanded the interface for setting the thread pool, used the thread pool provided by the infrastructure, and achieved unified management of threads. In practice, when the CPU is busy, the multi-threaded thread pool is better than the single-threaded one. When the CPU is idle, the single-threaded one is better because it can better utilize the performance of the released CPU core.

At the same time, we rewrote some thread-unsafe processing methods in ArrayMap so that there will be no crash when using ArrayMap in multiple threads or using functions that rely on ArrayMap. This involves some of our custom Views and our darkmode implementation.

In terms of inflation locks and some thread-unsafe container processing, the cloneInContext method of LayoutInflater is rewritten to remove the synchronized restrictions. At the same time, a thread-safe container is added to the onCreateView process to ensure the thread safety of the inflation process.

In summary, we rewrote AsyncLayoutInflater, ArrayMap and LayoutInflater to achieve thread safety, and integrated them into our business framework to reduce the cost of use.

4.5 ViewCache

Another practice is to further encapsulate on the business side. Through a ViewCache singleton, some modular Views are inflated in advance and stored in ViewCache. When they are needed later, they are retrieved from ViewCache, thus avoiding the time-consuming problem caused by inflating them again when they are needed. The overall code is relatively simple, so I will not discuss it separately. The point that needs to be noted is that some Views that are not used need to be released in time to avoid memory leaks.

V. Conclusion

The practice and optimization of AsyncLayoutInflater lasted for about half a year. We obtained more than 20% performance benefits and significant business benefits in the performance optimization of App cold start and note detail page. At the same time, we also deposited this capability into the business framework, which facilitated the subsequent access and usage costs. Through ViewCache and the business framework, we have basically achieved the ability to cover most business needs. In the future, we will further optimize the usability of the framework and the use of some scenarios, and combine other optimization methods to provide business parties with more choices, so that they can write business without paying attention to the time and complexity of this part, thereby improving development efficiency.

6. Author information

No worries

Xiaohongshu Business Technology Android Engineer, formerly responsible for business architecture design and performance optimization, currently focusing on the iteration and optimization of transaction links.