REPLAY-1727: Base64 Caching Mechanism#1534
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## feature/base64-jmoskovich #1534 +/- ##
=============================================================
- Coverage 83.66% 83.32% -0.34%
=============================================================
Files 438 439 +1
Lines 14854 14927 +73
Branches 2237 2250 +13
=============================================================
+ Hits 12427 12437 +10
- Misses 1868 1897 +29
- Partials 559 593 +34
🚀 New features to boost your workflow:
|
8418b54 to
7754a16
Compare
7754a16 to
5e57c0b
Compare
5e57c0b to
3c431ae
Compare
3c431ae to
92ba7a7
Compare
mariusc83
left a comment
There was a problem hiding this comment.
We need to test and register that callback
0xnm
left a comment
There was a problem hiding this comment.
nice idea! I've added some comments to discuss.
| } | ||
|
|
||
| @VisibleForTesting | ||
| internal fun setBackingCache(cache: LruCache<Int, String>) { |
There was a problem hiding this comment.
minor: maybe just a provider (Int) -> LruCache in the constructor with default value for prod and mock value for tests?
This reverts commit ef005ea.
57d6d54 to
af3259a
Compare
a9c7810 to
69e1ffe
Compare
69e1ffe to
3e9b47a
Compare
| private const val ON_MODERATE_MEMORY_SIZE_BYTES = (MAX_CACHE_MEMORY_SIZE_BYTES / 4) * 3 // 75% size | ||
| private var componentCallbacksRegistered = false | ||
|
|
||
| private var cache: LruCache<String, ByteArray> = object : |
There was a problem hiding this comment.
minor: for testing we can remove this mutability and inject a provider, but I'm not pushing for it (just it is better to have less mutability).
0xnm
left a comment
There was a problem hiding this comment.
I've added some questions and suggestions, but overall I think it is good to go.
| } | ||
|
|
||
| private fun getPrefixForDrawableContainer(drawable: DrawableContainer): String { | ||
| if (drawable !is AnimationDrawable) { |
There was a problem hiding this comment.
it means that the key for the AnimationDrawable will always be the same independent of the state? meaning that even state of AnimationDrawable has changed then the cache entry for the first known state will be served? Is it is an intention we want to have?
There was a problem hiding this comment.
Yes, its just a fix to avoid having AnimationDrawable take up too much space in the lrucache. We'll need to have a discussion/brainstorming if we decide we want to send animations with base64, and this will in any case cease to be an issue once we have the resources endpoint.
0xnm
left a comment
There was a problem hiding this comment.
I added a comment about internalLogger storage, it is a potential memory leak.
1f11ad4 to
9d3d7a8
Compare
9d3d7a8 to
257722b
Compare
What does this PR do?
Adds an LRUCache for base64 strings - cache base64 strings against drawable hashcodes.
Evict all items in the LRUCache every time we change views.
Motivation
Without a caching mechanism we create and garbage collect an excessive number of bitmaps.
Additional Notes
This PR contains a revert commit of the revert of imagebuttonmapper (iow it adds base64 functionality back)
Review checklist (to be filled by reviewers)