个人知识库(小明)

本文档面向初次接触 集度 OTX 代理插件（otxproxy）的开发者，系统地介绍项目的构建体系、第三方依赖、平台适配机制以及从源码到产物的完整构建流程。阅读完本文后，你将能够在 Windows（x86/x64）和 Linux（x86_64）平台上独立完成项目的编译与部署。

Sources: README.md

构建系统概览

项目采用 CMake 3.5+ 作为跨平台构建系统，源码编译为动态链接库（Windows 下输出 otxproxy.dll，Linux 下输出 libotxproxy.so），作为插件被 OTX 诊断运行时加载调用。整个构建体系围绕 根 CMakeLists.txt 进行平台检测与路径配置，再由 src/CMakeLists.txt 完成源码编译与第三方库链接，最后通过 install() 指令将产物部署到统一的输出目录。

Sources: CMakeLists.txt src/CMakeLists.txt

构建流程

mermaid

flowchart TD
    A["开发者执行构建脚本"] --> B{"操作系统检测"}
    B -->|Windows| C["build-win64.bat<br/>或 build-win32.bat"]
    B -->|Linux| D["build-unix-x86_64.sh"]
    
    C --> E["CMake 生成器:<br/>Visual Studio 17 2022"]
    D --> F["CMake 生成器:<br/>Ninja + GCC 11"]
    
    E --> G["CMakeLists.txt<br/>平台检测与路径配置"]
    F --> G
    
    G --> H["src/CMakeLists.txt<br/>源码收集与库链接"]
    G --> I["test/CMakeLists.txt<br/>测试工程编译"]
    
    H --> J["输出: otxproxy.dll / libotxproxy.so"]
    H --> K["输出: 公共头文件<br/>otxproxy.h, jidu.h, algorithm.h, jidu_uri.h"]
    I --> L["输出: test_proxy.exe"]
    
    J --> M["install 到 out/&lt;platform&gt;/lib/"]
    K --> N["install 到 out/&lt;platform&gt;/include/"]
    L --> O["install 到 out/&lt;platform&gt;/test/"]

构建脚本本身是极简的——仅负责调用 CMake 生成构建系统文件，实际编译由 Visual Studio 或 Ninja 完成。构建类型固定为 Release，同时启用 CMAKE_EXPORT_COMPILE_COMMANDS 以生成 compile_commands.json 供 IDE 工具使用。

Sources: build-win64.bat build-win32.bat build-unix-x86_64.sh

输出目录结构

无论哪个平台，编译产物统一安装到项目根目录下的 out/ 目录，按平台和架构分层：

out/
├── Windows/
│   ├── x86_64/
│   │   ├── lib/
│   │   │   └── otxproxy.dll      ← 动态链接库
│   │   ├── include/
│   │   │   ├── otxproxy.h        ← 公共 API 头文件
│   │   │   ├── jidu.h
│   │   │   ├── algorithm.h
│   │   │   └── jidu_uri.h
│   │   └── test/
│   │       └── test_proxy.exe    ← 测试可执行文件
│   └── x86/
│       └── ...（同上结构）
├── Unix/
│   └── x86_64/
│       └── lib/
│           └── libotxproxy.so
├── Android/
│   ├── arm64-v8a/
│   └── armeabi-v7a/
└── RK3568/                       ← 嵌入式 Linux

out/ 和 build/ 目录已被 .gitignore 排除在版本控制之外，确保构建产物不会污染代码仓库。

Sources: CMakeLists.txt .gitignore

编译前提与环境要求

工具链要求

平台	编译器	CMake 生成器	最低 CMake 版本	C++ 标准
Windows x64	MSVC (Visual Studio 2022)	`"Visual Studio 17 2022" -A x64`	3.5	C++11
Windows x86	MSVC (Visual Studio 2022)	`"Visual Studio 17 2022" -A Win32`	3.5	C++11
Linux x86_64	GCC 11 (`x86_64-linux-gnu-gcc-11` / `g++-11`)	Ninja（默认）	3.5	C++11
Android arm64-v8a	Android NDK（交叉编译）	—	3.5	C++11
Android armeabi-v7a	Android NDK（交叉编译）	—	3.5	C++11
RK3568（嵌入式 Linux）	交叉编译工具链	—	3.5	C++11

特别说明：Linux 构建脚本硬编码了 GCC 11 的完整路径 /usr/bin/x86_64-linux-gnu-gcc-11 和 /usr/bin/x86_64-linux-gnu-g++-11，如果系统中编译器路径或版本不同，需修改 build-unix-x86_64.sh 中的 CMAKE_C_COMPILER 和 CMAKE_CXX_COMPILER 参数。此外，Linux 构建依赖 Ninja 构建工具（ninja && ninja install），需提前安装。

