ANDROID BEST PRACTICES

Why are these rules important?

Text

mobile devices have constraints that are completely different to the world of desktop computers

failure to put these to account

Text

failure to account for such limitations may lead to very poor performance and poor memory management

not only for the app alone but also for the entire device

memory

most devices in the mobile ecosystem have low memory

android runs various activities and services in parallel. apps dont need to relauch afresh from the start

if these apps consume more memory than they have to. the result is?

what happens when we don't?

the android system starts to evict processes and services forcing a user into a situation where apps are constantly relaunching

this is due to pressure piled on memory

overall use as little mem as possible otherwise the whole system suffers

CPU

highest end mobile CPUs compared to desktop CPUs. comparison?

don't benchmark your apps performance based on its performance on high end devices e.g(nexus 5/6).

also at times the cpu is throtled down to better utilize battery life. therefore only a fraction of cpu pow

CPU

also at times the cpu is throttled down to better utilize battery life. therefore only a fraction of cpu power is at use then.

you app may also be the one preventing down clocking by triggering things such as animations

animation effect on CPU

memory = performance

low end devices

grab the cheapest phone as your main development phone

smooth frame rates

the average time that an application should target for processing input, layout and drawing should be 16ms for a frame

allows the system to render at 60fps during animations and input gestures

smooth frame rates

less than this speed is picked up on users as slow or jerky motion

even more problematic are apps that can hit that 16ms time but drop a frame or two due to inability to consistently hit that speed

dalvik vs ART

JIT vs Ahead-of-time

speed of both

Garbage Collection

is directly proportional to the number of objects in an app

process by which runtime frees memory for objects which are no longer referenced

ui Thread

Android is a single threaded UI system

lots of jank problems are due to doing too much on the UI thread

all activities that occur on views including drawing them happen on the single UI thread in the activity

ui Thread

doing other things on this thread can cause jank since 16ms just isnt enough time to do everything

lollipop introduced the render thread which involves sending everything being rendered to the GPU

input scrolling and animations still happen on the UI thread

storage

it varies with the low end devices having as low as 4gb for everything which includes, OS, media downloaded and all applications

Network

reliance on fast network speeds
oversyncing (doesn't mean the user needs all the data being pushed to them)

Every app is a village

no app should be greedy in its utilization of system resources