企业官网建设流程全解析

1. 为什么有人想放弃 Bazel？——从 MediaPipe Tasks 编译现场说起

MediaPipe Tasks 是 Google 开源的一套面向移动端和边缘设备的预构建 AI 任务 SDK，覆盖图像分类、目标检测、手势识别、语音识别等高频场景。它默认采用 Bazel 作为构建系统，官方文档、CI 流程、甚至 GitHub Actions 模板都深度绑定 Bazel。但真实开发中，我见过太多团队在落地时卡在第一步：连编译都跑不起来。

这不是能力问题，而是工具链错配。Bazel 的优势在于超大规模多语言协同构建（比如 Google 内部数百万行代码的统一构建），但它对 Android 开发者极不友好：没有图形化界面、调试困难、Gradle 插件集成生硬、依赖缓存路径晦涩、Windows 下 shell 脚本兼容性差、NDK 版本锁死严格、错误提示像谜语——“Target @com_google_absl//absl/base:base was referenced by //mediapipe/tasks/cc/core:task_runner but no matching target was found”。你得翻三遍 WORKSPACE 文件，再查五次 BUILD.bazel 语法，最后发现只是某处cc_library少了个visibility = ["//visibility:public"]。

而 Android Studio + CMake 是什么？是绝大多数 Android 工程师每天打开 IDE 后第一眼看到的构建视图，是 Gradle 同步后自动生成的CMakeLists.txt结构，是点击 Run 按钮就能直接部署到真机的调试闭环。它不追求构建速度的极致，但追求“所见即所得”的确定性。当你需要快速验证一个手势识别模型在 vivo X100 上的帧率，或者把 MediaPipe Tasks 集成进现有 App 的某个 Fragment 里，你不需要重写整个构建体系，你只需要让libmediapipe_tasks_core.so和libmediapipe_tasks_vision.so能被app/src/main/cpp/下的业务代码正常#include并链接。

这就是放弃 Bazel 的真实动因：不是技术上做不到，而是工程效率上划不来。Bazel 是重型坦克，CMake 是越野摩托——你要横跨戈壁滩运万吨钢材，选前者；你要在老城区小巷里送三份外卖，后者才是唯一解。本文讲的，就是如何把 MediaPipe Tasks 这辆“坦克”拆解成可组装的摩托零件，并用 Android Studio 这个维修站完成现场组装。核心关键词——Bazel、Android Studio、CMake、MediaPipe、Tasks——每一个都不是孤立概念，而是环环相扣的工程决策点：Bazel 是旧范式，Android Studio 是开发终端，CMake 是新桥梁，MediaPipe 是目标库，Tasks 是具体产物。下面，我们从零开始，把这套流程走通、踩坑、固化。

2. 整体设计思路与关键取舍逻辑

2.1 放弃 Bazel 不等于抛弃其产出，而是重构依赖路径

很多人误以为“放弃 Bazel”就是删掉所有.bazelrc、WORKSPACE和BUILD.bazel文件，然后从头手写 CMakeLists。这是最危险的误区。MediaPipe Tasks 的 C++ 核心逻辑、JNI 绑定层、模型加载器、GPU 加速路径（OpenGL ES / Vulkan）全部由 Bazel 构建规则定义。直接重写不仅工作量巨大，更会丢失关键优化——比如mediapipe::StatusOr<T>的零拷贝传递、Packet的内存池管理、CalculatorGraph的调度策略。我们的策略是：保留 Bazel 的编译产出，剥离其构建过程。

具体做法分三步：

1. 用 Bazel 完成一次干净构建，生成所有.so动态库、.a静态库、头文件目录、proto 编译产物（.pb.h/.pb.cc）；
2. 提取这些产物为标准 C/C++ 依赖包，结构清晰：include/存头文件，lib/存.so，lib/static/存.a，proto/存协议缓冲区定义；
3. 在 Android Studio 的 CMake 环境中，通过find_package()或add_library(... IMPORTED)方式导入这些预编译产物，并配置正确的 include 目录、链接路径、符号可见性。