Sources: build-win64.bat build-win32.bat build-unix-x86_64.sh

第三方依赖库总览

项目通过 third_parts/ 目录管理所有预编译的第三方库，采用平台→架构→{include, lib, bin} 的目录规范。下表列出了全部依赖及其在构建中的角色：

依赖库	支持的平台/架构	在构建中的角色	链接方式
libcurl + OpenSSL + zlib	Windows x64	HTTPS 通信（TLS 双向认证）	静态链接（`.lib`）
libuv	Windows x64/x86, Unix x86_64, Android arm/arm64	跨平台异步 I/O（被 MCD3D 或 OTX 运行时间接使用）	静态链接（`uv_a.lib`）
libxml2 + iconv	Windows x64	XML 解析 + 字符编码转换	静态链接（`.lib`）
MCD3D (`mcd3rts`)	Windows x86_64	DoIP（Diagnostics over IP）诊断协议栈	静态链接（`mcd3rts.lib`）
OTX Runtime (`otxrt`)	Windows x86_64	OTX 诊断运行时框架（提供 `OTXBase.hpp`、`OTX_API` 宏等）	静态链接（`otxrt.lib`）

在 Windows 平台，所有第三方库的头文件路径和链接库路径在 src/CMakeLists.txt 中硬编码为 x64 子目录。当前构建脚本不支持 Windows x86（32 位）的第三方库路径——尽管根 CMakeLists.txt 为 32 位定义了 UV_LIB_DIR、XML_LIB_DIR 等变量，但 src/CMakeLists.txt 的 include_directories 和 target_link_libraries 中均写死了 x64 路径，这意味着在 32 位 Windows 上构建需要手动调整这些路径。

Sources: src/CMakeLists.txt CMakeLists.txt

在 Linux 平台，依赖库路径在根 CMakeLists.txt 中通过 CMAKE_PREFIX_PATH 变量配置，链接时使用静态库（.a 文件）。附加的系统库包括 pthread 和 dl（动态加载器）。

Sources: CMakeLists.txt

分平台构建步骤

Windows x64（推荐）

前置条件：安装 Visual Studio 2022（含"使用 C++ 的桌面开发"工作负载）和 CMake 3.5+。

第一步，打开 x64 Native Tools Command Prompt for VS 2022（开始菜单中搜索），这是最关键的一步——普通命令提示符不会设置正确的 MSVC 环境变量。

第二步，切换到项目根目录并执行构建脚本：

cd D:\otxproxy
build-win64.bat

该脚本等效于以下 CMake 命令：

cmake --no-warn-unused-cli ^
  -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE ^
  -DCMAKE_BUILD_TYPE:STRING=Release ^
  -H. ^
  -B./build/Windows/x86_64 ^
  -G "Visual Studio 17 2022" -A x64

执行后，CMake 在 build/Windows/x86_64/ 下生成 Visual Studio 解决方案文件（.sln）。第三步，打开生成的解决方案编译，或在命令行中执行：

cmake --build ./build/Windows/x86_64 --config Release
cmake --install ./build/Windows/x86_64 --config Release

编译产物自动安装到 out/Windows/x86_64/。

Sources: build-win64.bat CMakeLists.txt

Windows x86（32 位）

步骤与 x64 相同，但需使用 x86 Native Tools Command Prompt for VS 2022，并执行：

cd D:\otxproxy
build-win32.bat

该脚本指定 -A Win32 生成 32 位构建。注意：如前所述，src/CMakeLists.txt 中的第三方库路径写死为 x64，32 位构建可能需要手动修改这些路径或准备对应的 32 位预编译库。

Sources: build-win32.bat

Linux x86_64

前置条件：安装 GCC 11、CMake 3.5+、Ninja 以及对应的 64 位标准库（libstdc++ 需支持 C++11 ABI）。

第一步，确认编译器路径正确（脚本中硬编码为 /usr/bin/x86_64-linux-gnu-gcc-11），若不一致需修改 build-unix-x86_64.sh：

bash

# 检查 GCC 11 是否已安装
ls /usr/bin/x86_64-linux-gnu-gcc-11
ls /usr/bin/x86_64-linux-gnu-g++-11

第二步，执行构建脚本：

bash

cd /path/to/otxproxy
chmod +x build-unix-x86_64.sh
./build-unix-x86_64.sh

该脚本依次执行 CMake 配置、Ninja 编译和 Ninja 安装。产物输出到 out/Unix/x86_64/lib/libotxproxy.so。注意：脚本中的源路径硬编码为 /home/datou/projects/otxproxy，如果你的项目路径不同，需同步修改 -H 和 -B 参数。

