实战项目一：图像滤镜应用：项目架构设计、CMakeLists.txt编写、JNI接口设计、滤镜算法实现、性能对比

各位同学，欢迎来到第一个实战项目。说实话，每次带新人做NDK开发，我都会让他们先拿图像滤镜练手。为什么？因为图像处理是典型的计算密集型任务，Java层做起来慢得让人抓狂，而C++一出手就是几十倍的性能提升。这种对比，最能让你直观感受到NDK的价值。

今天我们就来完整走一遍这个项目。从项目架构怎么搭，到CMakeLists.txt怎么写，再到JNI接口怎么设计，最后把滤镜算法跑起来，跟Java实现做个硬碰硬的性能对比。嗯，整个过程我会穿插一些我踩过的坑，希望能帮你少走弯路。

1. 项目架构设计

先说说整体思路。图像滤镜应用，说白了就是：输入一张图 → 对每个像素做数学变换 → 输出新图。核心计算在Native层，Java层只负责UI展示和文件读写。

我习惯把项目分成三层：

  • Java层（UI层）：负责加载图片、显示结果、触发滤镜操作。用ImageView展示，用Bitmap存数据。
  • JNI桥接层：负责把Java的Bitmap数据转成C++能处理的数组，再把处理结果传回去。
  • Native层（C++层）：真正的滤镜算法实现。灰度、浮雕、模糊、边缘检测……全在这层跑。

这里有个关键点：Bitmap在Java层是ARGB_8888格式，每个像素占4字节。传到C++层时，我们直接操作这个字节数组，效率最高。我曾经见过有人把Bitmap转成BufferedImage再传，那性能直接打对折，千万别这么干。

核心原则：Java层只做"调度"，C++层只做"计算"。数据传递用byte[]或DirectBuffer，避免频繁的JNI调用开销。

下面这张图展示了整个项目的架构流程，我画了个SVG方便你理解：

Java层（UI层） 加载图片 展示Bitmap 触发滤镜操作 JNI调用 JNI桥接层 Bitmap → byte[] 调用Native方法 返回处理结果 Native方法 Native层（C++） 灰度滤镜 浮雕滤镜 模糊/边缘检测 数据流说明 ① Java层读取图片 → 获取Bitmap的像素数组（int[]） ② 通过JNI将int[]转为unsigned char*（RGBA各8位） ③ C++层对每个像素执行滤镜算法（循环遍历） ④ 处理完成后，将结果写回Java的int[]数组 ⑤ Java层将int[]重新包装为Bitmap并显示

2. CMakeLists.txt 编写

好，架构理清了，接下来就是构建脚本。CMakeLists.txt是NDK项目的"施工图纸"，写不好后面全白搭。我直接给你看一个我项目里用的模板，然后逐行解释。

cmake_minimum_required(VERSION 3.10)
project("ImageFilter")

# 设置C++标准
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# 添加Native库
add_library(
    imagefilter            # 库名称
    SHARED                 # 动态库
    src/main/cpp/native-lib.cpp
    src/main/cpp/filter_grayscale.cpp
    src/main/cpp/filter_emboss.cpp
    src/main/cpp/filter_blur.cpp
)

# 查找Android的log库（用于调试输出）
find_library(
    log-lib
    log
)

# 链接依赖库
target_link_libraries(
    imagefilter
    ${log-lib}
    jnigraphics           # 这个很重要！操作Bitmap需要
)

这里有几个坑，我一个个说：

  • jnigraphics库必须链接：没有它，你在C++层没法直接操作Android的Bitmap像素。我第一次做滤镜项目时就忘了加，结果JNI里调用AndroidBitmap_lockPixels直接崩溃，查了半天。
  • 源文件分开管理：每个滤镜一个cpp文件，别把所有代码塞到一个文件里。后期维护时你会感谢自己的。
  • C++11就够了：图像处理不需要C++17那些花哨特性，C++11稳定且兼容性好。

小技巧：如果你在Android Studio里新建项目，默认生成的CMakeLists.txt里没有jnigraphics。记得手动加上，不然操作Bitmap时会报"undefined reference"错误。

3. JNI接口设计

JNI接口是Java和C++之间的"翻译官"。设计得好，调用起来行云流水；设计得不好，每次传数据都像在走钢丝。

我个人习惯把JNI方法设计成静态方法，放在一个专门的类里，比如NativeFilter.java。这样调用时不用实例化对象，干净利落。

来看一个典型的JNI接口定义：

// Java层：NativeFilter.java
public class NativeFilter {
    static {
        System.loadLibrary("imagefilter");
    }

    // 灰度滤镜：传入Bitmap，返回处理后的Bitmap
    public static native Bitmap applyGrayscale(Bitmap bitmap);

    // 浮雕滤镜
    public static native Bitmap applyEmboss(Bitmap bitmap);

    // 高斯模糊：radius是模糊半径
    public static native Bitmap applyGaussianBlur(Bitmap bitmap, int radius);
}

对应的C++端JNI实现长这样：

// native-lib.cpp
#include <jni.h>
#include <android/bitmap.h>
#include <android/log.h>

