[go: nahoru, domu]
Chrome Speed

Binary Size Metrics

This document lists metrics used to track binary size.

Metrics for Desktop

Alerting

  • Alerts are sheriffed as part of the main perf sheriff rotation.
  • Alerts generally fire for ~100kb jumps.

Metrics for Android

For Googlers, more information available at go/chrome-apk-size.

  • Sizes are collected by //build/android/resource_sizes.py.
  • How to analyze Android binary size discussed in apk_size_regressions.md#debugging-apk-size-increase.
  • Sizes for ChromePublic.apk, ChromeModernPublic.apk, MonochromePublic.apk, SystemWebview.apk are tracked.
    • But only MonochromePublic.apk is actively monitored.
  • We care most about on-disk size (for users with small device storage)
    • But also care about patch size (so that browser updates get applied)

Normalized APK Size

  • Telemetry Graph
  • Monitored by Binary Size Sheriffs.
    • Alerts fire for changes of 16kb or more.
  • Computed as:
    • The size of an APK
    • With all native code as the sum of section sizes (except .bss), uncompressed.
      • Why: Removes effects of ELF section alignment.
    • With all dex code as if it were stored uncompressed.
      • Why: Best practice is to store dex uncompressed on Android P and above.
      • On prior versions, or when stored compressed, dex is extracted upon installation.
    • With all zipalign padding removed.
      • Why: Removes effects of file alignment (esp. relevant because native libraries are 4k-aligned).
    • With size of apk signature block removed.
      • Why: Size fluctuates by several KB based on how hash values turn out.
    • With all translations as if they were not missing (estimates size of missing translations based on size of english strings).
      • Why: Without translation-normalization, translation dumps cause jumps.
      • Translation-normalization applies only to apks (not to Android App Bundles).
  • For Android App Bundles, the normalized size is the sum of the normalized size of all splits that have (those installed by default).

Native Code Size Metrics

  • Telemetry Graph
  • File size of libchrome.so
  • Code vs data sections (.text vs .data + .rodata)

Java Code Size Metrics

  • Telemetry Graph
  • File size of classes.dex
  • “Dex”: Counts of the number of fields, methods, strings, types.
  • “DexCache”: The number of bytes of RAM required to load our dex file (computed from counts)

Breakdown Metrics

  • Telemetry Graph
  • Compressed size of each apk component.
  • The sum of these equals APK Size (which can be found under “Install Size Metrics”: “APK Size”)

Install Metrics

  • Telemetry Graph
  • Estimated installed size: How much disk is required to install Chrome on a device.
    • This is just an estimate, since actual size depends on Android version (e.g. Dex overhead is very different for pre-L vs L+).
    • Does not include disk used up by profile, etc.
    • We believe it to be fairly accurate for all L+ devices (less space is required for Dalvik runtime pre-L).
  • The sum of these equals Estimated installed size.

Transfer Size Metrics

  • Deflated apk size:
    • Telemetry Graph
    • Only relevant for non-patch updates of Chrome (new installs, or manual app updates)
  • Patch Size (no longer available):

Uncompressed Metrics

  • Telemetry Graph
  • Uncompressed size of classes.dex, locale .pak files, etc
  • Reported only for things that are compressed within the .apk

Metrics for LaCrOS