这个思路的关键在于：Bazel 只做“原料加工厂”，CMake 做“装配车间”。加工厂的输出必须稳定可复现——我们固定使用 Bazel 5.4.0（MediaPipe v0.10.11 官方指定版本），NDK r23b（避免 r25+ 中std::filesystemABI 不兼容），JDK 17（Android Gradle Plugin 8.1+ 强制要求）。每次 MediaPipe 升级，只需重新运行一次 Bazel 构建，更新依赖包即可，CMake 层几乎零修改。

2.2 为什么选 CMake 而非 ndk-build 或 Android.mk？

ndk-build 是 Android NDK 的传统构建系统，基于 GNU Make，语法冗长，对现代 C++ 特性支持弱（如target_compile_features无法精细控制），且已被 Google 官方标记为 deprecated。Android.mk 更是彻底淘汰。CMake 成为唯一选择，原因有三：

• Gradle 深度集成：AGP（Android Gradle Plugin）从 2.2 版本起原生支持 CMake，externalNativeBuild { cmake { ... } }配置一行生效，同步后自动解析CMakeLists.txt，生成 Ninja 构建脚本，无需额外插件；
• 跨平台一致性：同一份CMakeLists.txt，既可在 Android Studio 中构建 ARM64-v8a，也可在 VS Code + CMake Tools 下构建 x86_64 Windows 测试桩，甚至导出为 Visual Studio 解决方案（cmake -G "Visual Studio 17 2022"），极大方便单元测试；
• 依赖管理成熟：find_package(OpenCV REQUIRED)、find_package(protobuf REQUIRED)等命令可自动定位系统或本地安装的第三方库，配合set(CMAKE_PREFIX_PATH ...)指向 MediaPipe 产出目录，比手动include_directories()和link_libraries()更健壮。

提示：不要试图用 CMake 重写 MediaPipe 的所有 BUILD 规则。Bazel 的cc_library对应 CMake 的add_library()，但 MediaPipe 中大量使用genrule生成代码（如 proto 编译、calculator 注册表生成），这些必须提前用 Bazel 执行完毕，CMake 只负责消费结果。强行在 CMake 中调用protoc会导致路径混乱、依赖顺序错乱，最终编译失败。

2.3 Android Studio 的角色：不只是 IDE，更是构建协调中枢

Android Studio 在此方案中承担三重角色：

• Gradle 配置中心：管理build.gradle中的android.ndkVersion、externalNativeBuild.cmake.version、defaultConfig.ndk.abiFilters，确保与 Bazel 构建环境一致；
• CMake 工具链代理：自动将CMAKE_TOOLCHAIN_FILE指向 NDK 提供的android.toolchain.cmake，处理 ABI 切换、STL 选择（c++_shared）、API Level 适配；
• 调试与 Profiling 入口：点击 Run 按钮后，自动将libmediapipe_tasks_vision.so加载到app进程，支持 native 断点、内存泄漏检测（AddressSanitizer）、GPU 调试（Graphics Debugger）。

这意味着，你无需在终端敲cmake .. -DCMAKE_TOOLCHAIN_FILE=...，也不用记忆-DANDROID_ABI=arm64-v8a这类参数。Android Studio 把这些细节封装进 GUI，你只需关注CMakeLists.txt中的逻辑——这正是工程师该有的体验：工具隐形，逻辑显性。

3. 核心细节解析与实操要点

3.1 Bazel 构建 MediaPipe Tasks 的标准化流程（含避坑清单）

MediaPipe Tasks 的 Bazel 构建不是简单bazel build //...。官方未提供一键构建脚本，需手动组合多个 target。以下是经过 17 次完整构建验证的最小可行命令集（以 v0.10.11 为例）：

