当前位置： 首页 > article >正文

探讨如何在AS上构建webrtc(2)从sdk/android/Build.gn开始

article 2025/2/9 4:42:52

全文七千多字，示例代码居多别担心，没有废话，不建议跳读。

零、梦开始的地方

要发美梦得先入睡，要入睡得找能躺平的地方。那么能躺平编译webrtc-android的地方在哪？在./src/sdk/android/Build.gn。Build.gn是Build.ninja的规则文件，类似build.cpp gcc -o后生build.o一样的意思，所以要搞清楚webrtc-android的细节脉络，就要从./src/sdk/android/Build.gn入手分析。

./src/sdk/android/Build.gn分三大部分，如下：

if (is_android) {
  import("//build/config/android/config.gni")
  import("//build/config/android/rules.gni")
  import("//third_party/jni_zero/jni_zero.gni")
  import("../../webrtc.gni")

  #####################
  # Aggregate targets #
  #####################
}


if (current_os == "linux" || is_android) {
  ################################
  # JNI targets for Java modules #
  ################################
  ... ...
  #########################
  # Generated JNI targets #
  #########################
  ... ...
  ######################
  # Native API targets #
  ######################
  ... ...
  ####################
  # Internal targets #
  ####################
}


if (is_android) {
  ################
  # Test targets #
  ################
  ... ...
}

我们节省工程量，不要测试部分，所以排除第三个if（Test targets）

第二个if是核心组成部分，囊括了多个target。这几个target也说明了整个libwebrtc.aar的核心组成结构。包括：Java层对外暴露的API 和相关内部模块，JNI层，Native可暴露的API，以及跨平台的cpp内部模块。总结来说就分三个部分：Java部分、JNI部分、CXX部分。

接下来，我们按照这三个部分逐一分析。

一、第1层梦境——Java部分

上面Build.gn的片段节选中，我特意显示了开头几行的import gni。这个gni文件分别定义了整个Build.gn中使用的编译函数和相关的指令参数。可以说我所知道的内容都是从这几个gni以及其import的gni文件中慢慢看代码翻译出来的内容。精力有限，很多都是逆向查找，有什么不对的地方可以留言指正。

  dist_jar("libwebrtc") {
    _target_dir_name = get_label_info(":$target_name", "dir")
    output = "${root_out_dir}/lib.java${_target_dir_name}/${target_name}.jar"
    direct_deps_only = true
    use_unprocessed_jars = true
    requires_android = true
    no_build_hooks = true

    deps = [
      ":audio_api_java",
      ":base_java",
      ":builtin_audio_codecs_java",
      ":camera_java",
      ":default_video_codec_factory_java",
      ":filevideo_java",
      ":hwcodecs_java",
      ":java_audio_device_module_java",
      ":libaom_av1_encoder_java",
      ":libjingle_peerconnection_java",
      ":libjingle_peerconnection_metrics_default_java",
      ":libvpx_vp8_java",
      ":libvpx_vp9_java",
      ":logging_java",
      ":peerconnection_java",
      ":screencapturer_java",
      ":surfaceviewrenderer_java",
      ":swcodecs_java",
      ":video_api_java",
      ":video_java",
      "../../rtc_base:base_java",
    ]
  }

先来看最顶层的目标dist_jar的定义在import 的rules.gni当中，其解释的意义如下：

  # Combines all dependent .jar files into a single .jar file.
  #
  # Variables:
  #   output: Path to the output jar.
  #   use_interface_jars: Use all dependent interface .jars rather than
  #     implementation .jars.
  #   use_unprocessed_jars: Use unprocessed / undesugared .jars.
  #   direct_deps_only: Do not recurse on deps.
  #   jar_excluded_patterns (optional)
  #     List of globs for paths to exclude.
  #
  # Example
  #   dist_jar("lib_fatjar") {
  #     deps = [ ":my_java_lib" ]
  #     output = "$root_build_dir/MyLibrary.jar"
  #   }

