Performance optimization for Android

Boutique product development company
It is amazing what you can accomplish when you have a client-centric team to deliver outstanding products.

Boutique product development company
It is amazing what you can accomplish when you have a client-centric team to deliver outstanding products.
Performance Optimization
For Android
Arslan Anwar | Senior Software Engineer
Omer Tanveer | Software Engineer

Any developer can write code that a computer can
understand. Good programmers write code that humans
can understand. - Martin Fowler
Best Practices for Android / Mobile applications
❏ Managing Your App's Memory
❏ Improving Layout Performance
❏ Optimizing Battery Life
❏ Multi Threading
❏ Performance Optimization
❏ Resource Optimization
Arslan Anwar | Senior Software Engineer , Omer Tanveer | Software Engineer

Optimization in Android
Managing Your App's Memory
❖ Android application memory limit start from 16MB for a low/normal
device
❖ Allocating new objects remains resident in RAM.
❖ So the only way to completely release memory from your app is to release
object references you may be holding, making the memory available to the
garbage collector.

❖ Each Android-powered device has a different amount of RAM available
❖ getMemoryClass() to get an estimate of your app's available heap in
megabytes.
❖ Try to avoid largeHeap attribute to "true" in the manifest <application> tag
if possible
❖ It can justify when you have large photo editing app type app
❖ Additionally, the large heap size is not the same on all devices and, when
running on devices that have limited
RAM, the large heap size may be exactly
the same as the regular heap size.
Managing Your App's Memory

Switching Apps
Android keeps processes that are not hosting a foreground ("user visible") app
component in a least-recently used (LRU) cache
If your app has a cached process and it retains memory
that it currently does not need, then your app even while
the user is not using it is constraining the system's
overall performance
So, as the system runs low on memory, it may kill
processes in the LRU cache beginning with the process
least recently used, but also giving some consideration
toward which processes are most memory intensive.

Using Services
Do not keep running service unless it's actively performing a job.
Also be careful to stop service it when its work is done.
System prefers to always keep the service process in running. Then the RAM
used by the service can’t be used by anything else or paged out.
This reduces the number of cached processes that the system can keep in the
LRU cache, making app switching less efficient. It can even lead to thrashing
in the system when memory is tight and the system can’t maintain enough
processes to host all the services currently running.

Using Services (Continued..)
The best way to limit the lifespan of your service is to use an IntentService,
which finishes itself as soon as it's done handling the intent that started it.
Leaving a service running when it’s not needed is one of the worst memory-
management mistakes an Android app can make.
So don’t be greedy by keeping a service for your app running. Not only will it
increase the risk of your app performing poorly due to RAM constraints, but
users will discover such misbehaving apps and uninstall them.

Release memory when user interface becomes hidden
When app goes in background or UI hide for a screen, releasing UI resources
at this time can significantly increase the system's capacity for cached
processes, which has a direct impact on the quality of the user experience.
To be notified when the user exits your UI, implement the onTrimMemory()
callback in your Activity classes. You should use this method to listen for the
TRIM_MEMORY_UI_HIDDEN level, which indicates your UI is now
hidden from view and you should free resources that only your UI uses.

Release memory when user interface becomes hidden
Add callback for onTrimMemory() callback in your activity. This is distinct
from the onStop() callback, which is called when an Activity instance
becomes hidden, which occurs even when the user moves to another activity
in your app.
We can use onStop() to release activity resources such as a network
connection or to unregister broadcast receivers, you usually should not release
your UI resources until you receive onTrimMemory
(TRIM_MEMORY_UI_HIDDEN).
This ensures that if the user navigates back from another activity in your app,
your UI resources are still available to resume the activity quickly.

Release memory as memory becomes tight
During any stage of your app's lifecycle, the onTrimMemory() callback also
tells you when the overall device memory is getting low. You should respond
by further releasing resources based on the following memory levels
delivered by onTrimMemory():
1. TRIM_MEMORY_RUNNING_MODERATE
2. TRIM_MEMORY_RUNNING_LOW
3. TRIM_MEMORY_RUNNING_CRITICAL
4. TRIM_MEMORY_BACKGROUND
5. TRIM_MEMORY_MODERATE
6. TRIM_MEMORY_COMPLETE

