$30 off During Our Annual Pro Sale. View Details »

Chasing Performance Issues Methodically

Amanjeet Singh
September 04, 2022

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.

Amanjeet Singh

September 04, 2022
Tweet

More Decks by Amanjeet Singh

Other Decks in Technology

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 ✅
  100. None
  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