Android page rendering efficiency optimization practice

1. Current status of car series page layout rendering

The car series page is an important car series information page. It has been updated and iterated for many years, the page layout is constantly changing, and the XML layout files are becoming more and more complex.

Time taken to obtain the layout file of the car series page:

 startTime = System.currentTimeMillis();
 setContentView(R.layout.car_series_revision_activity);
 long durTime = System.currentTimeMillis() - startTime;
 LogHelper.e("Total layout time","Car series page layout time:" + durTime);

Here are the results:

2. Causes of lag

2.1Android drawing principle

► 1. The three most important concepts involved in Android screen refresh

(1) CPU: performs application-level operations such as measure, layout, and draw, and submits data to the GPU after drawing is completed

(2) GPU: further processes the data and caches it

(3) Screen: It is composed of pixels, and data is taken from the buffer at a fixed frequency (16.6ms, i.e. 60 frames per second) to fill the pixels.

To sum it up in one sentence: the CPU submits data after drawing, the GPU further processes and caches the data, and finally the screen reads the data from the buffer and displays it.

► 2. Double buffering mechanism

When the layout is complex or the device performance is poor, the CPU cannot guarantee that the calculation of drawing data will be completed within 16.6ms, so the system performs another processing here.

When your application is filling the Back Buffer with data, the system locks the Back Buffer.

If your application is still filling data into the Back Buffer when the GPU exchanges the two buffers, the GPU will find that the Back Buffer is locked and it will give up the exchange.

The consequence of this is that the phone screen still displays the original image, which is what we often call frame drop.

2.2 Layout loading principle

When the page starts, layout loading is a time-consuming operation on the main thread, which will cause slow page rendering and loading.

Layout loading is mainly implemented through setContentView. The following is its call sequence diagram:

We can see that there are two main time-consuming operations in setContentView:

(1) Parse XML and obtain XmlResourceParser, which is an IO process.

(2) Create a View object through createViewFromTag, using reflection.

The above two points are the reasons why the layout loads slowly and are also the performance bottleneck of the layout.

3. Layout loading optimization

The previous chapter analyzed the main reasons for slow layout loading. Therefore, our optimization methods mainly include the following two methods:

(1) Asynchronous loading, transferring the layout loading process to the child thread

(2) Remove IO and reflection processes

3.1 Asynchronous loading, AsyncLayoutInflater solution

By default, setContentView loads the layout in the UI main thread. Time-consuming operations in the loading process, such as parsing XML and creating view objects through reflection, are also performed in the main thread. AsyncLayoutInflater allows these loading processes to be performed in child threads, which can improve the responsiveness of the UI thread, and the UI thread can perform other operations at the same time. The usage of AsyncLayoutInflater is as follows:

 new AsyncLayoutInflater ( this ) .inflate ( R .layout .car_series_revision_activity , null , new AsyncLayoutInflater .OnInflateFinishedListener ( ) {
 @Override
 public void onInflateFinished ( @NonNull View view , int resid , @Nullable ViewGroup parent ) {
 setContentView ( view ) ;
 }
 } ) ;

Disadvantages of the AsyncLayoutInflater solution:

(1) UI layout and view initialization are performed in the child thread. If the view has not been initialized successfully, calling the view in the main thread will cause a crash.

(2) In general, the main thread will call the view, which involves a large number of synchronization issues between the child threads and the main thread in the view call, which sacrifices ease of use and reduces code maintainability.

(3) If AsyncLayoutInflater is introduced into the old page logic structure for transformation, the structure will change greatly, and it is easy to cause view call crash errors, which is not feasible.

3.2X2C Solution

X2C is an open-source layout loading framework developed by iReader. The main idea of ​​X2C is to use the apt tool to parse the XML layout file we wrote into a view during compilation, and dynamically set various attributes of the view according to the XML. In this way, when we call findViewById at runtime, the view obtained according to the view id is already a directly new view, avoiding XML IO operations and reflection operations at runtime, which solves the time-consuming problem of layout.

