Hybrid Container Optimization for Puhui Ride‑Hailing Business

The report presents a comprehensive technical upgrade of the Hybrid container used in Puhui’s ride‑hailing services (car‑service, car‑pool, taxi, quick‑delivery, etc.). It starts with an industry overview, noting that the boundary between mobile and front‑end is becoming blurred and that H5 performance and experience have improved thanks to better devices and networks.

Four main problems of the existing Hybrid container are identified:

Missing operational monitoring and alerts (network errors, white‑screen rate, OOM, crashes are not captured before the H5 page is entered).

Poor performance (average first‑screen time 2800 ms, 1 s open rate only 12%).

Low stability (frequent crashes, high white‑screen rate, Android fragmentation causing WebView incompatibility).

Bad interaction experience (ugly loading UI, title flickering).

To address these issues, the authors propose a three‑stage performance analysis and a set of concrete solutions.

Monitoring and Performance Data

They introduce a full‑link tracing that records the time from the native click to the H5 Largest Contentful Paint (LCP). The data is sent to the internal "Bianque" performance platform, which visualizes the timeline in three phases:

Container preparation (≈300 ms) – optimized by container reuse and pre‑loading.

HTML resource download (≈850 ms) – optimized by delivering resources via offline packages.

H5 page processing (≈1070 ms) – optimized by pre‑loading, image compression, and request pre‑fetch.

Sample code for the JS‑Bridge that passes native performance timestamps to H5 is shown below:

// JS bridge: getNativePerformanceTime parameter format
{
  classMap: 'UBTBridge',
  method: 'getNativePerformanceTime',
  callbackId: '1',
  params: {
    callbackName: 'tianQiApmEasyBikeWebviewCallback'
  }
}
// JS method: tianQiApmEasyBikeWebviewCallback parameter format
window.tianQiApmEasyBikeWebviewCallback({
  "code": 0,
  "data": {
    "nativePageRenderStartTime": "1605598621744",
    "nativePageNavigationStartTime": "1605598621743"
  },
  "callbackId": "1"
});

The corrected performance data shows a clear reduction of container‑creation and load‑request times.

Stability Monitoring

Stability is monitored through crash logs, white‑screen rate, JS‑Bridge errors, network errors, and memory warnings. The Argus platform aggregates these metrics and triggers alerts when thresholds are exceeded.

White‑Screen Detection

The previous white‑screen detection relied on a 6‑second rule that missed many cases. The new method captures a screenshot, analyzes the proportion of white pixels (with configurable tolerance), and flags a white screen when the ratio exceeds a threshold. This approach works for both online and offline H5 pages.

Performance Optimizations

Four optimization stages are implemented:

Container loading optimization : a WebView object pool is created during idle time; containers are reused, cutting Android init time from 146 ms to 75 ms and iOS from 381 ms to 199 ms.

Image loading optimization : static images are converted to WebP and cached uniformly, reducing image load time by up to 80 %.

H5 resource optimization : offline packages cache HTML/JS locally; pre‑rendering generates static HTML for first‑page loads; both reduce first‑screen time dramatically.

Interface pre‑request : network requests are routed through the native layer and executed in parallel with page transition animations, cutting request latency from 170 ms to 70 ms.

Additional UI improvements include a new NavigationBar that eliminates title flickering and a customizable loading UI (static images, GIFs, Lottie animations).

Weak‑Network Handling

Offline resources and cached API responses enable the app to function under poor or no network conditions, ensuring continuity of service.

Overall Impact

After the optimizations, first‑screen time dropped from 2834 ms to 530 ms on iOS (81 % improvement) and from 2482 ms to 581 ms on Android (77 % improvement). The 1‑second open rate rose from 12 % to 91 % and the 2‑second open rate from 59 % to 97 %.

More than 80 % of H5 page PVs in the Puhui business now run on the upgraded container, covering seven high‑traffic pages.

The authors outline future work: unified WebView kernel, security hardening, deeper performance techniques (SSR, Prefetch, map component rendering), standardized JS‑Bridge, self‑healing H5 fallback, and further improvements to offline resource usage.