Java Android 美颜相机实战：从相机采集到滤镜链的完整实现

简介：这份资源是面向高校计算机相关专业学生与Java初学者的一套Android美颜相机类应用完整工程，可作为毕业设计、课程设计或移动开发练手项目参考，帮助读者理解从相机取像、滤镜处理到界面交互的实现思路。压缩包共约2000个文件，以xml布局与资源、json配置、java源码为主，辅以少量sh脚本、properties配置及C语言图像处理代码，整体约19.43MB，目录结构完整，便于按模块检索与二次修改。资源已有118人学习下载，具备一定参考基础。工程中涉及GPUImage滤镜框架、YUV解码等图像处理环节，读者可据此梳理美颜类App的架构分层、滤镜链组织与相机数据流转方式，并对照源码理解界面与逻辑的衔接，适合作为移动端图像处理入门与项目复现的实践素材。

1. 从一张“能跑通的毕业设计”说起：这个 Android 美颜相机项目到底能干什么

很多同学做毕业设计时，最怕的不是写不出代码，而是写完发现跑不起来——相机权限一申请就崩、滤镜一叠加就卡成幻灯片、保存出来的图片和预览完全两个样。这个项目就是冲着解决这类问题去的：一个用 Java 写的 Android 美颜相机 App，功能覆盖拍照、实时滤镜预览、磨皮美白、贴纸叠加、图片保存到相册，基本对标美图秀秀那类应用的核心链路。它适合两类人：一是正在找 Java 毕业设计或课程设计参考的同学，想拿一份结构完整、能编译能运行的工程；二是已经会点 Android 基础、想搞清楚“相机预览帧怎么变成美颜图”这条数据流的开发者。项目没有堆砌花哨的 AI 模型，走的是经典 Camera API + 像素级图像处理的路线，代码量可控，改起来不玄学，对新手友好，对熟手也能看到一套完整的图像处理管线该怎么组织。

2. 技术选型与工程结构：为什么用 Java + Camera API 而不是 CameraX

2.1 技术栈拆解：一套“够用且好改”的组合

这个项目的技术栈不复杂，但每一层都有明确的理由。语言用 Java，是因为毕业设计场景下 Java 的 Android 教程和示例最多，答辩时老师也看得懂；相机采集用 Android 原生CameraAPI（android.hardware.Camera），而不是 CameraX 或 Camera2，原因是 CameraX 虽然封装好，但版本依赖和生命周期绑定对新手反而是黑匣子，出问题不好排查，而原生 Camera 的setPreviewCallback能直接拿到 NV21 帧数据，正好是图像处理的入口。图像处理全部在 Java 层用Bitmap和int[]像素数组完成，不依赖 OpenGL ES 或 RenderScript，好处是逻辑透明、每行代码都能讲清楚，代价是性能上限不高——但作为毕业设计，这个取舍是合理的。

依赖方面，常见做法是只引入 AndroidX 基础库和appcompat，不额外引第三方滤镜库，保证工程干净、编译不卡在依赖下载上。图片加载和保存走系统MediaStore，避免自己处理存储路径的兼容性问题。整体技术栈可以概括为：

2.2 目录结构：按“采集—处理—展示—存储”分层

拿到源码后先别急着点运行，花五分钟看目录，能省掉后面一半的调试时间。这个项目的包结构大致如下（不同版本命名可能略有差异，但分层逻辑一致）：

app/src/main/java/com/example/beautycamera/ ├── MainActivity.java // 入口，权限申请与相机初始化 ├── camera/ │ ├── CameraHelper.java // 相机打开、预览、帧回调封装 │ └── PreviewSurfaceView.java// 自定义预览控件 ├── filter/ │ ├── BeautyFilter.java // 磨皮、美白核心算法 │ ├── ColorFilter.java // 色调滤镜（复古、黑白等） │ └── FilterManager.java // 滤镜链管理与切换 ├── ui/ │ ├── CameraActivity.java // 拍照界面 │ └── EditActivity.java // 拍后编辑界面 └── util/ ├── ImageSaver.java // 保存到相册 └── BitmapUtil.java // Bitmap 与 byte[] 转换

