Optimizing Android Process Startup in Xigua Video: Strategies, Implementation, and Benefits

When an Android app starts, the Zygote forks a process to run its Activities and Services. Large apps often use multiple processes to isolate heavy features, but each extra process consumes memory and CPU, potentially degrading launch speed and user experience.

Xigua Video performed a comprehensive review of its startup subprocesses, identified optimization opportunities, and implemented solutions to reduce resource contention during the critical launch phase.

Process Startup Overview

The Android 10.0 process creation flow consists of three main steps: the system_server calls Process.start() to request a new process from Zygote via a socket; Zygote executes ZygoteInit.main() and enters a select loop; upon receiving a client connection, Zygote forks the new app process and the child runs ZygoteConnection.handleChildProc which eventually invokes ActivityThread.main .

Process.start
-> ZYGOTE_PROCESS.start
   // generate argsForZygote (uid, gid, flags, ...)
   -> ZygoteProcess.startViaZygote
      // choose ZygoteState based on ABI
      -> ZygoteProcess.openZygoteSocketIfNeeded
         -> attemptConnectionToPrimaryZygote | attemptConnectionToSecondaryZygote
            -> ZygoteProcess.zygoteSendArgsAndGetResult
               // usap introduction
               -> attemptUsapSendArgsAndGetResult |
               // send args via socket, block until pid returned
               -> attemptZygoteSendArgsAndGetResult

Other ways to start processes include using Runtime.exec to run shell commands or directly forking via native code, though the article focuses on processes launched through Android components.

Governance Approach

The team first enumerated all components that could start a subprocess by adding android:process in the AndroidManifest and then used logcat filtering or ADB commands to locate the first component that triggered each process.

Three general mitigation strategies were defined:

On‑demand loading: Load feature modules only when needed, avoiding early calls.

Delayed loading: If the exact trigger time cannot be determined, defer process creation until after 1 minute of foreground use or when the app moves to background.

Merge into main process: Consolidate logic into the main process after thorough verification.

Optimization Process for Specific Subprocesses

Push Process

The push SDK initializes in Application.onCreate (no intervention needed) while the push process handles keep‑alive, badge, and long‑connection tasks. Since the app is in the foreground during launch, push notifications are unnecessary, so the process can be delayed.

Three solutions were explored:

Manual approach: Merge essential long‑connection logic into the main process and block the service that would start the push process.

SDK approach: Add a configuration flag in the push SDK to postpone process creation until the app goes to background, while moving necessary logic (e.g., registration, pull interfaces) to the main process.

Interception approach: Instrument startService and bindService to capture push‑related component launches, store them as Runnable , and execute after the app backgrounds.

Performance tests showed the SDK and interception methods had similar gains, but the SDK solution offered better completeness and lower maintenance cost, so it was selected for production.

Mini‑App Process

Initially considered a service‑interception method, but the mini‑app logic resides in a plugin, making instrumentation cumbersome. Analysis revealed that most mini‑app processes were started by the PreloadMiniAppTask . Disabling this task allowed on‑demand launch without affecting functionality.

Further investigation uncovered a duplicate usage‑time reporting bug: both the host and the mini‑app plugin recorded onPause events, causing an extra 1 second per transition. The issue was identified, explained, and deemed not to affect the experiment.

Downloader Process

The downloader process is triggered by the mini‑app process. After suppressing the mini‑app, the downloader no longer starts early, and the underlying SDK already supports single‑process operation, so no additional changes were required.

Sandboxed (WebView) Process

WebView rendering is performed in a sandboxed process. Since Xigua’s usage of WebView is limited to ad landing pages and activity channels, delaying its creation is feasible.

Two configuration flags were examined:

RENDER_PROCESS – enables multi‑process WebView. Setting it to false prevents the sandboxed process, but the platform team advised against disabling it for stability.

WRAMUP – controls process pre‑warm. Disabling pre‑warm allows delayed creation; the SDK can then start the sandboxed process after a configurable delay (e.g., 1 minute).

Additional optimization cached the UserAgent string to avoid early WebView initialization during cold start.

Exec Process

Some code obtains system properties via Runtime.exec("getprop ...") . The team compared this with the standard Build.BRAND and SystemProperties.get paths, confirming they read the same underlying property. The final guideline is to use Build.BRAND for brand and reflective SystemProperties.get for other properties, eliminating unnecessary shell commands.

Process Startup Monitoring

A monitoring component collects component information from PackageInfo , proxies the IActivityManager interface, parses component start requests, and reports filtered start events. This ensures that any regression in process‑startup optimizations is detected.

Optimization Benefits

Optimized Process

Core Business Gains

Quality Gains

Push Process

Effective playback +0.189%

Cold‑start latency -140 ms, overall frame rate +0.5%, frame drops -1%~2%

Mini‑App (incl. Downloader)

Daily active users +0.0892%, effective playback +0.207%

Frame rate after 1 min +0.405%, ANR reduction -26.223%

Sandboxed Process

Daily active users +0.0712%, effective playback +0.168%

Cold‑start latency -120 ms, first‑frame latency -200 ms, frame rate after 1 min +0.1, ANR reduction -6.7%

Team Introduction

The ByteDance Xigua Video client team focuses on app development and foundational technology, covering architecture, performance, stability, build systems, and developer tools. Interested engineers can apply via the internal referral link or email [email protected] . The team offers a supportive environment and growth opportunities in Shanghai and Hangzhou.