Sources: build-unix-x86_64.sh

Android（交叉编译）

Android 构建通过环境变量 ANDROID_MACH 控制目标架构（arm64 对应 arm64-v8a，其他值对应 armeabi-v7a）。构建时需设置 CMake 的交叉编译工具链指向 Android NDK。这是未在预置脚本中覆盖的高级构建场景，需要开发者自行配置 CMake 工具链文件（CMAKE_TOOLCHAIN_FILE）。

Sources: CMakeLists.txt

RK3568 嵌入式 Linux（交叉编译）

当 CMAKE_CROSSCOMPILING 为真且系统名称不匹配 "Android" 时，CMake 自动将安装目标设为 out/RK3568/。与 Android 类似，这需要配置对应的交叉编译工具链。

Sources: CMakeLists.txt

编译配置详解

C++ 标准与 ABI

项目全局设定 C++11 标准，并定义了 _GLIBCXX_USE_CXX11_ABI=1 宏——这在 Linux 上至关重要，确保使用 GCC 5+ 的新 ABI（std::string 和 std::list 的新实现），避免与依赖库的 ABI 不兼容问题。

Sources: CMakeLists.txt

编译器字符集（Windows）

在 Windows/MSVC 环境下，项目强制将源文件字符集和执行字符集均设为 UTF-8：

cmake

add_compile_options("$<$<CXX_COMPILER_ID:MSVC>:/source-charset:utf-8>")
add_compile_options("$<$<CXX_COMPILER_ID:MSVC>:/execution-charset:utf-8>")

这是必要的——项目中包含中文字符注释（如 jidu_uri.h 中的接口说明），UTF-8 字符集确保在 MSVC 下不会出现乱码。

Sources: CMakeLists.txt

STATIC_LIB 与 OTX_API 导出宏

Windows 构建时定义 -DSTATIC_LIB 编译选项。该宏影响 OTX_API 的展开行为：在 CompilerMSVC.hpp 中，当 _WINDLL 未定义时，OTX_API 展开为 __declspec(dllimport)；而当本项目本身编译动态库时（_WINDLL 由 CMake 的 SHARED 库类型自动定义），OTX_API 展开为 __declspec(dllexport)。这确保了 otxproxy 作为 DLL 编译时导出符号，而其依赖方（如 test_proxy）引用时导入符号。

Sources: src/otxinc/otx/base/CompilerMSVC.hpp src/CMakeLists.txt

安全编译选项

Windows 构建还定义了 _CRT_SECURE_NO_WARNINGS，抑制 MSVC 对 strcpy、sprintf 等传统 C 函数的安全警告——这在混合 C/C++ 风格的老项目（如本项目的 cjson.c）中很常见。

Sources: src/CMakeLists.txt

Linux 编译选项

Linux 平台为动态库设置了 -pthread -fPIC 编译选项，并链接 -ldl -pthread。-fPIC（Position Independent Code）是构建共享库的必要条件，-pthread 启用 POSIX 线程支持（被 libuv 和 OTX 运行时使用）。

Sources: src/CMakeLists.txt

源码编译组织

src/CMakeLists.txt 使用 CMake 的 aux_source_directory 指令自动收集各子目录下的源文件，无需手动维护文件列表：

源码分组	对应目录	包含的源文件数
`SRC`	`src/`（根）	核心业务逻辑：`jidu.cpp`、`otxproxy.cpp`、`algorithm.cpp` 等
`AES`	`src/aes/`	AES 自定义实现
`VBF`	`src/vbf/`	VBF 文件解析器
`FLASH`	`src/otxFlash/`	ECU 刷写框架核心
`FLASH_EVENT`	`src/otxFlash/event/`	刷写事件定义
`FLASH_TASKPOOL`	`src/otxFlash/taskpool/`	并行任务池
`REPORT`	`src/otxReport/`	诊断报告系统

所有源文件合并编译为一个共享库目标 otxproxy。这种组织方式意味着新增源文件只需放入对应子目录即可自动参与编译，无需修改 CMakeLists.txt。

Sources: src/CMakeLists.txt

构建验证与测试

测试工程

test/ 目录下包含一个独立的 CMake 工程，编译生成 test_proxy 可执行文件。测试代码链接到 otxproxy 共享库，覆盖了以下验证场景：

