以下内容整理自高德地图智能应用与基建平台负责人杨夕凯及其团队公开技术分享，重点讨论核心交互控件如何在 iOS、Android、HarmonyOS 三端实现一致视觉表达，同时避免低端设备因复杂材质效果产生明显卡顿。

在地图、出行、导航这类高频操作型 App 中，液态玻璃效果如果直接铺满页面，很容易把视觉焦点变成性能负担。更稳妥的做法是把它限定在主按钮、路由引导、导航栏关键控件等强交互位置，再用一套分层跨端架构承接平台差异、保真分档和性能降级。核心思路可以概括为：设计侧克制使用，架构侧统一收敛，实现侧按设备能力分档，性能侧按实例数量选型。

一、先确定使用边界：液态玻璃是控件材质，不是页面背景

地图类界面和普通内容型应用不同。道路、文字、地点、交通状态、多语言信息会同时出现在画布上，地图还会持续平移、缩放、变色和刷新。尤其在导航过程中，用户能分配给界面的注意力非常有限，识别速度和操作确定性通常优先于视觉新奇感。

因此，液态玻璃不适合当作整页背景或全局装饰，更适合用于需要用户强感知的核心控件。例如：

• 主图底部 Bar 与 Widget 按钮
• AI 对话提示词引导
• 我的页右上角按钮
• 行中底部 Bar 与车速表
• 路线卡片中的主要行动按钮

这类控件有几个共同点：数量少、位置稳定、承担明确操作任务。它们不会随列表无限复制，也不会因为滚动加载导致实例数量指数级增长。把玻璃效果集中在这类控件上，可以在保持视觉焦点的同时控制绘制成本。

在界面层级上，可以拆成四层：

层级	作用	玻璃效果使用方式
地图层	承载道路、地点、交通状态等基础信息	不叠加玻璃背景，保持连续可见
内容层	承载详情、路线比较、服务信息等阅读内容	使用稳定内容表面，玻璃只做必要分隔
控制层	承载按钮、卡片操作、浮层控件	玻璃控件悬浮于内容之上
导航层	承载底部导航和任务路径	保持稳定可达，不增加过多动态干扰

这套层级的意义在于：玻璃不是给界面加一层皮肤，而是用来建立地图、信息与操作之间的空间关系。任务越关键，界面越需要清晰明确；在移动、驾车等状态下，视觉通透感要主动让位于可读性和出行安全。

二、区分两个正交问题：任务状态决定怎么用，设备能力决定怎么实现

很多跨端玻璃效果方案容易把两个问题混在一起：一个是设计表达问题，一个是设备实现问题。更清晰的做法是把它们拆开。

1. 任务状态：探索、决策、移动

同一种玻璃材质，在不同任务中不应保持完全相同的表现。

• 探索状态：用户感知地图和周边环境，界面应尽量轻盈、通透，让地图持续在场。
• 决策状态：用户阅读地点详情、比较路线或选择服务，内容表面需要稳定，玻璃主要承担操作与层级分隔。
• 移动状态：尤其是驾车导航，识别效率和安全优先，界面需要减少通透感和动态干扰，提高对比度，让路线、转向和关键指引更容易被快速识别。

2. 保真档位：液态玻璃、毛玻璃、模拟玻璃

设备能力决定玻璃效果如何实现。可以划分成三档：

保真档位	含义	适用情况
液态玻璃	平台原生液态玻璃或沉浸光感效果	高版本 iOS、HarmonyOS 等支持原生材质的设备
毛玻璃	原生模糊玻璃效果	支持模糊材质但不支持更高档液态玻璃的设备
模拟玻璃	通过边框、光影、渐变、切图等方式模拟玻璃观感	无原生玻璃材质或低版本系统设备

任务状态决定玻璃出现在哪里、如何表达；设备能力决定玻璃走原生渲染、模糊效果还是模拟方案。两者正交，架构需要保证任意状态都能在对应档位上成立。

三、架构目标：把设计效果、用户体验、业务适配的冲突收敛在架构层

