简介面向Android开发者的玻璃蒙层实现资源聚焦半透明模糊UI效果涵盖高斯模糊、毛玻璃效果及颜色叠加等关键手法适合需要提升界面层次感与交互反馈的中高级开发者。压缩包共55个文件约1.23MB内含17个class、13个xml布局、4个java源码及3个jar库辅以多尺寸png图标与drawable资源构成完整的Android工程示例。已有908人学习下载。资源以图片处理类为核心完整呈现启动模糊、BitmapShader与第三方库结合的实现路径并含有适配不同屏幕的drawable目录、动画资源及混淆配置便于开发者直接参考或集成。通过alpha通道、PorterDuff混合模式及动态动画示例可帮助理解毛玻璃效果在真实项目中的落地过程同时兼顾性能优化与代码组织适合作为UI改造的实用模板。1. 玻璃蒙层不是加一张半透明图先弄懂它在解决什么做底部弹窗或者侧滑抽屉时你多半遇到过这种场景弹层后面是一屏密密麻麻的列表文字背景只压一层半透明黑读起来费劲视觉上也没什么层次。设计师提了一句“后面毛玻璃一下”需求就落到你头上。所谓 Android 玻璃蒙层就是把这个“毛玻璃一下”实现出来把背面的真实内容采样、模糊、再作为一层覆盖物贴回屏幕让前景控件和背景内容之间形成一种看得清轮廓却认不出细节的层次关系。这个需求听起来很小落地时却很容易翻车。Android 系统本身没有现成的“玻璃蒙层”控件常见做法是自己抓取底层内容生成模糊位图再用 WindowManager 挂一个独立的透明层盖上去。难点集中在三处模糊效果怎么算、蒙层窗口怎么挂、以及怎么在低端机上不卡成 PPT。本文就用一个自研的 glass overlay 方案把这些步骤和参数讲清楚适合正在做 App 内弹窗蒙层、系统 UI 定制或者需要全局毛玻璃效果的一线开发。2. 从模糊原理到选型RenderEffect、离屏缓存与降级路径2.1 毛玻璃的三种实现层级做玻璃蒙层之前先得想清楚一个问题你要模糊的是“整个屏幕”还是“某个 View 背后的区域”。选错了实现层级后面性能怎么调都救不回来。第一种是 Activity 整体截图模糊。直接把 DecorView 画到一张 Bitmap 上压缩、模糊后再整屏铺回去。优点是实现快缺点也明显它只能做全屏静态蒙层弹窗打开后底层内容一旦滚动蒙层不会跟着变还会截到状态栏、导航栏这些不该模糊的区域。第二种是 View 树内自绘。自定义一个 BlurOverlayView通过 View.draw 把它底下兄弟节点的内容抓进一张离屏 Bitmap再绘制模糊结果。这种方式可以做局部蒙层也能感知内容变化但需要搞清楚兄弟节点的绘制顺序代码耦合度高。第三种是独立 Window 蒙层配合 WindowManager 插入一个不参与原布局的透明 View抓取它所在位置的屏幕内容并模糊显示。它解决的是“全局性蒙层”问题比如系统级弹窗、抽屉导航、动态壁纸上的悬浮层很多系统 UI 方案都走这条路。我一般会这样判断目标只是 App 内部截图分享的模糊背景用 Activity 截图省事目标是某个容器内的局部毛玻璃用 View 树自绘目标是不确定会盖在什么内容上的透明层比如音量条、全局提示、底部导航浮层优先用 WindowManager。本文主推第三种因为它在“玻璃蒙层”这个需求里通用性最强也可以和另外两种混用。2.2 为什么 Android 12 的 RenderEffect 是首选Android 12 引入了 RenderEffect这算把毛玻璃从“偏方”变成了“官方路子”。RenderEffect.createBlurEffect 可以直接挂到 View 的 RenderNode 上让硬件加速渲染管线在合成阶段对 View 的绘制结果做一次高斯模糊不需要你手动截屏也不需要额外跑模糊算法CPU 和内存开销都低很多。这个能力对玻璃蒙层的意义非常大。我之前用 RenderScript 做一版截屏后 Bitmap 模糊2560×1440 的屏幕在低端机上要 30ms 左右滚动时肉眼可见地掉帧。换成 RenderEffect 后模糊交给 GPU 做主线程只负责设置参数和触发重绘同一台机器帧耗时能降到 5ms 以内。所以如果你的 minSdk 允许蒙层的核心模糊直接用 RenderEffect 是最省力的选型。一个最小示例是这样val blur RenderEffect.createBlurEffect( radiusX 24f, radiusY 24f, tileMode Shader.TileMode.CLAMP ) overlayView.renderNode?.setRenderEffect(blur)逻辑解释createBlurEffect 的第一个参数是 X 轴模糊半径第二个是 Y 轴模糊半径单位是像素而非 dptileMode 决定模糊采样到边缘时怎么处理。CLAMP 表示边缘像素向外延伸适合全屏蒙层如果是圆角蒙层用 DECAL 能避免边缘发黑。设置到 renderNode 上后View 下一次绘制就会自动应用模糊不需要修改 onDraw。这里有个关键点要提醒RenderEffect 只对普通 View 的硬件加速绘制生效。SurfaceView、TextureView 这类独立 Surface 的内容不在 View 的绘制流里蒙层盖上去就会看到黑块这个问题第 5 章专门讲。2.3 兼容旧版本的降级方案自定义 Drawable 模糊位图如果项目 minSdk 低于 31或者需要覆盖大量旧平板设备RenderEffect 就不能作为唯一实现。常见做法是降级把蒙层区域的内容抓成 Bitmap缩小采样后再做一次高斯模糊最后作为 BitmapDrawable 画到蒙层 Paint 上。核心代码是一个可复用的模糊函数fun blurBitmap(src: Bitmap, radius: Float, sampleFactor: Float): Bitmap { val w (src.width * sampleFactor).toInt().coerceAtLeast(1) val h (src.height * sampleFactor).toInt().coerceAtLeast(1) val scaled Bitmap.createScaledBitmap(src, w, h, true) // 使用系统自带的高斯模糊实现不再依赖已废弃的 RenderScript val output Bitmap.createBitmap(w, h, Bitmap.Config.ARGB_8888) // 这里填充你的模糊算法调用可以是 MultiLineStackBlur 或 FastBlur stackBlur(scaled, output, radius) return output }参数含义sampleFactor 是降采样系数0.25 表示把 2000×1000 的屏幕采样成 500×250 再做模糊这一步能把模糊耗时降到原来的十几分之一radius 是模糊半径相对于降采样后的图片原图上约等于 radius / sampleFactor。这个函数最大的坑是 Bitmap 频繁创建低端机 GC 会被打爆所以真实组件里要复用输出 Bitmap或者直接用 SupportRenderEffect 库做抹平。兼容层策略上不要把降级做成一个孤立分支。正确的做法是做一个蒙层内部接口Android 12 走 RenderEffect旧版本走 Bitmap 模糊切换点放在初始化时。这样同一套对外配置不同系统版本自动选择实现后续维护时不用到处写 if。3. 用 WindowManager 挂一个真正的“蒙层”最小可运行实现3.1 布局与参数宽高、flags、模糊半径玻璃蒙层不是普通 View它必须脱离 Activity 的布局树直接挂在 WindowManager 上这样才有能力覆盖 Dialog、PopupWindow 甚至其他应用窗口。第一步是定义蒙层的 LayoutParams参数不同蒙层的行为会差很多。merge xmlns:androidhttp://schemas.android.com/apk/res/android View android:idid/glass_overlay_view android:layout_widthmatch_parent android:layout_heightmatch_parent android:backgroundandroid:color/transparent / /mergeMontage 布局透明背景因为模糊效果是绘制在 View 内容上的不是靠背景色。接下来是 WindowManager 参数表这些 flag 直接决定蒙层能不能盖到状态栏后面参数值作用width / heightMATCH_PARENT蒙层铺满整个窗口区域typeTYPE_APPLICATION_PANEL 或 TYPE_APPLICATION_OVERLAY决定蒙层在窗口层级里的位置flagsFLAG_LAYOUT_IN_SCREEN、FLAG_LAYOUT_NO_LIMITS、FLAG_NOT_FOCUSABLE、FLAG_NOT_TOUCH_MODAL允许布局延伸到屏幕边缘但不抢焦点formatPixelFormat.TRANSLUCENT保证透明通道生效这里最容易搞错的三个参数是TYPE_APPLICATION_PANEL 需要 token通常用在 Activity 挂载时FLAG_NOT_FOCUSABLE 必须加否则蒙层会吃掉所有按键事件FLAG_LAYOUT_IN_SCREEN 不加蒙层在带刘海屏的设备上会跟状态栏错位。3.2 在 Activity 里添加与移除蒙层的代码有了参数添加和移除的逻辑可以封装成一个 OverlayController。这个类负责创建 View、绑定 Lifecycle、处理重复添加代码量不大但边界条件多class GlassOverlayController(private val context: Context) { private val wm context.getSystemService(Context.WINDOW_SERVICE) as WindowManager private var overlayView: View? null fun show() { if (overlayView ! null) return // 防止重复添加同一个视图 val view LayoutInflater.from(context) .inflate(R.layout.glass_overlay, null, false) val params WindowManager.LayoutParams( WindowManager.LayoutParams.MATCH_PARENT, WindowManager.LayoutParams.MATCH_PARENT, WindowManager.LayoutParams.TYPE_APPLICATION_PANEL, WindowManager.LayoutParams.FLAG_LAYOUT_IN_SCREEN or WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS or WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE or WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL, PixelFormat.TRANSLUCENT ) wm.addView(view, params) overlayView view // Android 12 直接挂 RenderEffect旧版本走内部降级模糊 if (Build.VERSION.SDK_INT Build.VERSION_CODES.S) { val blur RenderEffect.createBlurEffect(24f, 24f, Shader.TileMode.CLAMP) view.renderNode?.setRenderEffect(blur) } } fun dismiss() { overlayView?.let { wm.removeView(it) overlayView null } } }这一段注释已经标明了两个分支逻辑说明如下addView 是同步操作调用完蒙层立刻可见重复调用 show 时用 overlayView 判空防止 WindowManager 抛异常。TYPE_APPLICATION_PANEL 这里依赖 Activity 的 token如果 controller 是用 Application 初始化的系统会拒绝添加报 BadTokenException。这个异常很典型原因是面板窗口必须依附于某个 Activity 的窗口令牌。3.3 让蒙层跟随弹窗和键盘动蒙层加上以后你会发现一个尴尬问题弹窗是 WindowManager 里的另一层窗口它自己在屏幕上移动或弹出软键盘时蒙层并不会自动跟随。表现就是键盘弹起来时蒙层还停留在原来的全屏位置底部一片没有被模糊或者弹窗盖在蒙层之上但背后内容已经露馅。常见的解决思路是给蒙层 View 注册一个 ViewTreeObserver监听全局布局变化overlayView?.viewTreeObserver?.addOnGlobalLayoutListener { val insets overlayView?.rootWindowInsets val imeHeight insets?.getInsets(WindowInsets.Type.ime())?.bottom ?: 0 // 键盘弹出时把蒙层底部裁到 IME 上边缘 overlayView?.translationY 0f overlayView?.clipBounds Rect(0, 0, overlayView?.width ?: 0, (overlayView?.height ?: 0) - imeHeight) }这个 onGlobalLayoutListener 在键盘弹出、窗口 insets 变化时都会回调。clipBounds 把蒙层的绘制区域裁掉底部键盘区域避免蒙层和输入法打架如果需求是蒙层也要模糊键盘后面这个裁切就去掉。注意如果还在 onGlobalLayoutListener 里做 Bitmap 截屏一定要判断上次截屏是否完成否则会出现蒙层比内容慢半拍的花屏感。4. 把蒙层做成可复用组件配置项与性能参数4.1 对外暴露的配置项没有配置项的蒙层只能叫“临时验证”。真实项目里不同业务对模糊强度、遮罩颜色、过渡动画要求完全不同用户引导要轻模糊、强遮罩媒体详情页要强模糊、低遮罩。组件化时我会把配置收敛成一个数据类默认值给到一套普通设备不卡的档位data class GlassOverlayConfig( val blurRadius: Float 24f, // 模糊半径像素推荐 12-36 val sampleFactor: Float 0.25f, // 降采样率低端机建议 0.1-0.25 val maskColor: Int 0x66000000, // 蒙层叠加色0x66 相当于 40% 黑色 val cornerRadius: Float 0f, // 蒙层圆角用于异形屏适配 val followIme: Boolean true, // 是否跟随软键盘裁切 val maxUpdateIntervalMs: Long 16 // 内容刷新节流间隔 )这里 blurRadius 的单位容易让新人困惑RenderEffect 的 radius 是渲染到屏幕上的像素不是 dpsampleFactor 只影响降级分支Android 12 分支会自动忽略它。maskColor 是蒙层整体叠加的半透明色用来保证模糊后前景内容依然有足够的对比度很多翻车案例就是忘了这层色值模糊以后文字像隔着一层水可读性极差。4.2 避免每帧全屏模糊缓存更新策略玻璃蒙层性能的生死线不在模糊算法本身而在更新频率。如果蒙层覆盖的内容是静态截图模糊一次就够了但如果底下是滚动的列表、正在播放的视频背景每帧都重新截屏模糊低端机直接卡死。我常用的策略是“脏区域标记 节流刷新”。class BlurOverlayView JvmOverloads constructor( context: Context, attrs: AttributeSet? null ) : View(context, attrs) { private var dirty true private var lastRefreshNanos 0L private var refreshIntervalMs 16L fun markDirty() { dirty true postInvalidateOnAnimation() } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) if (!dirty) return val now System.nanoTime() if (now - lastRefreshNanos refreshIntervalMs * 1_000_000L) return // 抓取底层内容并生成模糊位图 // 更新 Paint 的 BitmapShader lastRefreshNanos now dirty false } }关键逻辑在 onDraw 里的两个判断dirty 表示“底层内容变了”节流时间保证一帧内最多刷新一次。postInvalidateOnAnimation 会把重绘请求对齐到垂直同步比 postInvalidate 更平滑也避免一次布局变化触发多次重绘。markDirty 由外部调用比如 RecyclerView 的 scroll 回调里触发但注意不要在 onScroll 里直接调用 markDirty因为滚动事件一帧可能回调好几次。4.3 与列表滚动冲突的处理列表滚动和玻璃蒙层是一对经典冲突滚动时底层内容每帧都在变化你要模糊的内容也在变如果完全实时模糊等于给滚动过程套了一层全屏重绘如果不实时滚动时蒙层会出现明显的“糊一层旧图”的割裂感。我的处理思路是分级更新。列表滚动中用低半径低采样率做一次“预览模糊”只要大方向跟手用户感知不到细节差异列表停止滚动超过 120ms 后再用完整参数刷新一次高清模糊。写成代码就是滚动回调里判断状态recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() { override fun onScrolled(v: RecyclerView, dx: Int, dy: Int) { overlay.markDirty() if (!isScrolling) { isScrolling true // 降级档半径减半采样率提高保证跟手 overlay.setBlurParams(radius 12f, sampleFactor 0.2f) } } override fun onScrollStateChanged(v: RecyclerView, newState: Int) { if (newState RecyclerView.SCROLL_STATE_IDLE) { isScrolling false // 停止后恢复高清档 overlay.setBlurParams(radius 24f, sampleFactor 0.25f) overlay.markDirty() } } })这里的核心是 onScrollStateChanged 只在状态切换时触发用 isScrolling 标记避免重复设置。即使新手机性能强我也会保留这个分级更新逻辑因为透明层截屏本身是跨窗口操作低频下做到不卡和功耗可控高频下再强的 GPU 也扛不住全屏双模糊。5. 玻璃蒙层常见问题与排查模糊失效、黑屏、掉帧5.1 模糊失效某些设备上过度绘制直接变透明现象是蒙层区域在日志里一切正常但屏幕上完全透明或者蒙层显示成一块纯灰色没有任何模糊痕迹。这个在国产 ROM 的低端机上尤其明显不是你的代码没跑而是系统把蒙层所在的 Window 识别成了“不透明”或“不可见”直接跳过了绘制。原因有三个方向一是蒙层 View 的 background 被设置成了不透明色系统硬件加速合成时做了优化直接涂掉下层二是 WindowManager 的 format 参数没设 TRANSLUCENT三是 RenderEffect 依赖硬件加速而部分定制系统对“应用内窗口”默认关闭了硬件加速或使用了兼容绘制路径。排查步骤先看最直接的在 onDraw 里打印 canvas.isHardwareAccelerated()如果是 false说明蒙层 View 走了软件渲染RenderEffect 不生效。解决是 setLayerType(LAYER_TYPE_HARDWARE, null) 强制硬件层但要注意这会让 View 占用额外显存同时确认 format PixelFormat.TRANSLUCENT并把 background 设为透明。5.2 蒙层区域黑屏或花屏现象是蒙层盖上去以后它覆盖的位置出现一块纯黑色或者模糊结果和背景内容明显对不上像是隔了几帧的旧画面。这种事在视频播放器、地图、WebView 场景最常见血泪经验是SurfaceView 和 TextureView 的内容根本不在普通 View 的绘制缓存里你截屏得到的是黑色或上一帧的残影。原因在于 Surface 的合成是独立于 View 树的WindowManager 的截屏 API 只能抓取 View 层级抓不到 GPU 直接合成的 Surface 内容。解决没有银弹SurfaceView 场景下要让蒙层跟随 SurfaceHolder 的回调在 surfaceDestroyed 时暂停蒙层在 surfaceCreated 后再恢复TextureView 可以尝试 getBitmap 手动合成但高频更新时开销极高。我一般会给蒙层加一个“黑块检测”截屏后采样中心区域像素如果亮度接近 0 且饱和度极低就自动降级为半透明遮罩至少不要露出难看的黑块。5.3 掉帧和内存暴涨radius 与采样率现象是蒙层加上以后页面滑动从 60 帧掉到 20 帧内存增量达到几百 MB甚至直接 OOM。这个不是玄学就是模糊算法和 Bitmap 的内存没有控制住。内存账要这样算一张 1440×3200 的 ARGB_8888 位图占 1440×3200×4 18MB如果你的降级分支每次都新建一张再来点缓存几百 MB 分分钟。优化手段有三个优先级从高到低降采样率到 0.2 以下复用 Bitmap 而不是每次 createScaledBitmap模糊半径控制在 30px 以内超过 40px 人眼分辨不出区别但算法耗时几乎翻倍。掉帧的另一个隐藏原因是截屏时机。不要在 onDraw 里做 Bitmap 截屏和模糊这会让主线程卡在同步操作上。正确做法是先 post 到后台线程做模糊拿到结果再 postOnAnimation 回到主线程换图。一次跨线程的数据传递大约有 2-3ms 的延迟但换回来的是滚动不卡的主线程。5.4 状态栏与导航栏区域蒙层错位现象是蒙层盖上去以后屏幕顶部有一条没被模糊的区域或者模糊内容整体向下偏移了几十像素刘海屏上尤其明显。这个基本是布局边界没算对。WindowManager 的坐标系统默认不包括状态栏区域。你在 Activity 里加的全屏蒙层它实际的可绘制区域是从状态栏底部开始的但底层内容截屏时你抓的却是整个 DecorView坐标和蒙层对不上。解决方式是给蒙层加 FLAG_LAYOUT_IN_SCREEN 和 FLAG_LAYOUT_NO_LIMITS让窗口布局可绘制到屏幕被系统装饰覆盖的区域内同时在截屏时把内容裁剪到蒙层实际覆盖的矩形。另一个细节是 insets listener我这里给一个稳定的做法ViewCompat.setOnApplyWindowInsetsListener(overlay) { v, insets - val barInsets insets.getInsets( WindowInsets.Type.statusBars() or WindowInsets.Type.navigationBars() ) // 记录蒙层离屏边缘的距离截屏和绘制都按这个偏移 overlayOffsetX barInsets.left overlayOffsetY barInsets.top v.setPadding(0, 0, 0, 0) insets }注意这个 listener 必须在 addView 之后注册否则拿到的 WindowInsets 是 0。如果同时使用 WindowInsets 和 FLAG_LAYOUT_IN_SCREEN不要重复给蒙层 padding否则会出现双重缩进。5.5 蒙层与 Dialog 的层级冲突现象是弹窗打开时蒙层没有出现弹窗关闭后蒙层才显示或者蒙层直接盖在了 Dialog 上面把弹窗也一起模糊了。本质问题是你在 Activity 里添加的蒙层 Window 与 Dialog 的 Window 不在同一个层级。Dialog 默认使用 TYPE_APPLICATION 类型层级高于 Activity 但低于 TYPE_APPLICATION_PANEL。如果你把蒙层挂在 Activity 的 token 上它实际是 Activity 窗口的附属面板显示顺序在 Dialog 之下所以 Dialog 弹出来时蒙层被遮住。解决思路有两种一种是把蒙层也做成 Dialog 的兄弟窗口通过 dialog.window.addView 挂载保证它总是跟随 Dialog 展示另一种是放弃 WindowManager直接在 Dialog 的内容布局里加一个“内部蒙层” View模糊 Dialog 后面的内容用截屏实现。我倾向于第二种因为 Dialog 场景下的玻璃蒙层目标往往是“模糊 Dialog 背后的页面”而 Dialog 本身的前景内容不应该被模糊。这时把蒙层做成 Dialog 内容布局的背景层用 Dialog 的窗口 token 截取底层页面逻辑上最干净也不会牵扯到窗口类型权限问题。6. 进阶按需模糊的动态蒙层与验证方法6.1 动态更新模糊区域做一个会移动的“清晰窗口”玻璃蒙层不仅能做全屏静态模糊还能做成局部效果比如 Spotlight 引导整个屏幕被强模糊蒙住只有一个圆形区域保持清晰用来引导用户点击某个按钮。实现思路是蒙层绘制时用 clipPath 圈出清晰区域区域内绘制原始内容区域外绘制模糊内容。核心代码是蒙层 View 的 onDraw 改写override fun onDraw(canvas: Canvas) { canvas.save() // 先绘制模糊层 canvas.drawBitmap(blurredBitmap, 0f, 0f, blurPaint) // 用圆洞把清晰内容“挖”出来 canvas.clipPath(spotlightPath, Region.Op.DIFFERENCE) canvas.drawBitmap(originalBitmap, 0f, 0f, clearPaint) canvas.restore() }这里的逻辑是先用模糊位图铺底再用 DIFFERENCE 操作把圆形区域从裁剪范围里排除第二次 draw 的清晰位图只显示在圆洞内。坑在于 clipPath 在硬件加速下的 Region.Op.DIFFERENCE 兼容性一般Android 9 以下会出现锯齿或裁剪失效替代方案是用 BitmapShader 画一个圆形遮罩层。动态移动这个圆洞时不要在 onDraw 里反复 create 新的 Path复用同一个 Path只用 reset 和 addOval 更新圆心。6.2 用帧耗时和内存增量验证你的蒙层值不值得做蒙层做完了到底能不能上生产不能只看“挺好看的”。我会用一个固定的验证清单来验收每次改动后跑一遍数据都在预期内才敢合入。验证项阈值说明全屏模糊单帧耗时 8ms用 GPU 渲染分析器看 Draw 阶段内容滚动时掉帧率 5%连续滚动 10 秒统计帧间隔超过 20ms 的比例内存增量 30MB蒙层从显示到关闭Java 堆和 Native 堆的净增量模糊可见延迟 100ms底层内容变化到蒙层更新完成的时间这几个指标里“模糊可见延迟”最容易被忽略。我经历过一个案例模糊和性能都达标但用户反馈明显觉得“画面慢”排查半天发现是后台线程处理耗时 80ms加上主线程排队超过 100ms产生了可感知的滞后。后面加了一个“预览档”标记任何刷新请求先立刻放大当前缓存位图充数再用新位图替换用户就感知不到了。做这套东西的最终教训是玻璃蒙层不是“加上就好”的功能它是一个需要持续量化的性能债。每次改 radius、加动画、换实现分支都要回到这张表重新验收。我现在的习惯是固定把这些数据打进 release 包的日志里线上用户反馈卡顿时能直接拉出蒙层耗时而不是靠猜。希望这个方向能帮你把 Android 玻璃蒙层从“看着简单、做起来玄学”变成一套可控、可维护的组件。本文还有配套的精品资源点击获取