paint-brush
The Effect of Multiple Switching to and From Compose on Application Performanceby@leonidivankin
502 reads
502 reads

The Effect of Multiple Switching to and From Compose on Application Performance

by Leonid IvankinSeptember 1st, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

An article on refactoring performance on compose has shown that performance loss depends on different conditions. In large projects with a lot of legacy code, double switches (once from xml to compose and once from compose back to xml) can occur. In this article I want to evaluate the impact on performance of multiple switching from. xml to. compose and back. I would not recommend using double switches in a project in. a project with complex code. If you have noticed any inaccuracies in this article, please write about them in the comments.
featured image - The Effect of Multiple Switching to and From Compose on Application Performance
Leonid Ivankin HackerNoon profile picture

I have an article on evaluating refactoring performance on compose. My research has shown that performance loss depends on different conditions. In this article I want to evaluate the impact on performance of multiple switching from xml to compose and back.

Introduction

For the example, like in the last article, I have 49 indented rectangles nested inside each other. For the sake of clarity, I colored the shapes in two colors: red and blue. The code will look something like this:

FrameLayout (xml)
  Box (compose)
    FrameLayout (xml)
      Box (compose)
        FrameLayout (xml)
          Box (compose)
          …


FrameLayout is red, Box is blue.

So we have a tree of nested visual elements, some of which are FrameLayout on xml, some of which are Box on compose.

This example is even more hyperbolized than the examples in the last article. Naturally, in working projects, switching 49 times is unlikely. However, in large projects with a lot of legacy code, double switches (once from xml to compose and once from compose back to xml) can occur.

The full code is here: https://gist.github.com/f87c31426cfb0800cb647e0277654ca6 https://gist.github.com/9282dac01eb86e0c3a39150742383985


The task before us is to find out whether multiple switches from xml to compose and back will have a negative impact on performance?

Observations and Assumptions

  • This example is also not quite "pure" compared to the previous ones, because in addition to the directly useful views (FrameLayout and Box) there are also auxiliary ones (ComposeView and AndroidView). That is, the total number of visual elements will be about 98 (49*2). However, I decided to leave it that way, since it's closer to the working situation. In this context, FrameLayout cannot exist without AndroidView and Box cannot exist without ComposeView.
  • This comparison is by no means claiming to be absolutely correct for all types of devices, amounts of RAM, or different types of displays.
  • Measurements were made on the phone Xiaomi mi 5s, MIUI Global 10.2, quad-core processor 12.15GHz, 3GB of RAM, Android 8.0. Especially chose not the most powerful and top-end phone, so that the difference was more noticeable. Similar and weaker devices are used by most users in the world.
  • Measurement for each case was carried out 10 times, the average was calculated.

Measuring

As in the previous article, the measurements were made at three points: between onCreate() and onPause() and between onCreate() and onWindowFocusChanged(). The results are summarized in the table:

Notice that the time in the onResume method is reduced to 110. After that, however, the visual elements are not yet visible. They are displayed when window goes into focus in the onWindowFocusChanged method. As you can see, the maximum display time is now about 10 seconds. A little longer and an ANR error would have occurred.

Conclusion

As with everything in life, it also pays to connect the two tools together.


You can see that the display time of visual elements in MultiSwitchingActivity has dropped significantly and is about 10s. That's the answer to the question posed at the beginning of this article - performance will drop. It's worth noting that this time will be noticeable not only when the application is launched for the first time, but also when you turn the phone and the stack of onCreate(), onStart() and onResume() methods is repeated.


This is why I would not recommend using double switches (xml in compose and compose in xml) in a project. Because if you interpolate the results obtained 10 000 ms - 50 views -> 400 ms - 2 views, it will turn out that the translation from compose to xml and back takes 400 ms, which is still a lot. Keep in mind that in this example, the visual elements themselves were as simple as possible. In real projects, they are more complex, which will further degrade performance.

If you have noticed any mistakes or inaccuracies in this article, please write about them in the comments.