Kuikly是騰訊廣泛應用的跨端開發框架，基于Kotlin Multiplatform技術構建，為開發者提供了技術棧更統一的跨端開發體驗，由騰訊大前端領域 Oteam(公司級)推出。目前已有20+業務深度使用，服務業務的總頁面數1000+、日活用戶超5億，滿足了這些業務在眾多場景下的各類復雜需求(應用場景案例 )。Kuikly 作為騰訊端服務聯盟的重要成員，將持續推動跨端開發的技術創新和生態建設。

本次是在蘋果發布最新iOS 26 系統的背景下，Kuikly新增全新“液態玻璃”適配，進一步豐富平臺特性支持、助力業務體驗提升。

一、引言

在今年的 WWDC25 上，蘋果發布了其近十多年來最重要的一次視覺設計革新 —— 液態玻璃(Liquid Glass)。這種全新的設計語言，以其半透明3D質感和動態流體效果，為用戶創造了前所未有的沉浸式體驗，也讓軟件與硬件的界限變得更加模糊。

圖片 1 全新液態玻璃設計

“液態玻璃”的出現，將一個跨端開發領域中長期存在的根本性問題，以一種前所未有的方式重新推回到了聚光燈下：一個跨端框架，應該如何處理與宿主系統之間的關系?

這背后是兩種截然不同的架構路線：

?      自繪渲染(Self-Rendering)：追求在所有平臺上提供像素級一致的體驗，通過自帶的渲染引擎在系統畫布上繪制所有UI，從而實現最大程度的控制力和跨平臺一致性。

?      原生渲染(Native-Rendering)：致力于將框架的抽象層無縫對接到原生系統的UI組件和渲染管線上，以最大化地利用平臺特性、保證性能和跟進系統級的創新。

過去，關于這兩種路線的討論更多集中在性能和一致性的權衡上。而“液態玻璃”的出現，則將“ 跟進平臺創新的能力 ”這一維度，提升到了一個新的高度。本文將基于這一背景，分析“液態玻璃”對跨端開發的影響，并結合 Kuikly 在“原生渲染”路線上的探索與實踐，分享我們的經驗與思考。

圖片 2 基于Kuikly實現的液態玻璃demo效果預覽

二、 什么是“液態玻璃”?

“液態玻璃”是蘋果繼 iOS 7 的扁平化之后，在 UI 設計上的一次重要演進，它標志著UI設計正從“扁平化”向“沉浸化”過渡，其核心在于對光學、材質和縱深感的全新探索。

從蘋果給我們的解讀看，這一設計的核心特征主要體現在兩方面：

?      光學特性與動態流動性：“液態玻璃”能實時根據背景內容和環境光線進行“折射”和“反射”，使UI元素的顏色和光澤隨上下文動態變化。

?      多層級界面結構： 通過將UI分為背景、內容和懸浮的互動層，創造出顯著的空間感與深度。

這些特征已在最新的iOS 26系統中得到廣泛應用。例如，App圖標現在由多層玻璃構成，可動態適應主題色;Safari的懸浮工具條在滾動時也會自動收縮，以保證內容的全屏呈現。

圖片 3 蘋果液態玻璃效果展示

但與以往的風格迭代不同，“液態玻璃”的實現并非純粹的視覺技巧，而是深度依賴于系統底層的圖形處理能力。它不再像傳統設計那樣模擬紙張、油墨等物理隱喻，而是通過調用硬件加速的渲染管線來直接創造光線與材質的交互效果。

這種變化意味著，UI效果的實現方式發生了根本改變：從軟件層面的“模擬”，轉向了對底層硬件能力的“直接調用” 。而這一轉變，也給現有的跨端框架帶來了新的技術挑戰。

三、 不同架構路線的適配分析

“液態玻璃”的推出，對應用開發者提出了新的要求。隨著用戶逐漸習慣系統級應用所提供的流暢、靈動的“液態玻璃”視覺效果，未適配的應用在體驗上可能會出現割裂感。因此，如何有效跟進這一設計趨勢，成為開發者需要考量的問題。

