Thinking cpu & memory - DroidCon Paris 18 june 2013
2 likes774 views
This document discusses various techniques for improving mobile app responsiveness and performance, including: - Loading pages within 4 seconds to avoid high bounce rates. - Caching data and images to reduce network usage. - Avoiding work on the UI thread and blocking the UI to ensure responsiveness. - Optimizing rendering, memory usage, and network requests to achieve smooth 60 frames-per-second performance. - Profiling tools like Systrace, Hierarchy Viewer and GPU Overdraw can help detect issues.
Thinking cpu & memory - DroidCon Paris 18 june 2013
- 1. (Code for Responsiveness) Thinking of CPU & Memory
- 3. Why? 25% of people leave a web page if it takes more than 4 seconds to load
- 4. why? ● Amazon: +100ms = -1% sales ● Google: going from 0.4 seconds to 0.9 seconds loading a page causes a 20% decrease of benefits ● I don't have data about smartphones, but IMHO is even worse
- 5. The user is very demanding Mobile != Computer
- 6. The concept Classic case: 1. Download some data 2. Parse 3. Download more data (images, audios, ...) 4. Load it on memory 5. Show it on screen
- 7. Don't be a Java Hero It seems to me that Java is designed to make it difficult for programmers to write bad code, while Python is designed to make it easy to write good code.” — Magnus Lycka, Aug. 18, 2005
- 8. How? ● Compile always with the latest SDK (hardware accel, ...) ● Splash-screens are evil ● Don't do work on UI Thread ● Don't block the UI (ProgressDialogs...) ● Efficient GetViews ● Don't download same data 2 times ● Fight for the 60fps
- 9. Speed
- 12. DDMS (Network Statistics) Red (Análisis)
- 13. 12s -> 0.4s (bad network, good smartphone) Network - cache downloaded data (this code isn't complete)
- 14. Cache: ● Universal-Image-Loader ● Picasso Bandwidth: ● don't send too big bitmaps ● WebP (~-30%) Bitmaps
- 15. CPU Not everybody have a Nexus 4
- 16. Traceview (code y DDMS) CPU (Analyze)
- 17. Cache objects 7s -> 0.8s (bad smartphone)
- 19. RAM If you don't share you get kicked
- 20. $ adb shell procrank Keep the app in memory (Analyze)
- 21. Other tools to analyze memory usage ● adb shell dumpsys meminfo ● Heap dump ○ capture it with DDMS ○ +HeapDumpOnOutOfMemoryError ● MAT (Memory Analyzer Tool) ○ analyzes your heap dump ○ hprof-conv package.hprof package-converted.hprof ○ It has a stand-alone version if you don't want to use Eclipse
- 22. Keep the app in memory
- 23. Smoothness* The wanted 60fps *(Section "stolen" from Romain Guy)
- 24. Smoothness ● Profile GPU rendering (4.1) ● GPU Overdraw (4.2) ● Systrace (4.1) ● Hierarchy Viewer
- 25. Profile GPU Rendering ● profile last frames rendered ● You need to enable it on device (dev.options) ● you need <16ms per frame to get 60fps ● ddms -> System Information -> Frame render time
- 26. Systrace ● Enable on device (dev. options) ● tools/systrace/systrace.py or ddms
- 27. GPU Overdraw ● As a general recommendation we can paint every pixel a max of 3 times ● 9-patch for backgrounds ● lint can warn you about layouts with possible overdraw
- 28. Hierarchy Viewer
- 29. ● PerfMon (memory, cpu, network on a floating window) ● Usage Timelines (cpu, memory) Other tools
- 30. ● Save a long with start time on Application and show a diff with current time on a toast when you are end "printing" screen ● Send through analytics performance data ● You can do it on all parts of your app Detect regressions
- 31. "Donald Knuth" "Premature optimization is the root of all evil"
- 32. References ● Google I/O 2012 - Doing More With less: Being a Good Android Citizen ● Designing for Performance (developer.android.com) ● "Displaying Bitmaps Efficiently" Android Developers ● http://www.curious-creature.org/docs/android-performance- case-study-1.html ● http://www.curious-creature.org/2012/12/06/android- performance-in-practice/ twitter: @oriolj +Oriol Jiménez