Tencent Game Live SDK: 100% Code Reuse Across Android, iOS, HarmonyOS via Kuikly

Background and Motivation

With the release of HarmonyOS Next, Tencent's game esports live streaming SDK — used in titles like CODM, QQ Speed, Need for Speed, Dream Star, and AOV — needed to adapt to the new platform. The SDK has a long history and similar product forms across games. The team aimed not only to complete the adaptation at low cost but also to maximize the value of the adaptation work by enabling code reuse across multiple game apps.

Initial estimates showed that adding a HarmonyOS version would require significant upfront effort to align with Android/iOS capabilities and ongoing dedicated HarmonyOS manpower. The team therefore evaluated adaptation strategies to reduce cost and amplify value.

Technology Selection: Kuikly Cross-Platform Framework

Kuikly is Tencent's internal cross-platform framework that uses Kotlin to develop for Android, iOS, HarmonyOS, Web, and mini-programs. The game live SDK team had already collaborated with Kuikly for nearly two years, with Android and iOS implementations in multiple projects (CODM, QQ Speed, Need for Speed) using Kuikly for cross-platform business logic and cross-business-line development. Kuikly had also completed HarmonyOS adaptation early and validated it in Browser, K-Game, and other businesses.

The team chose the "KuiklyUI for business, KuiklyBase for logic components" approach after comparing three implementation options. This decision leveraged Kuikly's proven stability, hybrid development characteristics, performance, and package size on Android and iOS.

Overall Architecture Design

The architecture follows a KMP (Kotlin Multiplatform) paradigm: "seek commonality, preserve differences." Common logic is written in Kotlin for cross-platform calls, while platform-specific differences are implemented in each platform's native language.

Page Hierarchy

The HarmonyOS implementation uses a minimal native Entry page (a @Entry decorated Page component, not an Ability). All visible pages are Kuikly-rendered. This thin native layer avoids heavy Ability components while still providing an entry point.

Kuikly Business Framework

The business layer uses a custom page routing system built on KuiklyNativeView rather than Kuikly's official router. KuiklyNativeView allows any native View to be mapped to a KuiklyView via Kuikly's custom component protocol, enabling KuiklyPage nesting (similar to Android Fragments). This capability, already validated on Android, was replicated on HarmonyOS and became the foundation for feature modularization.

Native Component Kuikly Integration

Native View to KuiklyNativeView Mapping

The team embedded a KuiklyPage inside a HarmonyOS native View, then wrapped it as a KuiklyNativeView. This allows KuiklyPage to nest other KuiklyPages recursively, giving the main page freedom to compose multiple KuiklyPages of arbitrary size, position, and hierarchy.

Full-Screen Transparent Popup as Kuikly Container

For non-full-screen scenarios (e.g., floating activity pages over Unity game surfaces), the team used a native full-screen transparent popup as a container hosting KuiklyNativeView. This avoids the heavyweight Ability approach while letting Kuikly business logic control content, transparency areas, and positioning.

Player Component Integration

Previously on Android/iOS, the player used native containers (Activity/ViewController) with Kuikly slots, leading to complex bidirectional bridging. For HarmonyOS, the team reversed the approach: the native player View is wrapped directly into a KuiklyPlayerView, letting the host KuiklyPager manage lifecycle, hierarchy, size, and position. This eliminates heavy glue code.

Danmaku and WebView Components

Danmaku (bullet comments) and WebView components were similarly wrapped as Kuikly components following the player pattern, enabling unified management within the Kuikly page hierarchy.

Feature Modularization and Cross-Product Sharing

The SDK is heavily operations-driven; successful features in one game often roll out to others. The team moved from a traditional monolithic Activity (where features A, B, C, D become tightly coupled over time) to a weakly coupled model:

Host page is an independent full-screen KuiklyPager.

Each feature (A, B, C, D) is its own independent KuiklyPager.

KuiklyNativeView enables nesting of KuiklyPagers.

KuiklyPager's design naturally enforces weak coupling: high data-sharing cost (only via launch parameters or event bus), no direct object references between Pagers. This makes spaghetti code difficult to create. Each feature owns its KuiklyPager lifecycle, satisfying resource isolation with negligible overhead.

Inter-feature communication uses Schema-based routing, evolved through v1.0 (initial adoption) and v2.0 (enhanced configuration management to handle Schema explosion).

Standardized Iteration Process

Atomic Infrastructure Development

Instead of writing thick native bridge layers with business-specific if-else logic, the team now exposes only necessary atomic native interfaces. This keeps the native layer thin and reusable across features.

Business Kuikly Standardization

Business logic is pushed to the Kuikly layer as much as possible, with native providing only atomic interfaces. Combined with Schema configuration management, pipeline release standards, and requirement review processes, this workflow has run stably for over a year on the game live SDK and was replicated for the HarmonyOS project.

Results

The HarmonyOS adaptation achieved:

100% business code cross-platform reuse across Android, iOS, and HarmonyOS.

Cross-game-app sharing across multiple titles.

Over 50% manpower savings compared to independent per-platform development.

Performance and product experience meeting expectations, aided by Kuikly's HarmonyOS functional completeness, high performance, dynamic capabilities, and stability.

Visual comparison of CODM radio hall across HarmonyOS, Android, and iOS shows consistent UI.

The effort not only delivered HarmonyOS support but also strengthened the overall cross-platform foundation for more stable and efficient operation across all projects.

References

Kuikly official documentation: https://kuikly.tds.qq.com/Introduction/arch.html Kuikly GitHub repository:

https://github.com/Tencent-TDS/KuiklyUI