企业官网建设流程全解析

• 图像处理
• 音视频

导读

本文基于仓库根目录的 BUILDING.md 编写，系统讲解 mozjpeg（基于 libjpeg-turbo 的 JPEG 编码器优化分支）从源码构建的完整流程。mozjpeg 的构建方式与 libjpeg-turbo 完全一致（见 README.md 中 "Compiling" 一节），因此本文的流程、选项与配方同样适用于所有 libjpeg-turbo 系列项目。读完本文，你将掌握 Un*x、Windows（Visual C++ / MinGW）的构建方法、SIMD 汇编器（NASM/Yasm）的配置、libjpeg v7/v8 兼容模拟、算术编码开关、Java 封装构建、iOS/Android 交叉编译、安装路径定制、发行包制作以及回归测试的全套实战技能。

一、构建前置要求

1.1 所有平台通用要求

• CMake：需要 v2.8.12 或更高版本。当前仓库根目录的 CMakeLists.txt 声明为cmake_minimum_required(VERSION 2.8.12...3.28)，项目版本为 5.0.0。
• NASM 或 Yasm：仅在构建 x86 / x86-64 SIMD 扩展时需要：
  • NASM 要求 2.13 或更高；
  • Yasm 要求 1.2.0 或更高；
  • 若要以 Intel Control-flow Enforcement Technology（CET，控制流强制技术）支持构建 libjpeg-turbo，则需要 NASM 2.15 或更高（CET 检测逻辑见 simd/CMakeLists.txt，通过check_c_source_compiles检测__CET__宏后为汇编器追加-D__CET__标志）；
  • macOS 上可通过 MacPorts 或 Homebrew 安装 NASM/Yasm；若希望隐藏静态链接 libjpeg-turbo 的 Mac 可执行文件或动态库中的 SIMD 函数符号，必须使用 NASM 2.14 或更高，或使用 Yasm。

汇编器路径的指定方式：若 NASM/Yasm 不在PATH中，可通过以下两种方式之一指定完整路径：

• CMake 变量：CMAKE_ASM_NASM_COMPILER
• 环境变量：ASM_NASM

在 Windows 上路径需使用正斜杠，例如c:/nasm/nasm.exe。simd/CMakeLists.txt 中正是读取ASM_NASM环境变量来填充CMAKE_ASM_NASM_COMPILER。此外，RHEL 8+ 及其衍生发行版的 NASM/Yasm 位于 CRB（Code Ready Builder）或 PowerTools 仓库中，默认未启用。

1.2 Un*x 平台（Linux、macOS、FreeBSD、Solaris、Cygwin）

• 编译器：推荐 GCC v4.1 或更高，或 Clang，以获得最佳性能。
• TurboJPEG Java 封装：需要 JDK 或 OpenJDK 1.5 或更高（Solaris 10 及更高版本、多数现代 Linux 发行版自带）。若使用 JDK 11 或更高，则还必须使用 CMake 3.10.x 或更高。

1.3 Windows

构建 Windows 版本有三条可选路线：

1. Microsoft Visual C++ 2005 或更高：可通过安装 Visual Studio Community Edition 获得全部所需工具；也可下载安装独立的 Windows SDK（Windows 7 或更高），它包含 32 位与 64 位 Visual C++ 命令行编译器。

   • 若从命令行构建，需将相应的编译器和 SDK 目录加入INCLUDE、LIB、PATH环境变量，通常通过执行vcvars32.bat或vcvars64.bat完成；
   • 使用 Visual C++ 2015 或更高版本构建的静态库，无法与更早版本的 Visual C++ 混用，反之亦然；
   • libjpeg API 的 DLL（jpeg{version}.dll）将依赖与构建所用 Visual C++ 版本对应的 C 运行时 DLL。

2. Vcpkg 依赖管理器：先用 vcpkg 安装 libpng（cjpeg/djpeg 的 PNG 支持依赖），再构建或直接安装现成的 mozjpeg port：

   git clone https://github.com/Microsoft/vcpkg.git cd vcpkg ./bootstrap-vcpkg.sh ./vcpkg integrate install vcpkg install libpng:x64-windows vcpkg install libpng:x64-windows-static # 或直接通过 vcpkg 安装 mozjpeg（由微软团队成员与社区贡献者维护） vcpkg install mozjpeg

