How Dual‑Prefetch and Multi‑Instance Architecture Supercharged Our Order List

Introduction

In the mobile‑first era, the order list is a core feature of an e‑commerce platform, responsible for displaying and managing user orders. Rapid business growth introduced new challenges: complex business scenarios, evolving architecture, and strict performance and experience requirements.

Key Problems Identified

First‑screen performance bottleneck – after the flash‑sale split, P99 latency surged.

Interaction experience gaps – tab switching felt disjointed.

White‑screen issues – frequent edge‑case blanks degraded user experience.

Overall Optimization Architecture

The solution is divided into three domains: first‑screen performance optimization, interaction experience upgrade, and white‑screen mitigation. Together they form a complete user‑experience improvement system.

First‑Screen Performance Optimization

When the flash‑sale feature launched, a new top‑level tab (rootTabCode + tabCode) was added, breaking the existing single‑layer pre‑fetch mechanism. The problems were:

Pre‑fetch failed for non‑default tabs, causing noticeable loading delays.

Overall cache hit rate dropped.

White‑screen time increased on weak networks.

Technical Solution

Dual‑layer pre‑fetch strategy : traverse both rootTabCode and tabCode to build a two‑level request map.

Dynamic configuration : adjust pre‑fetch rules at runtime.

Smart cache filtering : skip already‑cached tabs.

Dynamic rate‑limiting : limit maximum concurrent pre‑fetches to protect server load.

Multi‑Level Cache System

A three‑tier cache improves hit rates. Sources include:

Default cache: rootTabCode+tabCode strategy.

Historical compatibility: all+tabCode fallback.

Fallback optimization: when rootTabCode is missing, use core components from the all cache to ensure non‑order components render quickly.

Interaction Experience Upgrade

The original single‑instance architecture ( ListProxy) recreated the entire page container on each tab switch, causing performance bottlenecks, state loss, and poor animation smoothness.

Technical Solution

Introduce MultiTabProxy as a global coordinator. TabStateManager maintains independent state for each tab. TabContainer encapsulates a tab’s Instance, data, and view.

Lazy loading creates a tab’s container only when it becomes visible.

Dynamic ViewPager adjusts page count based on protocol data.

White‑Screen Issue Governance

When cache misses occur, only the order tab renders, leaving large blank areas. The mitigation strategy:

Attempt to fetch cache for rootTabCode+tabCode.

If missed, fallback to all+tabCode.

Reuse core components from other tab caches via protocol trimming, ensuring correct rendering.

Concurrent Request White‑Screen Fix

Rapid user actions and poor networks caused multiple concurrent requests to render empty data. A passive defense adds protective checks before rendering, preventing blank screens.

Summary and Outlook

Through systematic optimization, the order list achieved:

Performance : significantly higher cache hit rate and reduced first‑screen render time.

Stability : dramatically lower page‑blank occurrence.

Architectural value : multi‑instance design solved tab state management, delivering smoother interactions.

Future work will focus on balancing performance gains with resource consumption, building proactive UX metrics, and further refining the multi‑instance framework.