Compose LazyColumn vs. RecyclerView, which one has better performance?

LazyColumn is a control used in compose to achieve effects similar to RecyclerView, but everyone says that the performance of LazyColumn is much worse than that of RecyclerView. After all, RecyclerView has been optimized by Google for more than ten years, so it is normal to be a little worse than RecyclerView. Today we will use actual data to compare LazyColumn and RecyclerView, take a look at the rising star Compose LazyColumn and compare it with the big brother RecyclerView (the Flutter list control will not be compared, it is definitely not comparable to these two). First we need to know the criteria for judging fluency.

Fluency criteria

The industry commonly uses FPS (frames per second) to evaluate fluency. The higher the FPS, the smoother the interface. Most of the current screen refresh rates are 120hz, so 1/120 is approximately equal to 8.3ms for the screen to refresh once, and 16.6ms for a 60hz screen. We can judge the performance of both LC and RV by monitoring the start and end of the sliding when the LC and RV slide quickly, and counting the number of rendering frames and the total rendering time during this period.

Okay, now that the theory is over, the solution is to write code and practice it. Practice will give you true knowledge, and data can prove everything. Talk is cheap. Show me the code.

Prepare data

For the sake of simplicity, LazyColumn will be referred to as LC and RecyclerView will be referred to as RV below.

For the sake of fairness, we fill the same data in LC and RV. The list size is 200, and both use the controls provided by the system. LC uses Text, and RV uses TextView. The height, color, and text of Text and TextView are the same. as follows

The code related to frame rate statistics is as follows

Statistics start when the interface starts sliding, and the number of rendering frames and time difference are printed when the sliding ends. Okay, it’s time for the exciting PK session. Both operations are to start swiping down quickly, then swipe up quickly after reaching the bottom, and cycle through this operation several times to see the data.

As for the usage, they are all used in official examples. There is no problem with usage that affects the results, right?

first round

This round of rendering does not add Thread.sleep and renders normally, simulating the situation of a simple list.

Looking at the data and actual experience, we know that LC won this round, with LC rendering time being shorter and rendering more frames. But in fact, the experience of both is not bad, and they are almost the same. However, when sliding very fast, I still feel that the LC has a better experience and is more silky. Regardless of whether it is extremely fast sliding or slow sliding, RV has the same time and number of rendering frames, which is relatively stable. So LC wins this round, so let’s add 10 points to LC.

second round

In this round, a Thread.sleep(4) half-frame is added to simulate the home page interface of the e-commerce super app and a large number of renderings.

Looking at the data, I thought LC was better, but in actual experience, LC will have very obvious lags when sliding very quickly, while RV is still very smooth no matter how you slide, and there is no lag, so RV wins this round. Yes, add 100 points to RV.

round three

This round adds Thread.sleep(8) for one frame to simulate extremely large rendering situations.

I really can't play this round of LC anymore because LC is too stuck and the framerate is very serious. After testing the RV, I found that the RV is still very smooth, but not as smooth as the RV in the previous round. The RV can feel a little stuck when sliding extremely fast, but the performance of the RV in this round can still beat the LC in the second round. This round gives RV +100000 points.

As for the reason why complex list LC renders more frames and takes less time, but is more laggy, consider the length of the article and write it later.

To sum up

LC and RV each have their own strengths and weaknesses, it depends on how we choose and what scenarios they are used in.

I believe you will know how to choose after reading this. For complex lists (like e-commerce homepages) you must choose RV. For simple lists, you can choose LC, because simple lists have a better LC experience, are smoother, and are more consistent with Better chirality.

Of course, LC is still being optimized by Google. The future LC will definitely be like its big brother RV, with more stable performance no matter what scene it faces.

Android study notes

Android performance optimization article: Android Framework underlying principles article: Android vehicle article: Android reverse security study notes: Android audio and video article: Jetpack family bucket article (including Compose): OkHttp source code analysis notes: Kotlin article: Gradle article: Flutter article: Eight knowledge bodies of Android: Android core notes: Android interview questions from previous years: The latest Android interview questions in 2023: Android vehicle development position interview exercises: Audio and video interview questions:https://qr18.cn/FVlo89
https://qr18.cn/AQpN4J
https://qr18.cn/F05ZCM
https://qr18.cn/CQ5TcL
https://qr18.cn/Ei3VPD
https://qr18.cn/A0gajp
https://qr18.cn/Cw0pBD
https://qr18.cn/CdjtAF
https://qr18.cn/DzrmMB
https://qr18.cn/DIvKma
https://qr18.cn/CyxarU
https://qr21.cn/CaZQLo
https://qr18.cn/CKV8OZ
https://qr18.cn/CgxrRy
https://qr18.cn/FTlyCJ
https://qr18.cn/AcV6Ap

Guess you like

Origin blog.csdn.net/maniuT/article/details/133212569