背景

隨著鴻蒙的推出，客戶端跨平臺需求被推到了前所未有的高度，單純的 UI 跨端已無法滿足業(yè)務(wù)訴求，構(gòu)建Android/iOS/鴻蒙平臺的全跨端APP能夠最大幅度的降低業(yè)務(wù)開發(fā)成本，提升人效。并且行業(yè)內(nèi)研發(fā)模式的逐步改進，單周發(fā)版已經(jīng)成為常態(tài)，對于常規(guī)APP，動態(tài)化的訴求并不是很強。開發(fā)者普遍希望在保持原生優(yōu)良性能的同時，使用行業(yè)通用的UI開發(fā)語言，從而最大程度降低學(xué)習(xí)成本。

Kotlin 與 Compose 是 Google 官方推薦的 Android 開發(fā)語言與 UI 框架，也是深受開發(fā)者喜愛的應(yīng)用開發(fā)方案。與其他跨端方案相比，Kotlin Multiplatform 還具備高性能，與原生交互更靈活等優(yōu)點。因此騰訊視頻選擇了 Compose Multiplatform 作為全跨端APP的基礎(chǔ)。當(dāng)然，這套方案也存在不支持鴻蒙、iOS平臺混排能力受限、GC性能表現(xiàn)一般等一系列問題，使得落地的過程充滿了挑戰(zhàn)。經(jīng)過不懈努力，上述問題均已得到妥善解決，現(xiàn)在我們希望將這些解決方案開源，期待與全行業(yè)一同推動Compose跨端生態(tài)走向成熟。

 特性優(yōu)勢

ovCompose已經(jīng)在騰訊視頻鴻蒙平臺全面落地，成為鴻蒙平臺首個全跨端APP。同時 KuiklyBase 基礎(chǔ)能力已在騰訊視頻、QQ 瀏覽器、騰訊體育等10+款A(yù)PP廣泛落地。Android、iOS、鴻蒙三端一碼的開發(fā)方式，使得業(yè)務(wù)的開發(fā)效率得到大幅度地提升。隨著鴻蒙系統(tǒng)的發(fā)展，ovCompose 和 KuiklyBase 也會在未來進一步擴展到TV和PC端。

鴻蒙高性能

Kotlin鴻蒙適配有JS與Native兩種技術(shù)方案可供選擇，KuiklyBase最終選擇了Native方案。因為KN相比JS有更快的執(zhí)行速度，更好的三端一致性。

 

關(guān)于 JS 和 KN 的性能測試的數(shù)據(jù)如上圖所示。我們對 KN 和 Compose 兩者都進行了性能優(yōu)化，在Compose "小球碰撞" Demo 中。以 30 FPS 為最低極限，經(jīng)優(yōu)化小球數(shù)量由600提升到1500（Android 1600球），繪制性能提升150%。后續(xù)將開放更多優(yōu)化策略。

相關(guān)資料如下：

1、 JS 和 KN 性能測試詳細數(shù)據(jù)：https://docs.qq.com/sheet/DQXB4YmxQaENSdkpD?u=255d89f8184e4be69e865ce6001f298b&no_promotion=1&tab=BB08J2

2、 ovCompose 小球碰撞 Demo：https://github.com/Tencent-TDS/ovCompose-sample

3、 Kotlin 官方的 Benchmark ：https://github.com/JetBrains/kotlin/tree/master/kotlin-native/performance/ring

鴻蒙三明治架構(gòu)支持混排

鴻蒙平臺采用了 Skia 的渲染方案，能夠100%支持 Compose 語法和渲染能力。Skia 渲染使用 XComponent 組件作為畫布，通過三明治鏤空結(jié)構(gòu)，很好地解決了與原生組件的混排問題，原生UI可以展示在 Compose 上層或下層，滿足了絕大部分的業(yè)務(wù)需求。同時支持了 粘貼按鈕 等安全組件的混排，使得 Compose 無需申請權(quán)限也能使用系統(tǒng)能力。

 

三端高一致性

對于邏輯運行：由于在鴻蒙平臺采取 Kotlin-Native 方案，解決了 Kotlin-JS 使用 TaskPool 時，Kotlin 語法無法約束跨線程訪問的問題，保持了高度的三端一致性。

