Native Refactoring of JD App Checkout: Architecture, Performance Gains, and Lessons Learned

In a previous article we covered the basic checkout functions such as payment, information confirmation, and activity promotion; this article introduces the native refactoring process of the checkout.

Native Refactoring Background and Goals During routine JD App checkout iterations, maintenance costs rose and performance analysis of server QPS, TP99 and front‑end H5 first‑paint revealed optimization opportunities. To improve user experience and upgrade the architecture, the team launched a native refactoring project aiming to enhance user experience, conversion rate, system security, stability, payment efficiency, and reduce maintenance costs.

Selection and Considerations Historically the checkout front‑end used a hybrid H5 + native model, where H5 handled rendering and interaction and native handled SDK calls. This long payment chain required login, URL redirects, UA parameters, CDN static resources, server API calls, WebView loading, and H5‑native bridge interactions, making it vulnerable to network jitter and WebView OOM, and increasing troubleshooting effort. Consequently, the team decided to abandon WebView‑related stacks and adopt a pure native stack to shorten the payment chain, while retaining a WebView container for the post‑payment success page to keep activity configuration flexible.

The native checkout introduced a configurable “element‑and‑slot” scheme with new server APIs, aiming for high flexibility and reuse to mitigate the drawback of native-only incremental releases, while still preserving WebView container capabilities for urgent cases.

After evaluation, the payment page and friend‑pay page were implemented with native technology, whereas other pages, including the payment success page, remain H5‑based.

Checkout Client Architecture Design The architecture focuses on abstraction and decoupling, emphasizing configurability to offset native stack limitations. The overall module architecture is shown below:

Previously, a single WebView container caused tight coupling; the new design splits different business H5 pages into separate WebView containers.

Payment behavior and process are unified into a payment object, while each payment method maintains independent, decoupled logic, simplifying integration and removal of payment methods.

Each payment method has its own “slot” in the UI; the native checkout abstracts these into common slots, allowing the server to dynamically deliver content without special handling per payment type.

Complex logic such as installment information retrieval and coupon‑installment linkage was refactored and moved to the server, preserving user experience while simplifying the client flow.

Quality and Performance After Refactor After comprehensive business analysis, redundant data removal, and logic consolidation, the native checkout API count decreased by five, data packet size on the payment page dropped by nearly 50%, single‑machine QPS increased by 18%, TP99 improved by 22.5%, machine cost fell by 18%, and maintenance cost halved. Startup time for the native payment page is roughly three times faster than the H5 version, and the overall payment chain is reduced to “open‑and‑pay”.

Prior to the 11.11 promotion, the native checkout underwent extensive traffic and stress testing; during the event, TP99 performance was the best in recent years, with virtually no customer complaints, demonstrating stable operation.

From a user‑experience perspective, further shortening of the payment chain is possible, and from a system‑upgrade perspective, security policies, interface layering, and API consolidation can still be optimized. The checkout team will continue to invest in these areas.