Zhihu: Save Your StartingWindow

Word count: 1.7kReading time: 10 min

 2018/05/20

It’s often said that the overall iOS experience is superior to Android. This is partly due to third-party software quality (iOS versions are often more polished) and partly due to Apple’s tight control over its ecosystem. To get on the App Store, you must pass rigorous reviews.

Today we look at the system-provided transition before app content is ready: Android’s StartingWindow and iOS’s Launch Screen. Neither is the same as an advertising Activity or business home screen rendered by the app.

I originally wrote that iOS required a single image. I was wrong about that. Xcode 6 release notes document XIB/Storyboard launch screens from iOS 8. They provide early feedback, not a guaranteed zero-delay timestamp. Older Android theme paths allowed customization, disabled previews, and translucent windows; behavior depends on the OS version.

Historical case (reviewed 2026-10-13): The observations, screenshots, and logs concern Zhihu 5.17.2 in 2018, Xiaomi Mix 2S, and Meizu Pro 7. App lists and criticism describe that period, not current-version tests. AOSP android-8.1.0_r1 is a mechanism reference, not an identification of either device’s ROM. Android 12 / API 31 migration guidance is added below.

How StartingWindow Affects User Experience

Because the StartingWindow is the first thing a user sees, its misuse can lead to a terrible first impression. Let’s look at three scenarios:

Theme-provided StartingWindow: The system can show a preview during a qualifying launch and transition to the app window. Its color depends on the theme; it need not be white, appear on every launch, or transition directly to a usable home screen. The examples I saw then included system apps, Jike, and Autohome.
Lightweight custom starting theme: Background colors and drawables can visually match the first frame. The system creates this window; it does not pre-run the app’s setContentView or arbitrary custom layouts. Large resources can still add cost. My examples at the time included Taobao, JD, Weibo, Toutiao, and Meituan.
Disabled preview or translucent theme: An older theme path may leave users looking at the launcher without clear progress. The visible symptom alone does not prove the exact attribute used. WeChat, WeChat Read, UC Browser, Alipay, ICBC, and Mi Home were my examples at the time.

I really could not understand why so many apps chose the third approach. Many users had only one phone to compare against, blamed the system, and sent us high-severity bug reports. It was enough to make me want to cry. Developers and product managers using this approach needed to give it some thought. Reusing a live process can hide the difference. I suggested trying adb shell am force-stop com.tencent.mm before relaunching. That forcibly stops the app; it is not identical to every natural process-death state, nor evidence that an OEM never kills WeChat.

Case Study: Zhihu’s UX Data

As a heavy Zhihu user, I’ve been frustrated by its deteriorating launch experience. In the original observation (v5.17.2), Zhihu uses the first approach (default window), but its startup is so slow that the user is stuck staring at a white screen for a significant amount of time.

I used a Xiaomi Mix 2S (Snapdragon 845) for the traces below; the log is from a Pro 7. White was the observed preview appearance, not a universal Android default. A long wait needs further investigation before assigning it to initialization, scheduling, or I/O.

Selected startup interval in SurfaceFlinger-related tracks (1.933s) — the cropped image does not independently establish physical presentation timestamps:
App process view of the same-length selection — showing bindApplication, Activity startup, and traversal work:
Log Perspective (am_activity_launch_time):
The Pro 7 event ends in 1078,2684 milliseconds. I also recorded 1552ms for Mix 2S at the time, but did not include that log line. These are not interchangeable measurements.

05-21 22:40:58.033  1252  3371 I am_create_activity: [0,128018471,73,com.zhihu.android/.app.ui.activity.LauncherActivity,android.intent.action.MAIN,NULL,NULL,270532608]
05-21 22:40:58.037  1252  3371 I am_focused_activity: [0,com.zhihu.android/.app.ui.activity.LauncherActivity,startedActivity]
05-21 22:40:58.042  1252  3371 I sysui_action: [323,com.zhihu.android/.app.ui.activity.LauncherActivity]
05-21 22:40:58.092  1252  1293 I am_proc_start: [0,20985,10111,com.zhihu.android,activity,com.zhihu.android/.app.ui.activity.LauncherActivity]
05-21 22:40:58.133  1252  2857 I am_proc_bound: [0,20985,com.zhihu.android]
05-21 22:40:58.140  1252  2857 I am_restart_activity: [0,128018471,73,com.zhihu.android/.app.ui.activity.LauncherActivity]
05-21 22:40:59.564  1252  3109 I am_create_activity: [0,123681068,73,com.zhihu.android/.app.ui.activity.MainActivity,android.intent.action.MAIN,NULL,NULL,270532608]
05-21 22:40:59.566  1252  3109 I am_focused_activity: [0,com.zhihu.android/.app.ui.activity.MainActivity,startedActivity]
05-21 22:40:59.567  1252  3109 I am_pause_activity: [0,128018471,com.zhihu.android/.app.ui.activity.LauncherActivity]
05-21 22:40:59.570  1252  3109 I sysui_action: [323,com.zhihu.android/.app.ui.activity.LauncherActivity]
05-21 22:40:59.571  1252  3126 I am_finish_activity: [0,128018471,73,com.zhihu.android/.app.ui.activity.LauncherActivity,app-request]
05-21 22:40:59.661  1252  3094 I am_restart_activity: [0,123681068,73,com.zhihu.android/.app.ui.activity.MainActivity]
05-21 22:41:00.222 20985 20985 I am_on_resume_called: [0,com.zhihu.android.app.ui.activity.MainActivity,LAUNCH_ACTIVITY]
05-21 22:41:00.736  1252  1305 I am_activity_launch_time: [0,123681068,com.zhihu.android/.app.ui.activity.MainActivity,1078,2684]
05-21 22:41:01.269  1252  2906 I am_destroy_activity: [0,128018471,73,com.zhihu.android/.app.ui.activity.LauncherActivity,finish-imm]
05-21 22:41:01.859  1252  3072 I am_proc_start: [0,21229,10111,com.zhihu.android:pushservice,service,com.zhihu.android/.push.getui.GetuiPushService]
05-21 22:41:01.882  1252  2857 I am_proc_bound: [0,21229,com.zhihu.android:pushservice]