3. MinGW：在 Windows 机器上推荐使用 MSYS2 或 tdm-gcc，两者都会在开始菜单安装一个"命令行快捷方式"，启动后编译器路径已自动配置好。

Java 封装要求：构建 TurboJPEG Java 封装需要 JDK 1.5 或更高；使用 JDK 11+ 时同样要求 CMake 3.10.x 或更高。

二、构建系统关键约束与概念

2.1 不支持作为子项目嵌入

libjpeg-turbo/mozjpeg 的构建系统不支持通过 CMake 的add_subdirectory()函数作为子项目集成。顶层 CMakeLists.txt 对此有硬性检查：一旦检测到不是从源码目录直接配置，就立即message(FATAL_ERROR ...)并提示改用ExternalProject_Add()。若下游项目需要集成，应使用 CMake 的ExternalProject_Add()函数，或对构建系统做下游定制。

2.2 Out-of-Tree 构建（外部构建目录）

所有二进制对象、库与可执行文件都生成在执行 CMake 的目录（即"二进制目录/binary directory"）中，该目录不必与源码目录相同。你可以基于同一份源码树，用不同编译器或配置创建多个相互独立的二进制目录。下文约定：

• {build_directory}—— 二进制目录；
• {source_directory}—— mozjpeg 源码目录；
• 若是 in-tree 构建，两者相同。

2.3 使用 Ninja

如果使用 Ninja 构建系统，则将所有流程中的make/nmake替换为ninja，并将-G指定的 CMake 生成器替换为Ninja即可。

三、各平台标准构建流程

说明：以下流程假设在命令行调用 CMake，但所有流程同样可以适配 CMake GUI（如cmake-gui）。

3.1 Un*x（Linux / macOS / FreeBSD / Solaris / Cygwin）

cd {build_directory} cmake -G"Unix Makefiles" [additional CMake flags] {source_directory} make

注意：在 Solaris 上，上述命令默认生成 32 位构建，64 位构建配方见下文"构建配方"。

3.2 Visual C++（命令行，NMake）

cd {build_directory} cmake -G"NMake Makefiles" -DCMAKE_BUILD_TYPE=Release [additional CMake flags] {source_directory} nmake

该流程构建 32 位还是 64 位版本，取决于PATH中cl.exe的版本。

3.3 Visual C++（IDE）

根据 Visual Studio 版本选择对应的 CMake 生成器（不带参数运行cmake可查看可用生成器列表），例如：

cd {build_directory} cmake -G"Visual Studio 10" [additional CMake flags] {source_directory}

• 在生成器名后追加Win64（如"Visual Studio 10 Win64"）可构建 64 位版本；
• 32 位与 64 位构建必须使用不同的构建目录；
• 随后在 Visual Studio 中打开ALL_BUILD.vcproj，构建其中的某个配置（"Debug"、"Release" 等）即可完成全部构建。

3.4 MinGW（MSYS 环境）

注意：以下流程假设在 Windows 机器上使用 MSYS 环境；若是在 Un*x（含 macOS 与 Cygwin）上交叉编译，参见"构建配方"。

cd {build_directory} cmake -G"MSYS Makefiles" [additional CMake flags] {source_directory} make

四、构建产物一览

4.1 Un*x / Cygwin 产物

版本号说明：{version}默认为 62.2.0、7.2.0 或 8.1.2，取决于启用的是 libjpeg v6b（默认）、v7 还是 v8 模拟；Cygwin 下{version}为 62、7 或 8。需要指出的是，当前仓库 CMakeLists.txt 中TURBOJPEG_SO_AGE已为 3（对应 TurboJPEG 3 API，TURBOJPEG_SO_VERSION = 0.3.0），因此实际生成的 TurboJPEG 共享库版本后缀以构建时的 CMake 计算值为准，文档中的 0.2.0 对应的是较旧的 TurboJPEG 2.x API 时代。

4.2 Visual C++ 产物

{version}为 62、7 或 8，取决于启用的 libjpeg 兼容版本。IDE 构建时产物位于{configuration}/子目录下（如Debug/、Release/、RelWithDebInfo/、MinSizeRel/）。

4.3 MinGW 产物

五、核心 CMake 配置选项

顶层 CMakeLists.txt 集中定义了所有可配置选项，下面逐一说明。