對于UI繪制：iOS、鴻蒙平臺均采用Skia渲染，Android底層使用Skia渲染，應(yīng)用層暴露了Paragraph/Canvas的繪制接口。所以基于Skia封裝后的Skiko可以完美還原Android繪制效果，達到三端一致的效果。三平臺均可以100%使用Compose的控件與繪制能力。

 

iOS多模態(tài)渲染解放混排能力

iOS端大量存量業(yè)務(wù)模塊高度依賴Compose與原生UI的混合編排能力，其靈活混排的技術(shù)實現(xiàn)及與原生UI性能標(biāo)準(zhǔn)的精準(zhǔn)對齊，是業(yè)務(wù)Compose化改造成功推進的核心前提。

Compose Multiplatform 官方在 iOS 端上使用 Skia + CAMetaLayer 實現(xiàn) UI 的渲染能力，這種方案的好處是與其他端表現(xiàn)完全一致，缺點就是與原生 UI 的混排能力較弱，且內(nèi)存占用較高，不適合多個 Compose 實例并存。因此我們必須考慮以下兩種方案：

1. 指令映射，即使用 UIKit 實現(xiàn)Compose Canvas 。

2. 組件映射：即將Compose組件映射為Native組件。

組件映射方案在組件層進行映射實現(xiàn)，是業(yè)內(nèi)最常見的跨端 UI 框架設(shè)計方案，實現(xiàn)難度相對較低，但存在后期維護成本高，多端不一致等問題。指令映射在畫布層進行映射實現(xiàn)，實現(xiàn)的邏輯層級更低也更加抽象，雖然開發(fā)難度相對較高，但卻可以充分利用 UIKit 豐富的渲染能力對Compose的繪制效果實現(xiàn)較高的還原度。

因此我們最終采用了指令映射的自研實現(xiàn)方案解決了 Compose 在 iOS 上面臨的諸多難題。這套方案也成功地在騰訊視頻 iOS 端核心業(yè)務(wù)場景落地。事實上，業(yè)務(wù)團隊甚至可以根據(jù)實際應(yīng)用場景在基于 UIKit 實現(xiàn)的自研指令映射方案或官方的Skia渲染方案之間進行自由切換，并且可以在 Runtime 期共存。

關(guān)于 UI 的多端一致性，文本渲染較為復(fù)雜，我們采取 Skia 將文本渲染成圖片，利用 CALayer 進行展示的方案，保持了高度的一致性。

 

Kotlin Native 內(nèi)存優(yōu)化

GC優(yōu)化

GC抑制

當(dāng)APP處于滑動等對幀率要求較高的場景，我們會短暫抑制GC，來換取更好的流暢度。

GC分段

不影響幀率情況下，進行更高頻次的 GC，降低 PSS 水位。通過分析 CMS（Concurrent Mark-Sweep）垃圾回收算法，發(fā)現(xiàn)其存在兩次 Stop-The-World（STW）暫停，并且第一次 STW 時間較短，第二次 Sweep 期間的 STW 較長。利用 GC 掛起的能力，我們在 Vsync 時進行 GC掛起，在 idle時進行 GC恢復(fù)。具體效果如下圖：

 

Sweep 優(yōu)化

Kotlin Native GC 在Sweep 階段，會有大量的munmap系統(tǒng)調(diào)用，導(dǎo)致STW時間過長，從而影響主線程。為此，我們將munmap移出STW階段，在STW階段僅做Page收集。在Resume后再進行集中 munmap。將第二次 STW時間降低到 1ms以內(nèi)。

 

KN堆Dump優(yōu)化

Kotlin Native（KN）支持生成堆內(nèi)存轉(zhuǎn)儲文件，用于內(nèi)存泄漏排查（類似 Android Profiler），但Dump過程需暫停所有KN線程，導(dǎo)致秒級界面凍結(jié)。針對不同平臺特性我們采用了不同優(yōu)化方案，從而達成線上可用的目標(biāo)。

鴻蒙系統(tǒng)

基于 Linux 內(nèi)核的 fork() 系統(tǒng)調(diào)用特性，采用「父進程無感知-子進程異步轉(zhuǎn)儲」方案實現(xiàn)零延遲內(nèi)存快照。

iOS系統(tǒng)

針對iOS系統(tǒng)無法支持fork的限制，我們重新設(shè)計了堆內(nèi)存分析流程，在保持性能的同時顯著降低主線程阻塞時間。

