★ FEATURED ARTICLE 手上有块 ARM 板子rootfs 分区只剩不到 10MB 可用空间产品经理还要求把摄像头抓拍、缩放、转灰度这套流程放到设备上跑。翻出之前编译的 OpenCV 动态库一看libopencv_world.so十九兆多光libopencv_core.so就五兆出头塞进去直接爆分区。于是就有了这次裁剪 opencv 库到 2Mb的折腾。先把结论放前面2MB 这个数字绝大多数情况下指的不是某一个 .so 文件的体积而是最终可执行文件里 OpenCV 实际占用的那部分。如果你非要一个 2MB 的libopencv_core.so还要带 dnn 和 gapi那基本是做不到的但如果你只留coreimgprocimgcodecs三件套配合编译期和链接期的一系列取舍把 OpenCV 在成品里的净占用压到 2MB 以内是完全可复现的事情。下面这套流程我在 ARMv7 和 x86_64 上都跑过尺寸数字会随版本和工具链浮动但思路和开关是一样好使的。1. 先把体积账本翻开再动手很多人裁 OpenCV 的第一反应是去翻 CMake 选项列表看到一个WITH_XXX就关一个关完发现体积只掉了几百 KB。原因是 OpenCV 的体积分布非常不均衡大头集中在少数几个地方你没砍到点子上关一百个边角开关也没用。1.1 用 size 和 nm 找出真正的胖子默认构建完成后先别急着改配置先量一遍。对静态库可以直接看归档里每个目标文件的大小# 按体积排序看清楚谁占地方 size -A lib/libopencv_core.a | sort -k2 -nr | head -30 # 按符号大小排序定位具体的函数 nm --print-size --size-sort --radixd lib/libopencv_core.a | tail -40如果是动态库bloaty更好用它能直接告诉你每个.o贡献了多少字节bloaty -d compileunits,symbols libopencv_imgproc.so我在 4.x 版本上量下来的典型分布是这样imgproc的滤波和几何变换占了很大一块core里的矩阵运算和并行框架占一块真正让人意外的是指令集分派代码和 IPP 的静态库——这两个加起来经常能占整个库里三分之一以上的体积而且它们藏在编译选项里不翻构建日志根本看不见。1.2 三个层级要分开算账把 OpenCV 的体积拆成三层看后面每一步操作都能对号入座层级典型占比主要手段源码模块层40% 到 60%BUILD_LIST只保留必要模块三方依赖层20% 到 40%WITH_IPP、WITH_FFMPEG、各图像编解码器编译分派层15% 到 35%CPU_BASELINE、CPU_DISPATCH、编译优化等级只看第一层是新手最常见的误区。我见过有人把模块从十几个砍到三个库从 19MB 掉到 11MB然后卡住了觉得再怎么砍也到不了 2MB。其实把第二层的 IPP 关掉、第三层的 dispatch 关掉剩下的 11MB 能直接掉到 4MB 左右。1.3 明确你的 2MB 到底是哪个 2MB这一点必须先跟需求方对齐否则后面全是无用功。三种常见口径差别巨大静态库总和的 2MBlibopencv_core.alibopencv_imgproc.alibopencv_imgcodecs.a三个归档文件的体积之和。这个目标偏紧需要动 dispatch 和 LTO。动态库的 2MB单个.so文件 2MB。如果只保留 core勉强能做带上 imgproc 就很吃力。最终可执行文件里 OpenCV 的净占用这是最合理也最常被实际使用的口径。因为静态链接加--gc-sections之后你代码里没调用的那 90% 函数根本不会被链进去最终算下来常常比库文件小一个数量级。提示谈指标的时候一定要说清楚是库文件体积还是链接后占用这两个数字在实际项目里能差三四倍先确认再开工能省掉大量返工。2. WITH 系列开关里哪些是真省空间cmake -L能列出几百个选项但真正影响体积的没几个。我按实测的收益从高到低排一遍你可以直接照着优先级砍。2.1 IPP 是第一个必须关掉的东西WITH_IPP默认是开的构建时 CMake 会去下载一个叫ippicv的预编译静态库然后静态链进libopencv_core。这个东西在 x86 上动辄二三十兆是整份代码里最大的一块外部依赖。对体积敏感的场景没有任何犹豫余地-DWITH_IPPOFF -DBUILD_IPP_IWOFF代价是部分滤波和矩阵运算会走 OpenCV 自己的通用实现性能可能有 10% 到 30% 的下降。但在嵌入式设备上你的瓶颈通常在内存带宽而不是指令吞吐这点损失基本感知不到。如果你的场景是 x86 服务器上跑高并发图像处理那要另算账。2.2 视频和 GUI 后端嵌入式场景一律关这类开关的特点是——只要你不用关掉就是纯赚选项作用关掉的理由WITH_FFMPEG视频编解码拉进来一堆 codec只做单帧抓拍完全不需要WITH_GSTREAMER流媒体管道同上还会拖进 GStreamer 的头文件依赖WITH_V4LLinux 摄像头采集如果你的相机走自己的驱动接口用不上WITH_GTK/WITH_QT桌面 GUI无显示设备imshow本来也用不了WITH_WIN32UIWindows GUI交叉编译时无意义WITH_OPENCLGPU 加速接口无 GPU且运行时会加载内核源码字符串WITH_OPENCL值得单独说一句。它不只是关掉一个调用接口OpenCV 会把一堆 OpenCL kernel 源码以字符串形式编译进库里运行时才去编译。关掉之后core能小几百 KB 到 1MB 不等具体看版本。2.3 并行框架省得不多但值得关WITH_TBB、WITH_OPENMP、WITH_PTHREADS_PF这三个是并行后端。TBB 会引入外部依赖并且体积可观OpenMP 依赖编译器运行时WITH_PTHREADS_PF是 OpenCV 自己基于 pthread 的实现藏在core里。-DWITH_TBBOFF -DWITH_OPENMPOFF -DWITH_PTHREADS_PFOFF关掉WITH_PTHREADS_PF之后cv::parallel_for_会退化成单线程串行执行。对单核嵌入式芯片来说这本来就是事实对多核芯片则要看你的处理流水线是不是真的靠parallel_for_撑性能。我的建议是先关掉把体积压下来如果实测发现某个 resize 慢得离谱再单独把WITH_PTHREADS_PFON打开它带来的体积增量相对可控。2.4 图像编解码器留一个就够WITH_JPEG、WITH_PNG、WITH_TIFF、WITH_WEBP、WITH_OPENEXR、WITH_JASPER这一串默认基本全开。每关一个都能省下几十到几百 KB全关能省一两兆。但你的业务总要读图所以策略是只留你真正用到的那一种-DWITH_JPEGON -DWITH_PNGOFF -DWITH_TIFFOFF \ -DWITH_WEBPOFF -DWITH_OPENEXROFF -DWITH_JASPEROFF另外还有个容易漏的WITH_PROTOBUF和WITH_QUIRC二维码识别用的如果不用 dnn 和二维码功能一起关掉。WITH_PROTOBUF在带 dnn 的构建里会拖进一大坨不带 dnn 时影响不大但关掉总没坏处。3. BUILD_LIST 精确到模块的取舍BUILD_LIST是 OpenCV 4.x 提供的一个很好的机制它让你直接列出想要的模块CMake 会自动把依赖补齐。注意这里写的是不带opencv_前缀的模块名。3.1 模块依赖链要心里有数OpenCV 模块之间有明确的依赖关系你写了上层模块下层会被自动带进来imgcodecs读写图片依赖imgprocimgproc滤波、几何变换、颜色空间转换依赖corecorecv::Mat、基础运算、内存管理不依赖任何其他模块所以如果你想保留imread、resize、cvtColor这套最常用的组合最小集合就是-DBUILD_LISTcore,imgproc,imgcodecs三个模块各自负责什么用一张表说清楚模块提供的能力能不能省corecv::Mat、逐像素运算、矩阵运算、FileStorage不能一切的基础imgprocresize、cvtColor、threshold、filter2D、形态学只要做图像变换就必须要imgcodecsimread、imwrite、编解码器封装只处理裸内存数据时可以省如果你的数据来源是相机直接给的 YUV/RGB 缓冲全程在内存里处理那imgcodecs可以不要只留core,imgproc能再省掉几百 KB 到 1MB。我当时为了支持本地 JPEG 抓拍落盘把它留下了。3.2 那些看着没用其实拖着大尾巴的模块有几个模块特别容易在默认构建里偷偷占地方ts测试支持模块。BUILD_TESTSOFF之后它本身不会构建测试用例但这个模块的骨架代码仍然可能被编译进去。显式加-DBUILD_opencv_tsOFF更保险。gapi图计算框架在 4.x 里体积相当可观还依赖一个叫ade的第三方库。除非你在做流水线式的图计算否则一定关掉。dnn深度学习推理。这是 4.x 里除了 IPP 之外最大的单体模块还拖着 protobuf。不做推理就关。world把全部模块打包成一个库方便但和裁剪是相反的方向保持-DBUILD_opencv_worldOFF。gapi和dnn这两个尤其要注意它们的体积在 4.x 各版本里增长得很快。你只写BUILD_LISTcore,imgproc,imgcodecs时它们不会被构建但如果你的构建脚本是从别处抄来的、用的是逐个BUILD_opencv_xxxOFF的写法很容易漏掉一两个。用白名单BUILD_LIST比用黑名单逐项 OFF安全得多这是我从一次线上事故里换来的教训——当时漏关了一个模块固件多出六兆产线刷机包直接超限。3.3 顺带把测试和示例全关掉这部分对库体积影响有限但对构建时间和磁盘占用影响巨大而且不关的话经常会出意外-DBUILD_TESTSOFF \ -DBUILD_PERF_TESTSOFF \ -DBUILD_EXAMPLESOFF \ -DBUILD_opencv_appsOFF \ -DBUILD_DOCSOFF \ -DBUILD_JAVAOFF \ -DBUILD_opencv_python2OFF \ -DBUILD_opencv_python3OFFBUILD_opencv_apps会生成一堆演示可执行文件交叉编译环境下它们占的空间经常比库本身还大务必关掉。Java 和 Python 绑定在嵌入式上基本用不上关掉还能避免 CMake 去找 JDK 和 Python 头文件。4. CPU_DISPATCH藏得最深的那个体积黑洞这一节是我认为最值得单独讲的部分因为绝大多数裁剪教程都不会提它但它往往是关掉 IPP 之后下一个能砍出大块体积的地方。4.1 运行时分派机制是怎么吃体积的OpenCV 为了保证同一份二进制能在不同年代的 CPU 上跑出性能实现了一套运行时分派机制。编译时它会为SSE4.2、AVX、AVX2、AVX512这些指令集各生成一份函数实现程序启动时检测当前 CPU 支持哪套指令再把函数指针指向对应版本。这套机制的代价是同一段算法被复制多份。imgproc里的滤波、resize、cvtColor这些热点函数每一个都有好几个变体编译进库里。默认情况下CPU_DISPATCH会打开一串指令集在 x86_64 上实测imgproc的体积能因为这部分翻倍。处理方式很直接-DCPU_BASELINESSE2 \ -DCPU_DISPATCHCPU_DISPATCH赋空值就是不分派只编译一份基线实现。CPU_BASELINE指定基线指令集x86_64 用SSE2这是 x86_64 的架构最低要求必然支持ARMv7 用NEONARMv8 用NEON或NEON_FP16。4.2 性能损失有多大这是必须诚实面对的问题。在我测过的 ARMv7 平台上把 dispatch 关掉、只保留 NEON 基线cv::resize双线性插值在 640x480 到 320x240 这个量级上耗时增加不到 15%cvtColor的 RGB 转灰度基本没变化。原因很简单——NEON 的向量化实现还在被去掉的是那些针对更高指令集的额外变体。x86 上的影响会大一些因为 SSE2 到 AVX2 的差距确实存在。如果你跑的是服务器端的批量图像处理我建议保留CPU_DISPATCHSSE4_2,AVX2这两档别全关。4.3 交叉编译时的 baseline 陷阱交叉编译 ARM 平台时要注意工具链的默认配置。有些 CMake 工具链文件里会写-DCPU_BASELINENEON但如果你的目标芯片是 ARMv7-A 又不带 FPU 的版本比如某些 Cortex-A5 配置强行开 NEON 会在运行时直接触发非法指令。安全做法是先确认目标 SoC 的-march和-mfpu参数再决定 baseline# ARMv7-A 带 NEON -DCPU_BASELINENEON -DENABLE_NEONON # 没有 NEON 的 ARMv7 -DCPU_BASELINE -DENABLE_NEONOFF -DENABLE_VFPV3ON还有一种更保守的玩法-DCV_ENABLE_INTRINSICSOFF把所有 SIMD 全部关掉只留纯 C 实现。体积能再降一点但性能会掉得很难看我在实际项目里没用过只在排查某次崩溃时临时验证过一次。5. 编译期和链接期的最后一公里模块砍完、依赖砍完、dispatch 砍完库大概能到 3 到 5MB 这个区间。想再往下走就得靠编译器和链接器的优化了。5.1 优化等级和函数分段CMAKE_BUILD_TYPE直接选MinSizeRel它会用-Os而不是-O2。这一步通常能省 10% 到 20% 的体积。然后再手动加上函数级分段为后续的链接期裁剪做准备-DCMAKE_C_FLAGS-Os -ffunction-sections -fdata-sections \ -DCMAKE_CXX_FLAGS-Os -ffunction-sections -fdata-sections-ffunction-sections让每个函数单独放在一个节里-fdata-sections对数据同理。这两个参数本身会让库稍微变大因为节变多了对齐填充增加但它们是--gc-sections能生效的前提。顺带提一下-flto。链接时优化能把跨编译单元的调用内联掉对小函数的体积收益明显但 OpenCV 的代码规模下 LTO 链接会非常慢而且在某些老版本 GCC 交叉工具链上会直接报错。我的建议是先把 LTO 放着等其他手段都用完了再考虑收益通常在 5% 到 10%。注意不要加-fno-exceptions。OpenCV 内部大量使用cv::Exception做错误传递虽然它有CV_TRY/CV_CATCH宏支持无异常模式但代码路径覆盖得并不完整实际构建出来运行时行为很难保证。我在一个项目里为了省那两百 KB 加过结果imread读不存在的文件时直接 abort排查了半天。5.2 符号可见性默认情况下动态库会导出所有非 static 符号.dynsym表本身就能占几百 KB。加-fvisibilityhidden让默认隐藏OpenCV 自己的CV_EXPORTS宏会把需要导出的符号再显式放出来-DCMAKE_CXX_FLAGS-Os -ffunction-sections -fdata-sections -fvisibilityhidden -fvisibility-inlines-hidden静态库场景下这个参数主要影响的是链接期的符号合并效率收益不算大但如果你做的是动态库这一步能省掉可观的符号表体积还能顺带减少符号冲突风险。5.3 gc-sections 才是最终体积的决定因素如果你是静态链接到自己的程序里强烈推荐这种方案那真正决定最终体积的是链接命令-Wl,--gc-sections \ -Wl,--as-needed \ -Wl,-s--gc-sections会把没有被引用到的节全部丢掉。因为前面加了-ffunction-sections粒度为单个函数所以你在代码里没调用的 OpenCV 函数一个字节都不会进最终产物。这就是为什么我一直强调 2MB 应该按最终可执行文件净占用来算。--as-needed确保不被使用的动态库依赖不会写进DT_NEEDED。-s在链接时就去掉符号表和后面手动 strip 是一个效果二选一即可。6. 一份能直接跑的裁剪脚本把上面所有开关拼起来就是我在 ARM 项目里实际用的配置。你把工具链文件路径换成自己的就能用。6.1 完整的 CMake 配置cmake -S opencv-4.8.0 -B build-arm \ -DCMAKE_TOOLCHAIN_FILE$PWD/arm-linux-gnueabihf.cmake \ -DCMAKE_BUILD_TYPEMinSizeRel \ -DCMAKE_INSTALL_PREFIX$PWD/out-arm \ \ -DBUILD_LISTcore,imgproc,imgcodecs \ -DBUILD_SHARED_LIBSOFF \ -DBUILD_opencv_worldOFF \ \ -DBUILD_TESTSOFF \ -DBUILD_PERF_TESTSOFF \ -DBUILD_EXAMPLESOFF \ -DBUILD_opencv_appsOFF \ -DBUILD_opencv_tsOFF \ -DBUILD_DOCSOFF \ -DBUILD_JAVAOFF \ -DBUILD_opencv_python2OFF \ -DBUILD_opencv_python3OFF \ \ -DWITH_IPPOFF \ -DBUILD_IPP_IWOFF \ -DWITH_ITTOFF \ -DWITH_OPENCLOFF \ -DWITH_OPENCLAMDBLASOFF \ -DWITH_OPENCLAMDFFTOFF \ -DWITH_TBBOFF \ -DWITH_OPENMPOFF \ -DWITH_PTHREADS_PFOFF \ -DWITH_EIGENOFF \ -DWITH_LAPACKOFF \ -DWITH_CUDAOFF \ -DWITH_FFMPEGOFF \ -DWITH_GSTREAMEROFF \ -DWITH_V4LOFF \ -DWITH_GTKOFF \ -DWITH_QTOFF \ -DWITH_PROTOBUFOFF \ -DWITH_QUIRCOFF \ -DWITH_ADEOFF \ \ -DWITH_JPEGON \ -DWITH_PNGOFF \ -DWITH_TIFFOFF \ -DWITH_WEBPOFF \ -DWITH_OPENEXROFF \ -DWITH_JASPEROFF \ -DBUILD_ZLIBON \ \ -DCPU_BASELINENEON \ -DCPU_DISPATCH \ -DENABLE_NEONON \ \ -DCMAKE_C_FLAGS-Os -ffunction-sections -fdata-sections -fvisibilityhidden \ -DCMAKE_CXX_FLAGS-Os -ffunction-sections -fdata-sections -fvisibilityhidden -fvisibility-inlines-hidden配置完之后先别急着make -j先看一眼 CMake 的输出摘要确认To be built那一行列出的模块只有你想要的三个以及IPP: NO、FFMPEG: NO、OpenCL: NO这些确实生效了。这一步花十秒钟能避免编译四十分钟之后才发现某个开关没起作用。6.2 构建和产物处理cmake --build build-arm -j$(nproc) # 静态库只去调试信息别用 --strip-unneeded arm-linux-gnueabihf-strip --strip-debug out-arm/lib/libopencv_core.a arm-linux-gnueabihf-strip --strip-debug out-arm/lib/libopencv_imgproc.a arm-linux-gnueabihf-strip --strip-debug out-arm/lib/libopencv_imgcodecs.a # 体积验收 du -h out-arm/lib/*.a这里要重点提醒静态库的 strip 参数。静态库必须用--strip-debug不能用--strip-unneeded。归档文件里的重定位信息对链接器是必需的--strip-unneeded在某些 binutils 版本上会把这类信息也一起去掉链接时报一堆undefined reference而且报错的符号看起来完全莫名其妙很容易误判成自己代码的问题。动态库则可以放心用--strip-unneeded。如果你需要保留调试能力用分离符号的方式objcopy --only-keep-debug libopencv_core.a libopencv_core.a.debug objcopy --strip-debug libopencv_core.a objcopy --add-gnu-debuglinklibopencv_core.a.debug libopencv_core.a这样发布包只带精简版出问题的时候把 debug 文件放到对应路径gdb 就能恢复完整的调用栈。6.3 验收不只看体积还要看能不能跑体积压下来了不等于活儿干完了。写一个最小验证程序把业务里真正会调用的函数都过一遍#include opencv2/imgcodecs.hpp #include opencv2/imgproc.hpp #include cstdio int main() { cv::Mat src cv::imread(/tmp/test.jpg, cv::IMREAD_COLOR); if (src.empty()) { printf(imread failed\n); return -1; } cv::Mat gray, small; cv::cvtColor(src, gray, cv::COLOR_BGR2GRAY); cv::resize(gray, small, cv::Size(), 0.5, 0.5, cv::INTER_LINEAR); cv::threshold(small, small, 128, 255, cv::THRESH_BINARY); printf(ok: %dx%d\n, small.cols, small.rows); return 0; }用和产品一致的链接参数编译然后看最终可执行文件里 OpenCV 贡献了多少arm-linux-gnueabihf-g -Os -ffunction-sections -fdata-sections \ verify.cpp -o verify \ -Iout-arm/include \ -Lout-arm/lib -lopencv_imgcodecs -lopencv_imgproc -lopencv_core \ -Wl,--gc-sections -Wl,--as-needed -Wl,-s size verify看text段的增长量这才是你真正要汇报给项目的数字。我最近一次在 ARMv7 上的结果三个静态库合计 3.6MB上面这个验证程序链接出来总大小 1.8MB减去空程序本身的一百多 KBOpenCV 的净占用在 1.7MB 左右目标达成。7. 我踩过的几个坑这一节写的都是实际发生过的、文档里不会告诉你的问题。7.1 关掉 dispatch 之后某个函数直接崩有一次在 ARMv8 平台上把CPU_BASELINE设成了NEON结果cv::resize用INTER_AREA插值跑到一半触发 SIGILL。排查下来是某些内核函数在编译时选择了比 baseline 更高的实现路径而运行时分派被关掉之后没有回退机制。解决办法是把CPU_BASELINE设成NEON_FP16或者干脆留空让 OpenCV 自己判断目标平台的默认值同时确认工具链的-march参数和 baseline 是一致的。这个坑的教训是关掉 dispatch 之后所有热点函数都要在真机上跑一遍不能只在 x86 的模拟环境里验证。模拟器和真机的指令集支持情况经常不一致。7.2 少了 codec 导致 imread 静默返回空我第一次只留WITH_PNGON的时候测试用的是 PNG 图片一切正常。上线之后业务方传的是 JPGimread返回空 Mat而且不抛异常也不打日志。OpenCV 在找不到对应解码器时的行为就是这样静默失败。后来我做了一条硬性规定裁剪构建的验收用例必须覆盖业务里出现的所有图片格式哪怕只有一次例外。另外可以在程序初始化时加一段自检std::vectoruchar buf; cv::imencode(.jpg, cv::Mat(4, 4, CV_8UC3), buf);如果业务要用 JPEG这行代码在裁剪后的构建里能正常跑说明编码器在。解码器可以用一个小尺寸的测试图提前验证。7.3 BUILD_LIST 里模块名的写法BUILD_LIST里写的是不带前缀的模块名core,imgproc,imgcodecs中间用逗号分隔且不能有空格。我见过有人写成opencv_core,opencv_imgprocCMake 不报错但结果是一个模块都没构建库文件是空的构建过程成功了。所以配置完一定要检查To be built那一行的输出。7.4 别忽略磁盘和内存开销裁剪之后构建时间会显著缩短但编译imgproc时的内存占用依然不低。我之前在一台 4GB 内存的虚拟机上用-j8直接被 OOM killer 干掉。安全做法是-j4或者用ninja配合负载限制cmake -G Ninja ... ninja -j4Ninja 在增量构建上的表现也比 Make 好不少改一个开关重新编译的时候差别很明显。8. 还有没有更极端的路可以走如果你的目标不是 2MB 而是 500KB 甚至更小上面的路就走到头了。还有两个方向可以考虑。一个是直接找社区已经维护好的移动端裁剪分支。这类项目专门针对移动端做了深度裁剪产物通常就是coreimgprocimgcodecs三个静态库体积控制在两兆上下而且把很多平台适配的坑都填过了。用之前注意核对它的 OpenCV 基础版本和你的需求是否匹配特别是 API 层面的差异。另一个是彻底放弃完整库只把你用到的算法摘出来。比如业务里只用resizecvtColorthreshold那完全可以去 OpenCV 源码里把这几个函数的实现抠出来去掉模块封装和错误检查机制自己维护一个小文件。这种做法体积能压到几十 KB但代价是后面 OpenCV 升级、发现 bug、需要新功能的时候都得自己动手。我只在极端的 MCU 项目上这么干过一般嵌入式 Linux 场景不值得。我个人在实际操作中的体会是裁剪的本质是明确知道自己不需要什么而不是尽可能多关开关。先把业务用到的 API 列清楚再反推需要哪些模块、哪些编解码器、哪档指令集剩下的全砍掉这样出来的配置最干净也最好维护。从 19MB 砍到 2MB 以下这件事我做过三四次每次真正花时间的不是编译而是前面那份到底用了什么的清单。清单列准了剩下的就是照着上面这套开关填参数而已。
阅读完成 · 觉得有帮助？
