I have an article on 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. evaluating refactoring performance 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.

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

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

10 good rules for bad App

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

10 good rules for bad App

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps