Chasing Performance Issues Methodically

Solving performance problems at scale has always been tricky. There is a lot of confusion on how to address those problems in android. In this talk, we will try to understand the nature of the performance problems, how to select tooling for these issues, and also try to make a generic approach that could apply to most of the problems.

Transcript

1. Chasing Performance Issues Methodically @droid_singh @amanjeetsingh150 Amanjeet Singh
2. What is Performance?
3. What is Performance? Story 📘
4. What is Performance? Story 📘
5. What is Performance? Story 📘
6. What is Performance? Story 📘
7. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase
8. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries
9. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates
10. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton ❤
11. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤
12. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤
13. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤
14. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤ Pattern 2: We get to know from customer tickets or Android Vitals
15. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤ Pattern 2: We get to know from customer tickets or Android Vitals
16. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤ Pattern 2: We get to know from customer tickets or Android Vitals Pattern 3: Prioritising performance issues 
 with other feature work is an issue
17. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤ Pattern 2: We get to know from customer tickets or Android Vitals Pattern 3: Prioritising performance issues 
 with other feature work is an issue • How are performance issues linked with business?
18. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤ Pattern 2: We get to know from customer tickets or Android Vitals Pattern 3: Prioritising performance issues 
 with other feature work is an issue • How are performance issues linked with business? • Time for solving one performance issue?
19. What is Performance? Story 📘 Pattern 1: Scalable ≠ High Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton • Selecting configs according to only business metrics ❤ Pattern 2: We get to know from customer tickets or Android Vitals Pattern 3: Prioritising performance issues 
 with other feature work is an issue • How are performance issues linked with business? • Time for solving one performance issue? 🤷
20. Platform Team of Company X
21. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold Start
22. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold Start •Draft I •Uplifting the app quality of X consumer app (O)
23. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold Start •Draft I •Uplifting the app quality of X consumer app (O) •Key Results I: Reduce cold start by 60% •Key Results II: Reduce wake locks by 30% •Key Results III: Reduce frame drops by 50%
24. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold Start •Draft I •Uplifting the app quality of X consumer app (O) •Key Results I: Reduce cold start by 60% •Key Results II: Reduce wake locks by 30% •Key Results III: Reduce frame drops by 50%
25. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold Start •Draft I •Uplifting the app quality of X consumer app (O) •Key Results I: Reduce cold start by 60% •Key Results II: Reduce wake locks by 30% •Key Results III: Reduce frame drops by 50% •No observability
26. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold Start •Draft I •Uplifting the app quality of X consumer app (O) •Key Results I: Reduce cold start by 60% •Key Results II: Reduce wake locks by 30% •Key Results III: Reduce frame drops by 50% •No observability •No quality gate
27. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold Start •Draft I •Uplifting the app quality of X consumer app (O) •Key Results I: Reduce cold start by 60% •Key Results II: Reduce wake locks by 30% •Key Results III: Reduce frame drops by 50% 😖 •No observability •No quality gate •Every fix might not have affect to gain performance
28. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold Start •Draft I •Uplifting the app quality of X consumer app (O) •Key Results I: Reduce cold start by 60% •Key Results II: Reduce wake locks by 30% •Key Results III: Reduce frame drops by 50% Pattern 4: Drafting OKRs for platform teams is difficult •No observability •No quality gate •Every fix might not have affect to gain performance 😖
29. First few Attempts to fix cold start ⏰
30. First few Attempts to fix cold start ⏰ 1. Looking online for blogs "Reducing cold starts at an X 
 company by 80%"
31. First few Attempts to fix cold start ⏰ 1. Looking online for blogs "Reducing cold starts at an X 
 company by 80%" 2. Playing with tools like profilers locally to identify 
 bottlenecks on app start and fix them
32. First few Attempts to fix cold start ⏰ 1. Looking online for blogs "Reducing cold starts at an X 
 company by 80%" 2. Playing with tools like profilers locally to identify 
 bottlenecks on app start and fix them 3. Randomly change something according to experience
33. First few Attempts to fix cold start ⏰ 1. Looking online for blogs "Reducing cold starts at an X 
 company by 80%" 2. Playing with tools like profilers locally to identify 
 bottlenecks on app start and fix them 3. Randomly change something according to experience 🚀
34. First few Attempts to fix cold start ⏰ 1. Looking online for blogs "Reducing cold starts at an X 
 company by 80%" 2. Playing with tools like profilers locally to identify 
 bottlenecks on app start and fix them 3. Randomly change something according to experience Theoretically ✅ 🚀
35. First few Attempts to fix cold start ⏰ 1. Looking online for blogs "Reducing cold starts at an X 
 company by 80%" 2. Playing with tools like profilers locally to identify 
 bottlenecks on app start and fix them 3. Randomly change something according to experience Theoretically ✅ ❌ 🚀
36. First few Attempts to fix cold start ⏰ Anti Methodology for Performance Analysis
37. First few Attempts to fix cold start ⏰ Anti Methodology for Performance Analysis • Blame-Someone-Else Anti-Method
38. First few Attempts to fix cold start ⏰ Anti Methodology for Performance Analysis • Blame-Someone-Else Anti-Method • Street light anti-method
39. First few Attempts to fix cold start ⏰ Anti Methodology for Performance Analysis • Blame-Someone-Else Anti-Method • Street light anti-method • Random Change Anti-Method
40. What are we 
 doing wrong?
41. What are we 
 doing wrong? • Are we chasing the right metric for cold start?
42. What are we 
 doing wrong? • Are we chasing the right metric for cold start? • Is there any missing case for cold start we are not 
 considering?
43. What are we 
 doing wrong? • Are we chasing the right metric for cold start? • Is there any missing case for cold start we are not 
 considering? • Maybe there were improvements but were neutralised 
 by changes made by other developers 🤔 

44. Sit back and Strategize! 🤔
45. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability
46. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch
47. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch • Different spans for app launch
48. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch • Different spans for app launch • Google Content 
 Provider First 
 Screen 
 Drawn
49. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch • Different spans for app launch • Google • User experienced Content 
 Provider First 
 Screen 
 Drawn onCreate 
 end onStart
50. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch • Different spans for app launch • Google • User experienced • Send app launch events and following attributes:
51. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch • Different spans for app launch • Google • User experienced • Send app launch events and following attributes: • First screen name
52. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch • Different spans for app launch • Google • User experienced • Send app launch events and following attributes: • First screen name • Total time
53. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch • Different spans for app launch • Google • User experienced • Send app launch events and following attributes: • First screen name • Total time • User ID
54. Sit back and Strategize! 🤔 Step 1: Identify proper metrics and create observability • Cold Start App Launch • Different spans for app launch • Google • User experienced • Send app launch events and following attributes: • First screen name • Total time • User ID • Tools selection: Firebase analytics
55. Sit back and Strategize! 🤔 // Start AppLaunchTracker.startTracking()
56. Sit back and Strategize! 🤔 // Start AppLaunchTracker.startTracking() // End AppLaunchTracker.stopTracking(firstScreenName) 
 

57. Sit back and Strategize! 🤔 // Start AppLaunchTracker.startTracking() // End AppLaunchTracker.stopTracking(firstScreenName) 
 
 // Track event Bundle bundle = new Bundle(); bundle.putString(FirebaseAnalytics.Param.USER_ID, id); bundle.putString( 
 FirebaseAnalytics.Param.FIRST_SCREEN_DRAWN, firstScreenName 
 ); bundle.putString(FirebaseAnalytics.Param.TOTAL_DURATION, totalTime); 

58. Sit back and Strategize! 🤔 // Start AppLaunchTracker.startTracking() // End AppLaunchTracker.stopTracking(firstScreenName) 
 
 // Track event Bundle bundle = new Bundle(); bundle.putString(FirebaseAnalytics.Param.USER_ID, id); bundle.putString( 
 FirebaseAnalytics.Param.FIRST_SCREEN_DRAWN, firstScreenName 
 ); bundle.putString(FirebaseAnalytics.Param.TOTAL_DURATION, totalTime); 

59. Sit back and Strategize! 🤔 // Start AppLaunchTracker.startTracking() // End AppLaunchTracker.stopTracking(firstScreenName) 
 
 // Track event Bundle bundle = new Bundle(); bundle.putString(FirebaseAnalytics.Param.USER_ID, id); bundle.putString( 
 FirebaseAnalytics.Param.FIRST_SCREEN_DRAWN, firstScreenName 
 ); bundle.putString(FirebaseAnalytics.Param.TOTAL_DURATION, totalTime); val firebaseAnalytics = FirebaseAnalytics.getInstance(this) firebaseAnalytics.logEvent(FirebaseAnalytics.Event.APP_LAUNCH, bundle) 

60. Sit back and Strategize! 🤔 // Start AppLaunchTracker.startTracking() // End AppLaunchTracker.stopTracking(firstScreenName) 
 
 // Track event Bundle bundle = new Bundle(); bundle.putString(FirebaseAnalytics.Param.USER_ID, id); bundle.putString( 
 FirebaseAnalytics.Param.FIRST_SCREEN_DRAWN, firstScreenName 
 ); bundle.putString(FirebaseAnalytics.Param.TOTAL_DURATION, totalTime); val firebaseAnalytics = FirebaseAnalytics.getInstance(this) firebaseAnalytics.logEvent(FirebaseAnalytics.Event.APP_LAUNCH, bundle) 

61. Sit back and Strategize! 🤔 // Start AppLaunchTracker.startTracking() // End AppLaunchTracker.stopTracking(firstScreenName) 
 
 // Track event Bundle bundle = new Bundle(); bundle.putString(FirebaseAnalytics.Param.USER_ID, id); bundle.putString( 
 FirebaseAnalytics.Param.FIRST_SCREEN_DRAWN, firstScreenName 
 ); bundle.putString(FirebaseAnalytics.Param.TOTAL_DURATION, totalTime); val firebaseAnalytics = FirebaseAnalytics.getInstance(this) firebaseAnalytics.logEvent(FirebaseAnalytics.Event.APP_LAUNCH, bundle) 
 Query data and create intelligence ✅
62. Tracker
63. Tracker
64. Tracker Attributes for app launch ✅
65. Tracker Attributes for app launch ✅ Insights from data: ✅
66. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only contributor 
 to first_screen_drawn 0 25 50 75 100 Survey Screen Splash Home Screen First screen names Percentage 
 distribution 
 of app launch
67. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only contributor 
 to first_screen_drawn • App Icon click is not only trigger 0 25 50 75 100 Survey Screen Splash Home Screen First screen names Percentage 
 distribution 
 of app launch
68. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only contributor 
 to first_screen_drawn • App Icon click is not only trigger • Campaigns 0 25 50 75 100 Survey Screen Splash Home Screen Percentage 
 distribution 
 of app launch First screen names
69. Sit back and Strategize! 🤔 Step 2:
70. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline
71. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline?
72. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs
73. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs • Ideal tool for this:
74. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs • Ideal tool for this: • Surface tentative regressions
75. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs • Ideal tool for this: • Surface tentative regressions • Detecting outliers and noise
76. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs • Ideal tool for this: • Surface tentative regressions • Detecting outliers and noise • Surface regressions mapping developers and teams
77. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs • Ideal tool for this: • Surface tentative regressions • Detecting outliers and noise • Surface regressions mapping developers and teams • Infra to run the tests
78. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs • Ideal tool for this: • Observability on tentative regressions • Detecting outliers and noise • Surface regressions mapping developers and teams • Infra to run the tests
79. Sit back and Strategize! 🤔 Common factors of noise and outliers • Network
80. Sit back and Strategize! 🤔 Common factors of noise and outliers • Network 🎹 Orchestration of test with mitm
81. Sit back and Strategize! 🤔 Common factors of noise and outliers • Network • Remote Configuration /data/data/com.app.id/files/frc_<mobile-sdk-id>_firebase_activate.json
82. Sit back and Strategize! 🤔 Common factors of noise and outliers • Network • Remote Configuration • Debug Builds
83. Sit back and Strategize! 🤔 Why not debug builds?
84. Sit back and Strategize! 🤔 Why not debug builds? • Account for Progaurd and Dexguard effects
85. Sit back and Strategize! 🤔 Why not debug builds? • Account for Progaurd and Dexguard effects • Don’t account for debug artifacts
86. Sit back and Strategize! 🤔 Why not debug builds? • Account for Progaurd and Dexguard effects • Don’t account for debug artifacts • Take in account build configuration as close to 
 release builds
87. Sit back and Strategize! 🤔 Common factors of noise and outliers • Network • Remote Configuration • Debug Builds • App/Device based noise
88. Sit back and Strategize! 🤔 App/Device based noise
89. Sit back and Strategize! 🤔 • Random GC triggers App/Device based noise
90. Sit back and Strategize! 🤔 App/Device based noise • Random GC triggers • System Dialogs from Crashes/ANRs
91. Sit back and Strategize! 🤔 App/Device based noise • Random GC triggers • System Dialogs from Crashes/ANRs • Device configuration like CPU frequency
92. Sit back and Strategize! 🤔 App/Device based noise • Random GC triggers • System Dialogs from Crashes/ANRs • Device configuration like CPU frequency • CPU/Runtime optimisations in general
93. Sit back and Strategize! 🤔 App/Device based noise • Random GC triggers • System Dialogs from Crashes/ANRs • Device configuration like CPU frequency • CPU/Runtime optimisations in general • Never ending.
94. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs • Ideal tool for this: • Observability on tentative regressions • Detecting outliers and noise • Surface regressions mapping developers and teams • Infra to run the tests Tool Selection
95. Sit back and Strategize! 🤔 Step 2: Stop bleeding by creating baseline • Creating observability on the PRs • Ideal tool for this: • Observability on tentative regressions • Detecting outliers and noise • Surface regressions mapping developers and teams • Infra to run the tests Tool Selection
96. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only 
 contributor to first_screen_drawn • App Icon click is not only trigger • Campaigns
97. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only 
 contributor to first_screen_drawn • App Icon click is not only trigger • Campaigns Eyes on the changes entering while you fix ✅
98. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only 
 contributor to first_screen_drawn • App Icon click is not only trigger • Campaigns Eyes on the changes entering while you fix ✅ Alert of PRs on slack, email ✅
99. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only 
 contributor to first_screen_drawn • App Icon click is not only trigger • Campaigns Eyes on the changes entering while you fix ✅ Alert of PRs on slack, email ✅ Flame graphs, diff, VCS metadata ✅
101. Sit back and Strategize! 🤔 Production analytics Quality gate on baseline branch ✅ ✅
102. Sit back and Strategize! 🤔 Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users
103. Sit back and Strategize! 🤔 Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users
104. Sit back and Strategize! 🤔 • Definition of Impacted session for app launch Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users
105. Sit back and Strategize! 🤔 • Definition of Impacted session for app launch • Google Android Vitals >= 5 seconds Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users
106. Sit back and Strategize! 🤔 • Definition of Impacted session for app launch • Google Android Vitals >= 5 seconds • Discussion with product stakeholders Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users
107. Sit back and Strategize! 🤔 • Definition of Impacted session for app launch • Discussion with product stakeholders • Google Android Vitals >= 5 seconds • Query the users having more than X percent sessions 
 as Impacted Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users
108. Sit back and Strategize! 🤔 • Discussion with product stakeholders • Query the users having more than X percent sessions 
 as Impacted • Tools selection: Firebase Realtime Database, Firebase 
 User Properties and Debug API on the rescue • Google Android Vitals >= 5 seconds • Definition of Impacted session for app launch Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users
109. Sit back and Strategize! 🤔 Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users Segment 
 impacted users 
 with firebase Uploading 
 traces from 
 impacted users
110. Sit back and Strategize! 🤔 Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users Segment 
 impacted users 
 with firebase Uploading 
 traces from 
 impacted users