5.1 Debug 构建

在 CMake 命令行追加-DCMAKE_BUILD_TYPE=Debug；若使用 NMake，则移除-DCMAKE_BUILD_TYPE=Release（NMake 下默认即为 Debug）。顶层脚本中未显式设置CMAKE_BUILD_TYPE时默认采用 Release（见 CMakeLists.txt）。

5.2 libjpeg v7 / v8 API/ABI 模拟

cmake -DWITH_JPEG7=1 ... # 构建与 libjpeg v7 API/ABI 兼容的版本 cmake -DWITH_JPEG8=1 ... # 构建与 libjpeg v8 API/ABI 兼容的版本

对应源码中JPEG_LIB_VERSION分别设为 70 与 80（默认 62，见 CMakeLists.txt）。更详细的 v7/v8 模拟说明可参考 README.md。

5.3 算术编码支持（Arithmetic Coding）

算术编码专利已过期，本版本内置了该功能（实现基于 libjpeg v8，但在模拟 v7 或 v6b 时同样生效）。默认同时启用算术编码与解码，若想关闭可分别使用：

-DWITH_ARITH_ENC=0 # 禁用算术编码 -DWITH_ARITH_DEC=0 # 禁用算术解码

注意：当启用WITH_JPEG7或WITH_JPEG8时，源码会强制同时打开WITH_ARITH_ENC与WITH_ARITH_DEC（见 CMakeLists.txt）。这些开关会进一步控制C_ARITH_CODING_SUPPORTED与D_ARITH_CODING_SUPPORTED宏，并决定 CMakeLists.txt 中的-arithmetic回归测试是否加入构建。

5.4 TurboJPEG Java 封装

cmake -DWITH_JAVA=1 ...

该选项将 Java Native Interface（JNI）封装编入 TurboJPEG 共享库，并构建前端 Java 类，使 Java 应用能直接使用 TurboJPEG 共享库（同时自动隐含ENABLE_SHARED=1）。详见 java/README。

相关环境变量与 CMake 变量：

• JAVA_HOME：Java 不在PATH或想用其他 JDK 时，在运行 CMake 前设置；
• Java_JAVAC_EXECUTABLE、Java_JAVA_EXECUTABLE、Java_JAR_EXECUTABLE：分别指定 javac、java、jar 的替代命令或位置；
• CMAKE_JAVA_COMPILE_FLAGS或JAVAFLAGS环境变量：传给 Java 编译器的参数；
• JAVAARGS：运行 TurboJPEG Java 单元测试时传给 JRE 的参数。

5.5 其他常用选项（源码级佐证）

• ENABLE_SHARED/ENABLE_STATIC（默认均 TRUE）：是否构建共享/静态库；
• WITH_SIMD（默认 TRUE）：是否包含当前平台可用的 SIMD 扩展；
• REQUIRE_SIMD（默认 FALSE）：设为 TRUE 时，若当前平台没有可用 SIMD 扩展则直接报致命错误，而不是退化为非 SIMD 构建（simd_fail宏的实现见 simd/CMakeLists.txt）；
• WITH_TURBOJPEG（默认 TRUE）：是否包含 TurboJPEG API 库及其测试程序；
• PNG_SUPPORTED（默认 TRUE）：PNG 支持（需 libpng）；
• WITH_FUZZ（默认 FALSE）：是否构建 fuzz 目标（对应 fuzz/ 目录下的测试程序）。

六、构建配方（Build Recipes）

6.1 在 64 位 Linux/Unix 上构建 32 位

运行 CMake 前用 export/setenv 设置环境变量：

CFLAGS=-m32 LDFLAGS=-m32

6.2 在 Solaris 上构建 64 位

CFLAGS=-m64 LDFLAGS=-m64

6.3 指定其他 C 编译器

Un*x 系统上，运行 CMake 前可通过CC环境变量指定 C 编译器命令。

6.4 在 Un*x（含 Mac 与 Cygwin）上交叉编译 32 位 MinGW

在{build_directory}下创建toolchain.cmake：

set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR X86) set(CMAKE_C_COMPILER {mingw_binary_path}/i686-w64-mingw32-gcc) set(CMAKE_RC_COMPILER {mingw_binary_path}/i686-w64-mingw32-windres)

{mingw_binary_path}是 MinGW 二进制所在目录（通常为/usr/bin）。然后执行：

