当前，汽车工业正进入新一轮科技革命和产业变革中，自动驾驶正成为新的技术制高点，国内外传统车企和科技公司纷纷布局。十年前，百度便开始了自动驾驶相关研发投入。2017年，Apollo计划正式宣布。

经过六年建设，Apollo开源项目在GitHub上获得的Star数超过2.3万，在社区中也备受欢迎。然而，自动驾驶系统本身的复杂性和Apollo开源代码的工程庞大，导致Apollo的使用门槛很高。对于基础开发者来说，从基础安装、使用到开发调试，开发者都可能会碰到各种问题。而对于高阶开发者，由于Apollo系统与Robotaxi场景的深度耦合，开发者如果期望在其他场景直接复用，门槛也很高。更多时候，开发者只是参考Apollo工程算法实现之后再移植到自身系统。为了更好地系统化解构和量化易用性问题，我们从以往侧重技术模块的角度转换为侧重不同类型技术开发者使用场景的角度来重塑产品，并参考内外部优秀开源社区经验，采用NPS（Net Promoter Score，净推荐值）、开发者深度访谈、工具链使用量等工具来系统获取开发者反馈，并以此作为衡量易用性的参考指标。

开发者使用场景根据不同类型技术开发者差别，把开发者使用场景大致分为以上机仿真开发调试为主的规划控制仿真开发调试场景和感知仿真开发调试场景，以上车调试为主的车辆适配与集成场景和实车路测与调试场景。通过场景分类，我们可以更好地理解开发者需求，并从中找到共性需求与理解差异性需求。开发者调研
从2022年上半年开始，我们进行了社区的第一次NPS调研，并形成了半年一次的面向所有开发者的例行反馈机制。表1是2022年上半年第一次NPS调研的数据，Apollo整体NPS极高，但感知和PnC（规划与控制）的开发体验NPS极低。这也进一步印证了我们对于Apollo社区价值与产品价值差距的认知。表1 2022年上半年NPS数据同时，在每次发版前，我们会进行alpha内测与beta公测，针对不同使用场景的开发者形成SIG（Special Interest Group，特别兴趣小组）来定向获取反馈，如图1的感知场景开发者访谈记录。图1 感知仿真开发调试场景SIG调研反馈此外，我们定期与社区布道师进行深度访谈来进一步收集意见与建议。通过这些方式，我们期望深度切入开发者痛点，切实解决开发者使用中的各种问题，让小白开发者从入门到精通，帮助资深开发者快速从0到1，提升效率。通过基于场景的分类和多方位的开发者反馈收集，我们梳理了四类核心问题。首先，是如何高效复用工程能力？Apollo工程庞杂且与Robotaxi场景耦合较深，如何能快速基于Apollo的核心能力扩展应用到其他场景？需要更灵活方便的发布机制来支撑；第二，如何快速验证新的算法模型，满足各种差异化应用场景落地对于算法模型的需求，或是满足科研领域对于新型算法的探索；第三，如何提升开发调试效率？工欲善其事必先利其器，目前Apollo工具偏向整车应用场景，而非个人开发调试场景。开发个人开发者工具，缩小与个人开发者需求之间的差距同样非常重要。最后，如何降低学习曲线？提供符合开发者学习习惯的内容与产品，缩短开发者学习过程是提升产品价值不可或缺的部分。接下来，我们将基于以上四点，详细介绍最新发布的Apollo开放平台8.0在工程技术、算法模型、开发工具、知识学习等方面可以为开发者带来哪些价值应用。高效复用平台能力——包管理升级Apollo软件包管理的主要目标是将自动驾驶系统的编译产出按照“模块”粒度进行规范化组织，一方面支持直接使用产出包的方式使用组件，另一方面规范组件的依赖关系以及组件的粒度，从而降低组件的使用/复用难度，提升自动驾驶系统的的研发效率。Apollo的源码是基于Bazel进行构建的，其优劣势都很明显，一方面得益于Bazel先进的并行编译速度，70W+行的源码可以在1小时内完成整体编译。另一方面受限于Bazel的单源码树的限制，Apollo模块之间无法使用二进制的方式进行依赖。Bazel包支持嵌套依赖，导致Apollo模块之间的依赖关系极其复杂，很难单独使用一个或者几个模块。因此，Apollo包管理将基于Bazel进行扩展，主要规范构建产出（以及部分源码）内容，并配套相关工具，让Apollo的模块可以通过二进制的方式引入复用，因此本文介绍的概念和术语主要是针对Apollo的构建产出。此外，Apollo的包目前对Bazel工程的支持将优先于CMake工程，但是Apollo包最终将制作成标准的DEB包，可以安装在Ubuntu操作系统上，也可以作为普通的系统包在CMake工程下使用。包管理的整体框架介绍Apollo的软件包管理是一系列工具的集合，覆盖整个软件包的整个生命周期，如图2所示。图2 Apollo包管理框架其中包含如下模块：RepoServer是软件包的云端仓库，存储包实体（即deb包）与包的索引。具体实现是采用静态网站服务结合CDN加速技术实现高速、高可用的文件下载服务。LocalRepo即软件包的本地仓库，是一个基础的本地文件系统，按照标准的文件系统规范存储包的内容，其中即包含从远程仓库下载安装的deb包，也包括本地工程构建产出的Local版本软件包。该本地仓库中存储的内容有两方面作用，一是在Apollo系统运行时提供动态链接库，另外也是在Apollo组件编译时提供依赖库。Buildtool是使用软件包作为扩展组件依赖时的配套构建工具。Apollo使用Bazel作为构建系统，所以推荐扩展组件也使用Bazel进行构建，Bazel在云端编译、缓存等技术上有很大的优势。而Buildtool目前的底层也是基于Bazel的（未来可以考虑支持CMake等多种编译系统）。Buildtool的核心作用是将Apollo的软件包作为编译依赖加到bazel构建体系中，而且尽量简化使用复杂度。众所周知，将动态库加到Bazel的依赖体系中是比较繁琐的，首先需要安装动态库，虽然Bazel中可以使用http_archive进行下载包，但是一般情况下还是会使用Apt等工具在操作系统中先安装好动态库。紧接着需要使new_local_repository创建一个repository并且提供一个BUILD文件,其中包含cc_library。在依赖包存在相互依赖的情况下,需要自行梳理版本防止依赖冲突。Buildtool通过依赖版本分析、自动拉取依赖包、自动生成repository配置、自动处理级联依赖等功能配合包描述文件(cyberfile.xml),可以让上述繁琐过程对使用者透明，只需要在包描述中声明一个依赖即可。Buildtool的第二个作用是支持源码方式使用Apollo的软件包。C++使用二进制作为依赖一直存在ABI等问题难以解决，所以在Apollo的软件包中将源码也作为标准内容，Buildtool支持将包的源码自动引入到使用者的工作空间下参与编译，与此同时Buildtool也将多个源码包的编译顺序纳入管理。除了在构建中使用Buildtool下载安装使用，也可以使用Apt等工具直接安装使用，例如在使用Dreamview播放Record文件的场景下我们不需要从头编译Apollo工程，只需要使用apt installapollo-neo-dreamview-dev，将dreamview以及其依赖按照到本地就可以来播放数据包回看数据了。软件包管理的各个组成部分已经介绍完了。可以看出其全部功能都跟无人驾驶系统本身没有关系，那它对于Apollo的发展有什么作用呢？Apollo开源项目是一整套完整的无人驾驶系统，但是由于业务场景不同，具体分场景下开发者不会直接部署一整套项目，而是从中选取适合自己的功能、算法等内容放到自己的项目中使用。而目前Monolithic Repository的组织结构，各个功能组件之间存在耦合，要抽离出来单独使用的成本很大，所以很多开发者会自己再重新实现一份代码。但这样不但浪费开发者的时间成本，也会导致开发者的扩展内容无法进行贡献。有了软件包管理后，一方面先进技术可以按照功能模块的粒度以二进制库（或者源码）的方式被开发者直接使用，同时也为开发者提供了更轻量级并且和Apollo庞大的单体源码解耦的方式来共享自己的扩展能力，即按照Apollo软件包的规范开发/发布自己的软件包，为Apollo自动驾驶系统生态的健康发展奠定了基础。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。