Thinking cpu & memory - DroidCon Paris 18 june 2013

620 views

Published on

http://www.paug.fr

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
620
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Thinking cpu & memory - DroidCon Paris 18 june 2013

  1. 1. (Code for Responsiveness)Thinking of CPU & Memory
  2. 2. Done!The app works!
  3. 3. Why?25% of people leave a web page if it takes more than 4seconds to load
  4. 4. why?● Amazon: +100ms = -1% sales● Google: going from 0.4 seconds to 0.9 seconds loadinga page causes a 20% decrease of benefits● I dont have data about smartphones, but IMHO is evenworse
  5. 5. The user is verydemandingMobile != Computer
  6. 6. The conceptClassic case:1. Download some data2. Parse3. Download more data (images, audios, ...)4. Load it on memory5. Show it on screen
  7. 7. Dont be a Java HeroIt seems to me that Java is designed to make itdifficult for programmers to write bad code,while Python is designed to make it easy towrite good code.” — Magnus Lycka, Aug. 18,2005
  8. 8. How?● Compile always with the latest SDK (hardware accel, ...)● Splash-screens are evil● Dont do work on UI Thread● Dont block the UI (ProgressDialogs...)● Efficient GetViews● Dont download same data 2 times● Fight for the 60fps
  9. 9. Speed
  10. 10. Strict Mode.penaltyLog().penaltyDeath()
  11. 11. Network(Public enemy #1)
  12. 12. DDMS (Network Statistics)Red (Análisis)
  13. 13. 12s -> 0.4s (bad network, good smartphone)Network - cache downloaded data(this code isnt complete)
  14. 14. Cache:● Universal-Image-Loader● PicassoBandwidth:● dont send too big bitmaps● WebP (~-30%)Bitmaps
  15. 15. CPUNot everybody have a Nexus 4
  16. 16. Traceview (code y DDMS)CPU (Analyze)
  17. 17. Cache objects7s -> 0.8s (bad smartphone)
  18. 18. Show old dataalways
  19. 19. RAMIf you dont share you get kicked
  20. 20. $ adb shell procrankKeep the app in memory (Analyze)
  21. 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 dont want to use Eclipse
  22. 22. Keep the app in memory
  23. 23. Smoothness*The wanted 60fps*(Section "stolen" from Romain Guy)
  24. 24. Smoothness● Profile GPU rendering (4.1)● GPU Overdraw (4.2)● Systrace (4.1)● Hierarchy Viewer
  25. 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. 26. Systrace● Enable on device (dev. options)● tools/systrace/systrace.py or ddms
  27. 27. GPU Overdraw● As a general recommendationwe can paint every pixel a maxof 3 times● 9-patch for backgrounds● lint can warn you about layoutswith possible overdraw
  28. 28. Hierarchy Viewer
  29. 29. ● PerfMon (memory, cpu, network on a floating window)● Usage Timelines (cpu, memory)Other tools
  30. 30. ● Save a long with start time on Application and show adiff 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 appDetect regressions
  31. 31. "Donald Knuth""Premature optimization is the root of allevil"
  32. 32. References● Google I/O 2012 - Doing More With less: Being a GoodAndroid 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

×