跨端玻璃效果通常会遇到三类互相牵制的目标：

1. 设计效果还原度：视觉细节、动效、光影、跨端一致性。
2. 用户体验流畅度：响应时延、帧率稳定、内存与功耗。
3. 业务适配成本：接入工作量、定制自由度、迭代效率。

这三者往往互为代价。还原度提高，通常意味着更多绘制开销和更多适配分支；业务定制自由度提高，又可能增加维护成本。架构的价值不是消灭这些代价，而是决定由谁承担。更合理的选择是：让取舍发生在架构层，而不是业务层。

如果每个业务页面都自行判断 iOS、Android、HarmonyOS 的系统版本，再决定用哪种玻璃效果，后续一旦系统升级或策略调整，改动会分散到大量业务代码中。相反，如果平台分档和降级链写在框架层，业务方只需要使用统一入口，未来调整策略时业务代码可以保持零改动。

四、五层架构：业务只面对一个入口，平台差异由框架吸收

一种可行的分层方式如下：

层级	名称	职责
L1	业务使用层	提供统一入口 <GlassView>，业务不感知平台与系统版本
L2	框架复合组件层	负责系统版本分档判定与降级链 liquid → blur → similar
L3	玻璃原子组件层	提供 <liquid-glass>、<blur-glass>、<similar-glass> 等原子能力
L4	跨端容器能力层	处理无原生材质时的组件降级、渐变色边框与内阴影等样式扩展
L5	系统平台层	对接 iOS、Android、HarmonyOS 的原生能力或兜底方案

L1：业务统一入口

业务侧只使用一个入口组件，例如 <GlassView>。业务不需要判断当前设备是 iOS、Android 还是 HarmonyOS，也不需要判断系统版本是否支持原生玻璃材质。

这样做的好处是：业务代码描述的是“这里需要一个玻璃控件”，而不是“这个平台该怎么画玻璃”。

L2：版本分档与降级链

框架复合组件层负责把不同平台的判定结果收敛出来。例如：

平台	判定结果
iOS	高版本使用液态玻璃，中版本使用毛玻璃，低版本使用模拟玻璃
Android	无原生玻璃材质，使用模拟玻璃
HarmonyOS	高版本使用液态玻璃，其余版本跨档降级为模拟玻璃

降级链遵循固定顺序：liquid → blur → similar。能使用更高保真档位时，不越级使用低保真方案；不支持时再逐档降级。这样任何设备呈现的都是其能力范围内尽可能接近设计目标的效果。

L3：原子组件层

原子组件层把三档效果拆成明确组件：

• <liquid-glass>：对应液态玻璃档，优先使用平台原生能力。
• <blur-glass>：对应毛玻璃档，适合支持模糊材质但不支持液态玻璃的环境。
• <similar-glass>：对应模拟玻璃档，用于无原生材质或低版本系统。

如果页面明确只需要毛玻璃或模拟玻璃，也可以直接复用对应原子组件，而不必强行走最高档。

L4：容器能力层兜底

对于没有原生玻璃材质的平台，容器层需要做两件事：

1. 组件能力扩展：当原生材质不存在时，将玻璃标签降级为普通节点，避免报错或空渲染。
2. 样式能力扩展：通过自绘或切图实现渐变色边框、内阴影、光影等效果，让模拟玻璃在前端也能高效呈现。

这一层的关键是避免用大量运行时开销较高的滤镜或复杂绘制去硬仿玻璃。没有原生能力时，应使用轻量方案守住性能底线。

L5：系统平台层

系统平台层负责对接真实平台能力：

• iOS：可使用 UIVisualEffectView 配合 UIGlassEffect / UIBlurEffect 等能力。
• HarmonyOS：可使用 ImmersiveMaterial 等沉浸光感能力。
• Android：当前背景中明确没有原生玻璃材质，因此主要依赖模拟玻璃方案。

只要平台提供原生材质，就优先使用原生渲染，而不是前端多层模糊叠加。这是还原度和性能之间更稳的平衡点。

五、Android 与低端机：用模拟玻璃，但要控制绘制成本

