Abstract There are many benchmarks that compare the performance and rendering speed of and . For the most part, they all show that is faster. However, there are suggestions that these benchmarks do not give a complete picture of performance because they compare trivial solutions, such as single nesting or lack of a large number of views. It is also assumed that in critical cases, such as deep or wide nesting, there will be different results. There are also opinions that it doesn't make sense to refactor code to in already existing large project, because the hybrid variant ( ) will exist in the project for a long time, and rendering performance will suffer even more because of it. That's why I decided to compare more complex variants: XML compose compose view compose compose+xml -deep and wide nesting; view -influence of state with respect to these cases. hybrid (compose+xml) Observations and Assumptions -This comparison in no way claims to be absolutely correct for all types of devices, amounts of RAM or different types of displays. -Measurements were made on Xiaomi mi 5s phone, MIUI Global 10.2, 12.15GHz quad-core processor, 3GB RAM, Android 8.0. Especially chose not the most powerful and top-end phone, so that the difference was more noticeable. Most people use similar devices. -To reduce the amount of code, I did not calculate the density of the screen, because I know that I have 3. -Use the 16 colors suggested by to separate the views from each other. Android Studio -The measurement for each case is taken 10 times and the average is calculated.
-If you have any questions about quality or quantity, the complete test code is given after each example and you can repeat it at any time. Introduction I wanted to nest about 100 views into each other to make comparisons, but I ran into an parsing error: This error occurred when nesting more than 49 views. Therefore, in the comparisons below I have operated with exactly this number of nested elements. To visually display and control what is happening, I have assigned a different background color and some indents to each element. As you can see in the picture to the left, the red view has a raspberry view nested, the crimson view has a purple view nested, etc. This group of examples will show how deep nesting affects performance in different execution options: . These examples will be labeled as depth. xml AAPT: error: failed to parse proto XML xml, code, compose, hybrid (xml+compose) Along the way, I created another critical case - "very wide nesting". That is, I put also 49 elements in one and colored them with different colors (see picture on the right). I purposely didn't use and for my comparisons. This group of examples will be marked as . Each view is also colored to control what happens. view RecyclerView LazyColumn width We now have the task of figuring out the rendering speed at each execution and answering a few questions: a) will there be an advantage in using when nesting is deep and wide? compose b) does the hybrid state affect rendering speed and performance in these cases? We will use the segment between the two points for measurements. The start point after . Intermediate ― after . The final one is which coincides with the full display of activity and the change of focus to the active state. The end point is after . The time will be measured by , because we don't need to calculate absolute values, so there is no point in using more precise tools. super.onCreate(savedInstanceState) super.onResume() onWindowFocusChanged() super.onResume() System.currentTimeMillis() XML depth Let's start with the first example. Let's put 49 times into each other and color the background in the standard colors. Let's add indents. FrameLayout 
<FrameLayout>
   <FrameLayout>
          <FrameLayout>
          ...
          </FrameLayout>
   </FrameLayout>
</FrameLayout> Full code https://gist.github.com/eef908bf788f36941beddc1cbc6d2348 https://gist.github.com/36b1e4870d86ae760ee238a3557d3d83 Table with the results: XML width Let's put the following example into 49 . I purposely didn't use to determine how the view would behave with wide nesting without optimizations. LinearLayout FrameLayout RecyclerView <LinearLayout>

   <FrameLayout/>
   <FrameLayout/>
   <FrameLayout/>
   ...
</LinearLayout> Full code https://gist.github.com/51b6b1e8dc288fb1decf7cbcb2ddd563 https://gist.github.com/504a474e66443813af1372c53bf316cc Table with the results: Code depth In this example, we'll put 49 in, but in runtime. We'll also color it with standard colors and add indents. In this example, we know in advance that the will be faster because there is no xml parsing step. This example is very close to compose. Rather, the goal here is to find out how much influence legacy has accumulated over the years in . As you will see below, the influence of legacy code is quite big. FrameLayout xml View //49 times
FrameLayout(this)
   FrameLayout(this)
       FrameLayout(this)
       ... Full code https://gist.github.com/48ade4ab6d6cde33a6e1d2f5b7aff95c Table with the results: Code width In this example we will place the 49 vertically in the . Let's add colors to each element. FrameLayout LinearLayout LinearLayout(this)
//49 times
   FrameLayout(this)
   FrameLayout(this)
   FrameLayout(this) Full code https://gist.github.com/808fd9ac925cf8f53260726f6e54ef09 Table with the results: Compose Depth In this example, let's finally start using compose. Let's nest 49 times inside each other to achieve deep nesting like in the example. Based on these two results, we will be able to compare whether deep nesting affects the rendering speed of the hierarchy. Box xml view //49 times
Box()
    Box()
        Box()
        ... Full code https://gist.github.com/7fc700187c33d90ddf20bb4af4694a16 Table with the results: Compose Width In this example, as in the , we'll make a wide nesting by inserting 49 into one . Just like in the example above, we intentionally didn't use the . Based on this example and the example above in the , we can conclude whether wide nesting affects the speed of rendering. xml Boxes Column LazyColumn xml Column()
//49 times
    Box()
    Box()
    Box()
    ... Full code https://gist.github.com/604ecdea027321df09d11778ce7d6bef Table with the results: Hybrid (xml + compose) depth In this example, we put 24 , then we put . In we'll put 24 (24 + 1 + 24 = 49). This way we can assess whether the hybrid state during refactoring affects the performance and the rendering speed of the view. Let's assume that all is the remaining legacy, and is the refactored part. FrameLayout ComposeView ComposeView Boxes FrameLayout ComposeView Box FrameLayout Box 
<FrameLayout>
   <FrameLayout>
          <FrameLayout>
              ...
              <ComposeView>
              //24 times
              Box()
                  Box()
                      Box()
                      ...
              </ComposeView>
          </FrameLayout>
   </FrameLayout>
</FrameLayout> Full code https://gist.github.com/06020dc278669e72431fbb2b97b3b3b0 https://gist.github.com/789b7407559b84f92df8d6bf2220fd06 Table with the results: Hybrid: xml + compose width In this example, create 49 in a and put a in each one. ComposeViews LinearLayout Box 
<LinearLayout>
    <ComposeView>
        Box()
    </ComposeView>
    <ComposeView>
        Box()
    </ComposeView>
    <ComposeView>
        Box()
    </ComposeView>
        ...
<LinearLayout> Full code https://gist.github.com/9a6316c0d9e3be6f60076c858e4c1b02 https://gist.github.com/c9cee224fe8cddca71eb9559a9a385d6 Table with the results: Conclusion Let's summarize all the results in a graph. The results were quite ambiguous. turned out to be 50% faster than in the method, but 2 times slower in the method. Compose xml onPause() onWindowFocusChanged() Answering the two questions originally posed, we conclude: There is an advantage with respect to the method, but not with respect to the method. onPause() onWindowFocusChanged() With respect to the method, the hybrid state ( ) does not affect the rendering speed, does not affect with respect to the method with multiple horizontal arrangement onPause() xml + compose onWindowFocusChanged() ComposeView is a very powerful and useful tool, but as you can see, it won't solve all the problems for us. Using , like any other technology, requires compromises and accuracy in its application. Compose compose

Super

Design Your Own Shimmering UI in 25 Lines of Code with Compose

Best Android Tools to Work With Databases

Nominated for 2022 - Android Advocate of the Year

Too Long; Didn't Read

Make resilience your competitive advantage

Comparing XML and Compose Rendering Speed at Deep and Wide Nesting

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

6 Ways to Run Kotlin Code in Android Studio

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

6 Ways to Run Kotlin Code in Android Studio

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps