Hello In Android Views world creating new objects in `onDraw

Question

Hello In Android Views world creating new objects in `onDraw` callback is considered a bad practice In compose official docs we see creating instances of Offset Path etc in DrawScope Is it going to be impacting draw performance the same way as in views Or we shouldn t care about such things in compose world

Filip Wiesner · Answer

Not sure about `Path` but `Offset` is inline value class so that shouldn t be a problem

ade · Answer

I don t think so because recomposition doesnt happen on every frame and if it does you ve got a larger problem

Anton Shilov · Answer

If you re running an animation it could recompose on every frame and become problematic thinking face

Albert Chang · Answer

Firstly many of these e g `Offset` `Color` are inline classes which are essentially primitive types so there isn t any object allocations when using these classes Secondly that rule was proposed in the early years of Android when it was still using Dalvik ART is much better in this respect and the performance of mobile chips has also improved a lot Generally I don t think this should be a big problem now You can start to think about optimization when you actually see some performance issues

Adam Powell · Answer

All of the above is true slightly smiling face ART and hardware have improved but putting pressure on the GC when you don t need to comes at a cost In particular on modern versions of ART the GC runs concurrently without the kinds of stop the world pauses you might be used to but the trade off is that while it s running field reads involve full memory barriers making all of the rest of your code on other threads run slower

Adam Powell · Answer

It s not free on desktop JVM either but the characteristics are different

Adam Powell · Answer

If we didn t worry about it at all then we wouldn t have bothered making the classes mentioned above inline You ll see that in some very frequent code paths we also make sure to use O 1 indexed collection classes and forEach variants that avoid creating iterators

Adam Powell · Answer

All that said we ve done this in the deeper compose internals so that in the common case you don t have to go this far yourself in your own code unless you ve measured a problem Hardware and software have gotten better here Keep it in mind don t be unnecessarily wasteful but don t tie your code completely in knots for something you haven t measured either

Adam Powell · Answer

`Modifier drawWithCache` is a good example of an API designed for helping you with this you get an outer block for creating things you might reuse over time and an inner block for drawing using those same object instances

Filip Wiesner · Answer

gt we ve done this in the deeper compose internals so that in the common case you don t have to go this far yourself Same reasoning as with enums in the old days enums being represented with Integers instead of an actual enum

Adam Powell · Answer

Eh kinda slightly smiling face With the direction Kotlin took with exhaustive when around enums it s a really good thing Android mostly didn t use them since exhaustive when means adding a new enum value is both binary and source breaking whereas in plenty of cases with Java you can get away with it

Adam Powell · Answer

And if you have thousands of them they really do add up in terms of overhead unless you have a whole program shrinker like r8 eliminate them and reduce them to primitives Can t do that across a dynamically linked API boundary at least not yet

Adam Powell · Answer

Avoiding the exhaustive when gotcha and being able to compatibly add new values to a type is why compose uses inline value classes for a lot of things instead of enums

Filip Wiesner · Answer

Fair enough ok hand Thanks for the explanation

Anton Shilov · Answer

Thank you for the detailed explanation Adam pray