可以很清楚的看到其目的是将多个jar合并成一个jar，换句话说 dep 依赖列表中显示的节点，全都是.jar模块。

rtc_android_library("video_api_java") {
  visibility = [ "*" ]
  sources = [
    "api/org/webrtc/CapturerObserver.java",
    "api/org/webrtc/EncodedImage.java",
    "api/org/webrtc/VideoCodecInfo.java",
    "api/org/webrtc/VideoCodecStatus.java",
    "api/org/webrtc/VideoDecoder.java",
    "api/org/webrtc/VideoDecoderFactory.java",
    "api/org/webrtc/VideoEncoder.java",
    "api/org/webrtc/VideoEncoderFactory.java",
    "api/org/webrtc/VideoFrame.java",
    "api/org/webrtc/VideoSink.java",
  ]
  deps = [
    ":base_java",
    "//rtc_base:base_java",
    "//third_party/androidx:androidx_annotation_annotation_java",
  ]
  srcjar_deps = [ "//api/video:video_frame_enums" ]
}

拿其中一个依赖节点作为举例，比如说"video_api_java"。

  • rtc_android_library是构建Android的jar模块函数，visibility是可见性定义。
  • sources就是源文件列表，指定当前模块所包含的源文件。这个比较好理解。
  • deps就是依赖列表，指的是当前模块依赖了哪些模块。其中":base_java"是指当前build.gn文件中定义的模块。"//rtc_base:base_java" 是指根目录下的rtc_base工程目录下的build.gn里所定义的"base_java"模块，也可以用相对路径的写法"../../rtc_base:base_java"
  • "//third_party/androidx:androidx_annotation_annotation_java"这个依赖模块比较特殊，因为在AndroidStudio建立的工程中，是可以直接引用androidx相应的annotation包，所以我们要自行判断忽略没必要的模块引用。
  • srcjar_deps 是一个特殊的依赖参数，在rule.gni中可以找到相关说明，.srcjar是由CXX生成的java文件，以纯java文本的方式(并不是.class)打包成一个jar。我们可以在之前用脚本命令编译后的out路径下找到。然后直接用解压工具解压出所需要的java文件。

以上基本上描述了webrtc-android编译构建的Java部分，基本上都是利用 rtc_android_library 这个编译函数单独生成各个模块项，然后根据需要组合成最终形态。

找全所有模块的java文件后，按文件自带的package路径放好，基本结构如下：

在高版本的分支我发现有几个注解类，是在编译期根据cxx枚举生成的。为了在AS上不报错，我创建了 generatefromc并将对应的文件放在这里，这个目录不属于webrtc工程，请知悉。 

二、第2层梦境——JNI部分

第一层其实是# JNI targets for Java modules #这部分。总所周知Android系统源码，Java只是Android平台的API入口，真正的实现都是放在CXX中，那么就需要JNI做转接，对应的就是第二层# Generated JNI targets #。

这一层需要关注Build.gn的两个方法。generate_jar_jni 、generate_jni。举例解读如下：

  generate_jar_jni("generated_external_classes_jni") {
    classes = [
      "java/lang/Integer.class",
      "java/lang/Double.class",
      "java/lang/Long.class",
      "java/lang/Iterable.class",
      "java/util/Iterator.class",
      "java/lang/Boolean.class",
      "java/math/BigInteger.class",
      "java/util/Map.class",
      "java/util/LinkedHashMap.class",
      "java/util/ArrayList.class",
      "java/lang/Enum.class",
    ]
    jni_generator_include = "//sdk/android/src/jni/jni_generator_helper.h"
  }

  generate_jni("generated_audio_device_module_base_jni") {
    sources = [ "src/java/org/webrtc/audio/WebRtcAudioManager.java" ]
    namespace = "webrtc::jni"
    jni_generator_include = "//sdk/android/src/jni/jni_generator_helper.h"
  }