111. Sit back and Strategize! 🤔 1. Create Firebase User Properties on Console
112. Sit back and Strategize! 🤔 1. Create Firebase User Properties on Console pro fi le_app_startup
113. Sit back and Strategize! 🤔 users ……. 2. Firebase Realtime Database
114. Sit back and Strategize! 🤔 2. Firebase Realtime Database users ……. ……. user-id-1 ……. user-id-2
115. Sit back and Strategize! 🤔 users ……. ……. user-id-1 ……. user_property_a: true ……. user-id-2 ……. user_property_a: true 2. Firebase Realtime Database
116. Sit back and Strategize! 🤔 users ……. ……. user-id-1 ……. user_property_a: true ……. user-id-2 ……. user_property_a: true ……. pro fi le_app_startup: true ……. user_property_b: true 2. Firebase Realtime Database
117. Sit back and Strategize! 🤔 users ……. ……. user-id-1 ……. user_property_a: true ……. user-id-2 ……. user_property_a: true ……. pro fi le_app_startup: true ……. user_property_b: true 2. Firebase Realtime Database Dynamically enable app start up profiling for these users
118. Sit back and Strategize! 🤔 3. Enable via remote config
119. Sit back and Strategize! 🤔 3. Enable via remote config • Create parameter enable_trace_app_launch
120. Sit back and Strategize! 🤔 3. Enable via remote config • Create parameter enable_trace_app_launch • Create condition with user property profile_app_startup
121. Sit back and Strategize! 🤔 3. Enable via remote config • Create parameter enable_trace_app_launch • Create condition with user property profile_app_startup • Enable the parameter for the condition and default to false
122. Sit back and Strategize! 🤔 Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users Segment 
 impacted users 
 with firebase Uploading 
 traces from 
 impacted users
123. Sit back and Strategize! 🤔 4. Debug API •Fetch performance traces for the impacted users from 
 production
124. Sit back and Strategize! 🤔 4. Debug API •Fetch performance traces for the impacted users from 
 production class AppLaunchTracker(private val remoteConfig: RemoteConfig)
125. Sit back and Strategize! 🤔 4. Debug API •Fetch performance traces for the impacted users from 
 production class AppLaunchTracker(private val remoteConfig: RemoteConfig) fun startTracking() { ... if(remoteConfig.isEnabled(enable_trace_app_launch)) { Debug.startMethodTracingSampling( context.cacheDir, maxBufferSize, samplingIntervalUs ) } }
126. Sit back and Strategize! 🤔 4. Debug API •Fetch performance traces for the impacted users from 
 production class AppLaunchTracker(private val remoteConfig: RemoteConfig) fun stopTracking() { ... if(remoteConfig.isEnabled(enable_trace_app_launch)) { Debug.stopMethodTracing() } }
127. Sit back and Strategize! 🤔 4. Debug API •Fetch performance traces for the impacted users from 
 production •Upload traces from periodic work manager
128. Sit back and Strategize! 🤔 4. Debug API •Fetch performance traces for the impacted users from 
 production •Upload traces from periodic work manager • Firebase Storage • Multipart API upload
129. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only 
 contributor to first_screen_drawn • App Icon click is not only trigger • Campaigns Eyes on the changes entering while you fix ✅ Alert of PRs on slack, email ✅ Flame graphs, diff, VCS metadata ✅
130. Tracker Attributes for app launch ✅ Insights from data: ✅ • Splash screen is not the only 
 contributor to first_screen_drawn • App Icon click is not only trigger • Campaigns Eyes on the changes entering while you fix ✅ Alert of PRs on slack, email ✅ Flame graphs, diff, VCS metadata ✅ Traces from production ✅
131. Sit back and Strategize! 🤔 Flamegraphs ✅
132. Sit back and Strategize! 🤔 What we achieved with flame graphs?
133. Sit back and Strategize! 🤔 •Study issues which are consistent in the impacted flame 
 graphs What we achieved with flame graphs?
134. Sit back and Strategize! 🤔 •Study issues which are consistent in the impacted flame 
 graphs What we achieved with flame graphs? •Creating a priority list of the issues that needs to be fixed
135. Sit back and Strategize! 🤔 •Study issues which are consistent in the impacted flame 
 graphs What we achieved with flame graphs? •Creating a priority list of the issues that needs to be fixed •Performance gain they will provide
136. Sit back and Strategize! 🤔 •Study issues which are consistent in the impacted flame 
 graphs What we achieved with flame graphs? •Creating a priority list of the issues that needs to be fixed •Performance gain they will provide •Effort of fix on the basis of: •Refactor •Upgrading library •Executing on background thread
137. Step4: 
 Lets ship the fixes