cd {build_directory} cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \ -DCMAKE_INSTALL_PREFIX={install_path} \ [additional CMake flags] {source_directory} make

{install_path}是 libjpeg-turbo 二进制应安装到的路径。

6.5 在 Un*x 上交叉编译 64 位 MinGW

同样的步骤，toolchain.cmake 内容改为：

set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR AMD64) set(CMAKE_C_COMPILER {mingw_binary_path}/x86_64-w64-mingw32-gcc) set(CMAKE_RC_COMPILER {mingw_binary_path}/x86_64-w64-mingw32-windres)

配置与构建命令与 32 位完全一致。

七、为 iOS 构建

iPhone/iPad 等 iOS 平台使用 Arm 处理器，且目前所有受支持的型号都包含 Neon 指令，因此可以充分利用 mozjpeg 的 SIMD 扩展显著加速 JPEG 编解码（Arm Neon 的实现源码见 simd/arm/ 目录，构建逻辑见 simd/CMakeLists.txt，其中包括 Neon 内联函数可用性探测与NEON_INTRINSICS选项）。

Armv8（64 位）

要求 Xcode 5 或更高（推荐 Xcode 6.3.x 或更高）。以下脚本演示如何构建运行于 iPhone 5S / iPad Mini 2 / iPad Air 及更新设备上的版本：

IOS_PLATFORMDIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform IOS_SYSROOT=($IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS*.sdk) export CFLAGS="-Wall -miphoneos-version-min=8.0 -funwind-tables" cd {build_directory} cmake -G"Unix Makefiles" \ -DCMAKE_C_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang \ -DCMAKE_OSX_ARCHITECTURES=arm64 \ -DCMAKE_OSX_SYSROOT=${IOS_SYSROOT[0]} \ [additional CMake flags] {source_directory} make

若要在 Apple silicon Mac 上为 iOS 模拟器构建，将iPhoneOS替换为iPhoneSimulator，并将-miphoneos-version-min替换为-miphonesimulator-version-min即可。

八、为 Android 构建

构建 Android 版本要求Android NDK v13b 或更高。以下为各 ABI 的通用配方脚本，可按需修改。

8.1 Armv7（32 位，推荐 NDK r19+ 与 Clang）

# 按需设置这些变量 NDK_PATH={full path to the NDK directory-- for example, /opt/android/android-ndk-r16b} TOOLCHAIN={"gcc" or "clang"-- "gcc" 用于 NDK r16b 及更早版本， "clang" 用于 NDK r17c 及更高版本} ANDROID_VERSION={要支持的最低 Android 版本-- 例如 "16"、"19" 等} cd {build_directory} cmake -G"Unix Makefiles" \ -DANDROID_ABI=armeabi-v7a \ -DANDROID_ARM_MODE=arm \ -DANDROID_PLATFORM=android-${ANDROID_VERSION} \ -DANDROID_TOOLCHAIN=${TOOLCHAIN} \ -DCMAKE_ASM_FLAGS="--target=arm-linux-androideabi${ANDROID_VERSION}" \ -DCMAKE_TOOLCHAIN_FILE=${NDK_PATH}/build/cmake/android.toolchain.cmake \ [additional CMake flags] {source_directory} make

8.2 Armv8（64 位，推荐 Clang）

NDK_PATH={full path to the NDK directory} TOOLCHAIN={"gcc" or "clang"-- "gcc" 用于 NDK r14b 及更早版本， "clang" 用于 NDK r17c 及更高版本} ANDROID_VERSION={要支持的最低 Android 版本，64 位构建要求 "21" 或更高} cd {build_directory} cmake -G"Unix Makefiles" \ -DANDROID_ABI=arm64-v8a \ -DANDROID_ARM_MODE=arm \ -DANDROID_PLATFORM=android-${ANDROID_VERSION} \ -DANDROID_TOOLCHAIN=${TOOLCHAIN} \ -DCMAKE_ASM_FLAGS="--target=aarch64-linux-android${ANDROID_VERSION}" \ -DCMAKE_TOOLCHAIN_FILE=${NDK_PATH}/build/cmake/android.toolchain.cmake \ [additional CMake flags] {source_directory} make

8.3 x86（32 位）

