Activity lifecycle methods (onCreate, onStart, onResume, onPause, onStop, onDestroy) in Android Kotlin - Build, Publish & Deploy

Build & Publish - Activity lifecycle methods (onCreate, onStart, onResume, onPause, onStop, onDestroy)

Performance Impact of Activity Lifecycle Methods

Activity lifecycle methods control how your app behaves as users open, leave, or return to screens. Efficient use ensures smooth transitions and good battery life.

• onCreate: Called once when activity starts. Heavy work here can delay screen display, causing jank.
• onStart/onResume: Prepare UI and resources. Slow code here can reduce frame rate below 60fps, causing lag.
• onPause/onStop: Release resources to save memory and battery.
• onDestroy: Cleanup to avoid memory leaks.

Proper lifecycle management helps maintain 60fps frame rate and keeps memory use under device limits (~1.5GB on iOS, varies on Android).

💻

How to Optimize Activity Lifecycle Methods for Smooth 60fps

• Keep onCreate lightweight: load only essential UI and defer heavy tasks using background threads or coroutines.
• Use onStart and onResume for quick UI updates, avoid blocking calls.
• Release or pause animations, sensors, or GPS in onPause or onStop to save battery.
• Avoid memory leaks by nullifying references in onDestroy.
• Use profiling tools (Android Profiler) to check CPU and memory during lifecycle transitions.

Impact on App Bundle Size and Startup Time

Lifecycle methods themselves do not add to app size, but what you do inside them affects startup time and memory use.

• Heavy initialization in onCreate can increase startup time, making app feel slow.
• Loading large resources (images, databases) here increases memory use and can cause slow UI rendering.
• Deferring non-essential work improves perceived startup speed.

iOS vs Android Differences for Activity Lifecycle

Android uses explicit lifecycle methods like onCreate, onStart, onResume, etc. iOS uses different patterns:

• iOS UIViewController lifecycle methods include viewDidLoad, viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisappear.
• Android lifecycle is more granular and mandatory to handle for resource management.
• iOS apps rely on system to manage memory aggressively; Android requires explicit release in lifecycle callbacks.
• App store review times differ: iOS reviews take 24-48 hours, Android can be faster.

Relevant Store Review Guidelines and Requirements

• Google Play: Ensure your app handles lifecycle properly to avoid crashes or freezes, which can cause rejection.
• Battery Usage: Apps must not drain battery excessively; releasing resources in onPause and onStop helps comply.
• Privacy: If lifecycle methods access sensors or location, request permissions properly and explain usage.
• Performance: Apps that freeze or lag during lifecycle transitions may be flagged.

Self-Check: Your App Takes 5 Seconds to Load This Screen. What's Likely Wrong?

Common issues include:

• Heavy work done synchronously in onCreate, blocking UI thread.
• Loading large images or databases without background threads.
• Not releasing resources in onPause or onStop, causing memory pressure.
• Excessive logging or network calls during lifecycle methods.

Fix by moving heavy tasks off the main thread and optimizing resource management.

Key Result

Efficient use of Android activity lifecycle methods ensures smooth 60fps UI, optimal memory use, and faster startup times, which are critical for passing app store reviews and providing a good user experience.

Practice

1. Which lifecycle method is called first when an Android activity is launched?
onCreate(), onStart(), onResume(), or onPause()?

easy

A. onStart()

B. onResume()

C. onCreate()

D. onPause()

Solution

1. Step 1: Understand activity launch sequence

   When an activity starts, onCreate() is the first method called to set up the UI and initialize components.

2. Step 2: Confirm order of lifecycle methods

   After onCreate(), onStart() and onResume() follow, but they are not first.

3. Final Answer:

   onCreate() -> Option C

4. Quick Check:

   First lifecycle method = onCreate() [OK]

Hint: Remember: onCreate() is always first when activity starts [OK]

Common Mistakes:

• Confusing onStart() as the first method
• Thinking onResume() is called before onCreate()
• Assuming onPause() is called on launch

2. Which of the following is the correct Kotlin syntax to override the onPause() method in an Android activity?

easy

A. override fun onPause() {
pause.super()
}

B. fun onPause() {
super.onPause()
}

C. override onPause() {
super.onPause()
}

D. override fun onPause() {
super.onPause()
}

Solution

1. Step 1: Check Kotlin override syntax

   In Kotlin, to override a method, use override fun methodName() and call super.methodName() inside.

2. Step 2: Validate each option

   override fun onPause() { super.onPause() } correctly uses override fun onPause() and calls super.onPause(). Others miss override keyword, have wrong syntax, or wrong super call.

3. Final Answer:

   override fun onPause() { super.onPause() } -> Option D

4. Quick Check:

   Correct override syntax = override fun onPause() { super.onPause() } [OK]

Hint: Always use 'override fun method()' and call 'super.method()' inside [OK]

Common Mistakes:

• Omitting the override keyword
• Calling super incorrectly
• Wrong function declaration syntax

3. Consider this Kotlin code snippet inside an activity:

override fun onPause() {
    super.onPause()
    println("Paused")
}
override fun onStop() {
    super.onStop()
    println("Stopped")
}

What will be printed if the user presses the home button while the activity is visible?

medium

A. Stopped
Paused

B. Paused
Stopped

C. Paused

D. Stopped

Solution

1. Step 1: Understand lifecycle on home press

   Pressing home triggers onPause() first, then onStop() as activity goes to background.

2. Step 2: Check print order

   Since onPause() runs before onStop(), "Paused" prints first, then "Stopped".

3. Final Answer:

   Paused Stopped -> Option B

4. Quick Check:

   onPause() then onStop() prints = Paused, Stopped [OK]

Hint: onPause() always runs before onStop() when leaving activity [OK]

Common Mistakes:

• Assuming onStop() runs before onPause()
• Thinking only one method runs on home press
• Confusing print order

4. This code snippet is intended to save data when the activity is paused:

override fun onPause() {
    saveData()
}

What is the main problem with this code?

medium

A. Missing call to super.onPause()

B. saveData() should be called in onStop() instead

C. onPause() cannot be overridden

D. saveData() must be asynchronous

Solution

1. Step 1: Check lifecycle method override rules

   When overriding lifecycle methods, always call super.method() to keep system stable.

2. Step 2: Identify missing super call

   The code lacks super.onPause(), which can cause unexpected behavior.

3. Final Answer:

   Missing call to super.onPause() -> Option A

4. Quick Check:

   Always call super in lifecycle overrides [OK]

Hint: Never forget super.onPause() when overriding onPause() [OK]

Common Mistakes:

• Forgetting to call super method
• Thinking onPause() can't be overridden
• Assuming saveData() timing is wrong

5. You want to release a camera resource when the activity is no longer visible to save battery. Which lifecycle method is the best place to release the camera?
A) onDestroy()
B) onStop()
C) onPause()
D) onResume()

hard

A. onPause()

B. onStop()

C. onDestroy()

D. onResume()

Solution

1. Step 1: Understand visibility and resource management

   When activity is partially or fully hidden, onPause() is called first, signaling to release resources like camera to save battery.

2. Step 2: Compare lifecycle methods for releasing resources

   onStop() is later, but releasing in onPause() ensures resources are freed as soon as activity is not in foreground. onDestroy() may never be called if system kills process. onResume() is for acquiring resources.

3. Final Answer:

   onPause() -> Option A

4. Quick Check:

   Release resources in onPause() to save battery [OK]

Hint: Release heavy resources in onPause(), reacquire in onResume() [OK]

Common Mistakes:

• Waiting until onStop() or onDestroy() to release resources
• Releasing resources in onResume() by mistake
• Not releasing resources early enough