堆凍結(jié)階段：將堆內(nèi)存數(shù)據(jù)保存到緩存文件，這里的堆內(nèi)存是指 KN 堆用來分配對象內(nèi)存的幾種 Page 類，粒度很大，一種 Page 可能會有上千個對象，寫文件時無需解析 Page 內(nèi)容，所以耗時很少且不會因為對象數(shù)量的增加而顯著增加耗時。

線程恢復(fù)后：異步地從緩存文件中讀取對象內(nèi)容并寫到 Dump 文件，由于每次從文件讀取的只是對象大小數(shù)據(jù)，所以內(nèi)存消耗很低。

優(yōu)化后450MB 堆內(nèi)存轉(zhuǎn)儲耗時從 2.8 秒降低到 410 毫秒達到線上可用水平。該功能預(yù)計 6 月份上線。

方案對比

KuiklyBase組件生態(tài)

—Kotlin Native 堆棧還原組件

提供 Kotlin 異常堆棧還原，方便定義 Kotlin異常對應(yīng)的Kotlin 代碼行號、方法名等。

—Kotlin Native/ ArkTS 互調(diào)用組件

提供 ArkTS 與 Kotlin Native 跨語言訪問場景的解決方案，支持基礎(chǔ)類型、閉包、ArrayBuffer等類型互轉(zhuǎn)，統(tǒng)一的生命周期管理，支持跨線程同步調(diào)用，支持跨Runtime的服務(wù)發(fā)現(xiàn)，為開發(fā)者提供簡便的跨語言互調(diào)用能力。

—資源管理組件

本項目基于Kotlin Multiplatform技術(shù)，構(gòu)建了一套跨平臺原生資源管理解決方案，支持Android、iOS及HarmonyOS三大移動端平臺。通過構(gòu)建時同步生成類型安全的資源訪問類（Resource Class），結(jié)合Kotlin/Native（klib）/ Kotlin/Jvm（aar）的標(biāo)準(zhǔn)化資源封裝機制，實現(xiàn)了多平臺資源統(tǒng)一管理與編譯器強校驗，為開發(fā)者提供與Android R類相仿的資源調(diào)用體驗。

—原子操作組件

基于Kotlin 官方提供的多平臺原子操作庫，旨在以高效且符合 Kotlin 慣用語法的方式實現(xiàn)線程安全的并發(fā)編程，提供輕量級的原子類型（如 AtomicInt、AtomicReference），支持原子讀寫、CAS（Compare-And-Swap）等操作，無需顯式鎖即可實現(xiàn)線程安全。

—協(xié)程組件

基于Kotlin 官方提供的協(xié)程庫，旨在簡化異步和并發(fā)編程，通過輕量級協(xié)程替代傳統(tǒng)線程和回調(diào)機制。支持協(xié)程構(gòu)建器、調(diào)度器、掛起函數(shù)、結(jié)構(gòu)化并發(fā)、流處理、通信與同步、異常處理、超時控制等能力。

—序列化組件

基于Kotlin 官方提供的多平臺序列化庫。專為 Kotlin 語言設(shè)計，支持高效、類型安全的對象序列化與反序列化。多格式支持、編譯器插件集成、兼容Kotlin類型安全與空安全。支持嵌套對象、泛型類、密封類（sealed class）等復(fù)雜類型。

—日期時間處理庫

基于 Kotlin 官方提供的多平臺日期時間處理庫，簡化跨平臺的日期和時間操作。支持時區(qū)處理、時間運算。

—IO庫

基于 Square 提供的高效 I/O 庫，旨在簡化輸入輸出操作。提供高效緩沖區(qū)管理、同一流抽象、智能數(shù)據(jù)移動。

—不可變集合庫

基于 Kotlin 官方提供的不可變集合庫，專注于為開發(fā)提供線程安全、高效且符合函數(shù)式編程范式的數(shù)據(jù)結(jié)構(gòu)。提供不可變的集合接口，確保集合創(chuàng)建后不可修改，避免意外數(shù)據(jù)變更。

—并發(fā)集合庫

基于StatelyConcurrency提供的并發(fā)集合庫，簡化跨平臺開發(fā)中的狀態(tài)管理和并發(fā)控制設(shè)計。支持線程安全集合、并發(fā)控制、同步機制。針對 Kotlin/Native 的嚴格內(nèi)存模型優(yōu)化，減少線程切換開銷。簡化狀態(tài)管理。

