This spike is to perform a thorough profile of the app's memory usage, and identify any memory leaks or memory hogs, and propose solutions for them.
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T98139 OutOfMemoryError errors due to various causes. (tracking) | |||
| Resolved | Dbrant | T102062 OutOfMemory condition in Image Gallery results in an unhelpful 'Could not draw the image' error. | |||
| Resolved | • Mholloway | T109128 [Spike 4h] Perform memory profiling of the app, and identify any offending parts. |
Event Timeline
I spent a good deal of time on Thurs/Fri looking at memory usage via adb/Android Studio while performing all of the various actions available in our app and also trying some classic memory pressure tricks (rotating the screen repeatedly & switching rapidly into and out of the app). The only way I found to put substantial memory pressure on the app was to use the gallery activity, which causes a sharp rise in memory usage even with normal, casual image browsing (and even more so, of course, when swiping rapidly through images).
I was unable to induce a memory-related crash through this or any other method on any of my devices, but based on this testing, I would suspect that taking steps to rein in memory usage in the gallery would substantially reduce OutOfMemory errors.
I would recommend implementing some sort of intelligent subsampling functionality to ensure that we're not requesting, processing, and displaying images that are at a higher resolution than the user's device is capable of displaying. One possibility is that we could mitigate memory use problems by adjusting the bitmap config and/or the size and resolution requested using a scheme like Facebook's Device Year Class.
There are also a few libraries out that claim to be able to give us subsampling for free, including Subsampling Scale Image View and Glide. (Of these, the latter is more famous and widely adopted, but the former seems to very neatly fit our use case here.) It might also be worth taking a serious look at Facebook's Fresco library, which leverages native memory for bitmap processing and might give us a big payoff in exchange for what looks like a fairly substantial learning/implementation curve.
I also did some exploratory profiling with Square's Leak Canary library, which mostly yielded the result that ACRA was leaking GalleryActivity references (this was patched a while back, but doesn't seem to have resolved the issue) but that will be moot since we'll no longer be using ACRA very shortly.
@Mholloway FWIW, I'm able to get the app to crash very easily on the API 15 emulator, which also corresponds with @Etonkovidova's experiences with her API 15 tablet. (I also tried ripping out ACRA, to little effect)