Kuikly是騰訊廣泛應(yīng)用的跨端開(kāi)發(fā)框架，基于Kotlin Multiplatform技術(shù)構(gòu)建，為開(kāi)發(fā)者提供了技術(shù)棧更統(tǒng)一的跨端開(kāi)發(fā)體驗(yàn)，由騰訊大前端領(lǐng)域 Oteam(公司級(jí))推出。目前已有20+業(yè)務(wù)深度使用，服務(wù)業(yè)務(wù)的總頁(yè)面數(shù)1000+、日活用戶超5億，滿足了這些業(yè)務(wù)在眾多場(chǎng)景下的各類復(fù)雜需求(應(yīng)用場(chǎng)景案例 )。Kuikly 作為騰訊端服務(wù)聯(lián)盟(tds.qq.com)的重要成員，將持續(xù)推動(dòng)跨端開(kāi)發(fā)的技術(shù)創(chuàng)新和生態(tài)建設(shè)。
本次是在蘋果發(fā)布最新iOS 26 系統(tǒng)的背景下，Kuikly新增全新“液態(tài)玻璃”適配，進(jìn)一步豐富平臺(tái)特性支持、助力業(yè)務(wù)體驗(yàn)提升。
一、引言
在今年的 WWDC25 上，蘋果發(fā)布了其近十多年來(lái)最重要的一次視覺(jué)設(shè)計(jì)革新 —— 液態(tài)玻璃(Liquid Glass)。這種全新的設(shè)計(jì)語(yǔ)言，以其半透明3D質(zhì)感和動(dòng)態(tài)流體效果，為用戶創(chuàng)造了前所未有的沉浸式體驗(yàn)，也讓軟件與硬件的界限變得更加模糊。
圖片 1 全新液態(tài)玻璃設(shè)計(jì)
“液態(tài)玻璃”的出現(xiàn)，將一個(gè)跨端開(kāi)發(fā)領(lǐng)域中長(zhǎng)期存在的根本性問(wèn)題，以一種前所未有的方式重新推回到了聚光燈下：一個(gè)跨端框架，應(yīng)該如何處理與宿主系統(tǒng)之間的關(guān)系?
這背后是兩種截然不同的架構(gòu)路線：
? 自繪渲染(Self-Rendering)：追求在所有平臺(tái)上提供像素級(jí)一致的體驗(yàn)，通過(guò)自帶的渲染引擎在系統(tǒng)畫(huà)布上繪制所有UI，從而實(shí)現(xiàn)最大程度的控制力和跨平臺(tái)一致性。
? 原生渲染(Native-Rendering)：致力于將框架的抽象層無(wú)縫對(duì)接到原生系統(tǒng)的UI組件和渲染管線上，以最大化地利用平臺(tái)特性、保證性能和跟進(jìn)系統(tǒng)級(jí)的創(chuàng)新。
過(guò)去，關(guān)于這兩種路線的討論更多集中在性能和一致性的權(quán)衡上。而“液態(tài)玻璃”的出現(xiàn)，則將“ 跟進(jìn)平臺(tái)創(chuàng)新的能力 ”這一維度，提升到了一個(gè)新的高度。本文將基于這一背景，分析“液態(tài)玻璃”對(duì)跨端開(kāi)發(fā)的影響，并結(jié)合 Kuikly 在“原生渲染”路線上的探索與實(shí)踐，分享我們的經(jīng)驗(yàn)與思考。
圖片 2 基于Kuikly實(shí)現(xiàn)的液態(tài)玻璃demo效果預(yù)覽
二、 什么是“液態(tài)玻璃”?
“液態(tài)玻璃”是蘋果繼 iOS 7 的扁平化之后，在 UI 設(shè)計(jì)上的一次重要演進(jìn)，它標(biāo)志著UI設(shè)計(jì)正從“扁平化”向“沉浸化”過(guò)渡，其核心在于對(duì)光學(xué)、材質(zhì)和縱深感的全新探索。
從蘋果給我們的解讀看，這一設(shè)計(jì)的核心特征主要體現(xiàn)在兩方面：
? 光學(xué)特性與動(dòng)態(tài)流動(dòng)性：“液態(tài)玻璃”能實(shí)時(shí)根據(jù)背景內(nèi)容和環(huán)境光線進(jìn)行“折射”和“反射”，使UI元素的顏色和光澤隨上下文動(dòng)態(tài)變化。
? 多層級(jí)界面結(jié)構(gòu)： 通過(guò)將UI分為背景、內(nèi)容和懸浮的互動(dòng)層，創(chuàng)造出顯著的空間感與深度。
這些特征已在最新的iOS 26系統(tǒng)中得到廣泛應(yīng)用。例如，App圖標(biāo)現(xiàn)在由多層玻璃構(gòu)成，可動(dòng)態(tài)適應(yīng)主題色;Safari的懸浮工具條在滾動(dòng)時(shí)也會(huì)自動(dòng)收縮，以保證內(nèi)容的全屏呈現(xiàn)。
圖片 3 蘋果液態(tài)玻璃效果展示
但與以往的風(fēng)格迭代不同，“液態(tài)玻璃”的實(shí)現(xiàn)并非純粹的視覺(jué)技巧，而是深度依賴于系統(tǒng)底層的圖形處理能力。它不再像傳統(tǒng)設(shè)計(jì)那樣模擬紙張、油墨等物理隱喻，而是通過(guò)調(diào)用硬件加速的渲染管線來(lái)直接創(chuàng)造光線與材質(zhì)的交互效果。
這種變化意味著，UI效果的實(shí)現(xiàn)方式發(fā)生了根本改變：從軟件層面的“模擬”，轉(zhuǎn)向了對(duì)底層硬件能力的“直接調(diào)用” 。而這一轉(zhuǎn)變，也給現(xiàn)有的跨端框架帶來(lái)了新的技術(shù)挑戰(zhàn)。
三、 不同架構(gòu)路線的適配分析
“液態(tài)玻璃”的推出，對(duì)應(yīng)用開(kāi)發(fā)者提出了新的要求。隨著用戶逐漸習(xí)慣系統(tǒng)級(jí)應(yīng)用所提供的流暢、靈動(dòng)的“液態(tài)玻璃”視覺(jué)效果，未適配的應(yīng)用在體驗(yàn)上可能會(huì)出現(xiàn)割裂感。因此，如何有效跟進(jìn)這一設(shè)計(jì)趨勢(shì)，成為開(kāi)發(fā)者需要考量的問(wèn)題。
面對(duì)這一變化，基于不同架構(gòu)路線的跨端框架，其適配路徑和成本也表現(xiàn)出顯著差異。
3.1 自繪渲染路線
對(duì)于采用自繪渲染路線的框架(如CMP、Flutter)而言，其核心特點(diǎn)是在系統(tǒng)提供的畫(huà)布上，通過(guò)自帶的渲染引擎(如 Skia)繪制全部 UI。這種架構(gòu)在保證跨平臺(tái)視覺(jué)一致性上具備優(yōu)勢(shì)，但在適配“液態(tài)玻璃”這類深度依賴原生系統(tǒng)的特性時(shí)，則面臨著獨(dú)特的挑戰(zhàn)。
因?yàn)椤耙簯B(tài)玻璃”并非簡(jiǎn)單的視覺(jué)濾鏡，而是與系統(tǒng)渲染器(metal)及核心動(dòng)畫(huà)(Core Animation)深度綁定的硬件加速效果，自繪框架無(wú)法直接調(diào)用系統(tǒng) API 來(lái)實(shí)現(xiàn)。其適配路徑通常是通過(guò)自定義著色器(Shaders)或圖像處理技術(shù)，在自身渲染引擎內(nèi)對(duì)原生效果進(jìn)行視覺(jué)上的模擬。這種模擬不僅成本高，結(jié)果也往往不盡人意：性能和保真度較低，視覺(jué)效果難以完全對(duì)齊原生。更重要的是，這種架構(gòu)上的不匹配會(huì)成為長(zhǎng)期問(wèn)題。未來(lái)任何依賴系統(tǒng)級(jí)深度、光線或動(dòng)態(tài)效果的更新，自繪框架都將再次面臨被動(dòng)的“模擬”難題。
圖片 4 Flutter關(guān)于如何實(shí)現(xiàn)液態(tài)玻璃的討論
正如Flutter社區(qū)中部分開(kāi)發(fā)者所言：“重新實(shí)現(xiàn)各種設(shè)計(jì)語(yǔ)言的成本和難度正變得越來(lái)越高。” 這體現(xiàn)了自繪渲染路線在設(shè)計(jì)理念上的核心取舍：優(yōu)先保障跨平臺(tái)視覺(jué)的絕對(duì)一致性，相應(yīng)地，在跟進(jìn)特定平臺(tái)的深度創(chuàng)新時(shí)則需要付出更高的工程成本。
3.2 原生渲染路線
與自繪路線不同，以Kuikly、Hippy、ReactNative等為代表的“原生渲染”框架，在適配平臺(tái)級(jí)創(chuàng)新時(shí)則更具天然優(yōu)勢(shì)。這類框架通過(guò)將上層抽象映射為原生 UI 組件來(lái)進(jìn)行渲染。
這種架構(gòu)使得它們能夠直接利用和封裝系統(tǒng)發(fā)布的新特性。當(dāng)蘋果推出“液態(tài)玻璃”時(shí)，原生渲染框架可以通過(guò)調(diào)用系統(tǒng)提供的原生 API，讓框架內(nèi)的組件直接獲得新效果的加持。
這一路徑的優(yōu)勢(shì)在于：
? 較低的適配成本：無(wú)需從零模擬，主要工作在于對(duì)原生 API 的封裝和框架層面的暴露，開(kāi)發(fā)成本相對(duì)較低。
? 較高的保真度：由于直接使用系統(tǒng)能力，最終呈現(xiàn)的效果在視覺(jué)和性能上能與原生應(yīng)用保持一致。
? 可持續(xù)的演進(jìn)能力：框架的設(shè)計(jì)理念決定了它能與宿主系統(tǒng)的創(chuàng)新保持同步。未來(lái)的平臺(tái)級(jí)更新，同樣可以通過(guò)相似的路徑被快速集成。
圖片 5 Kuikly 原生渲染架構(gòu)圖
對(duì)于 Kuikly 而言，原生渲染的價(jià)值不止于 UI 呈現(xiàn)。更重要的是，這種架構(gòu)選擇確保了框架能夠與宿主平臺(tái)的技術(shù)演進(jìn)保持同步，使得基于 Kuikly 的應(yīng)用能夠持續(xù)、低成本地集成系統(tǒng)級(jí)創(chuàng)新，給用戶帶來(lái)與系統(tǒng)原生應(yīng)用相同的優(yōu)質(zhì)體驗(yàn)。
四、Kuikly的適配經(jīng)驗(yàn)
作為致力于提供高性能、原生UI渲染的跨端框架，Kuikly現(xiàn)已完成對(duì)“液態(tài)玻璃”的首階段適配，并對(duì)外開(kāi)源發(fā)布。Kuikly的適配工作并非簡(jiǎn)單的UI改造，而是充分利用原生提供的基礎(chǔ)能力，在框架渲染層和DSL驅(qū)動(dòng)層兩方面進(jìn)行擴(kuò)展，旨在為開(kāi)發(fā)者提供一套便捷、低成本的適配方案。
4.1 適配原則
Kuikly框架在適配“液態(tài)玻璃”時(shí)，需要平衡一個(gè)核心問(wèn)題：如何在保持我們“通過(guò)Kotlin跨端層組合原子組件以最大化UI一致性”的核心理念，與“液態(tài)玻璃”所強(qiáng)調(diào)的平臺(tái)原生特色之間做出選擇。面對(duì)這一挑戰(zhàn)，我們選擇靈活處理：將用戶體驗(yàn)置于最高優(yōu)先級(jí)，在追求一致性的同時(shí)，積極擁抱平臺(tái)特色。
我們認(rèn)為，跨端一致性的重點(diǎn)，是在不同平臺(tái)提供符合用戶習(xí)慣的優(yōu)質(zhì)體驗(yàn)，而不是追求UI像素的絕對(duì)相同。因此，我們選擇以一種靈活、務(wù)實(shí)的方式來(lái)?yè)肀脚_(tái)特色。對(duì)于常用組件，盡可能在跨端層抹平差異，提供一致的開(kāi)發(fā)體驗(yàn);同時(shí)通過(guò)“自定義組件”來(lái)解決系統(tǒng)對(duì)高級(jí)組件所做的特殊優(yōu)化，例如疊加的復(fù)雜交互動(dòng)畫(huà)效果。這種設(shè)計(jì)思路，使得我們能夠在統(tǒng)一代碼庫(kù)的基礎(chǔ)上，仍能充分發(fā)揮平臺(tái)原生體驗(yàn)的優(yōu)勢(shì)。
4.2 開(kāi)發(fā)者友好的API設(shè)計(jì)
Kuikly在API設(shè)計(jì)上同樣追求簡(jiǎn)潔與高效。對(duì)于常用的`View`、`Button`等組件，為了適配“液態(tài)玻璃”，我們沒(méi)有引入新的獨(dú)立組件，而是為現(xiàn)有組件提供了簡(jiǎn)潔的視圖屬性擴(kuò)展。例如，開(kāi)發(fā)者只需通過(guò)一行 `glassEffectIOS()` 代碼，即可為任意容器視圖啟用液態(tài)玻璃效果。
這種設(shè)計(jì)的主要優(yōu)勢(shì)在于，它避免了開(kāi)發(fā)者在UI代碼中編寫(xiě)大量平臺(tái)相關(guān)的 IF/ELSE 判斷。框架會(huì)自動(dòng)處理平臺(tái)差異：當(dāng)代碼在支持的iOS平臺(tái)運(yùn)行時(shí)，啟用液態(tài)玻璃效果;而在其他平臺(tái)或舊系統(tǒng)版本上，則平滑降級(jí)為默認(rèn)樣式，確保界面表現(xiàn)正常。通過(guò)這種方式，Kuikly將復(fù)雜的平臺(tái)差異管理進(jìn)行了內(nèi)部抽象，讓開(kāi)發(fā)者可以更專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)。
圖片 6 Kuikly 液態(tài)玻璃組件示例
4.3 適配方案與技術(shù)實(shí)現(xiàn)
針對(duì)不同類型的組件，我們采取了差異化的適配策略：
? 基礎(chǔ)組件： 對(duì)基礎(chǔ)的容器組件如View、Button，我們通過(guò)原生屬性擴(kuò)展的方式實(shí)現(xiàn)適配。同時(shí)，也提供了獨(dú)立的 `LiquidGlass` 與 `LiquidGlassContainer` 組件(類似于BlurView 的用法)，滿足更靈活的布局需求。
? 復(fù)雜組合組件： 對(duì)于 `Input`、`alertDialog` 等組合型組件，支持通過(guò)組合效果，讓業(yè)務(wù)以較低成本按需適配。
? iOS特有組件： 對(duì) `Slider` 和 `Switch` 這類在iOS 26上擁有全新動(dòng)態(tài)效果的控件，我們?cè)阡秩緦有略隽薸OS平臺(tái)專屬的組件進(jìn)行封裝，這確保了這些控件在具備液態(tài)玻璃效果的同時(shí)，能夠獲得與原生完全一致的交互體驗(yàn)。在上層DSL使用上，我們封裝了平臺(tái)差異，開(kāi)發(fā)者無(wú)需修改原有組件的使用代碼，只需添加 `enableGlassEffect(true)` 屬性，即可輕松啟用。
4.4 兼容性保障
在適配新特性的同時(shí)，Kuikly也全面考量了兼容性問(wèn)題：
? 對(duì)舊系統(tǒng)的兼容：對(duì)于使用了液態(tài)玻璃的組件，Kuikly封裝的系統(tǒng)原生組件會(huì)自動(dòng)處理兼容性，在舊系統(tǒng)上平滑切換為原有樣式。而對(duì)于組合類組件，框架也提供了兼容性保障，業(yè)務(wù)代碼無(wú)需擔(dān)憂在舊系統(tǒng)上出現(xiàn)異常。
? 對(duì)其他平臺(tái)的兼容：對(duì)于使用了液態(tài)玻璃的代碼，Kuikly框架保障在Android等不支持的平臺(tái)上能夠自動(dòng)降級(jí)到默認(rèn)實(shí)現(xiàn)，避免業(yè)務(wù)UI代碼編寫(xiě)大量的平臺(tái)判斷邏輯 。利用這一機(jī)制，開(kāi)發(fā)者可以在iOS上采用最新設(shè)計(jì)語(yǔ)言，同時(shí)無(wú)需為其他平臺(tái)維護(hù)一套獨(dú)立的UI，極大地降低了開(kāi)發(fā)和維護(hù)成本。
篇幅所限，更多技術(shù)實(shí)現(xiàn)細(xì)節(jié)，歡迎訪問(wèn)文末Kuikly官網(wǎng)或Github倉(cāng)庫(kù)直接獲取源碼。
五、總結(jié)與展望
“液態(tài)玻璃”的出現(xiàn)，為我們提供了一個(gè)絕佳的案例，去重新審視跨端框架的兩種核心路徑：是“抽象并抹平平臺(tái)差異”，還是“集成并利用平臺(tái)能力”?
過(guò)去，跨平臺(tái)開(kāi)發(fā)的核心挑戰(zhàn)是保證體驗(yàn)的一致性。但隨著操作系統(tǒng)能力的不斷發(fā)展——從空間計(jì)算(AR/VR)到硬件加速的AI能力——“抽象”的成本，可能正在變?yōu)殄e(cuò)失平臺(tái)最有價(jià)值的創(chuàng)新。一個(gè)框架的價(jià)值，不再僅取決于它能“抹平”什么，更在于它能“釋放”什么。
因此，Kuikly在“液態(tài)玻璃”上的適配，并非一次簡(jiǎn)單的功能跟進(jìn)，而是驗(yàn)證了這樣一種可能：真正的跨平臺(tái)，可以既不必以犧牲平臺(tái)深度特性為代價(jià)，又將原生創(chuàng)新直接轉(zhuǎn)化為自身優(yōu)勢(shì)。
對(duì)于開(kāi)發(fā)者而言，選擇一個(gè)跨端框架，不僅是工程和技術(shù)層面的權(quán)衡，更是決定了App在未來(lái)競(jìng)爭(zhēng)中能否保持領(lǐng)先。我們相信，通過(guò)與原生生態(tài)的深度融合，Kuikly 能幫助開(kāi)發(fā)者在不斷演進(jìn)的平臺(tái)之上，持續(xù)創(chuàng)造出卓越的應(yīng)用體驗(yàn)。
---
立即體驗(yàn) Kuikly，加入開(kāi)源社區(qū)。
Github 倉(cāng)庫(kù) | https://kuikly.tds.qq.com
Kuikly框架屬于騰訊端服務(wù)聯(lián)盟重要成員，歡迎關(guān)注及了解更多信息：
騰訊端服務(wù)官網(wǎng)：https://tds.qq.com/
TDS framework官網(wǎng)：https://framework.tds.qq.com/
閱讀更多：
