How MYKMP Enables One-Code-Three-Platform Development for Alipay’s Mobile Apps

What is MYKMP

MYKMP is Alipay’s native cross‑platform solution based on the community Kotlin Multiplatform and Compose Multiplatform stacks. It shares business logic and UI code across three platforms (Android, iOS, HarmonyOS) with a single codebase, reducing development and maintenance effort while preserving native flexibility and performance. Internally it is also called “Bundle 3.0”.

Development started in August of last year and, after more than a year of work, the framework now runs stable daily traffic at the hundred‑million level within Alipay.

This article gives an overview of the overall construction and a detailed look at the HarmonyOS version’s architecture and engineering.

Why We Built This Framework

Previously, mobile development only needed to handle Android and iOS. With the emergence of HarmonyOS, a third platform introduced a huge challenge: how to iterate efficiently across three platforms while keeping business logic consistent. C++ was an option but was hard to apply at scale for rendering and debugging. Kotlin, being modern, type‑safe, and supporting both functional and object‑oriented paradigms, offered an easier migration path for Android/Java developers and was supported by JetBrains’ stable Kotlin Multiplatform release.

Therefore we decided to develop MYKMP to provide a unified “three‑platform‑one‑code” development system for Alipay, delivering near‑native experience while significantly lowering overall development cost.

Differentiation on Top of the Community Stack

Optimized package size, GC, and runtime memory usage

Optimized startup and runtime paths

Improved scrolling experience

Enhanced stability (crash, ANR)

Optimized multi‑touch states and mixed rendering issues

Resolved font rendering differences with native systems

Addressed compatibility with Chinese OEM ROMs

Supported native rendering pipeline and asynchronous rendering

Other improvements

Construction for Billion‑Scale Applications

We built our own APP on top of the community Android/iOS versions, but Alipay’s long‑standing application requires far more complex engineering, experience standards, and release processes.

Our mPaas team previously shared an article on Alipay’s containerized Android framework, which introduced a modular “Bundle” architecture. MYKMP adopts a similar “Bundle 3.0” structure that can package three‑platform artifacts with a single click.

SampleProject
|--androidProject
|--common
|   |--kmp
|--gradle
|--iosProject
|--ohosProject
|--...

The engineering platform defines a three‑layer integration structure and corresponding scaffolding.

We use a native C++ base and a self‑developed IDL‑based Tecla API to bridge decades of APP capabilities across platforms, enhancing KMP capabilities on each native platform.

HarmonyOS Architecture Design and Engineering

Overall Architecture

Kotlin’s HarmonyOS adaptation uses two technology options (Kotlin‑Native / Kotlin‑JS). After extensive research and multiple evaluation rounds, we chose to extend the official Compose implementation by adding a nativeTarget→ohosMain target. The dependency chain progresses from skia → skiko → compose‑multiplatform‑core → compose‑multiplatform, finally compiling the produced klib into a dynamic library integrated into Alipay’s HarmonyOS project.

On HarmonyOS, we rely on the system‑provided XComponent rendering component to bridge Skiko for screen rendering. XComponent holds a Surface used by Skia as the canvas, allowing Compose UI to draw directly onto the surface while synchronizing with the system’s vsync signal.

Framework Design

To hide cross‑language complexities from business code, we implemented a native framework bridge in C++ that smooths out language‑level interactions, allowing developers to focus on business logic.

We introduced a three‑tier architecture on the native side: MicroPage/Page/App. On the ETS side we expose two key components: XComponentPage – an EntryPage‑type component XComponentWidget – an embeddable component

These provide flexible adaptation for various scenarios and future extensibility.

On the Kotlin side we provide a suite of Delegates that synchronize native component lifecycles with the app, exposing abstract classes MicroActivity, MicroPage, and Composable as entry points. The framework guarantees strong consistency between the Compose lifecycle and the native XComponent lifecycle.

Rendering to Screen

Business code does not need to know how XComponent renders. The framework ensures that the onLoad and onDestroy callbacks fire correctly and routes window lifecycle management so that Composable and XComponent share the same lifecycle.

The key adaptation in Skiko is adding SkiaLayer.ohos.kt.

Cross‑Language Interaction

Kotlin compiles to a dynamic library on HarmonyOS, so interaction with ArkTS (HarmonyOS native language) requires a C‑level bridge. We provide a bidirectional channel: ArkTS can call Kotlin via KotlinChannel, and Kotlin can invoke ArkTS via ArkTsChannel.

The channel implementation includes:

Using dlopen/dlsym on the C side to call Kotlin functions annotated with @CName.

Exposing NAPI interfaces via cinterop for type conversion.

Maintaining an ArkTS object table on the Kotlin side for per‑business object storage.

Thread‑safety guarantees for main‑thread and background‑thread calls.

Converting Kotlin callbacks to StableRef pointers for async ArkTS callbacks.

Product Integration

On HarmonyOS we use Kotlin/Native with cinterop to interact with C code. All Kotlin and native klibs are compiled into a single large dynamic library, while platform‑specific ETS code remains in separate .har files. The Kotlin Runtime adds roughly 12 MB, including libraries such as kotlinx‑atomicfu, kotlinx‑coroutines, kotlinx‑io, okio, kotlinx‑datetime, kotlinx‑serialization, kotlinx‑collections‑immutable, Skia binaries, and Compose UI modules.

We trim exported symbols to only those annotated with @CName, avoiding exposure of complex Kotlin classes or interfaces.

GC Performance Optimization

Kotlin/Native’s default GC (PMCS) caused noticeable STW pauses during heavy scrolling because Compose creates many small objects. We switched to the CMS algorithm and tuned thresholds to reduce pause time.

Algorithm Switch

Alipay’s Kotlin 2.1.0 now uses CMS instead of PMCS.

Threshold Tuning

We adjusted FixedBlockPage size to 16 KiB, reduced max block count to 64, and set both targetHeapBytes and minHeapBytes to 20 MiB, smoothing heap growth and preventing frequent GC spikes.

uint8_t* CustomAllocator::Allocate(AllocationSize size) noexcept {
    RuntimeAssert(size > AllocationSize::cells(0), "CustomAllocator::Allocate cannot allocate 0 bytes");
    CustomAllocDebug("CustomAllocator::Allocate(%" PRIu64 ")", size.inBytes());
    uint64_t cellCount = size.inCells();
    if (cellCount <= FixedBlockPage::MAX_BLOCK_SIZE) {
        return AllocateInFixedBlockPage(cellCount);
    } else if (cellCount > NextFitPage::maxBlockSize()) {
        return AllocateInSingleObjectPage(cellCount);
    } else {
        return AllocateInNextFitPage(cellCount);
    }
}

After extensive testing, memory peak reduced by ~180 MiB and GC efficiency improved markedly; on HarmonyOS the 90th‑percentile native heap dropped by 176 MiB compared with the baseline.

GC Sliding Suppression

During user‑initiated scrolling, we pause STW GC and resume after scrolling ends, also lowering the regular GC interval when Compose pages are inactive to reduce system resource consumption.

Current Application Scope

Many Alipay business scenarios have already adopted MYKMP, achieving at least a 50% reduction in development cost compared with separate three‑platform development, while ensuring consistent business logic across platforms.

Future Sharing Plans

We will continue to publish deep‑dive articles on topics such as MYTAB three‑platform architecture upgrades, MYKMP scrolling experience optimization, engineering system construction, startup optimization, AI‑assisted development, rendering architecture upgrades, compilation breakthroughs, and monitoring system building.