generate_jni很好理解，就是根据自定义的java源文件生成对应的jni 接口文件，内容也比较简单没啥好说的。

generate_jar_jni 是根据系统定义的包文件生成jni export接口文件，看上去可能有点难理解。为啥普通类也需要 jni 桥接？其实仔细想想用包装类&容器 作为参数输入输出也是很常有的事。

如上图所示，webrtc/src/api/ 对应 main/cpp/api/，webrtc/src/rtc_base/ 对应 main/cpp/rtc_base/，webrtc/src/third_party/ 对应 main/cpp/third_party/，webrtc/src/sdk/android 对应 main/cpp/sdk/android，如此类推，但内容不能全部无脑copy，往下会分析原因。

将由命令编译generate_jar_jni、generate_jni方法生成的 jni 产物文件（全局搜索generate_方法输入的模块名称）整理统一放到目录，cpp\sdk\android 下。收集好所需的jni 接口文件后，可以知道其目录下的jni文件依赖繁多，就拿generate_jni("generated_audio_device_module_base_jni")做举例说明，其接口文件WebRtcAudioManager_jni.h，其依赖关系树如下所示。

所有脚本生成的jni接口文件基本都包含了 third_party/jni_zero/jni_export.h 和 sdk/android/src/jni/jni_generator_helper.h 这两个文件。到这里我强烈建议手动找到WebRtcAudioManager_jni.h其依赖树的所有子项文件，这样有助于了解整个WebRTC工程的源码结构组成。

这里再多唠叨几句，说一些关键目录地址及其含义：

  • webrtc/src/api : 跨平台cxx实现部分，也可以说是webrtc的内核所在，其直接or间接依赖很多一级目录下的模块目录，譬如webrtc/src/rtc_base、webrtc/src/pc、webrtc/src/p2p、webrtc/src/call、还有最繁杂的webrtc/src/third_party 等等。
  • webrtc/src/sdk : 移动端的入口所在地，包含android和objc。webrtc/src/sdk/android下的 api/ & native_api/ 可以理解为对使用者暴露的 java api 和 native api。
  • 而 webrtc/src/sdk/android下的 src 是 java api 和 native api 的内部实现文件，所以我们会看到 webrtc/src/sdk/android/src下，又分了java目录和jni目录。

操作到这里脉络算是清晰起来了，但其实接下来才是重头戏。

三、第3层梦境——CXX & CMake

在处理移植时候，大家应该接触到 third_party这个目录，这里存放的都是网络上成熟开源的第三方工具库。上面我强烈建议手动处理 WebRtcAudioManager_jni.h 的依赖，会处遇到Google的一个知名轮子库 abseil.io (Abseil · GitHub)。以这个库为例思考分析：偌大的一个WebRTC工程，如何在AS上顺利进行编译构建。

如上图示：absl/是源码目录；ci/是不同平台的构建入口；CMake/是cmake构建方式的扩展目录。还看到三种不同的跨平台 bazel / gn / cmake 构建方式的入口文件。这里选用CMake

首先进入abseil-cpp/absl/目录，看到很多子模块，(以base为例)每个子模块也是会看到 bazel、gn、cmake 的构建脚本，如上图所示。而且我们还看到了很多_test.cc 和 _benchmark.cc的文件，它们都是 实现测试文件和性能测试文件，为了工程简洁 和 不额外引用googletest，我们直接舍弃掉这些文件。

把子模块所需要的文件 和 abseil-cpp/absl/CMakeLists.txt拷贝到 main/cpp/third_party/abseil-cpp/ 目录下。 目录结构如下组成。

然后翻阅子模块的CMakeLists.txt 和 abseil-cpp/absl/CMakeLists.txt可以发现，需要引入abseil-cpp/CMake/目录下的几个.cmake扩展文件，这样编译脚本才能正常工作起来。