Original xml layout file:

 < LinearLayout xmlns : android = "http://schemas.android.com/apk/res/android"
 xmlns : app = "http://schemas.android.com/apk/res-auto"
 xmlns : tools = "http://schemas.android.com/tools"
 android : id = "@+id/constraintLayout"
 android : layout_width = "match_parent"
 android : layout_height = "match_parent"
 android : gravity = "center"
 android : orientatinotallow = "vertical" >
 < Button
 android : id = "@+id/x2c"
 style = "@style/btn"
 android : text = "X2C" />
 < Button
 android : id = "@+id/xml"
 style = "@style/btn"
 android : layout_marginTop = "10dp"
 android : text = "XML" />
 < Button
 android : id = "@+id/sub"
 style = "@style/btn"
 android : layout_marginTop = "10dp"
 android : text = "subModule" />
 </LinearLayout>​

The java files generated by apt during X2C compilation:

 public class X2C127_Activity implements IViewCreator {
 @Override
 public View createView ( Context ctx ) {
 Resources res = ctx .getResources ( ) ;
 LinearLayout linearLayout0 = new LinearLayout ( ctx ) ;
 linearLayout0 .setTag ( R .id .x2c_rootview_width , ViewGroup .LayoutParams .MATCH_PARENT ) ;
 linearLayout0 .setTag ( R .id .x2c_rootview_height , ViewGroup .LayoutParams .MATCH_PARENT ) ;
 linearLayout0 .setId ( R .id .constraintLayout ) ;
 linearLayout0 .setGravity ( Gravity .CENTER ) ;
 linearLayout0 .setOrientation ( LinearLayout .VERTICAL ) ;
 Button button1 = new Button ( ctx ) ;
 LinearLayout .LayoutParams layoutParam1 = new LinearLayout .LayoutParams ( ( int ) ( TypedValue .applyDimension ( TypedValue .COMPLEX_UNIT_DIP , 150 , res .getDisplayMetrics ( ) ) ) , ( int ) ( TypedValue .applyDimension ( TypedValue .COMPLEX_UNIT_DIP , 50 , res .getDisplayMetrics ( ) ) ) ) ;
 button1 .setBackgroundColor ( res .getColor ( R .color .colorAccent ) ) ;
 button1 .setTextSize ( TypedValue .COMPLEX_UNIT_DIP , 20 ) ;
 button1 .setGravity ( Gravity .CENTER ) ;
 button1 .setTextColor ( Color .parseColor ( "#ffffff" ) ) ;
 button1 .setId ( R .id .x2c ) ;
 button1 .setText ( "X2C" ) ;
 button1 .setLayoutParams ( layoutParam1 ) ;
 linearLayout0 .addView ( button1 ) ;
 return linearLayout0 ;
 }
 }

X2c Advantages:

(1) Good usability and maintainability, not very invasive to the original code, and the application code still uses XML to write the layout

(2) Loading time can be shortened to 1/2 to 1/3 of the original time

Disadvantages of X2c:

(1) Incomplete support for View attributes

(2) The compatibility and stability are not very high. In higher versions of the gradle compilation tool, such as gradle3.1.4, there will be problems such as not being able to find the R.java file or the java file corresponding to the xml.

(3) Currently, X2C is updated to 2021, and there is no continuous maintenance or issue resolution.

3.3Compose Solution

Compose is a new member of Jetpack and is a new UI library announced by the Android team at the 2019 I/O conference.

Compose is developed in pure Kotlin and is simple and easy to use, but it completely abandons the View and ViewGroup system and creates a new rendering mechanism from the inside out. It is the official solution to replace XML in the future.

Advantages of Compose:

(1) Using declarative UI, eliminating runtime parsing of XML layout, making layout more efficient

(2) Developed in Kotlin, it is simple and easy to use, and its layout is consistent with Flutter.

If it is a new project developed using Kotlin, you can introduce the Compose solution. The Compose solution is not applicable to the optimization of old projects.

3.4 Our optimization solution - focusing on layout reflection

Parsing Xml to view is done completely by yourself, which is complicated and has many risks. This process involves two time-consuming points:

(1) XML parsing, IO operations

(2) Reflection

XML parsing is a very complex task and can be done by the Android system. We can find a way to remove the reflection logic.