NDK_PATH={full path to the NDK directory} TOOLCHAIN={"gcc" or "clang"-- "gcc" 用于 NDK r14b 及更早版本， "clang" 用于 NDK r17c 及更高版本} ANDROID_VERSION={要支持的最低 Android 版本-- 例如 "16"、"19" 等} cd {build_directory} cmake -G"Unix Makefiles" \ -DANDROID_ABI=x86 \ -DANDROID_PLATFORM=android-${ANDROID_VERSION} \ -DANDROID_TOOLCHAIN=${TOOLCHAIN} \ -DCMAKE_TOOLCHAIN_FILE=${NDK_PATH}/build/cmake/android.toolchain.cmake \ [additional CMake flags] {source_directory} make

8.4 x86-64（64 位）

NDK_PATH={full path to the NDK directory} TOOLCHAIN={"gcc" or "clang"-- "gcc" 用于 NDK r14b 及更早版本， "clang" 用于 NDK r17c 及更高版本} ANDROID_VERSION={要支持的最低 Android 版本，64 位构建要求 "21" 或更高} cd {build_directory} cmake -G"Unix Makefiles" \ -DANDROID_ABI=x86_64 \ -DANDROID_PLATFORM=android-${ANDROID_VERSION} \ -DANDROID_TOOLCHAIN=${TOOLCHAIN} \ -DCMAKE_TOOLCHAIN_FILE=${NDK_PATH}/build/cmake/android.toolchain.cmake \ [additional CMake flags] {source_directory} make

九、探索更多高级 CMake 选项

本文未专门提及的其他 CMake 选项，可以在初次配置完成后于构建目录中运行：

ccmake {source_directory}

或

cmake-gui {source_directory}

• ccmake是文本交互式版本的 CMake；
• CMake-GUI是图形界面版本。

两者都会显示所有与 libjpeg-turbo/mozjpeg 构建相关的变量、当前取值及帮助字符串。

十、安装与卸载

10.1 基本安装

运行make install或nmake install（Visual Studio IDE 中构建 "install" 目标）即可安装；卸载则运行make uninstall或nmake uninstall（或 IDE 中的 "uninstall" 目标）。卸载逻辑由 cmakescripts/cmake_uninstall.cmake.in 生成的脚本实现。

10.2 自定义安装前缀CMAKE_INSTALL_PREFIX

可通过该变量将文件安装到任意目录。默认值如下（与顶层 CMakeLists.txt 的默认前缀逻辑一致）：

• 使用默认前缀时，文件以"官方 libjpeg-turbo 二进制包"风格的目录结构安装；
• 修改前缀（例如设为/usr/local）后，则按 GNU 标准目录结构安装。

10.3 细粒度目录控制

以下 CMake 变量可精确控制各类文件安装位置：CMAKE_INSTALL_BINDIR、CMAKE_INSTALL_DATAROOTDIR、CMAKE_INSTALL_DOCDIR、CMAKE_INSTALL_INCLUDEDIR、CMAKE_INSTALL_JAVADIR、CMAKE_INSTALL_LIBDIR、CMAKE_INSTALL_MANDIR。

• 这些目录变量可指定为绝对路径，也可指定为相对CMAKE_INSTALL_PREFIX的路径（例如将CMAKE_INSTALL_DOCDIR设为doc，文档将安装到${CMAKE_INSTALL_PREFIX}/doc）；
• 若某目录变量以尖括号形式包含另一个目录变量名，其最终值取决于被包含变量的最终值，例如CMAKE_INSTALL_MANDIR的默认值为<CMAKE_INSTALL_DATAROOTDIR>/man。

安装时实际落地的文件可从 CMakeLists.txt 的install()指令中看到：包括turbojpeg.h、jconfig.h、jerror.h、jmorecfg.h、jpeglib.h头文件，libjpeg.pc/libturbojpeg.pcpkg-config 文件，以及mojpegConfig.cmake/mojpegTargets.cmake等 CMake 包配置文件。

十一、创建发行包

构建系统支持生成多种发行包，目标定义见 cmakescripts/BuildPackages.cmake。

11.1 Linux

make rpm # 生成 Red Hat 风格二进制 RPM 包，需要 RPM v4 或更高 make srpm # 先执行 make dist 生成纯净源码包，再生成源码 RPM，需要 RPM v4 或更高 make deb # 生成 Debian 风格二进制包，需要 dpkg

