HS Android - Android development process: no pain no gain

Serhii Yaremych, Android developer, Master of Code Global

Every device is a village, which means that everybody has to cooperate to make the user experience on that device work. You can all make it worse together, or you could make it nice together.

Transcript

2. Why is mobile development so difficult?
3. Memory • Limited • Shared
4. Memory You have to understand is that, of course, when you’re writing your app, to you, your app is the most important app on the device. But, it is not the only app on the device!
5. Memory Application#onTrimMemory(int level) • TRIM_MEMORY_BACKGROUND • TRIM_MEMORY_COMPLETE • TRIM_MEMORY_RUNNING_CRITICAL • TRIM_MEMORY_RUNNING_LOW • TRIM_MEMORY_UI_HIDDEN • etc.
6. Memory System is not just asking out of idle curiosity - “Gee, can you free up some memory?”.The system is asking because it needs more memory now. The bigger your app the more chances you will have to get killed once the app is in the background.
7. Memory “Premature optimization is the root of all evil.”
8. CPU • (Much) Slower than desktop and server • Throttled
9. GPU • [See CPU slide] • Texture upload is expensive • Fill rate vs. density
10. GPU Texture uploads tend to be expensive, so anything that is a bitmap, or results in a bitmap, will result in that being uploaded to the GPU. For example, if you’re drawing a path, these things go into bitmaps which get uploaded as textures, and can cost. You may suffer performance bottlenecks because of that.
11. GPU The rate of bandwidth performance has not kept up with that over time. So, the system is working harder and harder to fill all these pixels. The more you ask to do, the longer it’s going to take. ⏳
12. Memory == Performance • Larger application heaps lead to: • More task thrashing • Slower allocations • Slower collections • More GC activity
19. Low-End Devices • Your device is faster than your users’ • And has more memory • Moore’s Law does not always apply
20. Smooth Frame Rate • You have 16ms per frame to do everything • Consistency is good
21. Runtime • Dalvik vs. ART • Language != Runtime != Hardware
22. Language != Platform Java programming language Runtime Hardware
23. Server-Land Java programming language Server runtime Server Moving, compacting collector CPU: very very fast Memory: Basically ∞
24. Android-Land Java programming language Dalvik No compaction ART Idle compaction
25. UI Thread • Android is single threaded UI system(mostly) • Eliminate unnecessary work on UI thread
26. Storage • Storage performance varies • Storage size varies • So apk size matters
27. Storage Writing to flash storage means a lot of work for the controller because it has to do the collection and keep track of what’s used and what’s not. That means that if your application is in the background doing a lot of I/O operations, you might slow down everybody else.
28. Network • Your network is faster than your users’ • And maybe cheaper, too
29. And Finally • Every device is a village • Tragedy of the Commons
30. And Finally Every device is a village, which means that everybody has to cooperate to make the user experience on that device work.
31. And Finally The other dynamic is the “tragedy of the commons”: everybody thinks that their application is the most important. If everybody has that attitude, then everybody’s going to be as large and active as possible, and the device will be brought to its knees.
32. Tips. Language & Libraries
33. Know your language • Don’t use Java Serialization • Use android data structures(Sparse family, ArrayMap) • Be mindful of XML and JSON usage • Avoid JNI • Avoid reflection • Primitives vs boxed primitives
34. Know your language • Don’t use Java Serialization • Use android data structures(Sparse family, ArrayMap) • Be mindful of XML and JSON usage • Avoid JNI • Avoid reflection • Primitives vs boxed primitives
35. Know your language • Don’t use Java Serialization • Use android data structures(Sparse family, ArrayMap) • Be mindful of XML and JSON usage • Avoid JNI • Avoid reflection • Primitives vs boxed primitives
36. Know your language • Don’t use Java Serialization • Use android data structures(Sparse family, ArrayMap) • Be mindful of XML and JSON usage • Avoid JNI • Avoid reflection • Primitives vs boxed primitives
37. Know your language • Don’t use Java Serialization • Use android data structures(Sparse family, ArrayMap) • Be mindful of XML and JSON usage • Avoid JNI • Avoid reflection • Primitives vs boxed primitives
38. Know your language • Don’t use Java Serialization • Use android data structures(Sparse family, ArrayMap) • Be mindful of XML and JSON usage • Avoid JNI • Avoid reflection • Primitives vs boxed primitives
39. Know your language • Don’t use Java Serialization • Use android data structures(Sparse family, ArrayMap) • Be mindful of XML and JSON usage • Avoid JNI • Avoid reflection • Primitives vs boxed primitives
40. Know your language • Don’t use Java Serialization • Use android data structures(Sparse family, ArrayMap) • Be mindful of XML and JSON usage • Avoid JNI • Avoid reflection • Primitives vs boxed primitives • Be careful with finalizers
41. Syncing • Don't over-sync • Allow delayed downloading • Be mindful of XML and JSON usage • FCM • Job Scheduler/GCM Network Manager/Firebase Job Dispatcher • Don't poll • Only sync what you need to
42. Network Quality • Don't assume about the network • Develop for low-end network(and test for them)
43. Data & protocols • Design back-end APIs for mobile usage patterns • Minimize and compress data
44. Storage random stuff • Don't hard-code file paths • Persist relatives path only • Use storage cache for temp files • Avoid SQLite for simple needs • Avoid using too many databases • Let user choose content storage location
45. Q&A ❓