Evolution of iQIYI Mobile Client Dynamic Page Rendering: From Card 1.0 to Card 4.0

Mobile applications continuously seek dynamic page solutions to support rapid business iteration, app‑store review delays, slow user upgrades, and strong operational demands such as A/B testing.

iQIYI’s mobile client has gone through four major dynamic rendering schemes, named Card 1.0, Card 2.0, Card 3.0 and Card 4.0.

Card 1.0 – The page is assembled into a JSON structure on the server. The client receives the JSON, filters, parses, stitches it together and binds it to UI controls. This scheme solves data‑driven organization but suffers from heavy client‑side logic, lack of standardization and extensive manual composition.

Card 2.0 – Introduces a reusable “card” component composed of four optional parts: top_banner , bottom_banner , gap and container . The architecture is simple, UI is clear and client implementation is efficient. However, as business grew, the number of card types exploded, granularity was too coarse, standards were missing, and multi‑event support was limited.

Card 3.0 – Separates structure from style by introducing card templates and style sheets. The basic reusable unit becomes a block (e.g., image + description, player + description). Templates describe layout, style sheets describe visual details, and both are combined with page data to build the UI. Event handling is unified through a pingback framework and an event‑cascading protocol that can switch styles and routes based on execution results.

Card 4.0 – Adopts the “big‑frontend” concept. Layouts are described with XML files parsed by a dedicated renderer, and flex rules drive the layout. A layout‑pattern protocol defines component composition. Rendered components are placed into a reusable pool, supporting multiple reuse modes. Business teams can register custom tags and attributes, and Lua/JS scripts enable limited dynamic logic delivery. The scheme supports various deployment modes (full‑card pages, mixed‑card pages, block‑mix, structured non‑card lists, independent UI components) with low intrusion.

Supporting tools include Skin Designer (drag‑and‑drop layout generation) and Hot Swap (hot‑update of layout and script resources). Card 4.0 is already deployed in many iQIYI modules (children’s channel, VIP, wallet) and shows better learning curve, development efficiency and performance than previous versions.

Summary – Card 1.0 has been fully retired, Card 2.0 is near retirement, Card 3.0 is currently the main solution but is being gradually replaced by Card 4.0. The evolution follows a clear pattern: finer granularity (card → block → atomic control), standardized description (custom DSL → XML + flex), and increasing dynamic capability (static → configurable → scripted).

Future plans include expanding Card 4.0 to more business lines, improving tooling (layout generator, hot‑reload debugger) and eventually open‑sourcing the solution after documentation and examples are completed.