Android 没有原生玻璃材质时，不能简单用高斯模糊、多层阴影、复杂滤镜去模拟液态玻璃。尤其在低端机或长列表场景中，程序绘制很容易造成 CPU、GPU、内存和帧率压力。

实践中可以遵循一条经验规则：当玻璃效果的实例数量随列表或数据量成倍甚至指数级增长时，不要选择含有程序绘制的组件。

这条规则来自三端对比实验。以 Android 端为例，在 50 个玻璃效果实例的场景下，程序自绘方案的资源消耗明显高于贴图方案：

实现方式	CPU	内存	FPS	GPU
自绘	13.27%	1806.1 MB	26.90	38.15%
贴图：单图	11.61%	1227.2 MB	34.52	21.69%
贴图：多图	12.75%	1221.0 MB	37.98	23.66%

在 20 个实例的场景下，贴图方案整体也优于自绘方案：贴图方案 CPU 约 8%，内存约 1100 MB，FPS 约 41，GPU 约 14%；自绘方案 CPU 为 10.71%，内存为 1484.7 MB，FPS 为 40.90，GPU 为 22.48%。

这些数据说明，在 Android 上，贴图方案在多数指标上优于程序自绘。对于需要大量出现、参与列表复用或滚动刷新的组件，优先使用切图素材是更稳妥的选择。

程序绘制的性能陷阱：警惕离屏渲染

如果确实需要程序绘制，第一原则是尽量避免离屏渲染。一些看起来简单的 API 组合，可能就是性能黑洞。

以内阴影为例，常见写法可能是：

• 使用 CAShapeLayer
• 配合 even-odd path
• 再加 mask

这类写法可能导致强制离屏绘制。更优做法是把内阴影一次性转为位图，不再依赖 mask，从而绕开额外开销。

如果必须使用切图素材，也可以按优先级选择：

1. 优先图片拉伸方案：减少素材数量和内存占用。
2. 其次原样切图：保留细节，但需要控制资源体积。
3. 避免复杂运行时滤镜叠加：防止低端机出现明显掉帧。

六、iOS 高保真不等于可以无限制使用原生液态玻璃

iOS 原生液态玻璃在视觉保真上有优势，但也不适合无限制使用。三端对比实验中，iOS 端在 50 个实例的场景下，原生液态玻璃带来了较高资源消耗：

实现方式	CPU	内存	FPS	GPU
自绘	29.1%	597.4 MB	10.9	87.6%
贴图：单图	115.3%	527.2 MB	43.4	16.9%
贴图：多图	136.84%	557.9 MB	38.98	14.88%
液态玻璃	186.7%	721.2 MB	3.4	30.8%

在 20 个实例场景下，液态玻璃仍表现为 CPU 99.2%、内存 533.3 MB、FPS 23.4、GPU 57.1%。这说明即使走原生材质，也要控制实例数量和使用位置。

因此，原生液态玻璃更适合放在实例数量少、不随列表复用的位置，例如主体 UI 框架、页面导航上的功能按钮、核心操作入口。对于高频出现或位于列表项中的组件，仍应优先考虑切图素材或更轻量的模拟方案。

七、HarmonyOS：按版本分档，原生优先，低版本降级

HarmonyOS 端可采用类似策略：高版本使用 ImmersiveMaterial 承担液态档，其余版本跨档降级为模拟玻璃。这样既保证新设备上的高保真表达，也避免低版本设备因强行模拟复杂材质而产生性能问题。

HarmonyOS 端对比实验也显示，不同实现方式之间的性能差异明显。在 20 个实例场景下：

实现方式	CPU	内存	FPS	GPU
自绘	6.95%	946.34 MB	50.19	20.87%
贴图：单图	9.11%	990.08 MB	88.09	39.79%
贴图：多图	10.74%	992.32 MB	81.3	37.95%

在 50 个实例场景下，贴图方案在帧率上仍优于自绘：单图贴图 FPS 为 42.03，多图贴图为 39.25，自绘为 27.24。这说明即便在 HarmonyOS 上，也不能只凭视觉偏好选择方案，而要结合实例数量、组件位置和性能预算综合判断。

