Facebook tricks for image handling in Android
•Download as PPTX, PDF•
6 likes•2,507 views
One of the hardest parts of writing an Android application is dealing with images. They take up a lot of memory, and are a leading cause of crashes and slowdowns. This talk goes into the architecture of Android’s image processing libraries and how they have evolved over the years. It presents the different options available in the API for better image handling – bitmap recycling and pooling most prominently. I then go into more detail into work currently underway at Facebook to improve image handling. I discuss some poorly documented features in the Android SDK and NDK that offer keys to faster and safer image handling.
Recommended
Recommended
More Related Content
Similar to Facebook tricks for image handling in Android
Similar to Facebook tricks for image handling in Android (20)
Recently uploaded
Recently uploaded (20)
Facebook tricks for image handling in Android
- 1. Tips and Tricks for handling images in Android Tyrone Nicholas Software Engineer 8 May 2014
- 2. Memory is Scarce ▪ ~ 1/10 device RAM ▪ 480 x 800 = 1.5 MB
- 6. Android heaps Dalvik ▪ JDK ▪ Limited ▪ Slow ▪ Safe Other ▪ Certain system calls ▪ Like native Native ▪ NDK ▪ Unlimited ▪ Fast ▪ Unsafe
- 7. Put bitmaps in the native heap! Bitmap.java: Called from Bitmap.createBitmap() ▪ Eliminated in Android 3.0 Android’s Solution #1
- 8. Android’s Solution #2 Need memory? Look for unpinned memory Free it Ashmem • ashmem_create_region • ashmem_pin_region • ashmem_unpin_region
- 9. Android’s Solution #2 Draw Allocate Pin Decode Stop drawing Unpin Purgeable bitmaps
- 11. Android’s “Solution” #2 • Er, wait a minute…
- 12. Android’s Solution #3 Bitmap pooling ▪ When doing a decode, specify an old Bitmap object to re-use
- 13. Android’s Solution #3 Hang on…
- 14. Our solution
- 15. From the Android NDK… Screw purging. Just screw it.
- 16. How to do it (1)
- 17. How to do it (2)
- 18. Docs can lie
- 19. Without a GC…
- 20. Caveats • When are you ‘done’ with an image? • Application-specific • Nontrivial • Scrolling • Caches
- 21. ListViews and GridViews • Beware of flickering!
- 22. Other tips
- 23. An Image Pipeline Web P BMP BMP JPG JPG JPG UI thread Non-UI threads
- 24. Using native memory “Naïve native” • Can’t use for decodes!
- 25. ▪ Devices suck. Servers don’t ▪ Consider Resizing, scaling, and cropping
- 26. (c) 2009 Facebook, Inc. or its licensors. "Facebook" is a registered trademark of Facebook, Inc.. All rights reserved. 1.0
Editor's Notes
- ----- Meeting Notes (5/7/14 23:10) -----Introduction self
- ----- Meeting Notes (5/7/14 23:10) -----TeamWhat we've learned about images
- ----- Meeting Notes (5/7/14 23:10) -----Low-end devices 32 MB heap sizeCompressed vs uncompressed images4 bytes per pixelThe good/bad thing about Java is.Concurrent GCGC when it feels like, not when you need it.
- ----- Meeting Notes (5/7/14 23:10) -----Impact on UI threadImpact on user And if it fails...
- ----- Meeting Notes (5/7/14 23:10) -----Your app may not be doing anything 'wrong'
- ----- Meeting Notes (5/7/14 23:10) -----Android predicted this
- ----- Meeting Notes (5/7/14 23:10) -----SkiaBad because GC doesn't know when to triggerBad because images could crowd other apps out
- AshmemAnonymous shared memoryKernel allocates pages and these can be mapped to user spaceUnpinned is reclaimed when needed
- You can put intermediate bytes in native memory. More to avoid GC churn than to save memory.