# 1. 清理历史缓存（关键！Bazel 缓存污染是 80% 编译失败的根源） bazel clean --expunge # 2. 构建核心 runtime 库（必须先构建，否则 vision/task 会报 missing symbol） bazel build --config=android_arm64 \ --host_javabase=@local_jdk//:jdk \ //mediapipe/tasks/cc/core:task_common_lib \ //mediapipe/tasks/cc/core:task_runner_lib \ //mediapipe/tasks/cc/core:task_utils_lib # 3. 构建 vision 模块（含图像分类、检测、手势识别） bazel build --config=android_arm64 \ --host_javabase=@local_jdk//:jdk \ //mediapipe/tasks/cc/vision:image_classifier_lib \ //mediapipe/tasks/cc/vision:object_detector_lib \ //mediapipe/tasks/cc/vision:hand_landmarker_lib \ //mediapipe/tasks/cc/vision:pose_landmarker_lib # 4. 构建 audio 模块（可选，按需添加） # bazel build --config=android_arm64 --host_javabase=@local_jdk//:jdk //mediapipe/tasks/cc/audio:speech_recognizer_lib # 5. 构建 JNI 绑定层（Java 接口桥接） bazel build --config=android_arm64 \ --host_javabase=@local_jdk//:jdk \ //mediapipe/tasks/java/com/google/mediapipe/tasks/core:core_android_lib \ //mediapipe/tasks/java/com/google/mediapipe/tasks/vision:vision_android_lib

关键参数说明：

• --config=android_arm64：指定 Android ARM64 构建配置，对应tools/bazel.rc中定义的 toolchain；
• --host_javabase=@local_jdk//:jdk：强制使用本地 JDK，避免 Bazel 自带 JDK 与 AGP 版本冲突（AGP 8.1+ 要求 JDK 17）；
• //mediapipe/tasks/cc/...:xxx_lib：目标格式为//path/to/package:target_name，_lib后缀表示 C++ 库目标。

避坑清单（血泪经验）：

• NDK 版本陷阱：Bazel 5.4.0 默认使用 NDK r21e，但 MediaPipe Tasks v0.10.11 要求 r23b。需在.bazelrc中显式覆盖：build --android_ndk_repository=@androidndk//:ndk，并在WORKSPACE中android_ndk_repository(name = "androidndk", path = "/path/to/android-ndk-r23b")；
• Python 环境隔离：Bazel 构建中genrule会调用 Python 脚本（如 proto 编译）。务必使用pyenv创建独立 Python 3.9 环境，避免系统 Python 包冲突。执行pyenv local 3.9.18后再运行 bazel；
• 磁盘空间预警：一次完整构建占用 12GB+ 临时空间（/tmp/_bazel_$USER/）。若 SSD 空间不足，设置export TMPDIR=/path/to/large/disk/tmp；
• Windows 用户特别注意：禁用 WSL2 的autogroup功能，否则 Bazel 会因权限问题无法创建 symlink。在 WSL2 中执行echo 0 | sudo tee /proc/sys/kernel/unprivileged_userns_clone。

构建成功后，产物位于bazel-bin/目录下。例如bazel-bin/mediapipe/tasks/cc/vision/libhand_landmarker_lib.so即为手势识别核心库。但注意：这是未 strip 的 debug 版本，体积巨大（>20MB），不可直接用于 APK。需后续用llvm-strip处理。

3.2 依赖包结构化整理：从 bazel-bin 到 CMake 友好目录

Bazel 输出的文件散落在bazel-bin/、bazel-genfiles/、bazel-out/多个目录，CMake 无法直接消费。必须人工整理为标准依赖包结构。我设计了一套 Python 脚本package_mediatasks.py（附后），自动完成以下操作：

# package_mediatasks.py 核心逻辑节选 import shutil, os, glob # 1. 创建标准目录结构 os.makedirs("mediapipe_tasks_deps/include", exist_ok=True) os.makedirs("mediapipe_tasks_deps/lib/arm64-v8a", exist_ok=True) os.makedirs("mediapipe_tasks_deps/lib/x86_64", exist_ok=True) # 用于模拟器 os.makedirs("mediapipe_tasks_deps/proto", exist_ok=True) # 2. 复制头文件（从 mediapipe/ 和 third_party/） for inc_dir in ["mediapipe/", "third_party/absl/", "third_party/protobuf/"]: for h_file in glob.glob(f"bazel-genfiles/{inc_dir}**/*.h", recursive=True): rel_path = os.path.relpath(h_file, "bazel-genfiles/") dst = os.path.join("mediapipe_tasks_deps/include", rel_path) os.makedirs(os.path.dirname(dst), exist_ok=True) shutil.copy2(h_file, dst) # 3. 复制 .so 库（strip 后） for so_file in glob.glob("bazel-bin/mediapipe/tasks/cc/**/*_lib.so"): if "arm64-v8a" in so_file: dst = os.path.join("mediapipe_tasks_deps/lib/arm64-v8a", os.path.basename(so_file)) # 调用 llvm-strip 压缩 os.system(f"llvm-strip --strip-unneeded {so_file} -o {dst}") elif "x86_64" in so_file: dst = os.path.join("mediapipe_tasks_deps/lib/x86_64", os.path.basename(so_file)) os.system(f"llvm-strip --strip-unneeded {so_file} -o {dst}") # 4. 复制 proto 编译产物（.pb.h/.pb.cc） for pb_file in glob.glob("bazel-genfiles/mediapipe/tasks/proto/**/*_pb.h"): rel_path = os.path.relpath(pb_file, "bazel-genfiles/") dst = os.path.join("mediapipe_tasks_deps/proto", rel_path) os.makedirs(os.path.dirname(dst), exist_ok=True) shutil.copy2(pb_file, dst)

整理后，mediapipe_tasks_deps/目录结构如下：

mediapipe_tasks_deps/ ├── include/ │ ├── mediapipe/ │ ├── absl/ │ └── google/protobuf/ ├── lib/ │ ├── arm64-v8a/ │ │ ├── libmediapipe_tasks_core.so │ │ ├── libmediapipe_tasks_vision.so │ │ └── libmediapipe_tasks_audio.so # 可选 │ └── x86_64/ │ ├── libmediapipe_tasks_core.so │ └── libmediapipe_tasks_vision.so └── proto/ └── mediapipe/ └── tasks/ └── proto/ ├── image_classifier.pb.h └── hand_landmarking.pb.h

这个结构完全符合 CMake 的find_package()惯例。include/是标准头文件根目录，lib/下按 ABI 分目录，proto/单独存放协议缓冲区定义。后续 CMake 只需set(CMAKE_PREFIX_PATH ${CMAKE_SOURCE_DIR}/mediapipe_tasks_deps)即可全局生效。

注意：libmediapipe_tasks_vision.so依赖libmediapipe_tasks_core.so，但不依赖libmediapipe.so（MediaPipe Framework 主库）。Tasks 是轻量级封装，已剥离 Framework 的 heavy weight。因此，你的CMakeLists.txt中只需链接tasks_core和tasks_vision，无需引入整个 MediaPipe。

3.3 Android Studio 工程配置：Gradle 与 CMake 的协同

在 Android Studio 中新建项目时，选择 “Empty Activity”，勾选 “Include C++ support”。这会自动生成app/src/main/cpp/native-lib.cpp和CMakeLists.txt。我们需要在此基础上改造：

Step 1：配置app/build.gradle