TRIM_MEMORY_RUNNING_MODERATE
Your app is running and not considered killable, but the device is running low
on memory and the system is actively killing processes in the LRU cache.
TRIM_MEMORY_RUNNING_LOW
Your app is running and not considered killable, but the device is running
much lower on memory so you should release unused resources to improve
system performance (which directly impacts your app's performance).
TRIM_MEMORY_RUNNING_CRITICAL
Your app is still running, but the system has already killed most of the
processes in the LRU cache, so you should release all non-critical resources
now.

TRIM_MEMORY_BACKGROUND
The system is running low on memory and your process is near the beginning
of the LRU list. Although your app process is not at a high risk of being
killed, the system may already be killing processes in the LRU cache.
TRIM_MEMORY_MODERATE
The system is running low on memory and your process is near the middle of
the LRU list. If the system becomes further constrained for memory, there's a
chance your process will be killed.
TRIM_MEMORY_COMPLETE
The system is running low on memory and your process is one of the first to
be killed if the system does not recover memory now. You should release
everything that's not critical to resuming your app state.

implements ComponentCallbacks2
public void onTrimMemory(int level) {
if (level >= TRIM_MEMORY_MODERATE) { // 60
mCache.evictAll();
} else if (level >= TRIM_MEMORY_BACKGROUND) { // 40
mCache.trimToSize(mCache.size() / 2);
}
}

Avoid wasting memory with Bitmaps
❖ When you load a bitmap, keep it in RAM only at the resolution you need
for the current device's screen.
❖ Scaling it down if the original bitmap is a higher resolution.
❖ Keep in mind that an increase in bitmap resolution results in a
corresponding (increase2) in memory needed, because both the X and Y
dimensions increase.

Performance Tips
There are two basic rules for writing efficient code:
● Don't do work that you don't need to do.
● Don't allocate memory if you can avoid it.

Performance Tips (Continued..)
● Avoid Creating Unnecessary Objects
● Use Static Final For Constants
● Avoid Internal Getters/Setters
● Use Enhanced For Loop Syntax
● Consider Package Instead of Private Access with Private Inner Classes
● Avoid Using Floating-Point
● Know and Use the Libraries
● Use Native Methods Carefully

Avoid Creating Unnecessary Objects
Object creation is never free.
As you allocate more objects in your app, you will force a periodic garbage
collection.
● If you have a method returning a string, and you know that its result will
always be appended to a StringBuffer anyway, change your signature and
implementation so that the function does the append directly, instead of
creating a short-lived temporary object.
● When extracting strings from a set of input data, try to return a substring of
the original data, instead of creating a copy.

Use Static Final for Constants
static int intVal = 42;
static String strVal = "Hello, world!";
static final int intVal = 42;
static final String strVal = "Hello, world!";
It's good practice to declare constants static final whenever possible.

Avoid Internal Getters/Setters
It's reasonable to follow common object-oriented programming practices and
have getters and setters in the public interface, but within a class you should
always access fields directly.
Without a JIT, direct field access is about 3x faster than invoking a trivial
getter. With the JIT (where direct field access is as cheap as accessing a
local), direct field access is about 7x faster than invoking a trivial getter.

Use Enhanced For Loop Syntax
int sum = 0;
for (int i = 0; i < mArray.length; ++i) {
sum += mArray[i];
}
int sum = 0;
int len = mArray.length;
for (int i = 0; i < len; ++i) {
sum += mArray[i];
}
int sum = 0;
for (int a : mArray) {
sum += a;
}

Avoid Using Floating-Point
As a rule of thumb, floating-point is about 2x slower than integer on Android-
powered devices.
In speed terms, there's no difference between float and double on the more
modern hardware.
Space-wise, double is 2x larger. As with desktop machines, assuming space
isn't an issue, you should prefer double to float.

Know and Use the Libraries
In addition to all the usual reasons to prefer library code over rolling your
own, bear in mind that the system is at liberty to replace calls to library
methods with hand-coded assembler, which may be better than the best code
the JIT can produce for the equivalent Java.
The typical example here is String.indexOf() and related APIs.
System.arraycopy() method is about 9x faster than a hand-coded loop on a
Nexus One with the JIT.

Improving Layout Performance
Layouts are a key part of Android applications that directly affect the user
experience. If implemented poorly, your layout can lead to a memory hungry
application with slow UIs. By optimizing your layouts you will be able to
implement smooth scrolling interfaces with a minimum memory footprint.
Below is the list of topics we will discuss.
❖ Optimizing Layout Hierarchies
❖ Re-using Layouts with <include/>
❖ Loading Views On Demand
❖ Making ListView Scrolling Smooth

Re-using Layouts with <include/>
Reusing layouts is particularly powerful as it allows you create reusable
complex layouts. For example, a yes/no button panel, or custom progress bar
with description text.
It also means that any elements of your application that are common across
multiple layouts can be extracted, managed separately, then included in each
layout.
So while you can create individual UI components by writing a custom View,
you can do it even more easily by re-using a layout file.
● Create a Re-usable Layout
● Use the <include> Tag
● Use the <merge> Tag

Create a Re-usable Layout
If you already know the layout that you want to re-use, create a new XML file
and define the layout. For example, here's a layout that defines a title bar to be
included in each activity (titlebar.xml):
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width=”match_parent”
android:layout_height="wrap_content"
android:background="@color/titlebar_bg">
<ImageView android:layout_width="wrap_content"
android:src="@drawable/gafricalogo" />
</FrameLayout>

Use the <include> Tag
Inside the layout to which you want to add the re-usable component, add the
<include/> tag. For example, here's a layout that includes the title bar from
above:
Here's the layout file:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_height=”match_parent”>
<include layout="@layout/titlebar"/>
<TextView android:layout_width=”match_parent”
android:text="@string/hello"
android:padding="10dp" />
</LinearLayout>

Use the <include> Tag (Continued..)
You can also override all the layout parameters (any android:layout_*
attributes) of the included layout's root view by specifying them in the
<include/> tag. For example:
<include android:id=”@+id/news_title”
android:layout_height=”match_parent”
layout=”@layout/title”/>
However, if you want to override layout attributes using the <include> tag,
you must override both android:layout_height and android:layout_width in
order for other layout attributes to take effect.

Use the <merge> Tag
The <merge /> tag helps eliminate redundant view groups in your view
hierarchy when including one layout within another.
For example, if your main layout is a vertical LinearLayout in which two
consecutive views can be re-used in multiple layouts, then the re-usable
layout in which you place the two views requires its own root view.
However, using another LinearLayout as the root for the re-usable layout
would result in a vertical LinearLayout inside a vertical LinearLayout.
The nested LinearLayout serves no real purpose other than to slow down your
UI performance.

Use the <merge> Tag (Continued..)
To avoid including such a redundant view group, you can instead use the
<merge> element as the root view for the re-usable layout.
For example:
<merge xmlns:android="http://schemas.android.com/apk/res/android">
<Button
android:layout_width="fill_parent"
android:text="@string/add"/>
<Button
android:text="@string/delete"/>
</merge>
Now, when you include this layout in another layout (using the <include/>
tag), the system ignores the <merge> element and places the two buttons
directly in the layout, in place of the <include/> tag.

Loading Views on Demand
Sometimes your layout might require complex views that are rarely used.
Whether they are item details, progress indicators, or undo messages, you can
reduce memory usage and speed up rendering by loading the views only when
they are needed.
● Define a ViewStub
● Load the ViewStub Layout

Define a ViewStub
ViewStub is a lightweight view with no dimension and doesn’t draw anything or participate in
the layout.
As such, it's cheap to inflate and cheap to leave in a view hierarchy. Each ViewStub simply needs
to include the android:layout attribute to specify the layout to inflate.
The following ViewStub is for a translucent progress bar overlay. It should be visible only when
new items are being imported into the application.
<ViewStub
android:id="@+id/stub_import"
android:inflatedId="@+id/panel_import"
android:layout="@layout/progress_overlay"
android:layout_gravity="bottom" />

Load the ViewStub Layout
When you want to load the layout specified by the ViewStub, either set it visible by calling
setVisibility(View.VISIBLE) or call inflate()
((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);
// or
View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();
The inflate() method returns the inflated View once complete. so you don't need to call
findViewById() if you need to interact with the layout.
Once visible/inflated, the ViewStub element is no longer part of the view hierarchy. It is replaced
by the inflated layout and the ID for the root view of that layout is the one specified by the
android:inflatedId attribute of the ViewStub. (The ID android:id specified for the ViewStub is
valid only until the ViewStub layout is visible/inflated.)
Note: One drawback of ViewStub is that it doesn’t currently support the <merge/> tag in the
layouts to be inflated.

Making ListView Scrolling Smooth
The key to a smoothly scrolling ListView is to keep the application’s main
thread (the UI thread) free from heavy processing. Ensure you do any disk
access, network access, or SQL access in a separate thread.
● Use a Background Thread
● Hold View Objects in a View Holder
● Avoid heavy operations
● Efficiently load bitmaps

Use a Background Thread
// Using an AsyncTask to load the slow images in a background thread
new AsyncTask<ViewHolder, Void, Bitmap>() {
private ViewHolder v;
@Override
protected Bitmap doInBackground(ViewHolder... params) {
v = params[0];
return mFakeImageLoader.getImage();
}
@Override
protected void onPostExecute(Bitmap result) {
super.onPostExecute(result);
if (v.position == position) {
// If this item hasn't been recycled already, hide the
// progress and set and show the image
v.progress.setVisibility(View.GONE);
v.icon.setVisibility(View.VISIBLE);
v.icon.setImageBitmap(result);
}
}
}.execute(holder);

Hold View Objects in a View Holder
static class ViewHolder {
TextView text;
TextView timestamp;
ImageView icon;
ProgressBar progress;
int position;
}
Then populate the ViewHolder and store it inside the layout.
ViewHolder holder = new ViewHolder();
holder.icon = (ImageView) convertView.findViewById(R.id.listitem_image);
holder.text = (TextView) convertView.findViewById(R.id.listitem_text);
holder.timestamp = (TextView) convertView.findViewById(R.id.listitem_timestamp);
holder.progress = (ProgressBar) convertView.findViewById(R.id.progress_spinner);
convertView.setTag(holder);
Now you can easily access each view without the need for the look-up, saving valuable processor
cycles.

Optimizing Battery Life

Optimizing Battery Life
For your app to be a good citizen, it should seek to limit its impact on the
battery life of its host device. By taking steps such as disabling background
service updates when you lose connectivity, or reducing the rate of such
updates when the battery level is low, you can ensure that the impact of your
app on battery life is minimized, without compromising the user experience.
❖ Monitoring the Battery Level and Charging State
❖ Determining and Monitoring the Docking State and Type
❖ Determining and Monitoring the Connectivity Status
❖ Manipulating Broadcast Receivers On Demand

Monitoring the Battery Level and Charging State
If you are requesting for updates or synchronizing your data then frequency of
your background task should be based on battery level and charging state of
the device.
❖ Determine the Current Charging State
➢ Monitor Changes in Charging State
■ ACTION_POWER_CONNECTED
■ ACTION_POWER_DISCONNECTED
➢ If charing
■ AC Charge ( Update after 5 mint)
■ USB Charger ( Update after 15 mint)
➢ If not connected
■ Update after 1 hour ( Still need optimization )

You may choose to reduce the rate of your background updates if the battery
charge is below a certain level.
❖ Determine the Current Battery Level
➢ Monitor Changes in Charging State
■ ACTION_BATTERY_LOW
■ ACTION_BATTERY_OKAY
➢ Or you may want to check current level
■ if battery level > 50 ( Update after 30 mint )
■ if battery level < 20 ( don’t update )

Generally speaking, the impact of constantly monitoring the battery level has
a greater impact on the battery than your app's normal behavior, so it's good
practice to only monitor significant changes in battery level—specifically
when the device enters or exits a low battery state.
It is generally good practice to disable all your background updates when the
battery is critically low. It doesn't matter how fresh your data is if the phone
turns itself off before you can make use of it.

Determining and Monitoring the Docking State and Type
Android devices can be docked into several different kinds of docks. These
include car or home docks and digital versus analog docks. The dock-state is
typically closely linked to the charging state as many docks provide power to
docked devices.
You may choose to increase the update
frequency of a sports center app when it's in
the desktop dock, or disable your updates
completely if the device is car docked.
Conversely, you may choose to maximize
your updates while car docked if your
background service is updating traffic
conditions.

Determining and Monitoring the Docking State and Type
❖ Determine the Current Docking State
➢ The dock state is also broadcast as a sticky Intent, allowing you to
query if the device is docked or not, and if so, in which kind of
dock.
❖ Determine the Current Dock Type
➢ Car
➢ Desk
➢ Low-End (Analog) Desk
➢ High-End (Digital) Desk
❖ Monitor for Changes in the Dock State or Type
➢ ACTION_DOCK_EVENT

Determining and Monitoring the Connectivity Status
Some of the most common uses for repeating alarms and background services
is to schedule regular updates of application data from Internet resources,
cache data, or execute long running downloads.
But if you aren't connected to the
Internet, or the connection is too slow
to complete your download, why both
waking the device to schedule the
update at all?

❖ Determine if You Have an Internet Connection
➢ There's no need to schedule an update based on an Internet
resource if you aren't connected to the Internet.
❖ Determine the Type of your Internet Connection
➢ Device connectivity can be provided by mobile data, WiMAX,
Wi-Fi, and ethernet connections.
➢ You can alter your refresh rate based on the bandwidth available.
➢ Update rate should be lower when on mobile connections. It cost
more to user.
➢ Downloads of significant size should be suspended until you have
a Wi-Fi connection.
❖ Monitor for Changes in the Dock State or Type
➢ CONNECTIVITY_CHANGE

Changes to a device's connectivity can be very frequent—this broadcast is
triggered every time you move between mobile data and Wi-Fi. As a result,
it's good practice to monitor this broadcast only when you've previously
suspended updates or downloads in order to resume them.
It's generally sufficient to simply
check for Internet connectivity
before beginning an update and,
should there be none, suspend
further updates until connectivity
is restored.

Manipulating Broadcast Receivers On Demand
When register a broadcast for specific side-effect of this approach is that your
app will wake the device each time any of these receivers is triggered—
potentially much more frequently than required.
A better approach is to disable or enable the broadcast receivers at runtime.
That way you can use the receivers you declared in the manifest as passive
alarms that are triggered by system events only when necessary.
Example: If you are requesting for update from network when device connect
to charger. Then you should disable this receiver when network is not
connected.

Manipulating Broadcast Receivers On Demand
ComponentName receiver = new ComponentName(context, myReceiver.
class);
PackageManager pm = context.getPackageManager();
pm.setComponentEnabledSetting(receiver,
PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
PackageManager.DONT_KILL_APP);
Using this technique, if you determine that connectivity has been lost, you can
disable all of your receivers except the connectivity-change receiver.
Conversely, once you are connected you can stop listening for connectivity
changes and simply check to see if you're online immediately before
performing an update and rescheduling a recurring update alarm.

Sending Operations to Multiple Threads
The speed and efficiency of a long-running, data-intensive operation often
improves when you split it into smaller operations running on multiple
threads. On a device that has a CPU with multiple processors (cores), the
system can run the threads in parallel, rather than making each sub-operation
wait for a chance to run.
For example, decoding multiple image files in order to display them on a
thumbnail screen runs substantially faster when you do each decode on a
separate thread.

Threads

Running a Thread
❖ In a Thread run() method use Process.setThreadPriority() with
THREAD_PRIORITY_BACKGROUND. This approach reduces resource
competition between the Runnable object's thread and the UI thread.
❖ If you don't set the thread to a lower priority this way, then the thread could
still slow down your app because it operates at the same priority as the UI
thread by default.
❖ Stores the current Thread reference in your app, so that you want to
interrupt the Thread later on. e.g On network failure you can cancel that
thread operation.

Manager for Multiple Threads

Manager for Multiple Threads
❖ To automatically run tasks as resources become available, or to allow
multiple tasks to run at the same time (or both), you need to provide a
managed collection of threads. To do this, use an instance of
ThreadPoolExecutor, which runs a task from a queue when a thread in its
pool becomes free. To run a task, all you have to do is add it to the queue.
➢ You can have a reference of threads. e.g get current thread refrance
■ mPhotoTask.setImageDecodeThread(Thread.currentThread());
➢ You may want to discard old threads when adding a new one.
➢ You can peorities your threads
➢ You can discard any or all the thread if require.

Communicating with the UI Thread
❖ Every app has its own special thread that runs UI objects such as View
objects; this thread is called the UI thread. Only objects running on the UI
thread have access to other objects on that thread. Because tasks that you
run on a thread from a thread pool aren't running on your UI thread, they
don't have access to UI objects.
❖ To move data from a background thread to the UI thread, use a Handler
that's running on the UI thread.

Communicating with the UI Thread
// Defines a Handler object that's attached to the UI thread
mHandler = new Handler(Looper.getMainLooper()) {
@Override
public void handleMessage(Message inputMessage) {
// Gets the image task from the incoming Message object.
PhotoTask photoTask = (PhotoTask) inputMessage.obj;
...
}

AlarmManager Repeating tasks
Alarms (based on the AlarmManager class) give you a way to perform time-
based operations outside the lifetime of your application. For example, you
could use an alarm to initiate a long-running operation, such as starting a
service once a day to download a weather forecast.
❖ They let you fire Intents at set times
and/or intervals.

AlarmManager Repeating tasks
❖ You can use them in conjunction with broadcast receivers to start services
and perform other operations.
❖ They operate outside of your application, so you can use them to trigger
events or actions even when your app is not running, and even if the device
itself is asleep.
❖ They help you to minimize your app's resource requirements. You can
schedule operations without relying on timers or continuously running
background services.

Choose an alarm type
❖ ELAPSED_REALTIME—Fires the pending intent based on the amount of
time since the device was booted, but doesn't wake up the device. The
elapsed time includes any time during which the device was asleep.
❖ ELAPSED_REALTIME_WAKEUP—Wakes up the device and fires the
pending intent after the specified length of time has elapsed since device
boot.
❖ RTC—Fires the pending intent at the specified time but does not wake up
the device.
❖ RTC_WAKEUP—Wakes up the device to fire the pending intent at the
specified time.

Example Code
private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.
ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);
alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
SystemClock.elapsedRealtime() +
60 * 1000, alarmIntent);

AlarmManager operations
❖ Cancel Alaram
// If the alarm has been set, cancel it.
if (alarmMgr!= null) {
alarmMgr.cancel(alarmIntent);
❖ Start an Alarm When the Device Boots
public class SampleBootReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
// Set the alarm here.
}

Keeping Your App Responsive
In Android, the system guards against applications that are insufficiently
responsive for a period of time by displaying a dialog that says your app has
stopped responding, such as the dialog in Figure.

What Triggers ANR?
In Android, application responsiveness is monitored by the Activity Manager
and Window Manager system services. Android will display the ANR dialog
when:
❖ No response to an input event (such as key press or screen touch events)
within 5 seconds.
➢ an application blocks on some I/O operation
➢ app is working some network task on UI thread
➢ app spends too much time building an elaborate in-memory structure
➢ app sepnd computing the next move in a game on the UI thread
❖ A BroadcastReceiver hasn't finished executing within 10 seconds.

How to Avoid ANRs
❖ On UI thread do as little work as possible.
❖ Process.setThreadPriority() else Thread will be equal to UI thread
❖ If your application is doing work in the background in response to user
input, show that progress is being made (such as with a ProgressBar in
your UI).
❖ For games specifically, do calculations for moves in a worker thread.
❖ Use performance tools such as Systrace and Traceview to determine
bottlenecks in your app's responsiveness.
❖ If your application has a time-consuming initial setup phase, consider
showing a splash screen or rendering the main view as quickly as possible,
indicate that loading is in progress and fill the information asynchronously.

Keeping the Device Awake
To avoid draining the battery, an Android device that is left idle quickly falls
asleep. However, there are times when an application needs to wake up the
screen or the CPU and keep it awake to complete some work.
The approach you take depends on the needs of your app. However, a general
rule of thumb is that you should use the most lightweight approach possible
for your app, to minimize your app's impact on system resources

Keep the Screen On
Certain apps need to keep the screen turned on, such as games or movie apps.
The best way to do this is to use the FLAG_KEEP_SCREEN_ON in your
activity (and only in an activity, never in a service or other app component)
❖ getWindow().addFlags(WindowManager.LayoutParams.
FLAG_KEEP_SCREEN_ON); in your activity onCreate
❖ android:keepScreenOn="true" in your layout
❖ It doesn't require special permission
❖ Platform correctly manages the user moving between applications
❖ You can use clearFlags(): to remove this

Keep the CPU On
If you need to keep the CPU running in order to complete some work before
the device goes to sleep, you can use a Power Manager system service feature
called wake locks.
Creating and holding wake locks can have a dramatic impact on the host
device's battery life. Thus you should use wake locks only when strictly
necessary and hold them for as short a time as possible.
❖ <uses-permission android:name="android.permission.WAKE_LOCK" />
❖ PowerManager powerManager = (PowerManager) getSystemService(POWER_SERVICE);
❖ Wakelock wakeLock = powerManager.newWakeLock(PowerManager.
PARTIAL_WAKE_LOCK,
❖ "MyWakelockTag");
❖ wakeLock.acquire();
❖ wakelock.release().

Tips For Layout
❖ Put margins , padding in values/dimens.xml file
❖ User Nine Patch Image
❖ Reuse images
❖ Avoid hardcode sizes
❖ <Include layouts>
❖ Name layout that can easily access in activity
❖ For multiple screens extract dynamic information from layout and only
change these information instead of repeating files
❖ Use JPG image if transparency is not required in image.
❖ Use layout_weight
❖ Use styles / Themes for you application instead of duplicating code

Best Practices

Tips For Bitmap
❖ Scale down bitmaps
❖ Try to create drawable via xml if possible
❖ Recycle bitmap after using
❖ User SoftReference for bitmaps
❖ Cache Bitmaps instead of download again or load again
❖ Track memory size and discard old bitmaps
❖ User Nine Patch Image

Tips For Activity / Fragments
❖ Create Base activity that cover all your common /repeating functionality
❖ Divide functionality into methods as much as possible
❖ Class must not be too long. Remember SOLID principles
❖ Apply design patterns wherever possible.
❖ DO NOT use meaningless variables
❖ private method can have long name but public method should have small
name
❖ Methods must focus on single task
❖ Method should throw exceptions instead of catch and do nothing
❖ Don’t catch all exceptions. Only catch exception where you have
alternative flow

Tips For Activity / Fragments
❖ Remove listeners , release bitmap when destroying activity
❖ Resolve dependency using state/strategy design patterns methods
❖ Use TAG for fragments and reload on demand
❖ Deal with interfaces instead of classes
❖ Write code as a library project
❖ Minimize code complexity by avoiding if else paths
❖ Deal with DB carefully to avoid open close issues

Questions

Thank You

Design Principles
Reference
• Best Practices for Performance
• Best Practices for Background Jobs
• Pure Android

Performance optimization for Android

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Performance optimization for Android

Ähnlich wie Performance optimization for Android (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Performance optimization for Android