0% found this document useful (0 votes)
10 views47 pages

Android Vitals: Managing Wake Locks

Uploaded by

muneebfunsol
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views47 pages

Android Vitals: Managing Wake Locks

Uploaded by

muneebfunsol
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Application

Performance
Optimization
Enhancing efficiency, responsiveness, and
resource utilization.
What are Android Vitals?
Android Vitals is an initiative by google to improve
the technical quality of google play apps on
android devices.

● Stability
● Start up and loading times
● Rendering
● Battery
● Permissions
Android Vitals

Stability
● User-perceived ANR rate
● ANR rate
● Multiple ANR rate
● User-perceived crash rate ● Stability
● Start up loading
● Crash rate times
● Multiple crash rate ● Rendering
● Battery
● Permissions
1. User-Perceived ANR rate 2. ANR Rate
The Percentage of daily active users who The Percentage of daily active users who
experienced at least one user-perceived ANR experienced at least one ANR.

➔ User - Perceived ANR ➔ Behavior


An ANR that is likely to have been Does not require the app to be on
noticed by the user. foreground.

➔ ANR Type ➔ ANR Type


Currently only “Input dispatching time All ANR types are counted including
out” ANRs are counted. receiver and service ANRs

➔ Overall Bad Behavior Threshold ➔ Per-Device Bad Behavior


0.47% Threshold
8%
3. Multiple ANR Rate 4. User-Perceived Crash Rate
The Percentage of daily active users who The Percentage of daily active users who
experienced at least two ANRs experienced at least one User-Perceived
Crash.
➔ ANR Type
All ANR types are counted including ➔ User-Perceived Crash
receiver and service ANRs A crash that is likely to be noticed by
the user.
➔ Overall Bad Behavior Threshold
0.47% ➔ Detection
Displaying an activity or executing
➔ Per-Device Bad Behavior foreground service.
Threshold
8% ➔ Bad Behavior Threshold
1.09% , 8% (Per - Device)
5. Crash Rate 6. Multiple Crash Rate
The Percentage of daily active users who The Percentage of daily active users who
experienced at least one Crash. experienced at least two crashes.

➔ Behavior ➔ Behavior
Does not require app to be on Does not require app to be on
foreground. foreground.

➔ Crash Type ➔ Crash Type


All Crashes included All Crashes included

➔ Bad Behavior Threshold ➔ Bad Behavior Threshold


1.09% , 8% (Pre - Device) 1.09% , 8% (Pre - Device)
Important!
User perceived ANR rates and Crash Rates are
core Vitals that directly affect the discoverability
of your app on Google Play.

It is important because the crashes and ANRs


being counted always occur when user is engaged
with the app causing the most disruption.
App Startup
Time
The duration an application takes to become
fully responsive and operational after it is
launched
● Stability
● Start up loading
times
● Rendering
● Battery
● Permissions
Purpose statement
Cold Start
A cold start happens when the application process needs to be created from scratch. This
usually occurs when the app is launched for the first time after the device has been powered
off or restarted.

Warm Start
A warm start occurs when the application process is already running in the background, and
the app is launched again. This could happen when the user navigates away from the app and
then returns to it, or when the app is launched shortly after it was closed

Hot Start
A hot start, also known as a fast app resume, happens when the application process is
already running in the foreground, and the app is brought back to the foreground again.
Startup Time Constraints
Cold startup should not exceed

5 seconds

Warm startup should not exceed

2 seconds

Hot startup should not exceed

1.5 seconds
Startup Time Metrics
Time to Initial Display (TTID)
Time to initial display (TTID) is the time it takes to display the first frame of the app's UI
● Launching the process.
● Initializing the objects.
● Creating and initializing the activity.
● Inflating the layout.
● Drawing the app for the first time.
● Developers can retrieve their app’s TTID by filtering their logcat for “Displayed”

Time to Full Display (TTFD)


Time to full display (TTFD) is the time it takes for an app to become interactive for the user.
Developer can call reportFullyDrawn() method in their activities to retrieve TTFD.
Slow Start Up Causes ➔ Loading and Decoding Bitmaps
➔ CMP and Remote Config Bitmap processes are always very
Stopping initial fragment to draw layout intensive of cpu and memory. Running
until CMP or Remote config is fetched them on start up can cause significant
decrease in performance.
➔ Heavy Application Class
Running heavy tasks in Application ➔ Initialization of other
class. sub-systems of activity
Running processes before onCreate or
➔ Inflating large and complex onCreateView causes significant
layouts decrease in performance

➔ Blocking Screen Drawing on Disk ◆ Example: Applying Locale before


or Network IO calling setContentView()
Tips and Solutions
Larger View Hierarchies cause longer inflation times

○ Abstain from using nested layouts.


○ Use ViewStubs
○ Move resource initializations to lazy and different thread
○ Let the application load it’s views and not make them dependent on IO
Custom Splash Screens
○ Opting for vector animations rather than lottie animations for splash
Android Vitals

Rendering
● Excessive Slow Frames
● Excess frozen Frames
● Stability
● Start up loading
times
● Rendering
● Battery
● Permissions
Excessive Slow Frames Excessive Frozen Frames

The percentage of daily sessions in The percentage of daily sessions in


which more that 50% of the frames which more than 0.1% of the frames
were slow. A frame is considered slow had a frame time of longer than 700
if it missed the device’s drawing ms.
deadline.
What is OverDraw?
OverDraw refers to the system’s drawing a pixel
on the screen multiple times in a Single Frame of
Rendering.

● Painter’s Algorithm, Back to Front Order