面對這一變化，基于不同架構路線的跨端框架，其適配路徑和成本也表現出顯著差異。

3.1 自繪渲染路線

對于采用自繪渲染路線的框架(如CMP、Flutter)而言，其核心特點是在系統提供的畫布上，通過自帶的渲染引擎(如 Skia)繪制全部 UI。這種架構在保證跨平臺視覺一致性上具備優勢，但在適配“液態玻璃”這類深度依賴原生系統的特性時，則面臨著獨特的挑戰。

因為“液態玻璃”并非簡單的視覺濾鏡，而是與系統渲染器(metal)及核心動畫(Core Animation)深度綁定的硬件加速效果，自繪框架無法直接調用系統 API 來實現。其適配路徑通常是通過自定義著色器(Shaders)或圖像處理技術，在自身渲染引擎內對原生效果進行視覺上的模擬。這種模擬不僅成本高，結果也往往不盡人意：性能和保真度較低，視覺效果難以完全對齊原生。更重要的是，這種架構上的不匹配會成為長期問題。未來任何依賴系統級深度、光線或動態效果的更新，自繪框架都將再次面臨被動的“模擬”難題。

圖片 4 Flutter關于如何實現液態玻璃的討論

正如Flutter社區中部分開發者所言：“重新實現各種設計語言的成本和難度正變得越來越高。” 這體現了自繪渲染路線在設計理念上的核心取舍：優先保障跨平臺視覺的絕對一致性，相應地，在跟進特定平臺的深度創新時則需要付出更高的工程成本。

3.2 原生渲染路線

與自繪路線不同，以Kuikly、Hippy、ReactNative等為代表的“原生渲染”框架，在適配平臺級創新時則更具天然優勢。這類框架通過將上層抽象映射為原生 UI 組件來進行渲染。

這種架構使得它們能夠直接利用和封裝系統發布的新特性。當蘋果推出“液態玻璃”時，原生渲染框架可以通過調用系統提供的原生 API，讓框架內的組件直接獲得新效果的加持。

這一路徑的優勢在于：

?      較低的適配成本：無需從零模擬，主要工作在于對原生 API 的封裝和框架層面的暴露，開發成本相對較低。

?      較高的保真度：由于直接使用系統能力，最終呈現的效果在視覺和性能上能與原生應用保持一致。

?       可持續的演進能力：框架的設計理念決定了它能與宿主系統的創新保持同步。未來的平臺級更新，同樣可以通過相似的路徑被快速集成。

圖片 5 Kuikly 原生渲染架構圖

對于 Kuikly 而言，原生渲染的價值不止于 UI 呈現。更重要的是，這種架構選擇確保了框架能夠與宿主平臺的技術演進保持同步，使得基于 Kuikly 的應用能夠持續、低成本地集成系統級創新，給用戶帶來與系統原生應用相同的優質體驗。

四、Kuikly的適配經驗

作為致力于提供高性能、原生UI渲染的跨端框架，Kuikly現已完成對“液態玻璃”的首階段適配，并對外開源發布。Kuikly的適配工作并非簡單的UI改造，而是充分利用原生提供的基礎能力，在框架渲染層和DSL驅動層兩方面進行擴展，旨在為開發者提供一套便捷、低成本的適配方案。

4.1 適配原則

Kuikly框架在適配“液態玻璃”時，需要平衡一個核心問題：如何在保持我們“通過Kotlin跨端層組合原子組件以最大化UI一致性”的核心理念，與“液態玻璃”所強調的平臺原生特色之間做出選擇。面對這一挑戰，我們選擇靈活處理：將用戶體驗置于最高優先級，在追求一致性的同時，積極擁抱平臺特色。

我們認為，跨端一致性的重點，是在不同平臺提供符合用戶習慣的優質體驗，而不是追求UI像素的絕對相同。因此，我們選擇以一種靈活、務實的方式來擁抱平臺特色。對于常用組件，盡可能在跨端層抹平差異，提供一致的開發體驗;同時通過“自定義組件”來解決系統對高級組件所做的特殊優化，例如疊加的復雜交互動畫效果。這種設計思路，使得我們能夠在統一代碼庫的基礎上，仍能充分發揮平臺原生體驗的優勢。

