Kuikly是騰訊廣泛應用的跨端開發框架，基于Kotlin Multiplatform技术构建，为开发者提供了技术栈更统一的跨端開發体验，由腾讯大前端领域 Oteam（公司级）推出。目前已有20+业务深度使用，服务业务的总页面数1000+、日活用户超5亿，满足了这些业务在众多场景下的各类复杂需求(应用场景案例)。Kuikly 作为騰訊端服務聯盟(tds.qq.com)的重要成员，将持续推动跨端開發的技术创新和生态建设。

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

一、引言

在今年的 WWDC25上，苹果发布了其近十多年来最重要的一次视觉设计革新 ——液态玻璃（Liquid Glass）。這種全新的設計語言，以其半透明3D質感和動態流體效果，爲用戶創造了前所未有的沈浸式體驗，也讓軟件與硬件的界限變得更加模糊。

圖片1全新液態玻璃設計

“液态玻璃”的出现，将一个跨端開發领域中长期存在的根本性问题，以一种前所未有的方式重新推回到了聚光灯下:一个跨端框架，应该如何处理与宿主系统之间的关系?

這背後是兩種截然不同的架構路線:

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

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

过去，关于这两种路线的讨论更多集中在性能和一致性的权衡上。而“液态玻璃”的出现，则将“ 跟进平台创新的能力 ”这一维度，提升到了一个新的高度。本文将基于这一背景，分析“液态玻璃”对跨端開發的影响，并结合 Kuikly 在“原生渲染”路线上的探索与实践，分享我们的经验与思考。

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

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

“液态玻璃”是苹果继 iOS7的扁平化之后，在 UI 设计上的一次重要演进，它标志着UI设计正从“扁平化”向“沉浸化”过渡，其核心在于对光学、材质和纵深感的全新探索。

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

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

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

這些特征已在最新的iOS26系统中得到广泛应用。例如，App图标现在由多层玻璃构成，可动态适应主題色;Safari的悬浮工具条在滚动时也会自动收缩，以保证内容的全屏呈现。

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

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

这种变化意味着，UI效果的实现方式发生了根本改变:从软件层面的“模拟”，转向了对底层硬件能力的“直接调用” 。而这一转变，也给现有的跨端框架带来了新的技术挑战。

三、 不同架构路线的适配分析

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

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

3.1自繪渲染路線

对于采用自绘渲染路线的框架（如CMP、Flutter）而言，其核心特点是在系统提供的画布上，通过自带的渲染引擎(如 Skia)绘制全部 UI。这种架构在保证跨平台视觉一致性上具备优势，但在适配“液态玻璃”这类深度依赖原生系统的特性时，则面临着独特的挑战。

因为“液态玻璃”并非简单的视觉滤镜，而是与系统渲染器（metal）及核心动画(Core Animation)深度绑定的硬件加速效果，自绘框架无法直接调用系统 API 来实现。其适配路径通常是通过自定义着色器(Shaders)或图像处理技术，在自身渲染引擎内对原生效果进行视觉上的模拟。这种模拟不仅成本高，结果也往往不尽人意:性能和保真度较低，视觉效果难以完全对齐原生。更重要的是，这种架构上的不匹配会成为长期问题。未来任何依赖系统级深度、光线或动态效果的更新，自绘框架都将再次面临被动的“模拟”难题。

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

正如Flutter社区中部分开发者所言:“重新实现各种设计语言的成本和难度正变得越来越高。” 这体现了自绘渲染路线在设计理念上的核心取舍:优先保障跨平台视觉的絕對一致性，相應地，在跟進特定平台的深度創新時則需要付出更高的工程成本。

3.2原生渲染路線

与自绘路线不同，以Kuikly、Hippy、ReactNative等为代表的“原生渲染”框架，在适配平台级创新时则更具天然优势。这类框架通过将上层抽象映射为原生 UI 组件来进行渲染。

这种架构使得它们能够直接利用和封装系统发布的新特性。当苹果推出“液态玻璃”时，原生渲染框架可以通过调用系统提供的原生 API，让框架内的组件直接获得新效果的加持。

這一路徑的優勢在于:

較低的適配成本:无需从零模拟，主要工作在于对原生 API 的封装和框架层面的暴露，开发成本相对较低。

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

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

图片5Kuikly 原生渲染架构图

对于 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将复杂的平台差异管理进行了内部抽象，让开发者可以更专注于业务逻辑的实现。

图片6Kuikly 液态玻璃组件示例

4.3適配方案與技術實現

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

基礎組件:对基础的容器组件如View、Button，我们通过原生属性扩展的方式实现适配。同时，也提供了独立的 `LiquidGlass` 与 `LiquidGlassContainer` 组件（类似于BlurView 的用法），满足更灵活的布局需求。

複雜組合組件: 对于 `Input`、`alertDialog` 等组合型组件，支持通过组合效果，让业务以较低成本按需适配。

iOS特有組件:对 `Slider` 和 `Switch` 这类在iOS26上拥有全新动态效果的控件，我们在渲染层新增了iOS平台专属的组件进行封装，这确保了这些控件在具备液态玻璃效果的同时，能够获得与原生完全一致的交互体验。在上层DSL使用上，我们封装了平台差异，开发者无需修改原有组件的使用代码，只需添加 `enableGlassEffect（true）` 属性，即可轻松启用。

4.4兼容性保障

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

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

對其他平台的兼容:对于使用了液态玻璃的代码，Kuikly框架保障在Android等不支持的平台上能够自动降级到默认实现，避免业务UI代码编写大量的平台判断逻辑 。利用这一机制，开发者可以在iOS上采用最新設計語言，同時無需爲其他平台維護一套獨立的UI，極大地降低了開發和維護成本。

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

五、總結與展望

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

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

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

对于开发者而言，选择一个跨端框架，不仅是工程和技术层面的权衡，更是决定了App在未来竞争中能否保持领先。我们相信，通过与原生生态的深稛嶷合，Kuikly 能帮助开发者在不断演进的平台之上，持续创造出卓越的应用体验。

---

立即体验 Kuikly，加入开源社区。

Github倉庫

Kuikly框架属于騰訊端服務聯盟重要成员，欢迎关注及了解更多信息:

騰訊端服務官網

TDS framework官网

（推廣）