JSON 解析：jsonValue、jsonArraySize、jsonArrayValue 的函数调用测试
JSON 构造：addJsonKey、addJsonNum 的链式调用与嵌套 key 测试
服务器通信：通过 callServer 调用各类型请求（工厂模式 DMA/PMA、售后模式），覆盖 iType 1~92 的典型接口
加密算法：CRC16、SHA256、AES 加密/解密、ECDSA 签名验证
订单信息查询：ECU 列表遍历、软件版本匹配等

Sources: test/test.cpp test/CMakeLists.txt

手动部署验证

README.md 中记录了开发阶段的手动部署方式，即将编译产物复制到 OTX 诊断仪运行时目录：

:: Debug 模式
copy Debug\otxproxy.dll ..\test\Debug\otxproxy.dll

:: Release 模式部署到 OTX 运行时
copy Release\otxproxy.dll D:\JIDUDIAG_OTX\httpClient.dll
copy Release\otxproxy.dll D:\JIDUDIAG_S_OTX\httpClient.dll
copy Release\otxproxy.dll D:\JIDUDIAG_E_OTX\httpClient.dll

值得注意的一点：部署时 DLL 被重命名为 httpClient.dll，这意味着 OTX 运行时以 httpClient.dll 为名称加载本插件，而非 otxproxy.dll。三个目标目录分别对应生产环境（JIDUDIAG_OTX）、测试环境（JIDUDIAG_S_OTX）和开发环境（JIDUDIAG_E_OTX），与 EnvConfig 中的环境切换机制相对应。

Sources: README.md

常见构建问题排查

症状	可能原因	解决方向
CMake 找不到 "Visual Studio 17 2022" 生成器	未安装 VS 2022 或 CMake 版本过低	安装 VS 2022 并将 CMake 升级到 3.21+
`fatal error C1083: 无法打开包含文件: "otx/OTXBase.hpp"`	OTX SDK 头文件未就位	确认 `third_parts/otx/Windows/x86_64/include/otx/` 目录存在
`LNK1104: 无法打开文件 "mcd3rts.lib"`	MCD3D 库缺失	确认 `third_parts/mcd3d/Windows/x86_64/lib/mcd3rts.lib` 存在
Linux 下 `ninja: command not found`	未安装 Ninja	`sudo apt install ninja-build`
Linux 下 `gcc-11: command not found`	GCC 11 未安装或路径不同	安装 GCC 11 或修改脚本中的编译器路径
32 位构建链接失败	`src/CMakeLists.txt` 中第三方库路径写死为 x64	修改 `include_directories` 和 `target_link_libraries` 中的 `x64` 为 `x86`
`_GLIBCXX_USE_CXX11_ABI` 导致的链接错误	第三方库使用旧 ABI 编译	将 `add_definitions(-D _GLIBCXX_USE_CXX11_ABI=1)` 改为 `=0` 后重新编译

Sources: src/CMakeLists.txt build-unix-x86_64.sh CMakeLists.txt

下一步阅读

完成构建与环境配置后，建议按以下路径深入理解项目：

对外 API 契约：从 otxproxy.h：向 OTX 运行时暴露的 C 语言 API 契约开始，了解 JSON 解析、字符串工具和时间日志 API 的完整签名与用法。
核心业务入口：jidu.h（见 callServer 接口设计）是连接 OTX 脚本与集度服务器的核心 API，理解其请求路由机制是掌握整个插件的关键。
架构全景：返回概述：集度 OTX 代理插件可查阅完整的分层架构图与模块依赖关系。

构建系统概览 ​

构建流程 ​

输出目录结构 ​

编译前提与环境要求 ​

工具链要求 ​

第三方依赖库总览 ​

分平台构建步骤 ​

Windows x64（推荐） ​

Windows x86（32 位） ​

Linux x86_64 ​

Android（交叉编译） ​

RK3568 嵌入式 Linux（交叉编译） ​

编译配置详解 ​

C++ 标准与 ABI ​

编译器字符集（Windows） ​

STATIC_LIB 与 OTX_API 导出宏 ​

安全编译选项 ​

Linux 编译选项 ​

源码编译组织 ​

构建验证与测试 ​

测试工程 ​

手动部署验证 ​

常见构建问题排查 ​

下一步阅读 ​

构建系统概览

构建流程

输出目录结构

编译前提与环境要求

工具链要求

第三方依赖库总览

分平台构建步骤

Windows x64（推荐）

Windows x86（32 位）

Linux x86_64

Android（交叉编译）

RK3568 嵌入式 Linux（交叉编译）

编译配置详解

C++ 标准与 ABI

编译器字符集（Windows）

STATIC_LIB 与 OTX_API 导出宏

安全编译选项

Linux 编译选项

源码编译组织

构建验证与测试

测试工程

手动部署验证

常见构建问题排查

下一步阅读