Mobile Development 8 min read

Card-Based Native App Engine: Design, Implementation, and Optimization at Qunar

This article presents Qunar's card‑based native app engine, detailing its design origins, advantages such as reuse, dynamic page organization, style theming, operational delivery, data‑driven personalization, and performance optimizations, while also outlining the framework's boundaries, implementation process, and future roadmap.

Ctrip Technology
Ctrip Technology
Ctrip Technology
Card-Based Native App Engine: Design, Implementation, and Optimization at Qunar

Qunar's internal technical carnival introduced the concept of "cardification" for native iOS applications, aiming to create a flexible UI framework where the backend supplies a list of cards that dynamically compose pages.

The card concept originates from Google's 2012 design language, representing a rectangular container of information (images, text, buttons) first used in Google Now, and later adopted by many apps such as Twitter, Facebook, Weibo, and mobile Taobao for dynamic content delivery.

The card framework offers several advantages:

Reuse: each card type is reusable across pages, targeting a reuse rate of 80%.

Dynamic page organization: the backend can add, delete, modify, or reorder cards, allowing the entire page layout to be controlled remotely.

Style theming: page‑wide skinning can be driven by the backend, exemplified by a Spring Festival theme.

Operational dynamic delivery: card content and layout can be adjusted in real time for marketing activities.

Data‑driven user service: cards can be personalized based on user behavior, achieving high conversion rates.

Package reduction: adopting the card framework reduced the app package size by nearly 9%.

Design boundaries for cards include full‑screen width on mobile, ordered linear layout with array‑based data, composite UI elements, type‑driven rendering, and emphasis on single‑type reuse.

The ticketing section of Qunar was fully cardified, covering four major pages (home, sight detail, search results, product detail) that share the same engine.

Page generation follows an MVVM‑like flow: the view controller extracts scheme parameters, the model fetches data, parses it into a list of card view‑models, each mapped to a view, and finally rendered in a table view. Custom flows are supported by subclassing the base VC and model.

Performance optimizations split large cards into multiple smaller items, reducing rendering load and raising frame rates to 56‑57 fps.

Future plans include a universal rich‑text card supporting HTML/JS, view‑model to view data binding, and an event handling mechanism possibly based on ReactiveCocoa.

mobileNativeperformanceUIiOScard framework
Ctrip Technology
Written by

Ctrip Technology

Official Ctrip Technology account, sharing and discussing growth.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.