在地图、出行、导航这类高频操作型 App 里，给核心按钮加一层「液态玻璃」并不只是视觉升级。真正难的是：iOS 与 HarmonyOS 有原生材质可用，Android 没有对应能力；低端机一旦用程序绘制堆效果，帧率和内存很容易被拖垮；业务方又不想为每个平台、每个系统版本写分支判断。
更稳的做法，是把玻璃效果拆成两套正交问题：任务状态决定怎么用，设备能力决定怎么实现。前者控制设计边界，避免玻璃铺满界面；后者通过分层架构把平台差异收敛到框架层，让业务只面对一个统一入口。高德地图 2026 焕新版在核心交互控件上的液态玻璃实践，基本就是围绕这条思路展开的。
以下内容整理自高德地图智能应用与基建平台负责人杨夕凯及其团队在液态玻璃跨端落地实践，重点讨论核心控件如何在 iOS、Android、HarmonyOS 三端保持视觉一致，同时不把性能成本转嫁给业务页面。
先明确边界：玻璃是控件材质，不是页面背景
地图类界面和普通内容型应用不同。道路、文字、地点、交通状态、多语言信息会同时出现，画布还会持续平移、缩放、变色和刷新。尤其在导航过程中，用户能分配给界面的注意力很有限，识别速度和操作确定性比视觉新奇更重要。
因此，液态玻璃不适合当成整页背景或全局皮肤，而应集中用在少数关键控件上：
- 主图底部 Bar 与 Widget 按钮
- AI 对话提示词引导
- 行中底部 Bar 与车速表
- 路线卡片中的核心行动按钮
- 我的页右上角等高频入口
这类控件有共同特征：数量少、位置稳定、承担明确操作，不随列表无限复用。玻璃效果放在这里，既能建立层级，又不会把绘制成本扩散到整个页面。
如果界面同时存在探索、决策、移动三种状态，玻璃的表现也不能完全一样：
| 用户状态 | 典型场景 | 界面策略 |
|---|---|---|
| 探索 | 浏览地图、查看周边 | 保持轻盈通透，让地图持续在场 |
| 决策 | 看地点详情、比较路线 | 内容表面稳定，玻璃承担操作与层级分隔 |
| 移动 | 驾车导航、转向提示 | 降低通透感和动态干扰，提高对比度 |
任务越关键，界面越要明确。玻璃的视觉表现需要为可读性和出行安全让位，这也是后续技术选型的前提。
架构目标：把三方冲突收敛到框架层
跨端玻璃效果通常会同时撞上三个目标：
- 设计效果尽量保真：视觉还原度、动效细节、跨端一致性。
- 用户体验尽量流畅：响应时延、帧率稳定、内存与功耗。
- 业务适配成本尽量低：接入工作量、定制自由度、迭代效率。
这三者往往互为代价。还原度往上走，通常意味着更多绘制开销和更多适配分支；业务定制越自由，框架越难统一兜底。架构的价值不是消灭这些代价，而是决定由谁承担。
高德这套方案的选择是：让取舍发生在架构层，而不是业务层。业务方不应该判断 iOS 版本、Android 是否有原生材质、HarmonyOS 从哪个版本支持沉浸光感；这些逻辑一次性写进框架复合组件层，后续策略调整也不需要业务页面跟着改。
五层结构：业务只面对一个 GlassView
整体实现可以拆成五层。业务侧看到的是统一组件，框架侧负责分档降级，容器层负责兜底绘制，系统层负责原生能力承接。
| 层级 | 名称 | 承担职责 |
|---|---|---|
| L1 | 业务使用层 | 统一入口 <GlassView>，业务不感知平台与系统版本 |
| L2 | 框架复合组件层 | 系统版本分档判定与降级链 liquid → blur → similar |
| L3 | 玻璃原子组件层 | <liquid-glass>、<blur-glass>、<similar-glass> |
| L4 | 跨端容器能力层 | 无原生材质时降级为普通节点；渐变色边框、内阴影等样式自绘或切图 |
| L5 | 系统平台层 | iOS UIVisualEffectView、HarmonyOS ImmersiveMaterial，Android 无原生玻璃材质 |
这里的关键不是层数，而是每层只解决一类问题：
- L1 解决接入成本：业务只写一个入口。
- L2 解决平台差异：版本分档和降级策略集中维护。
- L3 解决效果分级：液态玻璃、毛玻璃、模拟玻璃不是一种笼统观感，而是明确档位。
- L4 解决无原生能力时的兜底：不能因为 Android 或低版本系统没有原生材质就报错或空渲染。
- L5 解决还原上限：能用原生材质就用原生材质，避免前端多层模糊硬仿。
三端分档：能上原生就不前端硬仿
在效果分级上，方案没有用一套 CSS 兼容所有场景，而是把保真度拆成三档：
- 液态玻璃：优先使用平台原生液态玻璃效果。
- 毛玻璃：原生不支持液态时，退到毛玻璃。
- 模拟玻璃：没有原生材质时，用边框、光影、渐变等模拟质感。
降级链固定为：
liquid → blur → similar
也就是说，只要设备能呈现更高保真档位，就不会越过它去用低保真方案。三端判定逻辑如下：
| 平台 | 判定条件 | 结果 |
|---|---|---|
| iOS | 系统版本较高，支持液态玻璃 | 液态玻璃 |
| iOS | 中间版本 | 毛玻璃 |
| iOS | 更低版本 | 模拟玻璃 |
| Android | 无原生玻璃材质 | 模拟玻璃 |
| HarmonyOS | 支持沉浸光感 | 液态玻璃 |
| HarmonyOS | 其余版本 | 跨档降级为模拟玻璃 |
这种分档方式有两个直接好处：
- 设计侧可预期：每台设备展示的是它能达到的较佳效果，而不是随机降级。
- 业务侧零分支：平台判断、版本判断、能力判断都收在 L2，业务代码不感知。
高德地图业务的很大一部分由自研跨端框架 AJX 实现，因此三端一致性也被收敛到 AJX 跨端框架与前端框架内部处理，而不是分散到各业务页面。
Android 没有原生材质时，怎么避免卡顿
Android 是这套方案里最典型的约束场景。它没有原生玻璃材质，如果直接用程序绘制去仿玻璃，很容易在低端机或列表场景中出现掉帧、内存升高、GPU 占用上升。
实践中的处理原则是：能原生就原生；没有原生时，用容器层轻量方案兜底，而不是让业务页面堆昂贵绘制。
在 L4 跨端容器能力层，主要做两件事：
1. 组件能力扩展
当 <liquid-glass> 或 <blur-glass> 落到没有原生材质的平台时，容器会把它们降级成普通节点，并承接模拟玻璃样式。这样不会出现找不到原生实现导致的报错，也不会出现空渲染。
2. 样式能力扩展
模拟玻璃常见的渐变色边框、内阴影、光影描边，不一定要靠运行时开销很大的 CSS 滤镜叠加。容器层可以选择自绘，也可以选择切图素材，根据组件重要性和出现频次做取舍。
这里有一条很实用的经验规则：
当玻璃效果的实例数量随列表或数据量成倍增长时，不要选择含有程序绘制的组件。
原因很直接。一个主按钮用自绘，成本可控；但如果列表里每个卡片都带玻璃效果，绘制对象数量会快速放大，CPU、内存、GPU 和帧率都会被拖住。
性能实验：贴图通常比程序自绘更稳
在三端对比实验中，团队把实现方式分成自绘、单图贴图、多图贴图等类型，并观察 CPU、内存、FPS、GPU 使用率变化。结果对业务选型很有参考价值。
在 Android 端，当玻璃效果实例较多时，贴图方案在 CPU、内存、GPU 与帧率方面整体优于程序自绘。实例数量下降后，自绘压力会变小，但贴图仍然更容易保持稳定表现。
在 iOS 端，原生液态玻璃的视觉保真最高，但在实例较多的场景下，CPU 与帧率代价也很明显。这再次印证了前面的规则：少量核心控件可以用高保真方案，高频列表项不要堆程序绘制。
在 HarmonyOS 端，不同实现方式的性能差异同样存在，贴图方案在部分场景下能换来更高帧率，自绘则在少量实例下可兼顾质感。
这些数据指向同一个结论：玻璃效果不能只看设计稿，还要看它出现在什么位置、出现多少次、是否随列表复用。
业务选型建议：按控件重要程度分档
如果没有完整的性能实验数据，也可以按下面这套规则做初步判断：
适合液态玻璃或高保真实现的位置
- 主图底部核心按钮
- 导航路由按钮
- 行中关键操作区
- 少量、固定、强感知的控件
这些位置实例少，不随列表复用，用户对操作确定性要求高，值得投入更高保真效果。
适合毛玻璃或模拟玻璃的位置
- 次级操作入口
- 信息卡片上的辅助按钮
- 需要层级分隔但不需要强视觉焦点的区域
这些位置不必追求最高保真，重点是层级清楚、识别稳定。
适合切图素材的位置
- 列表项中的高频组件
- 数据量增长后会大量复用的卡片
- 对帧率和内存敏感的低端机场景
切图素材会牺牲部分细节，但能显著降低运行时绘制压力。在性能与体验的平衡区间里，这是更稳的选择。
一个容易被忽略的坑：环境色变化导致文字不可读
在 iOS 上使用液态玻璃时，有一个典型问题：玻璃背景色会随环境色变化，如果按钮内的字色和图标没有同步调整，可能出现看不清的情况。
例如夜间导航场景下，路名气泡如果直接叠在深色玻璃上，环境色与玻璃底色接近时，文字识别会变差。解决思路不是简单加深背景，而是监听系统环境变化，并把结果同步给端侧 DesignToken 系统。
iOS 侧可以监听系统 trait 变化：
registerForTraitChanges:@[UITraitUserInterfaceStyle.class]
在回调中获取当前环境是浅色还是深色，再更新组件内的字色、图标颜色和必要衬底。这样玻璃效果仍然保留，但关键信息不会因环境色变化而失去可读性。
这个细节说明，跨端玻璃不只是「能不能渲染」的问题，还包括渲染之后文字、图标、状态色是否仍然稳定可读。
这套方案的边界与不足
从工程角度看，分层架构确实把大部分复杂度收进了框架层，但它也有明确边界。
首先，Android 目前仍然只有模拟玻璃一档。没有原生材质意味着它无法获得与 iOS、HarmonyOS 完全一致的材质表现，只能通过边框、光影和贴图尽量接近设计目标。
其次，长列表场景目前更多依赖经验规则约束，还没有完全变成框架层的自动判定。也就是说，业务如果错误地在高频列表里使用程序绘制玻璃组件，框架不一定能自动阻止，仍需要选型规范和评审机制配合。
最后，高保真效果天然有性能代价。即便架构把原生能力优先级提到最高，实例数量过多时仍会造成压力。上线后还需要持续跟踪三端实际帧率、内存和功耗表现，动态调整分档策略。
写在最后
核心控件上的液态玻璃，真正考验的不是「能不能做出亮晶晶的效果」，而是能否把设计、性能、业务成本放进同一套架构里求解。
比较清晰的路径是：
- 设计侧先克制，玻璃只用于关键操作与路径引导；
- 架构侧建立
liquid → blur → similar的明确降级链； - 平台侧优先使用原生材质，没有原生能力时用容器层兜底；
- 业务侧只面对一个
<GlassView>，不感知平台和版本差异； - 性能侧按控件重要程度和实例数量选型，避免列表场景堆程序绘制。
玻璃是控件的材质，不是页面的背景。这个判断如果从设计阶段一直贯彻到架构层，跨端一致性和性能才有机会同时成立。