—Lottie動畫庫

基于 Airbnb 開源的跨平臺動畫渲染庫，能夠?qū)?Adobe After Effects 設(shè)計的動畫轉(zhuǎn)換為輕量級 JSON 文件，并在多平臺上高效渲染。提供豐富的動畫控制、動態(tài)屬性修改、輕量高效。

—PAG 動畫流解決方案

騰訊開源的一套跨平臺動畫工作流解決方案，專注于將 Adobe After Effects (AE) 動畫高效轉(zhuǎn)換為輕量級文件，并在多終端渲染。支持AE動畫無縫導(dǎo)出、運行時編輯、高性能渲染、配套工具鏈完善。

—數(shù)據(jù)庫

基于 SQLite 封裝的輕量級、嵌入式的關(guān)系型數(shù)據(jù)庫，嵌入式設(shè)計、標(biāo)準(zhǔn)SQL支持、事務(wù)與ACID合規(guī)。輕量高效、弱類型系統(tǒng)，并且支持高級功能擴展（索引、觸發(fā)器、視圖等）

—工具庫

屏蔽Android/iOS/Harmony系統(tǒng)平臺差異，對外部統(tǒng)一提供常用的工具api集合作為業(yè)務(wù)開發(fā)的強力支撐。包括不限于 App信息管理(名稱、版本號、安裝時間、更新時間、包名等)、設(shè)備信息管理(設(shè)備類型、品牌、制造商、系統(tǒng)版本、電池狀態(tài)、亮度、內(nèi)存信息等)、屏幕信息管理（寬度、高度、分辨率、是否亮屏、鎖屏、屏幕旋轉(zhuǎn)、狀態(tài)欄、安全區(qū)域獲取、全屏模式等）、傳感器管理（重力、震動、陀螺儀、加速度）、前后臺狀態(tài)管理、音頻及音頻焦點管理、加解密管理(3DES、RSA、AES)、字符編碼（UTF-8、UTF-16、BASE64）、存儲空間管理、網(wǎng)絡(luò)狀態(tài)監(jiān)聽、沙盒目錄獲取、監(jiān)聽分屏/浮窗等狀態(tài)、圖片保存相冊能力。

—網(wǎng)絡(luò)庫

提供基于HTTP協(xié)議的POST、GET請求能力以及關(guān)鍵信息采集。

實現(xiàn)原理

KN鴻蒙平臺適配

kotlin 1.9 使用的LLVM 11，kotlin 2.1升級到LLVM 16，但是鴻蒙平臺能夠支持的版本在LLVM 12 ~ 15，蘋果和鴻蒙都是基于公共版本的LLVM進行修改，增加了自己的特性優(yōu)化，蘋果相對好的點在于公共版本的LLVM中包含有蘋果的target，所以鴻蒙版本的LLVM既可以支持iOS，又可以支持鴻蒙平臺。（KukilyBase-Kotlin當(dāng)前基于2.0.21進行鴻蒙適配）

—常規(guī)方案：常規(guī)的Kotlin適配思路是分別使用鴻蒙和蘋果的LLVM進行編譯，這種方案的好處是修改簡單，且不存在兼容性問題。缺點是由于Kotlin本身不支持多l(xiāng)lvm架構(gòu)，導(dǎo)致鴻蒙平臺的kotlin和iOS平臺要進行分別編譯，需要依賴不同的Kotlin版本。

—KuiklyBase方案：在第一步Kotlin IR轉(zhuǎn)LLVM IR時采用蘋果的LLVM 11，在LLVM IR生成可執(zhí)行文件時使用鴻蒙的LLVM 12，這樣既可以滿足訴求，Kotlin本身也無需進行架構(gòu)調(diào)整。

 

KN性能優(yōu)化

完成適配后，我們發(fā)現(xiàn)卡頓情況非常嚴重，從而進一步對Kotlin-Native性能進行評估，我們采用了官方Benchmark進行對比，測試發(fā)現(xiàn)鴻蒙耗時是iOS相同性能機器的2.48倍。

 

我們需要針對鴻蒙平臺進行一系列的優(yōu)化，經(jīng)過初步分析，我們也規(guī)劃了性能優(yōu)化的初步優(yōu)化思路。

 

內(nèi)聯(lián)優(yōu)化

