ImageVector vs XML drawable

[fergdev]

I have been looking into exporting assets for a project in the ImageVector format, but it appears ImageVector slows down the compilation time significantly. Is anyone able to offer an explanation for this?

The two big plus's to using ImageVector is

• Nicer API
• KMP support

Is the compilation time so much slow that it offsets these benefits?

[egorikftp]

Hello, thanks for the question.

The provided link shows that Google has stopped supporting its own material icons in ImageVector. Instead of providing tooling, they recommend downloading icons in XML manually and adding them to the project.

I don't have a benchmark for the increase in compilation time when using ImageVector.

Key ImageVector benefits from my side:

• Compose-first API: works directly with Icon(imageVector = …) and rememberVectorPainter without relying on Android drawables.
• Multiplatform-friendly: usable across Compose Multiplatform (Android, Desktop, iOS, WASM) from shared code.
• Type-safe Kotlin references: IDE autocomplete, refactoring, and compile-time checks. Also we provide Preview functionality for icons https://github.com/ComposeGears/Valkyrie?tab=readme-ov-file#imagevector-previewer
• No XML parsing overhead: small initialization benefit vs XML VectorDrawable (parsing happens once in XML, but ImageVector skips it).
• Tree-shrinking friendly: R8 can strip unused ImageVector references, helping reduce size.
• Simpler distribution: no resource folder setup, no resource ID collisions; everything is namespaced in Kotlin.
• Interop with painters: rememberVectorPainter provides a performant painter; works with Image, Icon, or custom Canvas drawing.

[fergdev]

Thank you so much for the detailed response. I am a fan of the ImageVector pattern and would prefer to use it in this project. But the compile time problems have me a little uneasy at the moment.

I am thinking of writing a benchmark for compilation times, but I am sure how effective it would be with a simple example. Have you had any thoughts on this?

The material-icons-extended library is 32mb in size, I know this is a large IconSet, for reference the aar I have generated using your lib is 9mb (it contains many complex SVGs). Is there a concern for having this much data in memory at once? Or does the JVM handle this?

I presume iOS has to load the whole lib into memory at runtime?

Would WASM targets have to download the whole Icon set on load? I presume so? And having them in resources would only download them on demand?

Sorry for off topic questions that are not specific to your library, I appreciate any response.

[egorikftp]

I am thinking of writing a benchmark for compilation times, but I am sure how effective it would be with a simple example. Have you had any thoughts on this?

The current Gradle tooling allows for effectively caching code between compilations. You can extract icons into a separate module and gain all the benefits of this feature. For example

it contains many complex SVGs
As for me, for complex icons, we should follow the same rules as for XML. If an icon has too many details, it is better to consider using the .png or .webp format.

For reference the aar I have generated using your lib is 9mb. Is there a concern for having this much data in memory at once? Or does the JVM handle this?

Unlike XML icons, the generated Kotlin code can be minified and optimized after compilation. Also, icons are not loaded into memory unless they are called. For example, the backing field format is nullable by default, and icon initialization occurs only after the first call.

Would WASM targets have to download the whole Icon set on load? I presume so? And having them in resources would only download them on demand?

In both cases (XML or ImageVector) icons will be part of WASM binary and will be loaded once during app startup.

[vkatz]

@fergdev
Hey there, few addings:

1. App performance > build performance, so you need to care more about user rather build (at least this how i think)
2. In case of build speed - you can dedicate a separate module and store all icons in there, so the module going to be cached by gradle and will not need to be rebuild (unless you change some icons) so here you will get same speed as for xml's (just packing into apk/aab/executable), the only initial/first build time will be affected (not much)
3. As for memory, as option you can use weekref or create some kind of scoped-access icons (eg: load off from memory if not used)

[fergdev]

Thanks for the response @vkatz.

The main reason I want the ImageVector is for ease of use for our Dev team. I am implementing this now and got nervous that I might introduce perf issues into our build system or runtime.

I can't visualize how the weakref would work. My thoughts were the classloader would bring the Vecs into memory when required, but they would never be unloaded. This would add 9mb of memory to consumption if all the assets were loaded (this won't happen, but it is the limit).

Looking at the compose drawable loader, it uses weakref to drop loaded svgs from memory when the GC deems necessary.