Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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. What is Performance? Story 📘 Pattern 1: Scalable ≠ High

    Performant Codebase • Not upgrading libraries
  2. What is Performance? Story 📘 Pattern 1: Scalable ≠ High

    Performant Codebase • Not upgrading libraries • Partial quality gates
  3. What is Performance? Story 📘 Pattern 1: Scalable ≠ High

    Performant Codebase • Not upgrading libraries • Partial quality gates • Not scoping dagger dependencies properly. I Singleton ❤
  4. 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 ❤
  5. 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 ❤
  6. 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 ❤
  7. 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
  8. 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
  9. 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
  10. 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?
  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 ❤ 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?
  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 ❤ 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? 🤷
  13. Mission I: Reducing Cold Start •Drafting OKRs for reducing Cold

    Start •Draft I •Uplifting the app quality of X consumer app (O)
  14. 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%
  15. 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%
  16. 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
  17. 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
  18. 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
  19. 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 😖
  20. First few Attempts to fix cold start ⏰ 1. Looking

    online for blogs "Reducing cold starts at an X 
 company by 80%"
  21. 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
  22. 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
  23. 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 🚀
  24. 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 ✅ 🚀
  25. 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 ✅ ❌ 🚀
  26. First few Attempts to fix cold start ⏰ Anti Methodology

    for Performance Analysis • Blame-Someone-Else Anti-Method
  27. First few Attempts to fix cold start ⏰ Anti Methodology

    for Performance Analysis • Blame-Someone-Else Anti-Method • Street light anti-method
  28. 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
  29. What are we 
 doing wrong? • Are we chasing

    the right metric for cold start?
  30. 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?
  31. 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 🤔 

  32. Sit back and Strategize! 🤔 Step 1: Identify proper metrics

    and create observability • Cold Start App Launch
  33. Sit back and Strategize! 🤔 Step 1: Identify proper metrics

    and create observability • Cold Start App Launch • Different spans for app launch
  34. 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
  35. 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
  36. 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:
  37. 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
  38. 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
  39. 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
  40. 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
  41. Sit back and Strategize! 🤔 // Start AppLaunchTracker.startTracking() // End

    AppLaunchTracker.stopTracking(firstScreenName) 
 

  42. 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); 

  43. 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); 

  44. 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) 

  45. 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) 

  46. 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 ✅
  47. 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
  48. 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
  49. 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
  50. Sit back and Strategize! 🤔 Step 2: Stop bleeding by

    creating baseline • Creating observability on the PRs
  51. Sit back and Strategize! 🤔 Step 2: Stop bleeding by

    creating baseline • Creating observability on the PRs • Ideal tool for this:
  52. Sit back and Strategize! 🤔 Step 2: Stop bleeding by

    creating baseline • Creating observability on the PRs • Ideal tool for this: • Surface tentative regressions
  53. 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
  54. 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
  55. 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
  56. 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
  57. Sit back and Strategize! 🤔 Common factors of noise and

    outliers • Network 🎹 Orchestration of test with mitm
  58. 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
  59. Sit back and Strategize! 🤔 Common factors of noise and

    outliers • Network • Remote Configuration • Debug Builds
  60. Sit back and Strategize! 🤔 Why not debug builds? •

    Account for Progaurd and Dexguard effects
  61. Sit back and Strategize! 🤔 Why not debug builds? •

    Account for Progaurd and Dexguard effects • Don’t account for debug artifacts
  62. 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
  63. Sit back and Strategize! 🤔 Common factors of noise and

    outliers • Network • Remote Configuration • Debug Builds • App/Device based noise
  64. Sit back and Strategize! 🤔 App/Device based noise • Random

    GC triggers • System Dialogs from Crashes/ANRs
  65. Sit back and Strategize! 🤔 App/Device based noise • Random

    GC triggers • System Dialogs from Crashes/ANRs • Device configuration like CPU frequency
  66. 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
  67. 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.
  68. 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
  69. 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
  70. 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
  71. 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 ✅
  72. 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 ✅
  73. 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 ✅
  74. Sit back and Strategize! 🤔 Step 3: Extract Impacted sessions

    and collect prod traces 
 from the impacted users
  75. Sit back and Strategize! 🤔 Step 3: Extract Impacted sessions

    and collect prod traces 
 from the impacted users
  76. Sit back and Strategize! 🤔 • Definition of Impacted session

    for app launch Step 3: Extract Impacted sessions and collect prod traces 
 from the impacted users
  77. 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
  78. 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
  79. 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
  80. 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
  81. 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
  82. 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
  83. Sit back and Strategize! 🤔 2. Firebase Realtime Database users

    ……. ……. user-id-1 ……. user-id-2
  84. Sit back and Strategize! 🤔 users ……. ……. user-id-1 …….

    user_property_a: true ……. user-id-2 ……. user_property_a: true 2. Firebase Realtime Database
  85. 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
  86. 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
  87. Sit back and Strategize! 🤔 3. Enable via remote config

    • Create parameter enable_trace_app_launch
  88. Sit back and Strategize! 🤔 3. Enable via remote config

    • Create parameter enable_trace_app_launch • Create condition with user property profile_app_startup
  89. 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
  90. 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
  91. Sit back and Strategize! 🤔 4. Debug API •Fetch performance

    traces for the impacted users from 
 production
  92. Sit back and Strategize! 🤔 4. Debug API •Fetch performance

    traces for the impacted users from 
 production class AppLaunchTracker(private val remoteConfig: RemoteConfig)
  93. 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 ) } }
  94. 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() } }
  95. Sit back and Strategize! 🤔 4. Debug API •Fetch performance

    traces for the impacted users from 
 production •Upload traces from periodic work manager
  96. 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
  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 ✅ Alert of PRs on slack, email ✅ Flame graphs, diff, VCS metadata ✅
  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 ✅ Flame graphs, diff, VCS metadata ✅ Traces from production ✅
  99. Sit back and Strategize! 🤔 •Study issues which are consistent

    in the impacted flame 
 graphs What we achieved with flame graphs?
  100. 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
  101. 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
  102. 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
  103. Step4: 
 Lets ship the fixes Some of the issues

    the team found •Dexguard class encryption of classes increasing 
 initialisation time
  104. 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
  105. 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
  106. 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 🎉
  107. Conclusion •Creating observability is the most important part, fixes can

    really be one line change •Lets revisit our patterns:
  108. 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: ✅
  109. 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 ✅
  110. 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 ✅
  111. 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
  112. 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:
  113. 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:
  114. 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.
  115. 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