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

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

一、引言

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

圖片 1 全新液態(tài)玻璃設計

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

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

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

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

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

圖片 2 基于Kuikly實現的液態(tài)玻璃demo效果預覽

二、 什么是“液態(tài)玻璃”?

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

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

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

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

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

圖片 3 蘋果液態(tài)玻璃效果展示

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

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

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

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

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

3.1 自繪渲染路線

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

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

圖片 4 Flutter關于如何實現液態(tài)玻璃的討論

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

3.2 原生渲染路線

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

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

這一路徑的優(yōu)勢在于：

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

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

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

圖片 5 Kuikly 原生渲染架構圖

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

四、Kuikly的適配經驗

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

4.1 適配原則

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

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

4.2 開發(fā)者友好的API設計

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

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

圖片 6 Kuikly 液態(tài)玻璃組件示例

4.3 適配方案與技術實現

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

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

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

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

4.4 兼容性保障

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

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

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

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

五、總結與展望

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

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

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

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