八、一个容易被忽略的 iOS 问题：环境色变化导致文字不可读

液态玻璃的背景色可能随环境色变化，这会导致按钮内文字和图标看不清。在深色夜间导航场景中，如果玻璃气泡与环境色接近，路名文字可能难以识别。

解决思路是监听系统环境变化，并同步更新组件内部的设计令牌。iOS 上可以监听系统 trait 变化，例如：

registerForTraitChanges:@[UITraitUserInterfaceStyle.class]

在回调中获取当前环境色是 UIUserInterfaceStyleLight 还是 UIUserInterfaceStyleDark，再传递给端侧 DesignToken 系统，用于更新组件内字色与图标颜色。

修复前后差异很直观：

• Bad case：玻璃气泡背景与环境色接近，路名文字识别困难。
• Good case：玻璃气泡增加与环境对比更明显的衬底，文字清晰可读。

这类问题不是单纯视觉细节，而是影响导航场景下的信息可读性。对于地图和出行类应用，控件可读性直接关联操作确定性。

九、业务接入原则：少改代码、复用能力、避免重复造轮子

衡量业务适配成本，可以只看一句话：在效果符合预期的前提下，业务改得少、能力复用度高。

对应到工程上，有三种理想状态：

1. 业务无需适配，效果符合预期。
2. 业务使用高阶组件，不感知策略细节，效果符合预期。
3. 业务无需重复造轮子，可以复用原子化能力，效果符合预期。

为了达到这个目标，可以在跨端框架中扩展原子组件，透出液态玻璃、毛玻璃、模拟玻璃等效果；在前端封装多样式原子组件与复合型组件，把跨端适配成本和单端不同系统版本的适配成本一并收敛。

这样做的直接结果是：将来某个平台的新系统开放新能力，或者降级策略需要调整，改动只发生在框架层，业务代码不需要逐页修改。

十、选型建议：按组件位置和实例数量决定实现方式

综合设计与性能实验，可以形成一条较实用的选型规则：

组件类型	推荐方案
主要功能按钮、导航路由按钮、核心操作控件	优先液态玻璃或高阶玻璃质感组件
需要极致还原模拟玻璃材质的少量控件	可使用程序自绘，但严格控制数量
列表项、高频出现、随数据量增长的组件	优先切图素材或轻量模拟方案
Android 无原生材质场景	使用模拟玻璃，避免复杂模糊叠加
低版本 iOS / HarmonyOS	按降级链使用毛玻璃或模拟玻璃

也可以把判断流程简化为四步：

1. 这个控件是否属于核心交互？ 如果不是，不要强行使用玻璃效果。
2. 这个控件是否会大量重复出现？ 如果是，避免程序绘制。
3. 当前平台是否有原生材质？ 如果有，优先原生渲染。
4. 没有原生材质时，是否有轻量切图或容器层兜底？ 如果有，优先轻量方案。

十一、当前方案的边界与后续观察点

这套架构并非没有边界。首先，Android 目前仍只有模拟玻璃一档，无法直接获得与 iOS、HarmonyOS 高版本一致的原生材质表现。其次，长列表场景目前主要依赖经验规则约束，还没有完全变成框架层的自动判定。也就是说，业务侧仍需理解组件位置和实例数量对性能的影响，不能完全依赖框架自动选出最优方案。

另外，焕新版本上线后，仍需要持续跟踪三端实际帧率、内存和功耗表现。设计稿中的高保真效果、工程实现中的性能预算、真实设备的碎片化环境之间，仍需要长期校准。

从这次实践看，液态玻璃跨端架构的关键并不在于把所有设备都强行拉到同一种视觉效果，而是把差异拆开：设计层明确玻璃只用于关键控件，架构层统一承接平台分档和降级策略，实现层按原生能力、自绘和切图做性能取舍。这样既能保持三端视觉语言一致，也能避免低端设备被复杂材质效果拖垮。