4.2 開發者友好的API設計

Kuikly在API設計上同樣追求簡潔與高效。對于常用的`View`、`Button`等組件，為了適配“液態玻璃”，我們沒有引入新的獨立組件，而是為現有組件提供了簡潔的視圖屬性擴展。例如，開發者只需通過一行 `glassEffectIOS()` 代碼，即可為任意容器視圖啟用液態玻璃效果。

這種設計的主要優勢在于，它避免了開發者在UI代碼中編寫大量平臺相關的 IF/ELSE 判斷。框架會自動處理平臺差異：當代碼在支持的iOS平臺運行時，啟用液態玻璃效果;而在其他平臺或舊系統版本上，則平滑降級為默認樣式，確保界面表現正常。通過這種方式，Kuikly將復雜的平臺差異管理進行了內部抽象，讓開發者可以更專注于業務邏輯的實現。

圖片 6 Kuikly 液態玻璃組件示例

4.3 適配方案與技術實現

針對不同類型的組件，我們采取了差異化的適配策略：

?      基礎組件： 對基礎的容器組件如View、Button，我們通過原生屬性擴展的方式實現適配。同時，也提供了獨立的 `LiquidGlass` 與 `LiquidGlassContainer` 組件(類似于BlurView 的用法)，滿足更靈活的布局需求。

?       復雜組合組件： 對于 `Input`、`alertDialog` 等組合型組件，支持通過組合效果，讓業務以較低成本按需適配。

?       iOS特有組件： 對 `Slider` 和 `Switch` 這類在iOS 26上擁有全新動態效果的控件，我們在渲染層新增了iOS平臺專屬的組件進行封裝，這確保了這些控件在具備液態玻璃效果的同時，能夠獲得與原生完全一致的交互體驗。在上層DSL使用上，我們封裝了平臺差異，開發者無需修改原有組件的使用代碼，只需添加 `enableGlassEffect(true)` 屬性，即可輕松啟用。

4.4 兼容性保障

在適配新特性的同時，Kuikly也全面考量了兼容性問題：

?       對舊系統的兼容：對于使用了液態玻璃的組件，Kuikly封裝的系統原生組件會自動處理兼容性，在舊系統上平滑切換為原有樣式。而對于組合類組件，框架也提供了兼容性保障，業務代碼無需擔憂在舊系統上出現異常。

?      對其他平臺的兼容：對于使用了液態玻璃的代碼，Kuikly框架保障在Android等不支持的平臺上能夠自動降級到默認實現，避免業務UI代碼編寫大量的平臺判斷邏輯 。利用這一機制，開發者可以在iOS上采用最新設計語言，同時無需為其他平臺維護一套獨立的UI，極大地降低了開發和維護成本。

篇幅所限，更多技術實現細節，歡迎訪問文末Kuikly官網或Github倉庫直接獲取源碼。

五、總結與展望

“液態玻璃”的出現，為我們提供了一個絕佳的案例，去重新審視跨端框架的兩種核心路徑：是“抽象并抹平平臺差異”，還是“集成并利用平臺能力”?

過去，跨平臺開發的核心挑戰是保證體驗的一致性。但隨著操作系統能力的不斷發展——從空間計算(AR/VR)到硬件加速的AI能力——“抽象”的成本，可能正在變為錯失平臺最有價值的創新。一個框架的價值，不再僅取決于它能“抹平”什么，更在于它能“釋放”什么。

因此，Kuikly在“液態玻璃”上的適配，并非一次簡單的功能跟進，而是驗證了這樣一種可能：真正的跨平臺，可以既不必以犧牲平臺深度特性為代價，又將原生創新直接轉化為自身優勢。

對于開發者而言，選擇一個跨端框架，不僅是工程和技術層面的權衡，更是決定了App在未來競爭中能否保持領先。我們相信，通過與原生生態的深度融合，Kuikly 能幫助開發者在不斷演進的平臺之上，持續創造出卓越的應用體驗。??