前段时间我们做一场线下直播 Demo，特意挑了一台千元级老安卓机跑腾讯特效SDK的 AI 美颜特效，结果现场掉到十几 fps，画面肉眼可见地卡顿。演示完产品经理拉住我问了一句："这效果能直接放出去给用户用吗？"——这句话比任何性能报告都扎心。于是我们回头把整个渲染链路重新理了一遍，从相机采集、纹理上传、人脸检测到特效叠加，逐个环节抠，最终把这台机器稳定拉回 30fps，CPU 占用还降了不少。今天就把这套实践拆开聊聊：腾讯特效SDK怎么覆盖 7 大平台，AI 美颜特效在老旧机上保持 30fps 渲染的优化思路，以及这些工作背后真正的降本提效逻辑。
这篇内容适合正在做直播、短视频、视频会议、在线教育等实时视频类 App 的客户端团队，也适合那些正在纠结"美颜特效到底自研还是接 SDK"的技术负责人。我不讲 PPT 上的概念，只讲我们在真实项目里遇到的问题、做的取舍和踩过的坑。
1. 为什么老旧机跑 30fps 会成为评审 AI 美颜特效的硬指标
1.1 真实使用场景里的设备，远比测试机残忍
很多团队做性能测试时习惯用旗舰机，或者买两台最新的中端机就以为覆盖了主力用户。但真实业务跑起来根本不是这么回事。我翻过我们 App 的设备分布后台，前 20 名机型里有接近一半是发布两三年以上的旧机型，骁龙 660、骁龙 710、麒麟 810 这些芯片依然大量存在，甚至还有不少 2GB 内存的低配设备在跑。
这些用户恰恰是直播、短视频类产品里最活跃的一批人。他们看直播要开美颜，拍短视频要加特效，视频会议要开背景虚化。你要是只保证旗舰机上效果惊艳，发版之后收到的不是好评，而是一堆"卡成 PPT""手机发烫""美颜开了就掉帧"的差评。老旧机的体验，直接决定一个视频特效功能能不能全量上线。
腾讯特效SDK 的能力再强，如果不能在老旧机上流畅跑起来，对真实业务来说就是镜花水月。所以我们把"老旧机 30fps"当成一个硬性准入门槛，而不是"尽力而为"的优化项。这个标准一开始就定下来，后续所有技术选型和效果配置都围绕它倒推。
1.2 30fps 是实时视频体验的"体感底线"
人眼对低于 24fps 的视频会感觉不流畅，但对实时交互画面，这个阈值会更高。用户在直播里看到自己的画面，或者视频会议里看着对方的脸，一旦帧率掉到 20fps 以下，画面就会明显发"木"，操作和画面之间有迟滞感，观感上非常难受。
30fps 正是实时视频通线和直播推流的最低舒适标准。60fps 当然更顺滑，但会让芯片负载和发热成倍上升，尤其在老机型上属于奢侈选项。所以定 30fps 不是目标低，而是这个帧率刚好踩在"用户能感知流畅"和"中低端硬件能扛住"的交汇点上。
我们把 30fps 定义为 P50 线，也就是至少一半的测试设备要达到这个水准。旗舰机要求 60fps P90 线不丢帧。这套标准看起来简单，却让我们在后续的优化里保持了清晰的优先级。
1.3 "老旧机能跑 30fps"等于给全机型矩阵兜了底
这里有一个在项目中反复被验证的规律：如果一款千元老机型能稳定跑到 30fps，那中端和旗舰机型几乎不会有性能问题。因为老机型卡，本质上是芯片的 CPU/GPU 算力、内存带宽、纹理吞吐能力卡住了某个瓶颈。你把老机型的瓶颈解决了，这些优化手段在高性能设备上只会更游刃有余。
反过来如果你只盯着旗舰机调效果，老机型一跑就露馅，最后还得回过头来重新适配，相当于做两遍工。用老旧机 30fps 当基准线，相当于用最苛刻的底线规格去要求整个技术架构，这比按设备分级一堆效果配置更省事。
我个人的建议是，性能测试机至少准备三台：一台近两年的旗舰、一台主力出货中端机、一台三年前的千元淘汰机。这三台跑通了，线上覆盖八九成问题都不大。我们后来把三台固定纳入 CI 自动化真机测试，每次 SDK 升级都先过这道门槛。
2. 7 平台接入背后的 SDK 架构与能力边界
2.1 7 平台到底覆盖哪些端
腾讯特效SDK 号称 7 平台覆盖，不是简单的"支持"两个字，而是每一端都有一致的核心能力和可接受的性能表现。结合我们的实际接入经验，这 7 个平台通常是：Android、iOS、Windows、macOS、Web H5、微信小程序，以及一个桌面应用容器端（Electron 或其他 Chromium 内核方案）。
这里有个容易踩的误区：很多团队以为"支持 Web"就是在页面上引一个 JS 文件，实际上 Web 端的性能损耗远高于原生，需要单独做降级策略。小程序端更特殊，因为渲染机制、线程模型都和原生应用完全不一样。7 平台不是让你一套代码无脑跑，而是 SDK 帮你把每一端的难点消化掉，但业务方仍然要知道各端的能力差异。
2.2 渲染层的统一抽象是跨端复用的关键
美颜特效的本质是视频帧处理，核心动作是：拿到相机帧、做人脸检测、做像素级美颜处理、叠加特效、输出给编码器或者预览层。这里最麻烦的就是不同平台的渲染 API 完全不同：Android 上是 OpenGL ES 或 Vulkan，iOS 上是 Metal，Windows 上是 Direct3D 或 OpenGL，Web 上是 WebGL，小程序里是一套基于同层渲染的兼容方案。
腾讯特效SDK 把这层差异封装成了统一接口。业务层只负责把视频帧传进去，设置美颜参数，然后从输出端拿处理后的帧，底层用的是什么 API 我们不用关心。这个抽象做得好不好，直接决定了跨端接入成本。我们团队之前也评估过自研跨端渲染方案，光是适配各端纹理格式和坐标系就够喝一壶的，更别提性能差异。
2.3 采集、预览、编码三大环路的接入模式
实际接入时，美颜特效要嵌进一条已经存在的音视频链路里。大多数 App 都有现成的采集和推流逻辑，SDK 不能太霸道地要求你推倒重来。腾讯特效SDK 提供了两种接入模式：
第一种是全链路接管模式，SDK 提供自定义采集器和渲染 View，从相机采集到预览显示都走 SDK 自己的链路。这个模式适合新项目或者链路比较简单的团队，好处是兼容性问题少，坏处是老链路里一些定制逻辑要迁移。
第二种是单点插入模式，业务方自己管采集和编码，只在中间某个环节把视频帧交给 SDK 处理，处理完再拿回来。我们当时用 iOS 端用的是第二种，因为原有采集链路里接了自定义的水印、连麦合成逻辑，不能全盘推倒。实践下来，单点插入的接入成本确实高一些，需要处理好帧格式转换和线程同步，但灵活性最大。
给个参考建议：如果你们只是给直播加个美颜，且链路不复杂，直接用 SDK 的全链路模式最省事；如果你们已经有一套成熟的自研音视频链路，老老实实用单点插入，不要为了省事重写采集层。
2.4 能力边界：它不是一个万能滤镜盒子
腾讯特效SDK 的核心能力包括人脸关键点检测、美颜美型、美妆、滤镜、动态贴纸、AI 手势识别、人像分割、背景分割等，基本覆盖了市面上绝大多数 C 端视频特效场景。但这不代表它能解决所有图形图像问题。比如老片修复、视频超分、局部重绘这类偏离线的重算法任务，更适合交给专门的算法服务去做，不要硬塞给实时特效链路。
对业务团队来说，清晰的能力边界反而省心。我们当时把所有需要人脸相关能力的场景列了个清单，逐个对照 SDK 能力表，发现大部分都能满足，个别特殊效果（比如特定行业的妆容还原）通过自定义贴纸资源也能搞定。认清边界，可以避免在接入过程中产生不切实际的期待。
3. AI 美颜特效链路：从人脸关键点到美颜上屏的每一帧
3.1 一帧美颜画面的完整旅程
美颜特效看起来只是一个"滤镜开关"，背后的链路比大多数人想象得要长。以 Android 端为例，一帧美颜画面的处理流程大致是：相机采集原始帧（YUV 或纹理）→ 预处理（旋转、镜像、缩放、格式转换）→ 人脸检测与关键点定位 → 根据美颜参数计算形变和滤波 → GPU Shader 执行磨皮、美白、瘦脸、大眼等算法 → 叠加贴纸、滤镜、人像分割效果 → 输出给预览 Surface 和编码器。
任何一个环节出现性能问题，帧率都会立刻掉下来。更麻烦的是，环节之间还有依赖关系：人脸检测慢了，后续的美颜形变就没了依据；纹理上传慢了，GPU 就得空转等待。我们做性能优化时，第一步就是把这整条链路在代码里埋点，用 systrace 和自定义耗时统计把每一段的耗时量化出来。
3.2 人脸关键点为什么是美颜的地基
美颜里的瘦脸、大眼、下巴调整、额头调整，本质上都是在做"人脸网格形变"。检测到的人脸关键点，就像给脸部画了一张网，每一个调整参数都是在移动网上的控制点，再由网格形变算法带动整块皮肤区域的像素重映射。
腾讯特效SDK 在这块用的是基于人脸关键点的实时形变方案，关键点数量越多、定位越准，形变就越自然。经典方案有 106 点和 240 点等级别，点数越多，对眼睛、嘴唇、脸颊轮廓的刻画越细腻，代价是 CPU 开销和模型体积上升。在老旧机上，我们一般把关键点等级调低一档，用 106 点保证基础美颜效果，只有在前置人像特写时才动态切换到更高级别。
这里分享一个实际经验：美颜算法最怕的不是检测不到人脸，而是检测到的人脸关键点在抖动。如果关键点在相邻帧之间轻微抖动，瘦脸效果就会变成"脸在呼吸"，非常明显。腾讯特效SDK 内部有时域平滑处理，但我们接自定义特效时也踩过这个坑，最后是在上层对关键点坐标做了低通滤波才解决。
3.3 实时磨皮的算法选型与代价
磨皮是美颜里最吃性能也最见效果的一项。常见方案有保边滤波（双边滤波、导向滤波）、基于皮肤检测的空域/频域滤波、以及近两年出现的 AI 肤色分割方案。保边滤波效果好但计算量大，空域滤波速度快但容易把皮肤纹理磨成"塑料脸"。
在实时视频链路里，腾讯特效SDK 走的是轻量级皮肤检测 + 多尺度保边模糊的路线。它先通过像素颜色空间和亮度特征检测皮肤区域，再对皮肤区域做平滑处理，非皮肤区域（眼睛、眉毛、头发、嘴唇）保持清晰。这样既能达到"磨皮但不失真"的效果，又不会让 GPU 负载爆炸。
有一点产品同学经常忽略：磨皮强度不是越大越好。我们刚开始把磨皮拉到 80% 看效果，觉得还挺好，后来发现人脸在运动时容易出现"糊成一团"的现象。最终线上默认磨皮强度控制在 50%-60%，既保留皮肤质感，又避免过度处理造成的不自然。
3.4 渲染管线的开销分布与定位方法
我们在一台典型老机型上用 Profile 工具统计了一帧美颜特效的耗时分布，大致是这样的：
| 环节 | 耗时占比 | 说明 |
|---|---|---|
| 人脸检测与关键点 | 20%-40% | CPU 端，模型推理为主，分辨率越高越慢 |
| 美颜 Shader（磨皮、美白、形变） | 25%-35% | GPU 端，受片元和纹理采样量影响 |
| 纹理上传与格式转换 | 10%-25% | 相机帧从 CPU 传到 GPU，老机型尤其明显 |
| 特效贴纸、滤镜、合成 | 10%-20% | 叠加层数越多越慢 |
| 其他开销（同步、线程切换） | 5%-10% | 容易被忽略但真实存在 |
这张表帮我们建立了优化的优先级：先看占比最高的环节，而不是凭感觉去调 Shader。我们实际调优时发现，很多团队一卡就先想到砍磨皮精度，其实纹理上传和线程同步的开销更大，优化空间也更大。
如果你要复现这张表，推荐做法是：在 SDK 回调里记录每帧的起始和结束时间，用人脸检测、美颜处理、特效合成的分阶段回调做耗时插桩。腾讯特效SDK 提供了部分接口能拿到处理耗时，拿不到的地方就用系统工具补。
4. 老旧机 30fps 渲染优化：我们项目实测的优化路径
4.1 先定位瓶颈，不要凭感觉优化
这是我们项目里最有价值的一条经验：性能优化最忌讳的是一开始就凭感觉猜瓶颈。我们最初以为美颜卡是因为磨皮 Shader 太重，于是花了一周去调 Shader 指令数，结果帧率几乎没变化。后来认真做 Profile 才发现，瓶颈出在相机帧从 CPU 拷贝到 GPU 的纹理上传环节，占了一帧耗时的近三分之一。
定位瓶颈的流程很简单但容易忽略：先用 systrace 或者 Android Studio Profiler 抓一帧的完整调用链，看 CPU 各线程和 GPU 各阶段的负载分布，再逐一放大可疑模块。如果 GPU 负载高，就调低渲染分辨率和 Shader 复杂度；如果 CPU 负载高，就查人脸检测模型和线程调度；如果两者都不算高但帧率还是上不去，多半是同步等待或者纹理上传的带宽瓶颈。
4.2 降低人脸检测频率，中间帧做预测补偿
人脸检测模型再轻量，跑一帧也要十几到几十毫秒的 CPU 时间。如果每一帧都全量检测，在老旧机上 CPU 很容易被吃满。我们在接入时做了一项改动：把连续帧的人脸检测频率降到每 2-3 帧检测一次，中间帧沿用上一帧的关键点结果，再用光流或位置预测做小幅修正。
实测下来，这个优化能省下大约 10%-15% 的 CPU 占用，而人脸美颜的观感几乎没有变化。因为人的脸部运动在连续帧之间本来就有很大的时间相关性，除非用户正在非常快速地左右摇头，否则降频检测的误差非常小。人脸跟踪一旦丢失，再立即恢复全帧检测，这样既保证体验，又不让 CPU 一直满负荷。
4.3 渲染分辨率分级与半分辨率方案
另一个立竿见影的优化是"半分辨率处理"。做法是先把输入视频帧缩小到一半分辨率（比如从 1080p 缩到 540p），在低分辨率下完成磨皮、美白、形变等计算量较大的处理，输出时再双线性放大回原始分辨率。
为什么能这么干？美颜特效处理的是人脸皮肤的大面积平滑，属于低频视觉信息，对分辨率不敏感。即使把处理分辨率降到原来的一半，肉眼几乎分辨不出差异，但 GPU 的片元着色压力会降到原来的四分之一，这是非常可观的性能收益。
我们在老机型上把美颜处理分辨率设为 540p，特效贴纸合成保持在 720p，整体渲染分辨率保持 1080p 输出。实际效果是，磨皮和美白在放大后依旧自然，只有凑近屏幕细看才会发现皮肤纹理被抹得稍微多了点，但在手机屏幕上完全够用。
4.4 减少绘制层级，能一次合成绝不来回切换
特效叠加场景多了之后，最常见的渲染性能杀手是 framebuffer 来回切换。假设用户同时开了美颜、滤镜、一个动态贴纸、一个背景分割，如果每个效果都渲染到独立缓冲再逐层合成，老机型直接卡死。
优化思路是把能合并到一起的 Shader 操作尽量合并。磨皮、美白、滤镜这些像素级效果，可以写进同一个片元着色器一次遍历完成；贴纸和背景分割这类需要单独纹理叠加的效果，则通过离屏 FBO 一次性合成，避免中间结果反复拷贝。
腾讯特效SDK 内部已经做了大量合并，但我们在接自定义贴纸资源时仍然发现过绘制层数过多导致的掉帧，后来通过减少贴纸层数、限制最大特效叠加数解决了。这里我的建议是：上线前给产品定一个"特效组合上限"，比如最多同时开 2 个动态贴纸 + 1 个背景特效，超过就自动降级，别让用户自由叠加到卡死。
4.5 纹理上传优化：OES 外部纹理与零拷贝
纹理上传是老旧机上一个很隐蔽的瓶颈。相机采集到的帧通常是一块 YUV 数据，需要转换成 RGBA 纹理才能给 GPU 的 Shader 采样。这个转换和上传过程，如果走"CPU 读回来再拷贝到 GPU"，一次就要拷贝好几 MB 的数据，在内存带宽有限的老机器上非常致命。
正确的做法是使用外部纹理（Android 上是 OES 外部纹理，iOS 上是 CVPixelBuffer 直接绑定纹理），让 GPU 直接从相机管线拿数据，避免 CPU 侧拷贝。腾讯特效SDK 在 Android 端支持通过 SurfaceTexture 直接消费相机纹理，iOS 端支持 Metal 的 CVPixelBuffer 零拷贝路径。我们切到零拷贝方案后，纹理上传耗时下降了一半还多。
这一步需要和采集端紧密配合。如果你用的是第三方采集库，要注意检查它是否暴露了纹理 ID 或 SurfaceTexture，而不是只给一个 YUV 字节数组。只给字节数组的话，零拷贝方案就无从谈起。
4.6 帧率与功耗自适应：先稳住 30fps，再谈效果
老机型即使优化过后，长时间运行也会因为发热而降频，帧率又会掉回去。所以我们加了一套简单的自适应策略：根据设备温度和最近几帧的平均耗时，动态调整特效配置档位。
具体来说分三档：流畅优先档（关闭美妆和高负载特效，只保留基础美颜，处理分辨率降到 480p）、均衡档（默认档，保留主要美型美颜，540p 处理）、效果优先档（打开所有特效，720p 处理）。系统监测到 CPU 温度超过阈值或连续掉帧，就自动降一档；温度回落后再恢复。
这套策略上线后，老机型的帧率稳定性明显改善。用户不会看到"突然卡一下"，只是特效细节轻微变化，对普通用户来说感知不强。相比硬顶着高效果跑，体验到热降频卡顿，自适应降级是更讨巧的做法。
4.7 优化结果数据参考
我们在某款骁龙 660 老机型上做了一轮完整优化，结果对比如下：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 平均帧率 | 18-22 fps | 29-31 fps |
| 人脸检测耗时 | 28 ms | 18 ms |
| 纹理上传耗时 | 14 ms | 6 ms |
| 磨皮 Shader 耗时 | 8 ms | 4 ms |
| 整帧处理耗时 | 52 ms | 32 ms |
| 相比自身优化前 | 卡顿明显 | 流畅可用 |
当然，每台设备情况不一样，这个数据只是参照。但整体的优化思路是共通的：先量化，再砍最大头，最后用自适应档位保底。
5. 降本提效的落地账本：包体积、接入成本和多端复用
5.1 包体积控制：老机型低配也要塞得下
在接入任何特效 SDK 之前，我们最先考虑的是包体积。一个美颜特效 SDK，如果动辄增加几十 MB，很多产品团队直接就不考虑了。腾讯特效SDK 在包体积上做了不少工作，核心算法模型和资源可以按需加载，基础美颜能力只占很小的体积。
我们在 Android 端集成了核心美颜 + 少量基础贴纸，包体积增量控制在 2MB 左右。其他动态贴纸、滤镜资源全部走云端下载，用户用到哪个特效才拉取哪个资源。这样既保证了首包轻量，又能在运营侧灵活下发新特效，不用发版。
对老旧机型用户来说，包体积大不大还会影响下载转化率和安装成功率，尤其在网络环境一般的地区，每 1MB 都很珍贵。控制包体积不是简单的技术洁癖，而是实打实的用户增长指标。
5.2 业务代码"一次编写、多端运行"的省人效应
我们团队最直接的降本体感来自业务层的复用。因为腾讯特效SDK 在 7 个平台上屏蔽了底层差异，我们只需要在业务层写一套美颜面板逻辑：获取摄像头、创建特效引擎、设置美颜参数、处理回调帧、更新 UI 状态。
这套逻辑在 Android 上写完后，iOS 端可以复用大约 70% 的代码，桌面端和 Web 端虽然要调整一些 UI 适配，但核心的状态机和参数配置模型是同一套。比我们之前设想的各端独立开发，至少省了一倍的人力。
有同学会问：SDK 的接口抽象会不会丢性能？从我们的实测看，跨端抽象层的开销非常小，和整体帧耗时相比可以忽略。这个抽象换来的多端复用收益，远比那点接口包装开销划算。
5.3 运营侧降本：远程配置与 AB 测试
美颜参数不是一个静态值。不同主播的肤质、光线环境、审美偏好都不一样，产品团队经常要调磨皮强度、美白强度、滤镜风格。如果每次调参都要发版，运营成本高到没法接受。
腾讯特效SDK 支持指令级参数下发，配合我们自己的远程配置中心，可以实时调整美白、磨皮、瘦脸等参数的上限和默认值，不需要更新 App。新特效资源也可以直接通过资源包下发进行 AB 测试，观察用户留存、使用时长的差异，再决定是否全量上线。
这种运营能力在很大程度上减少了"为调一个参数专门发版"的低效工作。我们把参数下发做成可视化配置之后，产品同学自己就能调，不再占用开发排期。这是非常容易被忽视的降本点。
5.4 自研还是接第三方 SDK：算一笔完整账
最后聊聊大多数团队纠结的问题：自研美颜特效到底值不值。很多团队一开始觉得"不就是几个滤镜加磨皮嘛，自己写也不难"。但真正做起来会发现，自研的核心成本不在第一版 Demo，而在后面三年的持续投入。
光是人脸关键点模型，就需要大量标注数据训练和真机适配；渲染层要兼容 7 个平台的不同 GPU 驱动；新机型摄像头纹理格式的兼容性测试要持续做；美颜算法还要跟随审美趋势和行业标准不断更新。这是一条没有尽头的维护线。
第三方 SDK 要付 license 费用，但换来的是持续更新的算法和跨端适配能力。我们把自研方案的成本拆解后做了一个粗算：如果只做 1 个端、覆盖基础美颜、半年迭代一次，自研确实省；但如果要做 7 个端、持续上线新特效、保持老机型流畅，第三方的整体成本优势非常明显。加上接入腾讯特效SDK 后我们团队可以省出人力去做真正有差异化的事情，这笔账怎么算都是划算的。
6. 接入过程中的坑与排查实录
6.1 老机型纹理格式不统一导致的偏色问题
我们灰度测试时，有部分老机型反馈美颜后的画面偏红。排查了半天，发现是这些设备的摄像头输出的纹理格式不是标准的 RGBA，而是 YUV 的某种变体（NV12 或 NV21），在 GPU 上直接采样时 R 和 B 通道发生错位。
这个问题在腾讯特效SDK 的高版本里会自动做格式检测和转换，但我们用的旧版本没有覆盖全。最终是我们把所有支持的分辨率和纹理格式组合在真机实验室里跑了一遍，确认 SDK 的输入格式接口处理正确后才解决。这里的教训是：接入时一定要确认你们传入 SDK 的视频帧格式是统一的，不要依赖单台设备的默认输出。
6.2 Web 端性能黑洞：Canvas 拷贝把 GPU 优势全吃掉了
Web 端接入时我们踩过一个比原生端更深的坑。一开始为了快速验证，我们用 Canvas 接视频帧，结果在 Chrome 上跑美颜特效，帧率只有十五六帧。排查后发现问题出在 Canvas 的每一帧拷贝和像素读取上，数据在 CPU 和 GPU 之间来回倒了至少三次。
后来改成 WebGL 直接上传纹理，让美颜 Shader 在 GPU 上跑，帧率一下就到了 40fps 以上。这里想提醒做 Web 的同事：接视频特效一定要走 WebGL 纹理路径，尽量避免 Canvas 的 drawImage 加 getImageData 组合，后者在低端电脑上基本是性能杀手。
6.3 小程序端双线程限制下的降级策略
小程序端的渲染机制比较特殊，不能直接像原生那样拿 GPU 纹理和 GL 上下文。我们在微信小程序里接入时，视频帧处理只能走同层渲染的兼容方案，性能天然比原生弱一个档次，想要在老机型上保持 30fps 非常吃力。
我们最终的方案是分场景降级：视频通话场景只保留基础美颜（磨皮、美白、瘦脸），关闭动态特效和背景分割；拍照和短视频录制场景再放开完整特效。用户侧感知是：通话时画面干净自然，拍摄时功能丰富。这样既保住了最核心的视频体验，又没有浪费 SDK 的能力。
6.4 重复创建 SDK 实例导致的内存泄漏
我们在做直播连麦功能时，因为用户频繁上下麦，每次连麦都创建一个新的特效引擎实例。灰度测试后发现内存持续上涨，最终定位到是旧实例没有被及时释放，GPU 纹理和模型资源仍然占用着内存。
排查链路是：先看内存快照，发现大量 Texture 对象残留，再定位到 SDK 实例没有走正确的 dispose 流程。修复方式是封装一个特效引擎生命周期管理器，进入连麦时创建、退出连麦时统一释放，并在释放前把 GL 资源回收干净。上线后内存曲线恢复平稳。
这里分享一个检查经验：接 SDK 时，一定要用 LeakCanary（Android）或 Instruments（iOS）做一次完整的连麦进出测试，专门看 OpenGL 纹理和 RenderBuffer 是否有泄漏。很多 SDK 的内存泄漏不会立刻崩溃，但会让 App 越用越卡。
6.5 灰度发布与专项监控体系
新版本特效 SDK 上线前，我们在线上做了严格的灰度监控。除了常规的崩溃率、卡顿率，还加了针对特效链路的专项指标：帧率分布、单帧处理耗时、内存峰值、GPU 温度、美颜开启率、特效使用时长。
这些指标按机型维度拆开看，一旦发现某款老机型的帧率 P50 掉到 25fps 以下，灰度就会自动暂停。有了这套监控，后面几次 SDK 升级都非常平稳，再也没有发生过"发版后大量用户反馈美颜卡顿"的事故。
我最后想分享的一个实际感受是：做美颜特效性能优化，不要被"AI 算法"四个字吓住。本质上它还是视频渲染管线的问题，先量化、再优化、最后用自适应方案保底，这套方法论在任何平台上都通用。腾讯特效SDK 帮我们省掉了多端适配的大量重复劳动，但真正的调优工作仍然需要业务团队深入链路里去抠细节。老机型这根弦绷住了，全机型矩阵的体验自然就稳了。
