企业官网建设流程全解析

简介：面向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 轴模糊半径，单位是像素而非 dp；tileMode 决定模糊采样到边缘时怎么处理。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:android="http://schemas.android.com/apk/res/android"> <View android:id="@+id/glass_overlay_view" android:layout_width="match_parent" android:layout_height="match_parent" android:background="@android:color/transparent" /> </merge>

Montage 布局透明背景，因为模糊效果是绘制在 View 内容上的，不是靠背景色。接下来是 WindowManager 参数表，这些 flag 直接决定蒙层能不能盖到状态栏后面：

这里最容易搞错的三个参数是：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 是渲染到屏幕上的像素，不是 dp；sampleFactor 只影响降级分支，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 用帧耗时和内存增量验证你的蒙层值不值得做

蒙层做完了，到底能不能上生产，不能只看“挺好看的”。我会用一个固定的验证清单来验收，每次改动后跑一遍，数据都在预期内才敢合入。

这几个指标里，“模糊可见延迟”最容易被忽略。我经历过一个案例：模糊和性能都达标，但用户反馈明显觉得“画面慢”，排查半天发现是后台线程处理耗时 80ms，加上主线程排队超过 100ms，产生了可感知的滞后。后面加了一个“预览档”标记，任何刷新请求先立刻放大当前缓存位图充数，再用新位图替换，用户就感知不到了。

做这套东西的最终教训是：玻璃蒙层不是“加上就好”的功能，它是一个需要持续量化的性能债。每次改 radius、加动画、换实现分支，都要回到这张表重新验收。我现在的习惯是固定把这些数据打进 release 包的日志里，线上用户反馈卡顿时能直接拉出蒙层耗时，而不是靠猜。希望这个方向能帮你把 Android 玻璃蒙层从“看着简单、做起来玄学”变成一套可控、可维护的组件。

本文还有配套的精品资源，点击获取