make dist本质上通过git archive打包当前 HEAD（见 cmakescripts/BuildPackages.cmake）。

11.2 Mac

make dmg # 生成 Mac 包/磁盘镜像，需要 pkgbuild 与 productbuild（OS X/macOS 10.7+ 默认安装）

若希望生成包含通用 x86-64/Arm 二进制的 Mac 包，需设置 CMake 变量：

• SECONDARY_BUILD：包含一份交叉编译的 x86-64 或 Armv8（64 位）iOS/macOS 构建的目录，用于合成通用二进制。

步骤：先用 CMake 在指定的构建目录中配置交叉编译的次级构建（iOS 场景参见上文"为 iOS 构建"），再以 out-of-tree 方式配置主（原生）构建并指定该变量完成构建，最后运行make dmg。打包系统会自动构建次级构建，用lipo将其与主构建合并为通用二进制后打包。

11.3 Windows

• NMake：nmake installer
• MinGW：make installer
• Visual Studio IDE：构建 "installer" 目标

安装包libjpeg-turbo-{version}[-gcc|-vc][64].exe位于{build_directory}下；IDE 构建时位于与配置同名的子目录（如Debug\、Release\）。生成 Windows 安装包需要Nullsoft Install System（NSIS），且makensis.exe需在PATH中。Windows 安装包的 NSIS 脚本由 release/installer.nsi.in 模板生成。

十二、回归测试

12.1 标准测试

构建完成后：

• Un*x：make test
• Windows 命令行：nmake test
• Visual Studio IDE：构建 "RUN_TESTS" 目标

标准测试会运行一系列用例，验证 libjpeg-turbo 与 libjpeg v6b 之间的数学兼容性是否得到保持，同时会调用 TurboJPEG 单元测试，验证 TurboJPEG C 与 Java API 的 colorspace 扩展、YUV 编码、解压缩放等功能（相应地，底层 libjpeg API 的等价功能也得到验证）。从 CMakeLists.txt 可以看到，测试矩阵覆盖了-revert、-dct int、-prog、-arithmetic、-crop、-precision等大量组合，并通过md5cmp与预置的 MD5 基准逐位比对输出图像。

12.2 清理测试产物

• Un*x：make testclean
• Windows 命令行：nmake testclean
• Visual Studio IDE：构建 "testclean" 目标

testclean 通过 cmakescripts/testclean.cmake 删除testout*及各类*_GRAY_*、*_420_*、*_422_*、*_444_*等测试输出图像和日志文件。

12.3 扩展 TurboJPEG 测试

Un*x 平台上可运行make tjtest，对 TurboJPEG C 与 Java 封装执行更全面的测试。这些扩展测试会遍历 TurboJPEG API 中未被单元测试覆盖的全部特性（包括无损变换选项），并将每个特性生成的图像与 libjpeg API 等价特性生成的图像进行比较。扩展测试的目标是检测 TurboJPEG 封装的回归，而非底层 libjpeg API 库的回归。

此外，构建系统还提供了tjtest12与tjtest16目标（分别以 12 位与 16 位精度运行测试，见 CMakeLists.txt），它们通过 cmakescripts/tjbenchtest.cmake 驱动tjbenchtest与tjexampletest，覆盖-alloc、-yuv、-optimize、-progressive、-arithmetic、-lossless及-java等参数组合。

结语

从本文可以看出，mozjpeg 沿用了 libjpeg-turbo 高度工程化的 CMake 构建体系：同一套源码树即可通过不同的生成器与配置选项产出 Linux、macOS、Windows（MSVC/MinGW）、iOS、Android 等多个平台的静态库、动态库与命令行工具，同时通过WITH_JPEG7/WITH_JPEG8、WITH_ARITH_ENC/DEC、WITH_JAVA、WITH_SIMD/REQUIRE_SIMD等开关对 API 兼容性、功能子集与性能路径做精细化裁剪。配合make test与make tjtest的多层次回归体系，任何对构建产物或 API 的改动都能被迅速验证。若需要进一步了解 mozjpeg 独有的压缩扩展（Trellis 量化、渐进式扫描优化等），可继续阅读 README-mozilla.txt；若要掌握其各命令行工具的用法，可参考 usage.txt 与 wizard.txt。

• 图像处理
• 音视频