我們分別對比了相同benchmark生成的Kotlin IR、LLVM IR文件。發(fā)現(xiàn)LLVM IR在內(nèi)斂上更加充分，特別是對于關(guān)鍵函數(shù)，例如EnterFrame等，反觀鴻蒙平臺此類優(yōu)化更少。

 

嘗試添加always inline后，發(fā)現(xiàn)程序性能得到了較為顯著的影響。但相對iOS仍然有一定差距。通過分析LLVM的內(nèi)聯(lián) pass 發(fā)現(xiàn)，在處理 EnterFame 等函數(shù)時，會對比cpu feature的兼容性，Kotlin和框架內(nèi)部C++代碼在生成LLVM的函數(shù)時，他們各自攜帶的cpu feature不一致，導(dǎo)致無法進行內(nèi)聯(lián)。配置正確的屬性后，此問題得到修復(fù)。

 

ThreadLocal引發(fā)的性能低

通過對 Benchmark 中耗時超 iOS 的 case 進行深度分析，最終發(fā)現(xiàn)如下高頻堆棧。線程私有數(shù)據(jù)的性能測試結(jié)果表明 Ohos 耗時波動較大。Ohos 耗時是 iOS 的 2-3 倍。（展示0ns是由于初期鴻蒙trace工具不完善導(dǎo)致，現(xiàn)已修復(fù)）

 

由于Kotlin-Native在內(nèi)存分配時都依賴ThreadLocal來訪問線程獨立的Page，故訪問頻率極高，導(dǎo)致性能低下。分析發(fā)現(xiàn)鴻蒙平臺默認采用了軟件模擬的thread_local。所以我們在編譯時通過參數(shù)強制使用硬件thread_local，整體性能提升了30%。

協(xié)程性能優(yōu)化

將 Jetbrains 的 Compose 成功適配到 Ohos 后，長列表的滑動過程中頻繁出現(xiàn)卡頓現(xiàn)象。trace分析發(fā)現(xiàn)異常的處理花費了大量的時間。

 

經(jīng)技術(shù)架構(gòu)分析，Compose Multiplatform 框架的協(xié)程調(diào)度機制深度依賴異常處理模型實現(xiàn)任務(wù)恢復(fù)與取消控制。其底層實現(xiàn)中，KN運行時將異常處理橋接至C++異常體系，該設(shè)計在運行時會產(chǎn)生顯著性能損耗：當(dāng)異常觸發(fā)時，系統(tǒng)需沿調(diào)用棧進行逐級回溯以定位匹配的異常捕獲點，其時間復(fù)雜度與調(diào)用棧深度呈正相關(guān)。更值得注意的是，該過程伴隨大量C++異常對象的動態(tài)構(gòu)建與析構(gòu)操作，頻繁的內(nèi)存分配與釋放行為進一步加劇了執(zhí)行時延，導(dǎo)致關(guān)鍵路徑上的協(xié)程調(diào)度效率受限于異常處理機制的性能瓶頸。

同時鴻蒙系統(tǒng)libhilog.so捕獲了拋出的異常進行處理，造成了大量延遲，與鴻蒙專家溝通后得到妥善優(yōu)化。最終長列表在滑動場景能夠穩(wěn)定在120Hz，處理方式如下：

—緩存或放棄部分關(guān)鍵位置的異常，降低異常處理的耗時與頻率。

—解決libhilog.so系統(tǒng)庫對于異常的非法捕獲。

調(diào)試性能優(yōu)化

使用 Jetbrains 的 Kotlin Native debuging 腳本后，調(diào)試斷點及打印變量耗時遠超 Native 。通過trace分析發(fā)現(xiàn)其 KDS 與 LLDB 交互極為原始和簡單。

 

 

經(jīng)技術(shù)架構(gòu)分析與處理，在 KDS 與 LLDB 上運用流程合并、復(fù)用、緩存、預(yù)加載潛在下一跳、局部調(diào)試的可容錯優(yōu)化等手段提高其通信和處理效率。整體性能視實際情況提升數(shù)倍至幾十倍（提升幅度隨調(diào)試棧的變量加密加深等因素影響），近似 Native。

鴻蒙繪制不同步問題解決

由于兩種組件屬于獨立的繪制層，在鴻蒙系統(tǒng)中存在不同步的問題。整體效果如圖，Compose的列表混排ArkUI的元素進行滾動，兩個同步向上進行運動，由于不同步，UI銜接處會展現(xiàn)出空白區(qū)域，出現(xiàn)割裂的現(xiàn)象。

 