这个结构的关键在于camera和filter两个包彻底解耦：相机层只负责“给我一帧 NV21”，滤镜层只负责“给我一个 Bitmap，还你一个处理后的 Bitmap”，中间靠FilterManager串起来。二次开发时想换滤镜算法，只动filter包；想换采集方式，只动camera包，互不影响。我一般会先确认MainActivity里相机初始化的调用顺序，再看FilterManager的滤镜链是怎么注册的，这两处看懂了，整个项目的数据流就通了。

2.3 运行前必须确认的三件事

在 Android Studio 里打开工程后，先做三件事再点 Run。第一，检查build.gradle里的compileSdk和targetSdk，如果项目较老（比如 targetSdk 28 以下），在高版本手机上安装可能被拦，常见做法是把 targetSdk 提到 30 以上，同时补上AndroidManifest.xml里的CAMERA、WRITE_EXTERNAL_STORAGE（或READ_MEDIA_IMAGES）权限声明。第二，确认minSdk不低于 21，因为项目里用到的Bitmap.createBitmap重载和Camera回调在低版本上行为不一致。第三，用真机调试，模拟器的相机预览经常是黑屏或绿屏，这不是代码问题，是模拟器没有真实摄像头帧，排查时会白白浪费时间。

<!-- AndroidManifest.xml 关键权限 --> <uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" /> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> <uses-feature android:name="android.hardware.camera" android:required="true" />

上面这段权限声明里，WRITE_EXTERNAL_STORAGE加了maxSdkVersion="28"，是因为 Android 10 之后分区存储生效，再申请这个权限没有意义，反而会在部分机型上触发审核提示；READ_MEDIA_IMAGES是 Android 13 之后的媒体读取权限，保存图片到相册时需要。uses-feature声明相机为必需硬件，避免安装到没有摄像头的设备上。改完这些再编译，能避开一大半“一装就闪退”的问题。

3. 核心链路拆解：一帧预览画面是怎么变成美颜图的

3.1 相机初始化与预览回调：数据从哪来

整个 App 的起点是CameraHelper里的相机打开逻辑。原生 Camera API 的套路是：Camera.open()拿到实例，设置预览尺寸和格式，绑定SurfaceHolder，然后startPreview()。真正让美颜生效的关键是setPreviewCallbackWithBuffer，它会在每一帧预览数据就绪时回调一个byte[]，格式通常是 NV21。下面这段是项目里相机初始化的核心代码，我按实际调用顺序整理过：