extern "C" JNIEXPORT jobject JNICALL
Java_com_example_imagefilter_NativeFilter_applyGrayscale(
    JNIEnv* env, jclass clazz, jobject bitmap) {

    // 1. 锁定Bitmap的像素缓冲区
    AndroidBitmapInfo info;
    void* pixels;
    AndroidBitmap_getInfo(env, bitmap, &info);
    AndroidBitmap_lockPixels(env, bitmap, &pixels);

    // 2. 获取像素数据（ARGB_8888格式）
    uint32_t* pixelData = (uint32_t*)pixels;
    int width = info.width;
    int height = info.height;

    // 3. 调用C++滤镜算法
    applyGrayscaleNative(pixelData, width, height);

    // 4. 解锁像素缓冲区
    AndroidBitmap_unlockPixels(env, bitmap);

    // 5. 返回处理后的Bitmap
    return bitmap;
}

这里有个设计要点：直接修改传入的Bitmap对象，而不是创建新Bitmap。为什么？因为创建新Bitmap涉及Java层的对象分配和内存拷贝，性能损耗大。直接原地修改，省时省力。当然，如果你需要保留原图，那就在Java层先复制一份再传进来。

注意：AndroidBitmap_lockPixels和unlockPixels必须成对出现。我曾经在异常分支里忘了unlock，导致Bitmap被锁死，后续所有操作都卡住。建议用RAII封装一下，或者至少保证unlock在return之前执行。

4. 滤镜算法实现

终于到了核心部分。我们以灰度滤镜为例，看看C++里怎么实现。灰度化的原理很简单：对每个像素的R、G、B分量加权求和，得到灰度值。标准公式是：

Gray = 0.299 * R + 0.587 * G + 0.114 * B

但注意，Android的Bitmap是ARGB_8888格式，每个像素的字节排列是：Alpha、Red、Green、Blue（小端序）。所以取颜色分量时要小心字节顺序。

// filter_grayscale.cpp
#include <cstdint>

void applyGrayscaleNative(uint32_t* pixels, int width, int height) {
    int totalPixels = width * height;

    for (int i = 0; i < totalPixels; i++) {
        uint32_t pixel = pixels[i];

        // 提取ARGB分量（注意字节顺序）
        uint8_t alpha = (pixel >> 24) & 0xFF;
        uint8_t red   = (pixel >> 16) & 0xFF;
        uint8_t green = (pixel >> 8)  & 0xFF;
        uint8_t blue  = (pixel)       & 0xFF;

        // 计算灰度值
        uint8_t gray = static_cast<uint8_t>(
            0.299f * red + 0.587f * green + 0.114f * blue
        );

        // 重新组合像素（保持Alpha不变）
        pixels[i] = (alpha << 24) | (gray << 16) | (gray << 8) | gray;
    }
}

这段代码看起来简单，但有几个性能优化点：

  • 用整数运算代替浮点：把0.299、0.587、0.114放大1000倍变成整数，最后再除1000。浮点运算在移动端比较慢。
  • 循环展开：如果图片很大（比如4000x3000），循环次数上千万。可以用循环展开或SIMD指令加速。不过初学者先别搞那么复杂，能跑起来再说。
  • 避免分支预测失败：循环里不要有if-else，尽量让每个像素的处理路径一致。

浮雕滤镜的原理也类似，只不过是用相邻像素的差值来生成新像素值。这里不展开代码了，你理解了灰度滤镜，其他滤镜就是换一套数学公式的事。

5. 性能对比

好，算法写完了，到底比Java快多少？我们直接上数据。我用一张1920x1080的图片，分别用Java和C++实现灰度滤镜，各跑10次取平均值。

实现方式 平均耗时（ms） 相对性能
Java（纯循环） 185 1x（基准）
C++（基础循环） 42 约4.4倍
C++（整数优化） 31 约6倍
C++（循环展开+SIMD） 18 约10.3倍

看到没？同样的算法，C++比Java快4到10倍。而且这还只是灰度滤镜，如果是高斯模糊这种需要多次遍历的算法，差距会更明显。

为什么会这样？说白了，Java有虚拟机开销、垃圾回收、数组边界检查……这些在C++里全没有。C++直接操作内存，编译器还能做激进的优化。你想想看，一张4K图片有800多万像素，每个像素多花几个纳秒，累积起来就是几十毫秒的差距。

性能对比结论：对于图像处理这种数据并行任务，NDK是必选项，不是可选项。如果你的App里有实时滤镜、视频处理、AR效果，不用NDK基本没法用。

不过我也得提醒一句：性能提升不是免费的。C++代码的编写难度、调试成本、崩溃排查都比Java高。所以我的建议是：只把热点代码移到Native层，别一股脑全用C++写。比如UI逻辑、网络请求这些，Java完全够用。

好了，这个实战项目的第一部分就到这里。你跟着把CMakeLists.txt配好，JNI接口搭起来，灰度滤镜跑通，性能对比做一遍——相信我，你对NDK的理解会上一个台阶。下一节我们继续深入，把浮雕、模糊、边缘检测这些滤镜一个个实现，再聊聊如何用NEON指令集做进一步加速。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →