App Startup States and issues

Users expect apps to be responsive and fast to launch

When you launch an app , it can take place in one of three states, each has some tasks to complete which takes time.if the time increases that is a problem, because users expect apps to launch fast.

so we will look at those states in detail and the issues slowing down launching.

The system process displays a blank screen until the app has finished rendering the activity

When you launch an app,launch can take place in one of three states namely cold start,warm start and hot start. Each affecting how long it takes for your app to become visible to the user.

Cold start

A Cold start refers to app starting from scratch (Systems process not yet created Apps process yet)

Cold start happens in cases where your app being launched for the first time

• since device booted.
• since system killed app process.

Cold start takes more time, compared to other two launching states

https://developer.android.com/topic/performance/images/cold-launch.png

First System process has three tasks to do:

• Loading and launching the app.
• Displaying a blank window for the app immediately after launch.
• Creating app process.

After System create app process, app process is responsible for next stages

These stages are :

• Creating app object
• Launching main thread.
• Creating the main activity.
• Inflating views.
• Laying out the screen.
• Performing first draw.

After app process completing first draw,the system process replaces the currently displayed blank window, replacing it with the main activity. At this point, the user can start using the app.

Hot start

In this state, system brings activity to foreground.If all application’s activities are still present in memory, then the app can avoid having to repeat object initialization, layout inflation, and rendering.so this is much simpler and lower-overhead than cold start.

If app objects removed from memory in response to memory trimming events, then all objects need to be recreated in response to the hot start event.

Warm start

A warm start encompasses some subset of the operations that take place during a cold start.

There are many potential states that could be considered warm starts. For instance:

• User backs out of your app,but then re-launches it, then recreation of activity will be done by calling onCreate() of main activity again.
• System removes app from memory, but your re-launches it, this time process and app both have to be restarted. bu this time task can be befit somewhat from the saved instance state bundle passed into onCreate()

warm start represents less overhead than a hot start

Android vitals considers your app’s startup times excessive when the app’s:

• Cold startup takes 5 seconds or longer.
• Warm startup takes 2 seconds or longer.
• Hot startup takes 1.5 seconds or longer.

issues that often affect apps’ startup performance

• Heavy app initialization
• Heavy activity initialization
• Themed launch screens

Heavy app initialization

There is a problem if your code overrides Applications onCreate() and executing heavy work in it.Your app may waste time during startup if your Application sub classes perform initialization that don’t need to be done yet.

Solutions to the problem

Initializing only those objects that are immediately needed.For example, rather than creating global static objects, instead, move to a singleton pattern.

Heavy activity initialization

Activity creation often entails a lot of high-overhead work. Often, there are opportunities to optimize this work to achieve performance improvements. Such common issues include:

• Inflating large or complex layouts.
• Blocking screen drawing on disk, or network I/O.
• Loading and decoding bitmaps.
• Rasterizing VectorDrawable objects.
• Initialization of other subsystems of the activity.

Solutions to the problem

There are many potential bottlenecks, but two common problems and remedies are as follows:

• The larger your view hierarchy, the more time the app takes to inflate it. So flatten your hierarchy by removing redundant and nested layouts and Not inflating parts of the UI that do not need to be visible during launch. Instead, use use a ViewStub object as a placeholder for sub-hierarchies that the app can inflate at a more appropriate time.
• Having all of your resource initialization on the main thread can also slow down startup. So move all resource initialization so that the app can perform it on a different thread and first load and display views, later update visual properties which are dependent on bitmaps and other resources.

Themed launch screens

You may wish to theme your app’s loading experience,Doing so can hide a slow activity launch.

A common way to implement a themed launch screen is to use thewindowDisablePreviewtheme attribute to turn off the initial blank screen that the system process draws when launching the app. It forces the user to wait with no feedback while the activity launches, making them wonder if the app is functioning properly.

Solutions to the problem

Rather than disabling the preview window, You can use the activity’s windowBackground theme attribute to provide a simple custom drawable for the starting activity.

Example is : https://www.bignerdranch.com/blog/splash-screens-the-right-way/

Summarized vesion of : https://developer.android.com/topic/performance/vitals/launch-time