Design and Implementation of the FoxPage Native Platform for Cross‑Platform Mobile UI Rendering

Author Ma Zengyi, a senior software engineer at Trip.com, introduces the motivation behind building a native platform for the Trip.com app homepage, highlighting challenges such as rapid business demand release, multi‑platform development cost, and maintainable data‑tracking (埋点) code.

The proposed solution, FoxPage Native, is built on a lightweight JSON + Flexbox rendering engine, chosen after evaluating React Native (high dynamism but lower performance) and Flutter (high performance but static).

Technical selection and reasoning : the framework must provide high performance, stability, dynamic updates without version releases, and multi‑platform rendering. The final design uses native JSON parsing combined with the Yoga Flexbox engine.

Architecture design : the system is divided into independent modules – Downloader (DSL download), CacheManager (DSL caching), Parse (DSL to node conversion), Layout (layout calculation), and Draw (native view tree creation). Each module follows the single‑responsibility principle to improve maintainability.

DSL definition : the DSL describes UI components, data binding (e.g., { "parentId":"...", "name":"image", "props":{ "url":"{{product.imageUrl}}" }, "type":"trip-app.image" } ), events (e.g., click routing), conditional rendering, and dynamic tracking data. Variable syntax uses double braces {{variable}} and array indexing {{array[0]}}.

Layout : three options were considered – custom rules, full Web CSS, and Flexbox. Flexbox was selected for its proven performance in React Native and its Yoga implementation, which the team customized for Android.

DSL parsing and view construction : the parser caches compiled DSL templates, then creates a tree of FPViewNode objects (Objective‑C example shown) that hold attributes, children, binding values, conditions, and references to native UI components.

Data update and dynamic update : a dirty‑checking mechanism triggers Layout and Draw recomputation only for changed UI elements. Dynamic updates are delivered via cloud‑side DSL changes, with version fallback handling and backup validation.

Visual page builder : a WYSIWYG editor allows product and operation teams to compose pages visually, with side‑by‑side previews of the editor and the actual app rendering.

Engineering transformation : the shift to a component‑centric, dynamic approach reduces development effort (from 4 person‑days to 1 person‑day for complex modules) and improves modular reuse across business lines.

Business‑operation closed loop : the platform enables product, operations, and engineering teams to collaborate, track KPI impact, and iteratively refine pages without app releases.

Conclusion : Within two months, FoxPage Native supported over 30 business adjustments and 5 urgent tracking updates, achieving high stability and significantly lowering development cost while maintaining quality.