Incremental Offline Package Update Solution for Ctrip Travel App

Author Bio

Zhao Xinguo, Director of Wireless R&D at Ctrip Technology Center, has been responsible for the app framework, performance, quality, efficiency, and new technologies since joining Ctrip in 2013, focusing on native, hybrid, and React Native frameworks.

Ctrip's travel app uses H5 Hybrid and React Native for nearly half of its pages. To improve load speed and reliability, business code is packaged as offline bundles and distributed via app stores; updates are delivered through a wireless publishing system.

Full‑package releases increase download size and failure risk, so incremental update strategies are required.

Offline Package Incremental Update Scheme

The following diagram illustrates the design of the incremental update scheme.

From the client side, the process consists of two parts: obtaining the offline‑package download list and downloading the package files.

Example workflow for a new business module:

1. Create business module – add a new module in the offline‑package management system and configure the applicable app, version, and environment.

2. Publish business module – select the code branch in the publishing system, build, and release.

3. App packaging – embed a script that fetches the latest offline package into the app and records version information.

4. App startup – send local offline‑package versions and app ID to the server, which returns the latest download URLs.

5. Download – the client sequentially downloads packages in a background thread.

6. Installation – after download, the package is decompressed, merged, and installed.

Offline Package Management System Functions

a) Metadata management (unique name, platform, priority, owner, description).

b) Maintenance of app‑package relationships for flexibility and extensibility.

c) Enable/disable control for packages no longer used.

d) API to query the latest package list for a given app, version, and environment.

Offline Package Publishing System Functions

a) Pull code from selected branch and build.

b) Publish the built package (update version in database and management system).

c) Support gray release, rollback, and disable.

d) Provide publishing statistics and monitoring (upgrade percentage, per‑user query).

Package Dependency Management

With over 100 offline packages, a lightweight dependency rule is used: lower numeric priority means higher install priority; packages with the same priority follow the release order. Two priorities are defined – 0 for framework/common packages and 100 for business features.

Dynamic Differential Updates

To reduce package size, a bsdiff‑based differential algorithm is applied. The server computes a patch between the latest package and the baseline packaged in the app. The client merges the patch with the baseline to obtain the updated package.

Testing showed that generating a zip of only changed files and adding per‑file hash verification yields smaller patches and ensures integrity.

Comparative results demonstrate significant size reduction with the optimized approach.

Because different app variants have different package versions, patches are generated on‑demand: the client first tries CDN, falls back to origin server, triggers dynamic patch generation, and then pushes the result back to CDN.

App‑Side Download Guarantees

1) Retry mechanism – up to three attempts with increasing back‑off intervals.

2) Signature verification – each downloaded file is signed; the client validates the signature before installation.

3) Periodic polling – after the first successful download, the client polls the server every 10 minutes for newer package lists, ensuring updates within ~10 minutes under normal network conditions.

Package Usage, Installation, and Loading

Offline packages are bundled with the app, downloaded, decompressed, and merged before use. The flow for a business module (e.g., Business A) includes merging new package Anew.7z with the baseline Abase.7z, storing the result in a work directory, and loading the updated resources after cache clearing.

Release Control

Gray release – gradual rollout (10 % after 10 min, 50 % after 30 min, 100 % after 1 h). Rollback – revert to previous package if issues arise. Stop – halt a release that shows no impact.

End‑to‑End Monitoring

In production, each download‑to‑install transaction is logged; aggregated logs enable monitoring, alerts, and success‑rate calculations (99.8 % iOS, 99.5 % Android). In testing, detailed logs and a debug tool display per‑package version information.

Conclusion

The continuously iterated wireless offline‑package update solution now runs stably across Ctrip's main travel app and other group apps, achieving high installation success rates and providing a reference for similar business scenarios.