核心問題時鴻蒙采用的是集中渲染架構(gòu)，XComponent的獨立繪制模式與ArkUI的繪制發(fā)生在不同的進程，無法保證完全不同。所以我們采用XComponent的Texture模式，將內(nèi)容繪制到FBO中，由FBO參與原有的ArkUI的繪制節(jié)奏，來保證完全的同步。

 

iOS多模態(tài)渲染

在基于 UIKit 進行渲染的基礎(chǔ)思路上，我們也發(fā)現(xiàn)了如 CALayer 重疊、未正確放置、無法復(fù)用等問題。對于Android來說，其是獨立繪制架構(gòu)，每個進程自己完成內(nèi)容的繪制，所以畫布是一整塊，內(nèi)容都繪制在其中，通過Skia的PictureRecorder命令錄制功能進行命令的快速回放。但這種模式在iOS集中渲染架構(gòu)上就不太適用了，需要有一個工具來進行差量處理繪制命令。所以我們設(shè)計了基于iOS的PictureRecorder局部更新架構(gòu)。

 

 

在PictureRecorder中，我們對繪制命令進行差量，只更新變化的部分，從而提升繪制效率。PictureRecorder核心就是我們通過hash來判斷繪制指令是否發(fā)生變化，常規(guī)的這種方式能夠提升繪制效率，但當(dāng)頁面無比復(fù)雜時，hash計算偶爾也會變成一種負擔(dān)。

PictureRecorder進行了進一步升級

我們優(yōu)化的核心思路是，通過增量hash來減少hash的計算量。每一個 draw 函數(shù)執(zhí)行的時候，都會對當(dāng)前的 hash 和 指令id 進行一次合并。并計算出最終的 hash。這個 hash 記錄了一次完整地使用。增量 hash 的目的是減少 diff操作，這種方式可以有效地減少，兩次指令相同的比較。在壓力測試中還發(fā)現(xiàn) OC 對象的創(chuàng)建和釋放耗時也會被放大。這種情況在騰訊視頻復(fù)雜頁面回遷的過程中尤其明顯，因此，這里還將原先由 OC 對象代表的指令，改為了非常簡單的 C 結(jié)構(gòu)體。之前的OC 閉包也去掉了。

 

 

優(yōu)化效果：以騰訊視頻的視頻播放頁面為例，首次渲染耗時降低13%，再次渲染耗時降低56%。

與KuiklyUI的差異

跨端框架自渲染與原生渲染在性能表現(xiàn)與多端適配層面各具優(yōu)勢。為滿足業(yè)務(wù)場景的差異化需求，騰訊大前端Oteam同時進行兩個方案探索。

—原生渲染方案 KuiklyUI：側(cè)重于靜態(tài)化+動態(tài)化雙運行模式，采用輕量原生渲染保持原生UI體驗并具備高度一致性，并基于原生組件映射的方式支持Compose API（本次已同步推出），支持H5和小程序（6月底推出）。

—自渲染方案 ovCompose：專注于全面對齊 Compose Multiplatform 標(biāo)準(zhǔn) API，采用自渲染方式實現(xiàn)鴻蒙平臺的適配，確保三端高度一致性。針對 iOS 上較多的存量業(yè)務(wù)，提出了多模態(tài)渲染方案解決低端iPhone內(nèi)存緊張、混排原生視圖、手勢等問題。

開源說明

此次開源共包含5個倉庫，包含了ovCompose和KuiklyBase。倉庫Group地址為：https://github.com/Tencent-TDS

 

 

計劃

隨著這幾年的快速發(fā)展，KMM生態(tài)得到了長足的發(fā)展，Kotlin-Native的執(zhí)行性能在很多方面已經(jīng)超越了Kotlin-JVM，但目前 Compose Multiplatform 跨平臺技術(shù)還沒有達到成熟的狀態(tài)（特別是GC），ovCompose & KuiklyBase將持續(xù)優(yōu)化，為開發(fā)者帶來體驗更好、性能更強的跨端開發(fā)體驗。以下是我們重點優(yōu)化的方向：

—GC在業(yè)務(wù)場景的表現(xiàn)

—Kotlin-Native組件化

—Kotlin-Native的開發(fā)體驗優(yōu)化

—UIKit渲染模式進一步對齊Skia 的渲染