In the checked AOSP 8.1 ActivityRecord.reportLaunchTimeLocked() implementation, 1078 is the current Activity’s thisTime and 2684 is totalTime for the still-open stack launch interval. They overlap and must not be added; neither says that the advertisement has finished.

Both cropped traces select 1.933s; the Pro 7 log comes from another device. Without the original trace, complete conditions, or repeated samples, they cannot form one precise timeline or prove how much slower another device will be. Below is what I recorded then: roughly 2s of blank screen, followed by about 3s of ads. After waiting through the blank screen, we still had an ad to get past. So much for user experience. A prettier preview would not remove the waiting that followed.

The Visual Journey

Here are the three stages I saw on the Pro 7. The approximate 2s/3s durations are my observations from then, not timings recoverable from individual screenshots. The ad image includes a “skip ad 3” control, so it does not establish a wholly unskippable wait.

Icon Tap -> Blank White StartingWindow (2s)
White Screen -> Ad Page (3s)
Ad Page -> Main UI

My suggestion was for Zhihu to use a lightweight starting theme, like the one in this iOS screenshot from the time. It improves feedback and visual continuity without automatically reducing initialization or advertisement time. Use the migration approach below for current Android implementations.

Zhihu iOS Splash Screen

2026 Update: StartingWindow and SplashScreen

In AOSP android-8.1.0_r1, AppWindowContainerController selects a splash, snapshot, or no starting window based on launch/task/snapshot state. The older splash-theme path excludes translucent, floating, or windowDisablePreview cases. PhoneWindowManager creates a TYPE_APPLICATION_STARTING window from theme resources; its windowSplashscreenContent path wraps a Drawable, not an arbitrary app layout.

Android 12 / API 31 introduced SplashScreen for the relevant cold/warm launch paths; a hot start reusing an Activity does not show it. For migration:

Use androidx.core:core-splashscreen; its 1.0.0 release supports API 23+. Configure Theme.SplashScreen, windowSplashScreenBackground, windowSplashScreenAnimatedIcon, and postSplashScreenTheme, and assign the starting theme to the launch Activity in the manifest.
Call installSplashScreen() before super.onCreate(), then create app content. Remove a separate branding-only SplashActivity to avoid showing two splash screens. See the migration guide.
If retention is needed, make setKeepOnScreenCondition a fast readiness check; do not do I/O or sleep there. A custom exit-animation listener must eventually call SplashScreenViewProvider.remove(). Icon-animation duration does not force the window to remain visible. See the API reference.
Measure TTID and business readiness separately, reporting reportFullyDrawn() at the right ready state for TTFD. Use Macrobenchmark and Perfetto to investigate actual work. Better animation is not evidence of faster startup; see startup timing boundaries.

Historical source references: AppWindowContainerController, PhoneWindowManager, and ActivityRecord. They explain this AOSP version, not an exact reconstruction of either vendor ROM.

Parting Thoughts

Android’s user experience depends heavily on third-party developers. While OEMs can optimize the hardware and OS, the moment a user enters an app, the developer is in the driver’s seat.

StartingWindow is a small detail, but it is the entrance to your app. If even that feels bad, why would users want to come back? Zhihu was just one example; I hoped it would get developers to try their own startup flow and feel the wait for themselves. As the saying goes, speed wins. Better apps make the system feel better too, and users get the benefit.

The following list is retained as a 2018 observation, not a new test of these apps.

The Hall of Shame (Apps using disabled/transparent StartingWindows):

WeChat
WeChat Read
UC Browser
Alipay
ICBC
Mi Home
… (Feel free to suggest more)

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”