We need to find an entry point for generating views through reflection. We know that the logic of view generation is in createViewFromTag of LayoutInflater, which calls onCreateView(parent, name, context, attrs) to generate views through reflection.

Through the LayoutInflater setFactory of the Android system, we can not only control the generation of View, but also turn View into another View. In the onCreateView(parent, name, context, attrs) callback of setFactory, we take over the generation of a single view, remove the reflection, and create our own view to solve the problem. The parameter name in onCreateView(parent, name, context, attrs) returns the name of the view used in XML. Based on this name, a new view is directly created. The method is as follows:

 LayoutInflaterCompat .setFactory ( getLayoutInflater ( ) , new LayoutInflaterFactory ( ) {
 @Override
 public View onCreateView ( View parent , String name , Context context , AttributeSet attrs ) {
 switch ( name ) {
 case "TextView" :
 return new TextView ( context , attrs ) ;
 case "ImageView" :
 return new ImageView ( context , attrs ) ;
 case "com.cubic.choosecar.ui.car.view.NewStarView" :
 return new com .cubic .choosecar .ui .car .view .NewStarView ( context , attrs ) ;
 case "com.cubic.choosecar.ui.carseries.scrolllayout.ScrollableLayout" :
 return new com .cubic .choosecar .ui .carseries .scrolllayout .ScrollableLayout ( context , attrs ) ;
 case "View" :
 return new View ( context , attrs ) ;
 case "com.cubic.choosecar.newui.carseries.view.CarRevisionSeriesImageScaleLayout" : // Custom view
 return new com .cubic .choosecar .newui .carseries .view .CarRevisionSeriesImageScaleLayout ( context , attrs ) ;
 case "ViewStub" :
 return new ViewStub ( context , attrs ) ;
 case "ScrollView" :
 return new ScrollView ( context , attrs ) ;
 case "androidx.constraintlayout.widget.ConstraintLayout" :
 return new androidx .constraintlayout .widget .ConstraintLayout ( context , attrs ) ;
 case "FrameLayout" :
 return new FrameLayout ( context , attrs ) ;
 case "RelativeLayout" :
 return new RelativeLayout ( context , attrs ) ;
 case "androidx.appcompat.widget.Toolbar" :
 return new androidx .appcompat .widget .Toolbar ( context , attrs ) ;
 case "LinearLayout" :
 return new LinearLayout ( context , attrs ) ;
 default :
 View view = getDelegate ( ) .createView ( parent , name , context , attrs ) ;
 return view ;
 }
 // return view ;
 }
 } ) ;

Including system view and our customized view.

This solution has little code intrusion on existing projects, low transformation cost, and high compatibility. Relatively speaking, its rendering efficiency is lower than that of the X2C solution, but it is more suitable for our rendering optimization of complex layouts of existing old projects.

3.5 Further optimization of layout

We can use viewStub to implement lazy loading of layout. The idea is to divide the layout into different modules, let some modules use viewStub tags to replace, after half of the module elements on the screen are rendered, use viewStub to render and generate other modules contained in viewStub, and implement delayed rendering and loading.

By analyzing the layout of the car series page, we have divided the layout elements into some modules according to their functions. We further grouped the layout modules with high correlation together, encapsulated them in a custom VIEW, and used viewStub to include and replace these module views. When the UI thread uses setContentView to render the layout, the modules contained in viewStub will not be rendered, but only some elements of the screen will be rendered, waiting for the main interface data to return, and then use viewStub to delay other modules, thus realizing lazy loading of the layout and speeding up the rendering speed of the main thread.

4. Optimize results

Through the optimization methods in Sections 3.4 and 3.5, the comparison results of the complex layout rendering optimization of the car series page are as follows:

By comparison, we can see that on Android models of different grades, the rendering time is reduced by about 20%-35%. On low-end models, the absolute time reduction is greater and the feeling may be more obvious.

About the Author

Jiang Xiongfeng

■ Dealer Business Unit - Dealer Technical Department.

■ Joined Automotive in 2018 and currently works in the mobile app team of the dealer technology department, mainly involved in Android mobile terminals, Flutter, React Native and other large front-end technologies, responsible for the development of automobile quotation app business.