Detect OverDraw
1. Open your device, go to Settings and tap on Developer
Options
2. Scroll down to Hardware accelerated rendering section and
select Debug GPU Overdraw
3. In the Debug GPU overdraw dialog, select Show overdraw
areas
UI
Optimization
UI optimization streamlines user interface
elements for seamless interaction.
Improve UI Techniques
● Minimize View Hierarchy ● Remove unnecessary backgrounds
● Use ConstraintLayout From layouts
● Optimize Image Loading ● Don’t use opacity in views
● Implement RecyclerView
● Use ViewStub for Deferred Loading
● Optimize Text Rendering
● Enable Hardware Acceleration
● Profile UI Performance
● Optimize Animation Performance
Tips and Solutions to Reduce Overdraw
Remove Unnecessary backgrounds from layouts

○ Giving backgrounds to layouts even colors causes them to render and might contribute
to overdraw.
○ Use Smart approaches to developing UIs and reduce overdraw.
○ Inefficient usage of include, use <merge> and ViewStubs
Flatten View Hierarchy
○ Using Constraint Layouts can help with least taxation.
Reduce Transparency
○ Alpha Values.
Go For Jetpack Compose
Power
Consumptions
Enhancing battery life and user experience
Android Vitals

Battery
● Excessive WakeUps
● Stuck Partial wake locks
● Excessive background Wifi scans ● Stability
● Start up loading
● Excessive background network times
● Rendering
usage ● Battery
● Permissions
1. Excessive Wake Ups 2. Stuck Partial Wake Locks
The Percentage of sessions in which your app
averaged more than 10 wake ups per hour.
➔ Wakeups The Percentage of sessions in which your app
When ELAPSED_REALTIME_WAKEUP had 1 or more partial wake locks lasting 1 hour.
flag is called
➔ Scenarios
➔ Data Collection Streaming Music.
When the device is not being charged
➔ Data Collection
➔ FCM, Volley and Local Alarms When the device is not being charged
included
4. Excessive background network
3. Excessive Background Wifi Scans usage

The Percentage of sessions in which your app


The Percentage of sessions in which your app
used more than 50 mb of network data per
averages more that 4 wifi scans per hour
day.
while running in the background.

Data Collections Data Collections


When the device is not being charged and
When the device is not being charged
app is running in background

Scenarios
Work Managers, services and widgets
Save Power Efficiently
● Reduce background activities
● Reduce sensor polling
● Networking calling optimization
● Doze mode
● Best selection of resources for Background tasks (Services,
Workmanagers, Alarm Managers, etc)
Android Vitals

Permissions
● Permission Denials

● Stability
● Start up loading
times
● Rendering
● Battery
● Permissions
2. Permission Denials
The percentage of daily permission sessions
in which the user denied your app at least 1
permission it requested.
➔ Multiple Decisions
If a user takes multiple decisions for the
same permission in the same session,
then the user’s final decision is
recorded.

➔ Tips
Make sure to clearly explain the reason
for any permission requests in you app
02

Coroutine
Consumption
Improves app performance by managing
asynchronous tasks effectively.
Optimal Scope Selection
● Lifecyclescope
● Viewmodelscope
● Coroutinescope
● Globalscope

Optimal Dispatcher Selection


● IO (Network / IO Operations)
● Main (UI Related Tasks)
● Default (Suitable for CPU-bound tasks that are not specifically IO-bound or UI-related)
Coroutine Lifecycle Handling
● Job Lifecycle
● Cancellation
● Structured Concurrency
● Optimised Context switching

Coroutine Builder Selection


● Launch (Fire and Forget)
● Async (Deferred resulting)
Memory
Usage
Efficient memory allocation boosts app
performance.
Optimal Memory Usage
● Releasing unused objects/resources
● Proper Object Caching
● Avoid memory leaks (Use LeakCanary or Android profiler to detect
any memory leak )
● Avoid using companions and singletons unnecessarily
● Wisely use ViewModel and SharedViewModel
● Caching Strategies
Network
Requesting
Optimizing network requests for faster data
transfer and smoother app.
Best Requesting Processes
● Use of caching mechanisms ● Using efficient network libraries
● Batching requests ● Reducing unnecessary
● Reducing payload size requests
● Implementing pagination ● Monitoring and profiling
● Using HTTP caching headers ● Proper use of timeouts
● Optimizing image loading
Crashes &
ANR’s
Preventing Crashes and ANR’s to make the app
smoother and more reliable.
Removes Crashes & ANR’s
● Error Handling and Logging
● Crash Reporting and Monitoring
● Memory Management (Avoid OutOfMemoryErrors or memory leaks)
● Network Error Handling (Connectivity, exceptions, timeouts, retrying)
● Async approach on long-running tasks
● Optimize Database Operations
● Continuous Testing and QA
● StrictMode for Debugging
User Action
Delay
Reducing user action delay through meticulous
optimization techniques.
Improving User’s Performance
● UI Thread Optimization
● Minimize Blocking Operations
● Lazy Loading and Prefetching on the basis of app requirements
● Async programming paradigm
● UI Component Recycling
● Optimized Input Handling
CPU
Usage
Efficient management of CPU resources
is pivotal for enhancing app.
CPU Usage Optimization
● Algorithm Efficiency
● Optimized Data Structures
● Asynchronous Processing
● Parallel Processing
● Optimized Libraries and APIs
● Loops Breaking & proper use of return statements
● Continuous Optimization
Use Use
Case 1 Case 2
Use Case 1
Use Case 2
Use Case 1
Use Case 2
Thanks!

You might also like