1. 为什么在相机数据流里NV21 到 Bitmap 的转换值得单独写一个工具类做过 Android 相机或者视频处理的人大概率都绕不开一个格式NV21。它是 Android 相机预览回调里最经典的输出格式之一尤其在 Camera1 时代几乎是默认选项到了 Camera2 和 CameraX 时代很多设备在特定分辨率下依然会吐出 NV21 数据。问题在于NV21 是一块裸的 YUV 内存而 UI 层要显示、要合成、要保存最终都得落到 Bitmap 上。这中间的转换如果处理不好轻则预览卡顿、掉帧重则内存暴涨直接 OOM。我见过不少项目直接把 NV21 转 Bitmap 的逻辑散落在相机回调里每次预览帧来了就 new 一个 Bitmap转完画到 SurfaceView 上然后交给 GC。这种写法在低分辨率下勉强能跑一旦上到 1080P 甚至更高帧率立刻崩掉。原因很简单NV21 转 Bitmap 涉及 YUV 到 RGB 的色彩空间转换逐像素计算量巨大纯 Java 实现单帧 1080P 转换动辄几十毫秒再加上频繁的对象分配GC 压力直接拉满。所以一个专门处理这类转换的工具类价值不在于能转而在于转得快、转得稳、转完还能直接参与后续合成。标题里提到的两件事——NV21 转 Bitmap以及两张 Bitmap 按透明度混合——其实是一条完整的图像处理链路相机拿到 NV21转成 Bitmap 作为底图再叠加一层带透明度的水印、贴纸或者 UI 图层最后输出给用户。这条链路在直播、短视频、扫码、AR 贴纸等场景里反复出现把它封装成一个可复用的工具类是很有必要的。这篇文章我会从实际工程角度出发把 RenderScript 在这两个环节里的用法讲透包括为什么选 RenderScript、脚本怎么写、内存怎么管、混合的 alpha 公式到底怎么算以及我在真机上踩过的那些坑。适合正在做相机预览、图像合成、视频帧处理的 Android 开发者也适合想了解 RenderScript 实际落地价值的朋友。即使你之前没接触过 RenderScript跟着看下来也能直接抄作业。2. RenderScript 在图像逐像素处理上的定位与选型逻辑2.1 为什么不用纯 Java 或者 OpenGL先说结论NV21 转 Bitmap 和 Bitmap 混合本质上都是对每个像素做独立或半独立的数学运算这类任务最适合并行化。纯 Java 循环是串行的CPU 单核跑满也快不到哪去OpenGL 虽然并行能力强但为了一个格式转换去搭一套 EGL 环境、写 shader、管理纹理工程量太大而且和 Bitmap 之间的来回拷贝反而增加开销。RenderScript 的定位刚好卡在中间它由 Android 框架提供运行时会把计算任务分发到多核 CPU、GPU 或 DSP 上执行开发者只需要写一段类似 C 的脚本描述每个像素怎么算剩下的并行调度交给运行时。对于图像处理这种天然并行的任务RenderScript 能用很低的接入成本拿到接近原生的性能。不过要客观说一句RenderScript 从 Android 12 开始被标记为废弃官方推荐迁移到 Vulkan 或者直接写 NEON 优化代码。但在大量存量项目里尤其是需要兼容到 Android 5.0 到 Android 11 这个区间的应用RenderScript 依然是性价比很高的选择。它的 API 稳定、兼容性好、代码量少对于工具类这种写完就不太动的基础设施维护成本可以接受。如果你的 minSdk 已经拉到很高那可以考虑用 RenderScript 的思路去写 NEON 或者用 libyuv但本文聚焦 RenderScript 方案。2.2 RenderScript 的三种典型用法在实际项目里RenderScript 处理图像一般有三种模式理解它们的区别很关键用法适用场景数据流转性能特点ScriptIntrinsic 内置内建函数模糊、卷积、色彩矩阵、混合Allocation 进 Allocation 出最快代码最少但功能固定自定义 ScriptC 脚本格式转换、自定义滤镜需要写 .rs 文件灵活性能接近内建配合 rsGetElementAt需要跨像素访问脚本内随机访问灵活但要注意访存模式NV21 转 Bitmap 因为涉及 YUV 到 RGB 的矩阵运算且 NV21 的 UV 是交错存储的用 ScriptIntrinsic 里的 YuvToRGB 内建函数是最省事的做法。而两张 Bitmap 按透明度混合ScriptIntrinsicBlend 提供了现成的混合模式其中就包括按 alpha 混合。所以这个工具类的核心其实是把这两个内建函数用好而不是自己从头写脚本。2.3 内存分配策略决定了工具类的成败RenderScript 里所有的数据都要先包装成 Allocation。Allocation 的创建和销毁是有成本的如果每帧都新建 Allocation性能优势会被抵消掉。正确的做法是复用根据输入尺寸缓存 Allocation尺寸不变就重复使用。这一点在相机预览场景里尤其重要因为预览分辨率通常是固定的完全可以做到 Allocation 只创建一次。另外要注意 Type 的构建。NV21 的 Y 分量是 width×heightUV 分量是交错的两个通道总大小是 width×height×3/2。用 Element 构建 Type 时要选对元素类型YUV 数据用 U88 位无符号整数就够了RGB 输出用 U8_4 或者 U8_3。这些细节如果搞错轻则颜色错乱重则直接崩溃。3. NV21 转 Bitmap从相机裸数据到可用位图3.1 NV21 的内存布局先搞清楚在动手写代码之前必须把 NV21 的内存排布弄明白否则后面调颜色会调到怀疑人生。NV21 属于 YUV420SP 的一种它的排列是先存一整块 Y 平面长度是 width×height紧接着存交错的 VU 平面长度是 width×height/2其中每两个字节是一组 V 和 U顺序是 V 在前 U 在后。注意这里有个容易记混的点NV21 是 VU 交错NV12 是 UV 交错两者刚好相反。YUV420 的特点是 UV 分量在水平和垂直方向都做了 2:1 下采样也就是说每 2×2 个像素共用一组 UV。这就是为什么 UV 平面的长度是 Y 的四分之一再乘以 2也就是总大小是 Y 的 1.5 倍。理解了这个布局才能正确地把数据塞进 Allocation。3.2 用 ScriptIntrinsicYuvToRGB 完成转换Android 框架提供了一个内建的 YuvToRGB 脚本专门干这件事。它的输入是一个包含 YUV 数据的 Allocation输出是 RGBA 的 Allocation。使用步骤大致如下// 假设 rs 是 RenderScript 实例yuvData 是 NV21 字节数组 Type.Builder yuvTypeBuilder new Type.Builder(rs, Element.U8(rs)) .setX(width) .setY(height) .setYuvFormat(ImageFormat.NV21); Type yuvType yuvTypeBuilder.create(); Allocation yuvAllocation Allocation.createTyped(rs, yuvType, Allocation.USAGE_SCRIPT); yuvAllocation.copyFrom(yuvData); Type.Builder rgbaTypeBuilder new Type.Builder(rs, Element.RGBA_8888(rs)) .setX(width) .setY(height); Type rgbaType rgbaTypeBuilder.create(); Allocation rgbaAllocation Allocation.createTyped(rs, rgbaType, Allocation.USAGE_SCRIPT); ScriptIntrinsicYuvToRGB yuvToRgb ScriptIntrinsicYuvToRGB.create(rs, Element.U8_4(rs)); yuvToRgb.setInput(yuvAllocation); yuvToRgb.forEach(rgbaAllocation); Bitmap output Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888); rgbaAllocation.copyTo(output);这段代码看起来简单但有几个关键点必须注意。第一setYuvFormat(ImageFormat.NV21)这一句不能省它告诉 RenderScript 输入的是 NV21 而不是别的 YUV 格式省了就会颜色错乱。第二输出 Allocation 的元素类型要和 Bitmap 的配置匹配ARGB_8888 对应 RGBA_8888。第三copyTo(Bitmap)这个重载方法要求 Bitmap 的配置和 Allocation 的元素类型一致否则会抛异常。3.3 复用 Allocation 的正确姿势上面那段代码如果每帧都执行性能会很差因为 Type 和 Allocation 都在反复创建。工具类里应该把 Allocation 缓存起来按尺寸做 key。我一般的做法是维护一个以 width x height 为 key 的缓存 Map里面存 yuvAllocation 和 rgbaAllocation。每次转换前先查缓存命中就直接 copyFrom没命中才创建。private Allocation getYuvAllocation(int width, int height) { String key width x height; Allocation cached yuvCache.get(key); if (cached null) { Type type new Type.Builder(rs, Element.U8(rs)) .setX(width).setY(height) .setYuvFormat(ImageFormat.NV21) .create(); cached Allocation.createTyped(rs, type, Allocation.USAGE_SCRIPT); yuvCache.put(key, cached); } return cached; }这里有个坑要提醒Allocation 是绑定到具体 RenderScript 实例的如果 RenderScript 被销毁重建了缓存里的 Allocation 就失效了必须一起清掉。所以工具类的生命周期管理要和 RenderScript 实例绑定通常放在一个单例或者和相机生命周期对齐的组件里。3.4 输出 Bitmap 的复用与内存控制Bitmap 的创建同样有成本。如果每帧都Bitmap.createBitmap即使 Allocation 复用了Bitmap 这一层的分配依然会带来 GC 压力。更优的做法是复用 Bitmap用rgbaAllocation.copyTo(bitmap)把数据写进已有的 Bitmap 里。但要注意如果这个 Bitmap 要交给 UI 线程显示而复用意味着下一帧会覆盖它的内容可能出现画面撕裂或者显示异常。所以复用 Bitmap 的前提是要么在同一个线程里同步完成显示要么用双缓冲交替使用两个 Bitmap。我在实际项目里的经验是相机预览这种高频场景用双缓冲 Bitmap 最稳。准备两个 Bitmap交替作为 copyTo 的目标显示完的那个下一帧再复用。这样既避免了频繁分配又不会出现覆盖问题。内存占用也可控1080P 的 ARGB_8888 Bitmap 大约是 8MB两个也就 16MB比每帧分配要健康得多。4. 两张 Bitmap 按透明度混合alpha 合成的原理与实现4.1 混合的数学本质两张 Bitmap 按透明度混合说白了就是 alpha 合成。假设底图是 dst上层图是 src上层图的 alpha 是 a0 到 1 之间那么混合结果的每个通道值可以表示为result src * a dst * (1 - a)这是最基础的线性插值也叫 source-over 合成。如果上层图本身每个像素还带有自己的 alpha 通道那就要用更通用的 Porter-Duff 公式outA srcA dstA * (1 - srcA) outRGB (srcRGB * srcA dstRGB * dstA * (1 - srcA)) / outA理解这个公式很重要因为它决定了混合结果是否符合预期。很多人在做水印叠加时发现边缘发黑或者颜色不对往往就是没处理好预乘 alphapremultiplied alpha的问题。Android 的 Bitmap 默认是预乘 alpha 的也就是说 RGB 通道的值已经乘过 alpha 了这一点在混合时必须考虑。4.2 用 ScriptIntrinsicBlend 实现混合RenderScript 提供了 ScriptIntrinsicBlend里面有一堆混合模式其中forEachSrcOver就是标准的 source-over 合成正好对应上面的公式。用法如下ScriptIntrinsicBlend blend ScriptIntrinsicBlend.create(rs, Element.U8_4(rs)); blend.forEachSrcOver(srcAllocation, dstAllocation);注意参数顺序第一个是源第二个是目标结果会写回目标 Allocation。也就是说dstAllocation 既是输入也是输出混合后的结果直接覆盖在它上面。这个语义要记清楚否则容易搞反。但这里有个问题ScriptIntrinsicBlend 的混合是逐像素按各自的 alpha 来的它没有一个全局的透明度参数。如果你想整体控制上层图的透明度比如让水印整体半透明就需要先把上层图的 alpha 通道统一乘一个系数再做混合。这一步可以用一个自定义脚本或者更简单地在生成上层 Bitmap 时就设置好 alpha。4.3 全局透明度控制的两种方案方案一在绘制上层 Bitmap 时用 Canvas 配合 Paint 的 alpha。比如你要把一张水印图以 50% 透明度叠加可以先用 Canvas 把水印画到一个临时 Bitmap 上绘制时paint.setAlpha(128)。这样得到的临时 Bitmap 每个像素的 alpha 就已经是原 alpha 乘以 0.5 了再走 forEachSrcOver 就是正确的整体半透明效果。方案二写一个自定义 RenderScript 脚本在混合前对 src 的 alpha 做缩放。这种方式更灵活适合透明度需要动态变化的场景比如滑动条实时调节水印透明度。脚本大概长这样#pragma version(1) #pragma rs java_package_name(com.example.imagetool) float gAlphaScale 1.0f; uchar4 RS_KERNEL scaleAlpha(uchar4 in) { uchar4 out in; out.a (uchar)(in.a * gAlphaScale); // 注意预乘 alphaRGB 也要跟着缩放 out.r (uchar)(in.r * gAlphaScale); out.g (uchar)(in.g * gAlphaScale); out.b (uchar)(in.b * gAlphaScale); return out; }这里为什么要连 RGB 一起缩放因为 Android Bitmap 是预乘 alpha 的如果只改 alpha 不改 RGB混合时颜色会偏亮。这个细节是很多人踩过的坑我在下面还会专门讲。4.4 混合结果的输出与显示混合完成后dstAllocation 里就是最终结果用copyTo(bitmap)写回 Bitmap 即可。如果这个 Bitmap 要显示到 ImageView 或者 SurfaceView注意线程问题RenderScript 的操作可以在任意线程执行但 UI 更新必须在主线程。我一般把整个转换和混合流程放在工作线程完成后通过 Handler 或者 post 把 Bitmap 交给 UI。还有一点如果底图和上层图尺寸不一致混合前必须先统一尺寸。ScriptIntrinsicBlend 要求两个 Allocation 的 Type 完全一致尺寸不同会直接报错。所以工具类里应该提供一个尺寸对齐的步骤通常是以上层图为准把底图缩放到相同尺寸或者反过来。缩放本身也可以用 RenderScript 做但那是另一个话题了。5. 工具类设计接口、缓存与线程安全的取舍5.1 对外暴露的接口应该长什么样工具类的接口设计要遵循调用方少操心的原则。我一般会暴露这么几个方法public class ImageProcessTool { // NV21 转 Bitmap复用内部缓存 public Bitmap nv21ToBitmap(byte[] nv21, int width, int height); // 两张 Bitmap 按透明度混合返回混合后的 Bitmap public Bitmap blendBitmap(Bitmap base, Bitmap overlay, float alpha); // 释放所有缓存资源 public void release(); }nv21ToBitmap内部处理 Allocation 缓存和 Bitmap 复用调用方只管传数据。blendBitmap接收一个 0 到 1 的 alpha 参数内部负责 alpha 缩放和混合。release用于在相机关闭或者页面销毁时清理资源这一步千万不能忘否则 RenderScript 和 Allocation 占用的内存不会释放。5.2 缓存设计的几个关键决策缓存的核心矛盾是缓存越多复用率越高但内存占用越大。对于相机预览这种固定分辨率的场景缓存一两个尺寸就够了。但如果你的应用同时支持预览和拍照拍照分辨率可能和预览不同那缓存就会多一份。我的建议是给缓存设一个上限比如最多缓存 3 个尺寸超出就按 LRU 淘汰。另外Bitmap 的复用要特别小心。前面提到双缓冲但如果调用方拿到 Bitmap 后异步使用比如丢给一个耗时任务处理那复用就会出问题。所以工具类要么明确文档说明返回的 Bitmap 在下一次调用后内容可能被覆盖要么干脆不复用 Bitmap只复用 Allocation。这是一个典型的性能与安全的权衡我倾向于在预览这种高频场景复用在拍照这种低频场景不复用。5.3 线程安全的边界在哪里RenderScript 本身是线程安全的多个线程可以共享一个 RenderScript 实例。但 Allocation 的 copyFrom 和 copyTo 如果并发操作同一个 Allocation就会出问题。所以工具类要么加锁要么约定单线程调用。我一般选择后者明确要求所有图像处理调用都在同一个工作线程里执行用一个 HandlerThread 串行化。这样既避免了锁的开销又保证了顺序。如果确实需要多线程并发处理不同尺寸的图像那就为每个线程维护独立的 Allocation 缓存或者用 ThreadLocal。但说实话相机预览场景很少需要这种并发串行化反而更简单可靠。6. 真机实测中那些文档不会告诉你的坑6.1 颜色偏绿或者偏紫YUV 格式没对上这是最常见的坑。NV21 和 NV12 的 UV 顺序相反如果设备实际输出的是 NV12你按 NV21 处理颜色就会偏。表现是肤色发绿或者发紫。排查方法很简单拿一张纯色图看转换后的颜色是否符合预期。如果偏绿大概率是 UV 顺序反了。解决办法是确认相机回调的格式Camera1 的onPreviewFrame默认是 NV21但有些设备可以通过参数改成 NV12改完记得同步改转换代码。6.2 混合后边缘发黑预乘 alpha 惹的祸前面提过Android Bitmap 默认是预乘 alpha 的。如果你从 PNG 加载一张带透明背景的水印它的 RGB 通道已经乘过 alpha 了。这时候如果你手动去改 alpha 而不改 RGB混合结果就会在透明边缘出现黑边。正确的做法是要么用Bitmap.setPremultiplied(false)关掉预乘要么在缩放 alpha 时同步缩放 RGB。我个人的经验是对于水印叠加这种场景保持预乘并同步缩放 RGB 最省心。6.3 高分辨率下依然卡顿Allocation 没复用或者 Bitmap 没复用如果你确认用了 RenderScript 还是卡先检查 Allocation 是不是每帧都在创建。一个简单的判断方法是在创建 Allocation 的地方打日志看每帧是否都打印。另一个检查点是 Bitmap如果每帧createBitmapGC 日志会很明显。这两个都复用之后1080P 的转换加混合在主流机型上单帧可以控制在 10ms 以内。6.4 RenderScript 实例泄漏release 没调用RenderScript 实例持有 native 资源如果不调用destroy()会一直占用内存。工具类的release方法里必须调用rs.destroy()并且清空所有缓存。我见过一个项目页面来回切换几次后内存就涨到几百 MB最后定位就是 RenderScript 没释放。这个坑很隐蔽因为 Java 层看不出明显泄漏得用内存分析工具看 native 部分。6.5 尺寸不是偶数时的诡异问题YUV420 要求宽高最好是偶数因为 UV 是 2×2 下采样的。如果相机输出的分辨率是奇数UV 平面的计算会出问题可能导致最后一行或者最后一列颜色异常。虽然大多数设备不会输出奇数分辨率但如果你自己裁剪或者缩放图像就要注意保持偶数尺寸。遇到颜色异常时先检查尺寸是不是偶数这个排查方向很多人想不到。7. 性能对比与优化空间RenderScript 到底值不值得用7.1 实测数据参考我在几台不同档次的设备上做过对比以 1080P NV21 转 Bitmap 为例纯 Java 实现单帧大约 40 到 80msRenderScript 大约 5 到 15ms差距非常明显。混合操作因为计算量小一些纯 Java 大约 10 到 20msRenderScript 大约 2 到 5ms。这个数据会因设备而异但量级上的差距是稳定的。操作纯 JavaRenderScript提升倍数NV21 转 Bitmap 1080P40-80ms5-15ms约 5-8 倍Bitmap 混合 1080P10-20ms2-5ms约 4-5 倍7.2 还能怎么优化如果 RenderScript 的性能还不够有几个方向可以继续压榨。第一降低处理分辨率预览场景很多时候不需要全分辨率处理可以先下采样再转换显示时再放大视觉上差别不大但性能提升明显。第二把转换和混合合并成一个脚本减少一次 Allocation 的读写往返。第三如果设备支持用 GPU 后端执行 RenderScript可以通过rs.setPriority或者环境变量控制但兼容性要测试。7.3 迁移到其他方案的时机如果你的项目 minSdk 已经到 31 以上或者对性能有极致要求可以考虑迁移。libyuv 是一个成熟的 C 库NV21 转 RGB 和混合都有现成实现性能比 RenderScript 还好一些但需要接入 NDK工程量更大。Vulkan 计算着色器是官方推荐的替代方案性能最强但学习曲线陡峭适合有图形编程基础的团队。对于大多数中小项目RenderScript 在可预见的未来依然够用没必要为了迁移而迁移。8. 把工具类用起来的几个真实场景8.1 相机预览加实时水印这是最典型的场景。相机回调拿到 NV21转成 Bitmap 作为底图再把水印 Bitmap 按设定透明度混合上去最后显示到预览控件。整个链路如果都在工作线程完成主线程只负责显示帧率可以稳定在 30fps 以上。水印的透明度可以做成可调节的用户滑动条改变 alpha工具类重新混合即可。8.2 扫码识别前的图像预处理扫码场景里有时候需要对图像做增强再送给识别引擎。比如先转成 Bitmap再叠加一层高对比度的图层做混合提升边缘清晰度。这种预处理用 RenderScript 做速度快到几乎无感不会拖慢扫码响应。8.3 短视频录制的帧合成录制短视频时可能需要在每一帧上叠加滤镜或者贴纸。NV21 转 Bitmap 后把贴纸按透明度混合上去再编码成视频。这个流程对性能要求很高因为要实时。工具类的 Allocation 复用和 Bitmap 双缓冲在这里就是刚需否则根本跑不到目标帧率。8.4 图像编辑器的图层混合静态图像编辑场景里用户可能想把两张图按不同透明度叠加。这时候不需要考虑实时性但需要支持任意尺寸和任意透明度。工具类的blendBitmap方法可以直接复用只是缓存策略可以简化因为调用频率低。9. 一些收尾的实操建议写这个工具类的过程中我最大的体会是性能优化不是靠某一个神奇的技术点而是靠一连串细节的累积。RenderScript 提供了并行计算的能力但如果你不复用 Allocation、不复用 Bitmap、不管理好生命周期它的优势会被这些开销吃掉。反过来把这些细节都做到位一个简单的工具类就能撑起整个相机预览链路。另外工具类的文档和注释要写清楚每个方法的线程要求、Bitmap 复用语义、以及 release 的调用时机。这些约定如果没写明白接手的人很容易用错然后回来找你排查为什么画面花了。我一般会在类注释里用醒目的方式标注这些约束比事后解释省事得多。最后分享一个小技巧在开发阶段可以加一个开关把转换和混合的中间结果保存到本地方便对比颜色是否正确。尤其是调 YUV 格式和 alpha 混合的时候肉眼看预览有时候不准存下来用图片查看器放大看问题一目了然。这个习惯帮我省了很多来回调试的时间。