万事具备了，那么东风在哪？我找到两个借东风的方法：

  • 翻阅官方网站的教程（Abseil CMake Build Instructions）
  • 翻阅\third_party\abseil-cpp\ci\对应平台的编译触发脚本

我翻看了\third_party\abseil-cpp\ci\linux_gcc-latest_libstdcxx_cmake.sh脚本，我们需要做的是：在AS项目工程上引入abseil-cpp模块的CMake编译。

add_subdirectory(third_party/abseil-cpp)

然后我们在abseil-cpp/CMakeLists.txt中，增加需要的编译参数，如上图所示。这里做些简单解读：

  1. 两个 if 折叠项都是可省略的测试项；
  2. 其他设置项都是通过\third_party\abseil-cpp\ci\linux_gcc-latest_libstdcxx_cmake.sh脚本翻译过来的；
  3. 至于ABSL_DEFAULT_LINKOPTS和 ABSL_DEFAULT_COPTS是absl的子项里需要到的编译参数。具体赋值是在\third_party\abseil-cpp\absl\copts\AbseilConfigureCopts.cmake，但测试发现ABSL_DEFAULT_LINKOPTS在Android平台上并没有具体值，但在链接的过程中又需要用到android原生的日志模块，如果需要生成独立动态库，则需要在这里手动添加。
  4. ABSL_BUILD_DLL这个标识，是abseil-cpp\absl\CMakeLists.txt文件中，用于触发生成独立动态库的方法absl_make_dll()，其详细实现参考third_party\abseil-cpp\CMake\AbseilDll.cmake

然后，就可以build看看了，我这里是成功的生成了产物。

Last but not least

自此整个AS工程的经络算是打通了。经过这么一折腾我是对整个webrtc的整体有了全新的认识。但兄弟们别忘了，这只是其中的一个第三方模块而已啊~后续还需要不断的填肉，顺着工程量的增加肯定会有更多问题出现，甚至整个工程结构都可能发生改变，到时候再出相关文章填补了。

还没说完，可能有大佬会说，用不着这样折腾。AndroidStudio原本就支持ninja。直接在webrtc\src目录创建一个AS工程目录，引用一下Build.gn就可以完美触发编译。这确实是一条容易走的路，但这个解决不了在AS上集成调试webrtc模块。这个和用命令行编译没什么区别。


http://www.kler.cn/a/537377.html

相关文章：

  • C# Mutex 锁 使用详解
  • 【Android开发AI实战】基于CNN混合YOLOV实现多车牌颜色区分且针对车牌进行矫正识别（含源码）
  • 设计模式Python版 代理模式
  • 深入理解k8s中的容器存储接口（CSI）
  • 神经网络常见激活函数 1-sigmoid函数
  • 老游戏回顾：G2
  • SpringBoot3 + Jedis5 + Redis集群 如何通过scan方法分页获取所有keys
  • 【大数据技术】Kafka实时分析用户行为日志（python+zookeeper+kafka）
  • VsCode创建VUE项目
  • 数据库操作与数据管理——Rust 与 SQLite 的集成
  • csv-parser在C++17下from_chars函数问题
  • 【GitLab CI/CD 实践】从 0 到 1 搭建高效自动化部署流程
  • Git命令缩写配置（git命令设置别名）
  • DFX（Design for eXcellence）架构设计全解析：理论、实战、案例与面试指南*
  • enableEdgeToEdge
  • 深度分析：网站快速收录与网站内容多样性的关系
  • java程序员面试自身优缺点,详细说明
  • Git命令的复习
  • SpringAI系列 - 使用LangGPT编写高质量的Prompt
  • NodeList 对象
  • Java-序列化
  • BUU24 [GXYCTF2019]BabyUpload 1
  • qt6.8安装mysql8.0驱动
  • PostgreSQL-字符串函数
  • 【算法】动态规划专题⑦ —— 多重背包问题 + 二进制分解优化 python
  • 解决 ssh: connect to host github.com port 22: Connection timed out