Componentization Architecture and Implementation for iQIYI Knowledge Mobile App

Componentization is essential for complex and iteratively evolved mobile applications. It involves decoupling a system by splitting and reorganizing functional modules, which requires strategies for module division, interaction, and build processes.

This article describes how iQIYI Knowledge designed and practiced an efficient mobile componentization solution that fits its business characteristics.

Background and Goals

iQIYI Knowledge runs on multiple platforms (mobile app, iPad plugin, Suike mobile app, and a standalone knowledge app). Different release timelines and feature sets caused code duplication across platforms, leading to high maintenance costs, increasing coupling, and difficulty scaling to new platforms. The goals of componentization are to:

Resolve multi‑platform code maintenance by defining horizontal and vertical component boundaries and reusing components across platforms.

Eliminate cross‑component calls and routing issues by clearly defining component boundaries and communication mechanisms.

Improve development efficiency and debugging by allowing independent compilation and testing of components.

Accelerate integration and testing, enabling each platform to pull required components via tooling.

The resulting architecture separates components into three horizontal layers—base components, functional components, and business components—and further refines each layer vertically.

Overall Technical Architecture

The lowest layer is the base component (baselib and componentService) that abstracts networking, pingback, database, logging, and utilities, shielding platform differences. Functional components sit above the base layer and provide common capabilities such as playback, history, payment, and sharing. Business components contain domain‑specific modules like search, feed, comments, and assignments. The topmost “shell” project integrates the selected components for each platform and handles framework initialization, platform‑specific logic, and non‑extractable business modules. Supporting infrastructure includes a ModuleRouter/UIRouter for inter‑component communication and a build system that assembles components into final packages.

Core Technical Implementation

Component Interaction

iOS uses a ModuleManager service that defines a non‑intrusive interface for all components. Each component registers its service interfaces with ModuleManager, which parses incoming data and forwards calls without direct dependencies. A Protocol‑based registration maps protocols to concrete classes via reflection, allowing dynamic lookup and decoupled invocation. Android adopts a similar approach with ZRouter, inspired by Java’s SPI mechanism, where each component provides a service interface that is registered at initialization, enabling callers to use the interface without knowing the implementation.

Component Routing

iOS registers URLs for navigation, supporting static, dynamic, and lazy loading registration modes. Lazy loading resolves URLs at call time, allowing custom handlers and clean resource release on plugin exit. Android implements UIRouter, which generates a routing table from @RouterPath annotations on Activities. A Gradle plugin injects automatic registration code via ASM at compile time, reducing boilerplate and improving build performance. The routing system also supports automatic version‑controlled registration for debug and release builds.

Build System

To quickly build components and projects, iQIYI Knowledge extended its existing CI pipeline. iOS components are managed as separate Git repositories and integrated via CocoaPods, with binary frameworks used for release builds. Jenkins with ParameterizedTrigger and shell scripts orchestrates component builds, handling dependency triggering, version auto‑increment, and notification integration. Android components are treated as independent modules or AARs, with build properties controlling platform‑specific code via macros. A unified gradle configuration manages dependency versions, Maven publishing, and conditional source vs. binary inclusion.

Summary and Outlook

The mobile side of iQIYI Knowledge has achieved all componentization objectives: clear business boundaries, cross‑platform component reuse, and significant gains in development and testing efficiency. Adding new platforms now requires only assembling existing components and minimal adjustments. Ongoing work will continue to refine the architecture and tooling to further support the growing knowledge business.