avif-coder icon indicating copy to clipboard operation
avif-coder copied to clipboard

using this Library increases APK file by 55MB

Open Particlo opened this issue 4 months ago • 2 comments

if some work could be put into this by about how much could the size be reduced

Particlo avatar Jul 12 '25 00:07 Particlo

It's close to not reducible further with current android packaging system.

Approximate size of libraries: AVIF encoder 5mb, AVIF decoder 1mb, any of HEIF requires libheif which is 1mb, HEIF encoder 2mb, HEIF decoder 2mb and shared code is 2mb.

There are only 3 ways how to deal with it:

  • Drop "unneeded" functionality.
  • Split the package into several modules, shipping shared code as dynamic libraries. This would make the project modular, bbut anyone needing multiple features would have to manage dynamic library conflicts in Gradle. That almost inevitably leads to UB if incompatible versions are chosen.
  • Publish multiple packages with different features sets. This technically doable, but it requires plenty of time to configure multiple packages and makes maintenance really hard one.

If you need all the features in the end you still need all the size.

awxkee avatar Jul 12 '25 08:07 awxkee

I tried actually some time ago ( about a year ago ) SVT instead AOM and kvazaar instead of x265.

SVT is using threading model not compatible with the JVM ( the JVM mandates all threads to be killed after exiting JNI env ) and it’s also too memory hungry to be used on the phone. It literally requires 2gb+ to encode 4k image which leads to a SIGKILL from the system. Additionally, it can encode the only 4:2:0 what makes impossible to use it for high quality pictures. So technically it’s possible to use it after patching it a little but with hard set restrictions. Thus, from my view saving 1mb from SVT is not worth the trade-offs.

As for kvazaar, it relies on thread synchronization via a lock file ( which is obviously not compatible with the JVM ) and also it has some global state that does use after free in JVM environment. So, using it would require to make a decent amount of work to fixup obvious UB's and rework its threading model.

Just from my perspective saving 1mb per platform is not worth to dealing with those libs and bringing obvious instability and UBs.

It's possible that in the past year some of these issues have been fixed, but given the design of these libraries, I see no reason to believe there are any plans to make them work properly on Android.

awxkee avatar Jul 12 '25 15:07 awxkee