138. Step4: 
 Lets ship the fixes Some of the issues the team found •Dexguard class encryption of classes increasing 
 initialisation time
139. Step4: 
 Lets ship the fixes Some of the issues the team found •Dexguard class encryption of classes increasing 
 initialisation time •List of consistent expensive initialisation of some SDKs
140. Step4: 
 Lets ship the fixes Some of the issues the team found •Dexguard class encryption of classes increasing 
 initialisation time •List of consistent expensive initialisation of some SDKs •Unwanted dependencies getting injected through dagger
141. Partayyy!! Some of the issues the team found •Dexguard class encryption of classes increasing 
 initialisation time •List of consistent expensive initialisation of some SDKs •Unwanted dependencies getting injected through dagger 🎉
142. Conclusion •Creating observability is the most important part, fixes can really be one line change
143. Conclusion •Creating observability is the most important part, fixes can really be one line change •Lets revisit our patterns:
144. Conclusion •Creating observability is the most important part, fixes can really be one line change • Pattern 1: Scalable ≠ High Performant Codebase •Lets revisit our patterns: ✅
145. Conclusion •Creating observability is the most important part, fixes can really be one line change • Pattern 1: Scalable ≠ High Performant Codebase •Lets revisit our patterns: ✅ • Pattern 2: We get to know from customer tickets or Android Vitals ✅
146. Conclusion •Creating observability is the most important part, fixes can really be one line change • Pattern 1: Scalable ≠ High Performant Codebase •Lets revisit our patterns: ✅ • Pattern 2: We get to know from customer tickets or Android Vitals ✅ • Pattern 3: Prioritising performance issues with other feature work is an issue ✅
147. Conclusion •Creating observability is the most important part, fixes can really be one line change • Pattern 1: Scalable ≠ High Performant Codebase •Lets revisit our patterns: ✅ • Pattern 2: We get to know from customer tickets or Android Vitals ✅ • Pattern 3: Prioritising performance issues with other feature work is an issue ✅ • Pattern 4: Drafting OKRs for platform teams is difficult
148. Conclusion •Creating observability is the most important part, fixes can really be one line change • Pattern 1: Scalable ≠ High Performant Codebase •Lets revisit our patterns: ✅ • Pattern 2: We get to know from customer tickets or Android Vitals ✅ • Pattern 3: Prioritising performance issues with other feature work is an issue ✅ • Pattern 4: Drafting OKRs for platform teams is difficult Proposal:
149. Conclusion •Creating observability is the most important part, fixes can really be one line change • Pattern 1: Scalable ≠ High Performant Codebase •Lets revisit our patterns: ✅ • Pattern 2: We get to know from customer tickets or Android Vitals ✅ • Pattern 3: Prioritising performance issues with other feature work is an issue ✅ • Pattern 4: Drafting OKRs for platform teams is difficult • KR 1: Bringing observability to metric x, y, z, a, b, c (first screen, app launch time, user id) Proposal:
150. Conclusion •Creating observability is the most important part, fixes can really be one line change • Pattern 1: Scalable ≠ High Performant Codebase •Lets revisit our patterns: ✅ • Pattern 2: We get to know from customer tickets or Android Vitals ✅ • Pattern 3: Prioritising performance issues with other feature work is an issue ✅ • Pattern 4: Drafting OKRs for platform teams is difficult • KR 1: Bringing observability to metric x, y, z, a, b, c (first screen, app launch time, user id) Proposal: • KR 2: Attempt 70% accuracy on the attempts for fixing cold start.
151. Conclusion •Creating observability is the most important part, fixes can really be one line change • Pattern 1: Scalable ≠ High Performant Codebase •Lets revisit our patterns: ✅ • Pattern 2: We get to know from customer tickets or Android Vitals ✅ • Pattern 3: Prioritising performance issues with other feature work is an issue ✅ • Pattern 4: Drafting OKRs for platform teams is difficult • KR 1: Bringing observability to metric x, y, z, a, b, c (first screen, app launch time, user id) Proposal: • KR 2: Attempt 70% accuracy on the attempts for fixing cold start. • KR 3: Creating quality gate and bringing X% confidence on detecting regressions
152. Fin 🙋 @droid_singh @amanjeetsingh150 Amanjeet Singh