导读

在软件开发过程中，调试是必不可少的环节，嵌入式操作系统的调试与桌面操作系统的调试相比有很大差别，嵌入式系统的可视化调试能力比桌面操作系统要弱一点。对于导航这种业务场景比较复杂的程序开发，可视化调试环境能让我们业务场景开发事半功倍，也能快速定位导航业务与车机中其他模块交互出现的问题，提高开发过程中的调试效率。

远程调试是真机调试中最便捷的一种，开发者只需借用在PC端强大的调试器就能完成业务场景的调试。

背景

Thrift是一种接口描述语言和二进制通讯协议，它被用来定义和创建跨语言的服务，是一种RPC（远程过程调用）通信框架，由Facebook为“大规模跨语言服务开发”。在车机系统中，各模块之间也可以使用Thrift通信框架进行通信。导航作为一个单独的为进程提供服务的模块，只提供导航相关的业务以及地图渲染的能力，导航的HMI界面是车机系统中统一的操作界面，系统HMI界面与导航之间的交互接口则是通过已经定义好的接口描述语言（IDL），使用自动化工具生成本地可调用的接口，然后使用Thrift框架传输完成系统HMI与导航之间的通信。

调试手段

为了开发过程中调试方便，我们在PC上做了一套模拟器，能在PC上进行地图渲染。还实现了一套在PC上使用的系统HMI模拟命令发送工具，模拟工具是作为客户端连接导航提供的服务，这样能在PC端模拟发送命令，帮助导航简单业务的开发，但这种方式存在着以下弊端：

模拟命令工具，只能模拟简单的业务场景，有多个交互的场景无法模拟。
无法操作地图HMI，也看不到HMI界面显示以及过程中的反馈。
无法滚动地图，后面接了Win32上面的鼠标事件，能用鼠标实现滚动，但这种方式与车机中滚动流程不一致。
PC端无法使用车机中的设备，如导航过程中没有导航音，无法使用USB等。
PC端拿不到车机中的数据，比如车身数据、GPS信号等。

调试方案优化

针对当前调试手段存在的以上问题。我们对调试方案进行了优化，我们可以借助车机中系统HMI来与导航进行交互。实现了使用车机环境中的信号对PC端导航业务场景进行调试。主要有以下几点功能：

1.PC端模拟器接收车机发来的信号

在该项目中，导航的相关业务都是作为服务端向车机中其他模块提供服务，在车机系统中，系统HMI连接导航服务的地址是固定的，我们在车机中开发了一个代理–Sandwich，主要作用是启动导航服务，这个导航服务并不实现真正的导航业务，而是启动了一个空服务，让车机中其他模块能成功建立连接，同时Sandwich作为客户端连接PC端模拟器提供的导航服务，PC端的导航服务真正实现导航业务，Sandwich负责接收车机发送过来的业务请求，并将请求转发给PC端模拟器，这样PC端模拟器就能接收到车机中的信号，收到的业务请求并做处理再将处理结果通过Thrift反馈到车机端。

这个流程我们打通了车机中信号发送到PC端模拟器，并可以将处理完的数据反馈给车机端。

2.PC端模拟器向车机发送信号

导航也需要连接车机中其他模块提供的服务，如，获取车身数据、获取GPS定位信号，将导航语音数据发送到车机语音播放模块等。

PC端模拟器需要作为客户端来连接车机中的服务，真正连接的是车机中Sandwich提供的服务，Sandwich作为客户端连接车机中其他模块的服务，比如Sandwich连接Sound模块，GPS模块，CarData模块等。PC端模拟器需要使用车机设备播放导航音，需要将播放内容发送给Sandwich，Sandwich收到播放内容后，再发送给车机中的Sound模块，导航音就能播放了。PC端连接车机中其他模块的工作原理也是一样。

3. 将PC端模拟器中显示的地图投射到车机端显示

实现了以上两步，一个使用车机信号调试PC端导航程序的环境基本完成了。已经能实现车机信号与PC进行双向接收，但是此时导航的渲染能力还是停留在PC端，车机中还只是显示了一个系统HMI界面，无法看到导航地图展现的效果，这样就会带来一个问题，一些需要强依赖地图的操作可能就无法精准操作，比如点击地图上某个POI等。此时需要将PC端的展现同步到车机侧。

要实现这一目的，一般我们有两种方法：

车机与PC同步渲染

车机中的导航正常运行，当导航接收到系统模块业务请求时，先是车机导航进行处理，处理完毕后将信号转发到PC端处理，这种方案两端导航业务逻辑并行运行，复杂的业务场景下，两端会同时跟车机进行交互，此时可能会产生互斥，会有两端逻辑不同步的场景，达不到预期效果。

将车机中渲染的数据投射到车机端

在这里我们可以将PC上程序每渲染一帧地图则将结果传到车机端，由车机端Sandwich负责接收，当Sandwich接收到一帧地图像素数据后，负责将此帧数据渲染到车机屏幕上，此时车机中呈现的效果跟PC端一致。在该项目中我们采用了这一方案，这种方案中，真正的导航业务逻辑是来自PC端，车机中只是一个转发过程，所以不会存在第一种方案中的问题。

但在某些特定的环境下，导航描画会很频繁，发送给车机的数据也会很多，频繁的数据发送可能会带来一定的性能开销，表现上可能会出现延迟。这里可以使用降低图像质量来减少图像数据，例如，可以使用16位或者8位BMP来传输，还可以压缩传输，这样1920*720分辨率图像传输大小能控制在30-50k左右。

小结

基于车机系统中Thrift通信框架，实现的这套远程调试方案，实质是在车机中使用Sandwich程序接管车机系统中与导航有交互的全部接口处理，通过RPC通信转发，实现了使用真实车机信号调试导航的目的。有了这套调试环境，我们甚至可以直接在真车上边路测边调试，跟以前的路测拿Log回来分析、重现相比，整个调试过程，简单，便捷，直观。大大提高了开发效率。

基于RPC通信的特性，我们还可以对调试方案再进一步优化，可以加入多客户端调试功能，使用同一台车机环境，不同的模块负责人可以同时进行复杂业务场景的联合调试。

本文转载自公众号高德技术（ID：amap_tech）。

原文链接：

远程调试在Linux车机中的应用

创作场景

远程调试在 Linux 车机中的应用