OOM with the new sheet approach

• Version of the library: Current SNAPSHOT
• Affected devices: Low memory devices
• Affected versions: Potentially all

I ran into an OOM with one of my old devices when opening an Activity with an EmojiTextView. This is due to the emoji Bitmap being really large when decoded. I can’t really use it in production like that sadly.

I tried:

• Only decoding the part of the sheet needed with BitmapRegionDecoder: Way too slow.
• Using a different decoder for the same purpose: Way too slow.

I can’t come up with a solution at this point. Maybe someone else has an idea? Otherwise: Should we revert?

[akwizgran]

I’ve experimented with a few approaches to this and found a solution that seems to work well.

The generator cuts the sprite sheet into strips, one sprite wide. (This was easier to implement than creating a sheet for each category.) The strips are loaded on demand and held by SoftReferences, so they’re released when the app’s under memory pressure. To avoid constantly loading and releasing strips, the most recently used emoji are cached without keeping the whole strip.

Here’s my branch. If you think this approach sounds reasonable I’ll open a PR: https://github.com/vanniktech/Emoji/compare/master...akwizgran:sprite-strips-soft-refs-lru-cache

On devices with low-density screens, it’s also possible to scale the strips (or sheets) by a factor of 2 when loading them, which reduces the memory overhead without increasing the APK size. However, this increases the CPU cost of loading a strip. This branch includes scaling as a separate commit: https://github.com/vanniktech/Emoji/compare/master...akwizgran:sprite-strips-soft-refs-lru-cache-scaling

[rocboronat]

Good news there: we are at 6,1% with 0 crashes. IMHO, move on with the PR of the branch sprite-strips-soft-refs-lru-cache. Congrats and thanks for that magnificent work, @akwizgran!