android { compileSdk 34 defaultConfig { applicationId "com.example.mediapipetasks" minSdk 21 targetSdk 34 versionCode 1 versionName "1.0" // 关键：指定 NDK 版本，必须与 Bazel 构建一致 ndk { abiFilters 'arm64-v8a', 'x86_64' } externalNativeBuild { cmake { cppFlags "-std=c++17 -O2" // 指向本地 CMake（避免 AS 自带旧版） version "3.22.1" } } } // 关键：关联 CMake 构建 externalNativeBuild { cmake { path "src/main/cpp/CMakeLists.txt" version "3.22.1" } } // 关键：打包 so 库 packagingOptions { pickFirst '**/libarm64-v8a/*.so' pickFirst '**/libx86_64/*.so' } }

Step 2：重写app/src/main/cpp/CMakeLists.txt

# 设置最低 CMake 版本 cmake_minimum_required(VERSION 3.22.1) # 项目名称 project("mediapipe_tasks_demo") # 设置 C++ 标准 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Werror") # 导入 MediaPipe Tasks 依赖包 set(MEDIAPLACE_TASKS_DEPS ${CMAKE_SOURCE_DIR}/../../mediapipe_tasks_deps) set(CMAKE_PREFIX_PATH ${MEDIAPLACE_TASKS_DEPS} ${CMAKE_PREFIX_PATH}) # 查找依赖（自动定位 include/ 和 lib/） find_package(mediapipe_tasks_core REQUIRED PATHS ${MEDIAPLACE_TASKS_DEPS}) find_package(mediapipe_tasks_vision REQUIRED PATHS ${MEDIAPLACE_TASKS_DEPS}) # 创建自己的 native 库 add_library(native-lib SHARED native-lib.cpp) # 包含头文件目录 target_include_directories(native-lib PRIVATE ${MEDIAPLACE_TASKS_DEPS}/include ${MEDIAPLACE_TASKS_DEPS}/proto) # 链接 MediaPipe Tasks 库 target_link_libraries(native-lib mediapipe_tasks_core mediapipe_tasks_vision log android EGL GLESv2)

关键点解析：

• find_package()命令会搜索${CMAKE_PREFIX_PATH}/lib/cmake/下的mediapipe_tasks_core-config.cmake文件。但我们没有生成这个文件！所以实际采用的是 CMake 的“fallback 模式”：当找不到 config 文件时，它会尝试在CMAKE_PREFIX_PATH下查找lib/和include/目录，并将mediapipe_tasks_core视为一个 imported library 名称。这正是我们整理目录结构的目的；
• target_include_directories()必须显式添加proto/目录，因为 Tasks 的头文件中大量#include "mediapipe/tasks/proto/image_classifier.pb.h"，而该路径不在include/下，需单独暴露；
• target_link_libraries()中的log、android、EGL、GLESv2是 Android NDK 必需的系统库，缺一不可。log用于__android_log_print，android用于looper，EGL/GLESv2是 GPU 加速基础。

3.4 C++ 层调用手势识别的完整实现（含 JNI 绑定）

native-lib.cpp是 Java 与 C++ 的桥梁。MediaPipe Tasks 提供了纯 C++ API，无需 Java 层参与核心逻辑。以下是手势识别的最小可行实现：

#include <jni.h> #include <string> #include <android/log.h> #include "mediapipe/tasks/cc/vision/hand_landmarker.h" #include "mediapipe/tasks/cc/vision/core/image.h" #include "mediapipe/framework/port/statusor.h" #define LOG_TAG "MediaPipeTasks" #define LOGI(...) __android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__) #define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, __VA_ARGS__) // 全局 HandLandmarker 实例（单例，避免重复初始化开销） std::unique_ptr<mediapipe::tasks::vision::HandLandmarker> hand_landmarker = nullptr; extern "C" { // Java 层调用：初始化模型 JNIEXPORT void JNICALL Java_com_example_mediapipetasks_MainActivity_initHandLandmarker( JNIEnv *env, jobject /* this */, jstring model_path) { const char *model_str = env->GetStringUTFChars(model_path, nullptr); std::string model_path_str(model_str); env->ReleaseStringUTFChars(model_path, model_str); // 构建 HandLandmarkerOptions mediapipe::tasks::vision::HandLandmarkerOptions options; options.base_options.model_asset_path = model_path_str; options.running_mode = mediapipe::tasks::core::RunningMode::VIDEO; // 支持连续帧 options.num_hands = 2; // 最多检测 2 只手 // 创建实例 auto status_or_landmarker = mediapipe::tasks::vision::HandLandmarker::Create( std::move(options)); if (!status_or_landmarker.ok()) { LOGE("Failed to create HandLandmarker: %s", status_or_landmarker.status().message().c_str()); return; } hand_landmarker = std::move(status_or_landmarker.value()); LOGI("HandLandmarker initialized successfully"); } // Java 层调用：处理一帧图像 JNIEXPORT jobjectArray JNICALL Java_com_example_mediapipetasks_MainActivity_processFrame( JNIEnv *env, jobject /* this */, jlong frame_data, // RGBA 数据指针 jint width, jint height) { if (!hand_landmarker) { LOGE("HandLandmarker not initialized"); return nullptr; } // 将 Java byte[] 转为 cv::Mat（此处简化，实际需 JNI 数组拷贝） // 假设 frame_data 是 RGBA uint8_t*，宽高已知 mediapipe::Image image = mediapipe::Image::CreateFromRgbaBuffer( static_cast<uint8_t*>(frame_data), width * height * 4, width, height, width * 4); // stride = width * 4 (RGBA) // 调用推理 auto status_or_result = hand_landmarker->Detect(image); if (!status_or_result.ok()) { LOGE("Detection failed: %s", status_or_result.status().message().c_str()); return nullptr; } // 解析结果（返回关键点数组） const auto& result = status_or_result.value(); jobjectArray points_array = env->NewObjectArray( result.hand_landmarks.size(), env->FindClass("[F"), // float[] nullptr); for (size_t i = 0; i < result.hand_landmarks.size(); ++i) { const auto& landmarks = result.hand_landmarks[i]; jfloatArray landmark_array = env->NewFloatArray(landmarks.size() * 3); // x,y,z std::vector<float> flat_points; for (const auto& lm : landmarks) { flat_points.push_back(lm.x()); flat_points.push_back(lm.y()); flat_points.push_back(lm.z()); } env->SetFloatArrayRegion(landmark_array, 0, flat_points.size(), flat_points.data()); env->SetObjectArrayElement(points_array, i, landmark_array); env->DeleteLocalRef(landmark_array); } return points_array; } }

关键细节：

• HandLandmarker::Create()返回StatusOr<HandLandmarker>，必须检查ok()，否则程序崩溃；
• Image::CreateFromRgbaBuffer()的stride参数极易出错：RGBA 图像每行字节数 =width * 4，不是width * 3（RGB）或width（灰度）；
• JNI 数组操作需严格DeleteLocalRef，否则内存泄漏。jobjectArray和jfloatArray都需释放；
• RunningMode::VIDEO模式启用内部帧率控制和状态保持，比IMAGE模式更适合摄像头流。

Java 层只需调用initHandLandmarker("file:///android_asset/hand_landmarker.task")和processFrame(byteArray, width, height)即可。模型文件hand_landmarker.task需放入app/src/main/assets/目录。

4. 实操过程与核心环节实现

4.1 从零开始：一次完整的端到端构建实录

以下是我在一个全新 Ubuntu 22.04 环境（无任何 Bazel/Android Studio 缓存）中，从下载源码到 APK 运行的完整时间线记录。全程耗时 48 分钟，其中 32 分钟为 Bazel 构建，16 分钟为 AS 配置与调试。

阶段 1：环境准备（8 分钟）

• 下载 Android Studio Giraffe | 2022.3.1 Patch 2（官网最新稳定版）；
• 安装 SDK Platform 34、NDK 23.2.8568313（r23b）、CMake 3.22.1（AS 自带）；
• sdkmanager --install "platform-tools" "platforms;android-34" "ndk;23.2.8568313" "cmake;3.22.1"；
• pyenv install 3.9.18 && pyenv global 3.9.18；
• pip install protobuf==3.20.3（MediaPipe 锁定版本）；
• curl -fsSL https://github.com/bazelbuild/bazel/releases/download/5.4.0/bazel-5.4.0-linux-x86_64 | sudo tee /usr/local/bin/bazel && sudo chmod +x /usr/local/bin/bazel。

阶段 2：Bazel 构建（32 分钟）

• git clone https://github.com/google/mediapipe.git && cd mediapipe；
• git checkout v0.10.11；
• 修改WORKSPACE：android_ndk_repository(name = "androidndk", path = "/home/user/Android/Sdk/ndk/23.2.8568313")；
• 执行前述 5 步构建命令；
• 运行package_mediatasks.py，生成mediapipe_tasks_deps/。

阶段 3：Android Studio 配置（12 分钟）

• 新建项目，选择 C++ 支持；
• 将mediapipe_tasks_deps/复制到项目根目录同级；
• 修改build.gradle和CMakeLists.txt（如前文）；
• app/src/main/cpp/native-lib.cpp替换为手势识别实现；
• app/src/main/java/.../MainActivity.java添加 JNI 方法声明和调用逻辑；
• 点击 Run，选择真机（Pixel 7, Android 14）。

构建成功标志：

• Gradle Sync 成功，无红色波浪线；
• Build > Make Project无 error，app/build/intermediates/cmake/debug/obj/arm64-v8a/下生成libnative-lib.so；
• APK 安装后，打开 App，Logcat 显示HandLandmarker initialized successfully；
• 摄像头画面中挥手，Logcat 输出Detected 1 hand, 21 landmarks。

性能实测数据（Pixel 7）：

• 模型：hand_landmarker.task（TensorFlow Lite, FP16, 256x256）；
• 分辨率：640x480；
• 帧率：稳定 28 FPS（CPU 模式），开启 GPU 加速后达 42 FPS；
• APK 体积增量：+3.2MB（仅 arm64-v8a so 库）。

4.2 CMakeLists.txt 的深度定制：处理多 ABI 与符号导出

MediaPipe Tasks 默认只构建arm64-v8a，但测试阶段需x86_64模拟器支持。CMake 必须能根据abiFilters自动切换库路径。标准写法如下：

# 在 CMakeLists.txt 开头添加 if(ANDROID_ABI STREQUAL "arm64-v8a") set(TASKS_LIB_DIR ${MEDIAPLACE_TASKS_DEPS}/lib/arm64-v8a) elseif(ANDROID_ABI STREQUAL "x86_64") set(TASKS_LIB_DIR ${MEDIAPLACE_TASKS_DEPS}/lib/x86_64) else() message(FATAL_ERROR "Unsupported ABI: ${ANDROID_ABI}") endif() # 导入库时使用变量 add_library(mediapipe_tasks_core SHARED IMPORTED) set_target_properties(mediapipe_tasks_core PROPERTIES IMPORTED_LOCATION ${TASKS_LIB_DIR}/libmediapipe_tasks_core.so) add_library(mediapipe_tasks_vision SHARED IMPORTED) set_target_properties(mediapipe_tasks_vision PROPERTIES IMPORTED_LOCATION ${TASKS_LIB_DIR}/libmediapipe_tasks_vision.so)

此写法比find_package()更可控，避免 CMake 在错误 ABI 目录下搜索。同时，需确保libmediapipe_tasks_vision.so的符号对 Java 层可见。MediaPipe Tasks 的 JNI 函数已用extern "C"声明，但 C++ 类方法需额外处理。在hand_landmarker.h中，确认有：

#ifdef __cplusplus extern "C" { #endif // C API wrapper（如果需要） MP_EXPORT void* create_hand_landmarker(const char* model_path); #ifdef __cplusplus } #endif

MP_EXPORT宏定义为__attribute__((visibility("default")))，确保符号不被 strip。

4.3 模型文件与资源管理：Assets vs. Files Dir

MediaPipe Tasks 模型文件（.task）必须放在assets/目录，因为 Tasks 的BaseOptions::model_asset_path仅支持file:///android_asset/协议。但assets/是只读的，无法动态更新。若需热更新模型，必须复制到getFilesDir()：

// Java 层 private void copyModelToFilesDir() { try { InputStream is = getAssets().open("hand_landmarker.task"); File modelFile = new File(getFilesDir(), "hand_landmarker.task"); FileOutputStream os = new FileOutputStream(modelFile); byte[] buffer = new byte[4096]; int len; while ((len = is.read(buffer)) != -1) { os.write(buffer, 0, len); } is.close(); os.close(); // 传入路径：file:///data/data/com.example.mediapipetasks/files/hand_landmarker.task } catch (IOException e) { e.printStackTrace(); } }

C++ 层接收此路径后，需用AAssetManager_open()读取，而非fopen()。Tasks 的model_asset_path不支持file://本地路径，只能用asset协议。因此，热更新方案需改用 Tasks 的ModelResourcesAPI，自行加载字节流。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 独家避坑技巧

技巧 1：Bazel 构建日志过滤法Bazel 错误信息常淹没在千行日志中。用grep -A 10 -B 5 "ERROR\|FAILED"快速定位。但更高效的是启用 `--verbose_fail