public void openCamera(SurfaceHolder holder) { try { // 1. 打开后置摄像头，0 表示后置 camera = Camera.open(0); Camera.Parameters params = camera.getParameters(); // 2. 选择预览尺寸，优先取接近 1280x720 的分辨率 List<Camera.Size> sizes = params.getSupportedPreviewSizes(); Camera.Size previewSize = sizes.get(0); for (Camera.Size size : sizes) { if (Math.abs(size.width - 1280) < 100) { previewSize = size; break; } } params.setPreviewSize(previewSize.width, previewSize.height); // 3. NV21 是 Android 相机默认输出格式，方便后续转 Bitmap params.setPreviewFormat(ImageFormat.NV21); camera.setParameters(params); // 4. 绑定预览显示 camera.setPreviewDisplay(holder); // 5. 分配帧缓冲并注册回调 int bufferSize = previewSize.width * previewSize.height * ImageFormat.getBitsPerPixel(ImageFormat.NV21) / 8; camera.addCallbackBuffer(new byte[bufferSize]); camera.setPreviewCallbackWithBuffer(this); camera.startPreview(); } catch (IOException e) { Log.e(TAG, "相机预览绑定失败", e); } }

这段代码里几个参数值得说清楚。Camera.open(0)的 0 是摄像头 ID，后置为 0、前置通常为 1，做自拍美颜时改成 1 即可。预览尺寸的选择没有用getSupportedPreviewSizes().get(0)直接取第一个，是因为不同机型返回的顺序不固定，第一个可能是 320x240 这种极低分辨率，美颜后糊成一片；这里用“接近 1280 宽”的启发式筛选，是常见做法。setPreviewFormat(ImageFormat.NV21)必须显式设置，否则部分机型默认输出 YV12，后面转 Bitmap 时颜色会偏绿。addCallbackBuffer配合setPreviewCallbackWithBuffer比setPreviewCallback更省内存，因为缓冲区复用，不会每帧都 new 一个数组——这个细节在低端机上差别很明显，用错方法预览会越来越卡。

3.2 NV21 转 Bitmap：颜色空间转换的坑

相机回调拿到的是 NV21 字节数组，不能直接给Bitmap用，必须先转成 ARGB 像素。项目里BitmapUtil的转换逻辑是手写的 YUV 转 RGB，而不是用YuvImage压缩成 JPEG 再解码——后者多一次编解码，帧率直接掉一半。核心转换如下：

public static void nv21ToBitmap(byte[] nv21, int width, int height, Bitmap out) { int[] argb = new int[width * height]; int yIndex = 0, uvIndex = width * height; for (int j = 0; j < height; j++) { for (int i = 0; i < width; i++) { // Y 分量 int y = nv21[yIndex++] & 0xff; // NV21 的 UV 交错存储，每两个像素共用一组 int v = nv21[uvIndex] & 0xff; int u = nv21[uvIndex + 1] & 0xff; if ((i & 1) == 0 && (j & 1) == 0) { uvIndex += 2; } // YUV 转 RGB 标准公式 int r = y + (int) (1.402f * (v - 128)); int g = y - (int) (0.344f * (u - 128) + 0.714f * (v - 128)); int b = y + (int) (1.772f * (u - 128)); argb[j * width + i] = 0xff000000 | (clamp(r) << 16) | (clamp(g) << 8) | clamp(b); } } out.setPixels(argb, 0, width, 0, 0, width, height); }

这里的uvIndex递增条件是(i & 1) == 0 && (j & 1) == 0，因为 NV21 的 UV 平面是每 2x2 个像素共享一组 U、V，写错这个条件会导致画面出现规律性的彩色条纹，这是血泪经验里最常见的一个翻车点。clamp方法把 RGB 值限制在 0~255，防止公式计算溢出变成花屏。out是复用的 Bitmap 对象，避免每帧createBitmap造成 GC 抖动。转换完成后，这一帧 Bitmap 就交给滤镜层处理。

3.3 磨皮与美白：像素级算法的实现

美颜的核心在BeautyFilter。磨皮用的是“均值模糊 + 原图混合”的简化方案，不是高斯模糊，因为高斯在 Java 层逐像素算太慢。思路是：对每个像素取周围 3x3 邻域的平均色，再按强度系数和原像素做线性插值，强度越高越平滑。美白则是整体提升亮度并轻微降低饱和度。代码如下：

public Bitmap process(Bitmap src, int smoothLevel, int whiteLevel) { int w = src.getWidth(), h = src.getHeight(); int[] pixels = new int[w * h]; src.getPixels(pixels, 0, w, 0, 0, w, h); int[] result = new int[pixels.length]; float smoothRatio = smoothLevel / 100f; // 0~1 float whiteRatio = whiteLevel / 100f; for (int y = 0; y < h; y++) { for (int x = 0; x < w; x++) { int idx = y * w + x; int color = pixels[idx]; // 3x3 邻域均值，边界处退化为自身 int sumR = 0, sumG = 0, sumB = 0, count = 0; for (int dy = -1; dy <= 1; dy++) { for (int dx = -1; dx <= 1; dx++) { int nx = x + dx, ny = y + dy; if (nx < 0 || ny < 0 || nx >= w || ny >= h) continue; int c = pixels[ny * w + nx]; sumR += (c >> 16) & 0xff; sumG += (c >> 8) & 0xff; sumB += c & 0xff; count++; } } int avgR = sumR / count, avgG = sumG / count, avgB = sumB / count; int r = (int) (((color >> 16) & 0xff) * (1 - smoothRatio) + avgR * smoothRatio); int g = (int) (((color >> 8) & 0xff) * (1 - smoothRatio) + avgG * smoothRatio); int b = (int) ((color & 0xff) * (1 - smoothRatio) + avgB * smoothRatio); // 美白：整体提亮，白度越高提升越明显 r = clamp((int) (r + 255 * whiteRatio * 0.3f)); g = clamp((int) (g + 255 * whiteRatio * 0.3f)); b = clamp((int) (b + 255 * whiteRatio * 0.3f)); result[idx] = 0xff000000 | (r << 16) | (g << 8) | b; } } return Bitmap.createBitmap(result, w, h, Bitmap.Config.ARGB_8888); }

smoothLevel和whiteLevel都是 0~100 的整数，来自 UI 上的滑动条，除以 100 归一化成混合系数。smoothRatio为 0 时输出原图，为 1 时完全取邻域均值，实际使用一般控制在 0.3~0.6，太高会糊掉五官细节。美白部分乘了 0.3 的系数，是为了避免直接加 255 导致过曝，这个系数可以根据实际效果微调。注意Bitmap.createBitmap每次都会分配新内存，如果要做实时预览，应该改成复用 Bitmap 加setPixels，否则帧率会被 GC 拖垮——项目里预览路径和拍照路径是分开的，预览用低分辨率复用，拍照才走全尺寸。

3.4 滤镜链与保存：从处理结果到相册

FilterManager负责把多个滤镜串起来，比如“先磨皮再套复古色调”。它的设计是一个List<BaseFilter>，按顺序调用每个滤镜的process，前一个的输出作为后一个的输入。这种链式结构的好处是加新滤镜只需实现接口并add进去，不用改调用方。保存环节用MediaStore插入图片，避免 Android 10 之后直接写文件路径失败：

public void saveToGallery(Context context, Bitmap bitmap, String name) { ContentValues values = new ContentValues(); values.put(MediaStore.Images.Media.DISPLAY_NAME, name + ".jpg"); values.put(MediaStore.Images.Media.MIME_TYPE, "image/jpeg"); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { values.put(MediaStore.Images.Media.RELATIVE_PATH, "Pictures/BeautyCamera"); } Uri uri = context.getContentResolver() .insert(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, values); try (OutputStream os = context.getContentResolver().openOutputStream(uri)) { bitmap.compress(Bitmap.CompressFormat.JPEG, 95, os); } catch (IOException e) { Log.e(TAG, "保存失败", e); } }

RELATIVE_PATH只在 Android 10 及以上生效，低版本走默认路径。compress的质量参数 95 是平衡画质和体积的常用值，调到 100 体积会明显变大但肉眼几乎看不出差别。保存成功后相册里会出现Pictures/BeautyCamera目录，这个路径在二次开发时可以改成自己的品牌名。

4. 避坑与常见问题：跑不起来时先查这几处

4.1 预览黑屏或绿屏

现象是 App 启动后预览区域一片黑，或者整屏偏绿。原因通常有两个：一是setPreviewFormat没设成 NV21，部分机型默认 YV12，转换公式对不上就偏绿；二是SurfaceHolder的surfaceCreated回调还没触发就调了startPreview。解决办法是在surfaceCreated里再调openCamera，并显式params.setPreviewFormat(ImageFormat.NV21)。如果用的是模拟器，先换真机，模拟器相机帧本身就不完整。

4.2 拍照后图片方向旋转 90 度

现象是预览正常，但保存出来的照片横躺着。原因是相机传感器方向和屏幕方向不一致，Camera不会自动纠正。解决方法是读取CameraInfo.orientation，结合当前屏幕旋转角度计算一个旋转矩阵，用Matrix.postRotate把 Bitmap 转正再保存。常见做法是封装一个getRotateDegree方法，在ImageSaver里统一处理，别在每个调用点各写一遍。

4.3 滑动条拖动时预览卡顿

现象是调美颜强度时画面一顿一顿的。原因是每次滑动都触发全尺寸 Bitmap 的逐像素处理，主线程被占满。解决办法是把预览处理放到低分辨率副本上（比如 640 宽），滑动停止后再用全尺寸处理一次用于拍照；同时用HandlerThread把process挪到子线程，处理完再post回主线程刷新。注意Bitmap跨线程传递时不要在主线程回收，否则会抛IllegalStateException。

4.4 高版本系统保存失败

现象是 Android 11 以上点保存没反应，日志里是FileNotFoundException或权限拒绝。原因是分区存储生效后不能再直接new FileOutputStream("/sdcard/...")。解决办法就是 3.4 节里的MediaStore插入方式，同时把WRITE_EXTERNAL_STORAGE的maxSdkVersion限制在 28，高版本改用READ_MEDIA_IMAGES。如果还失败，检查ContentResolver.insert返回的uri是否为 null，为 null 说明ContentValues里缺MIME_TYPE。

4.5 前置摄像头拍出来是镜像的

现象是自拍保存后左右颠倒。原因是前置相机预览默认是镜像显示，但保存的帧数据不是。解决方法是判断摄像头 ID 为 1 时，在保存前用Matrix做一次水平翻转（preScale(-1, 1)），预览层则保持镜像不动，这样所见即所得。这个细节不做的话，用户会觉得“拍出来和看到的不一样”，是很影响体验的小问题。

5. 二次开发改造思路：把滤镜链做成可配置的插件式结构

如果只是交作业，跑通就够了；但如果想在这个项目基础上继续做，我建议优先改FilterManager，把它从“硬编码的 List”改成“可配置的滤镜链”。具体做法是定义一个FilterConfig类，用 JSON 或SharedPreferences描述每个滤镜的启用状态和强度参数，启动时解析成滤镜实例列表。这样加新滤镜不用改调用代码，调参也不用重新编译。下面是一个改造后的注册示例：

public class FilterManager { private final List<BaseFilter> chain = new ArrayList<>(); // 按配置构建滤镜链，config 可来自 SharedPreferences 或远程下发 public void buildFromConfig(List<FilterConfig> configs) { chain.clear(); for (FilterConfig cfg : configs) { if (!cfg.enabled) continue; BaseFilter filter = FilterFactory.create(cfg.type); if (filter != null) { filter.setLevel(cfg.level); // 强度 0~100 chain.add(filter); } } } public Bitmap apply(Bitmap input) { Bitmap current = input; for (BaseFilter filter : chain) { current = filter.process(current); } return current; } }

FilterFactory.create根据type字符串返回对应滤镜实例，新增滤镜只需在工厂里加一个 case，符合开闭原则。setLevel统一强度接口，UI 上的滑动条直接绑定到FilterConfig.level，改完配置调buildFromConfig重建链即可。验证方法是：先在配置里只开磨皮，看效果；再加一个色调滤镜，确认叠加顺序符合预期；最后把配置清空，确认输出等于原图。这套验证走一遍，基本能保证滤镜链没有状态残留。

另一个值得改的点是相机采集层。原生CameraAPI 在新机型上逐渐被淘汰，如果目标设备较新，可以把CameraHelper替换成 CameraX 的ImageAnalysis，对外暴露的接口保持“给一帧 NV21 或 YUV”不变，滤镜层完全不用动。这就是前面说的分层解耦带来的好处——换采集方式只动一个类。改造时注意 CameraX 的ImageProxy需要手动close()，忘了关会导致分析器停止回调，这个坑我踩过，排查了半天才发现是资源没释放。

最后说一个我自己的习惯：每次改完滤镜参数，我都会用同一张测试图跑一遍“原图—单滤镜—多滤镜叠加”三组对比，把结果拼成一张图存下来。这样下次调参时能直观看到改动前后的差异，不至于改着改着把之前调好的效果弄丢。毕业设计答辩时，这组对比图也是很好的演示材料。希望帮到你。

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