车载Android串口开发实战：从UART/RS485到Modbus协议解析

做车载 Android 开发这几年，串口这块踩过的坑比写的代码还多。从最初在调试板上拿 USB 转串口线测 UART，到后来在量产车机上调 RS485 多设备组网，中间经历过电平不匹配烧板子、SELinux 权限搞不定一直打不开设备、Modbus 帧解析各种乱码丢包，每一个问题翻出来都能写一篇笔记。这次把车载串口开发涉及的核心内容重新梳理一遍，从硬件层的 UART、RS232、RS485 区别，到 Android 层的设备节点、权限配置、数据读写和协议解析，完整走一遍流程，顺便把这些年积累的排错经验一起放进来，给正在做类似项目的朋友一个参考。

这个内容适合谁看？刚接手车载项目、对串口通信不太熟的 Android 工程师，或者做嵌入式需要和车机联调驱动的同学。只要你的工作涉及 Android 设备通过串口和外设通信，这篇文章都能帮你在动手之前先把框架搭清楚，少走几条弯路。

1. 车载场景下的串口方案选型与整体设计

1.1 UART、RS232、RS485 到底怎么选

很多人刚接触车载项目时，第一反应是"串口不就是串口吗，直接接上就能用"，实际动手才发现根本不是一回事。UART（Universal Asynchronous Receiver/Transmitter）是芯片层面的通用异步收发器，它定义的是数据帧格式和时序，本身不规定电平标准；RS232 和 RS485 是基于 UART 的两种物理层接口标准，规定了电平范围、传输距离、连接方式这些物理特性。这个层级关系必须先理清，否则后面选型、做电路设计、判断故障都会乱。

先看最常用的三种形态：

• UART（TTL电平）：工作在 0～3.3V 或 0～5V 电平，适合板级通信，线长一般不超过 1 米，常见于手机主板和传感器模组之间。
• RS232：负逻辑电平，逻辑 1 是 -3V～-15V，逻辑 0 是 +3V～+15V，抗干扰能力强于 TTL，适合 15 米以内的点对点通信，电脑老式 DB9 串口就是这种。
• RS485：差分信号传输，A、B 两线之间的电压差表示逻辑状态，支持 1200 米长距离和最多 32 个节点（标准负载下），半双工通信，适合一主多从的总线组网。

车载场景里，短距离板内通信大多用 TTL 电平的 UART，比如中控主机和 4G 模块之间、主机和蓝牙模组之间；如果要引出到车身上的外部设备，比如 OBD 诊断口、充电桩、称重设备、广告屏控制卡，基本都会转成 RS232 或 RS485。曾经有个项目要求车机连接一台老式的工业串口打印机，设备只支持 RS232，这时候就是在主板上找一路 UART，通过 MAX3232 芯片转成 RS232 电平，再引线到 DB9 接口。

1.2 车载 Android 主机串口资源的规划思路

车载 Android 主机和我们平常用的手机开发板不太一样，它的串口数量通常比较多，而且设备节点类型五花八门。高通平台常见的节点是/dev/ttyS*，联发科平台可能是/dev/ttyMT*，USB 转串口芯片（比如 FT232R、CH340、CP2102）会生成/dev/ttyUSB*节点。启动之后先不要急着写代码，第一步是把设备节点全部列出来，确定每一路串口对应的硬件接口，这一步做扎实了后面能省很多时间。

我通常的做法是先在串口调试助手里手动测试，确认这一路串口确实能收发，再开始封装上层代码。调试时要注意物理电平类型，调试板的串口一般是 TTL，电脑上的是 RS232，中间必须加转换器，直接连大概率收不到数据甚至烧坏接口。准备一个 USB 转 TTL 模块，一个 USB 转 RS485 模块，一个 USB 转 RS232 模块，基本就能覆盖所有调试场景。

1.3 协议层设计：明文透传还是帧协议

串口本身只是管道，跑在管道上的业务协议需要自己定义。车载项目里常见的做法有两种：一种是无协议的透明传输，Android 只管把数据发出去、把数据收上来，具体含义由外设决定，适用于比较简单的控制指令；另一种是结构化帧协议，定义帧头、地址、功能码、数据长度、数据域、校验位，适用于数据量较大、可靠性要求较高的场景，比如和 BMS 电池管理系统通信、和车身控制器交互。

如果外设是工业设备，大概率跑的是 Modbus RTU 协议，帧结构固定，CRC16 校验，广播地址 0 和从站地址 1-247，一主多从轮询。这个协议我后面会专门展开，这里先提醒一点：串口通信的可靠性设计不能只靠协议层，物理层的接地、屏蔽、终端电阻同样重要，协议再好，硬件不过关一样跑不起来。

2. 硬件层关键细节：电平、接线与保护电路

2.1 电平转换芯片选型注意事项

Android 主板的 UART 引脚通常是 1.8V 或 3.3V 电平，外设可能是 5V 的 TTL 或者 RS232/RS485，直接对接几乎都会出问题。电平转换芯片的选型要看工作电压、波特率、通道数、封装这几个维度。

常用芯片里，TTL 转 RS232 最常见的是 MAX3232，支持 3.0V～5.5V 供电，内置电荷泵，不需要额外的 ±12V 电源，外围只需要几个 0.1uF 电容，很适合车载板子使用。TTL 转 RS485 常见的是 SP3485 和 MAX3485，都是 3.3V 供电，半双工，自带驱动器使能脚 DE 和接收器使能脚 RE。如果主板 UART 电平是 1.8V，选择转换芯片时要特别确认一下逻辑电平兼容性，有些芯片的输入高电平阈值是 2.0V，1.8V 信号驱动不了，这种情况需要加电平转换电路，比如 TXB0108 或 TXS0108。

选芯片还有一个容易忽略的点：静电防护能力（ESD）。车载环境静电干扰严重，芯片选型尽量选内置 ESD 保护的型号，或者外部接口处加 TVS 管。曾经有一批板子现场烧了好几路 RS485 接口，排查后发现是插拔端子时静电打坏的，后来在 A、B 线上并联了 TVS 管并且把保护地接好，问题才彻底消失。

2.2 RS485 组网接线与终端电阻

RS485 组网看起来简单，就是 A 接 A、B 接 B，但实际工程里经常因为线缆和终端电阻的问题导致通讯不稳定。标准 RS485 总线要求使用双绞线，A、B 两根线绞在一起可以抵消电磁干扰；总线两端各接一个 120Ω 终端电阻，用来匹配特征阻抗，减少信号反射。终端电阻的数量是两个，不是每个节点都接。如果只有两个设备点对点通信，主机端和从机端各接一个即可；如果是一主多从，只在总线的物理两端接，中间的设备不接。

判断是否需要终端电阻，最直接的方法是看通讯波形。用示波器测 A、B 之间的差分波形，如果上升沿和下降沿有过冲振铃，加终端电阻会明显改善；波形太圆滑、幅度偏低，可能是线缆过长或者节点数太多，需要检查总线和驱动能力。实际项目中经常遇到一种情况：线不长、设备不多，但通讯偶尔出错，最后排查发现是电平门限余量不足，这种情况下适当调整上下拉偏置电阻（在 A、B 之间加 390Ω 或者 560Ω 的偏置）可以有效提高抗干扰能力。

接地问题也要重视。RS485 是差分传输，理论上可以不共地，但长距离传输时节点之间地电位差过大，会导致共模电压超出接收器允许范围，轻则数据错乱，重则烧毁芯片。工程上一般建议多点接地或者通过总线给每个节点提供共地参考，实在无法共地时要选择隔离型 RS485 收发器（比如带隔离电源的 ADM2483），把总线侧和主板侧电气隔离。

2.3 RS485 自动收发电路：解决方向切换痛点

RS485 是半双工总线，发送和接收共用一对线，要切换方向。最简单的方式是让 MCU 或 SoC 的 GPIO 控制收发器的 DE/RE 引脚，发送数据前拉高 DE，发送完再拉低重新进入接收状态。Android 系统上实现这种控制有个难点：用户态串口驱动并不能直接在数据发送前打断 GPIO，做不好就会丢第一个字节或者最后一个字节。

很多项目喜欢用"自动收发电路"，也就是把发送信号 TXD 经过三极管或比较器处理后自动控制 DE/RE，不需要额外 GPIO。典型的电路是：TXD 经过一个非门或者三极管反相后接到 DE/RE，空闲时 DE/RE 为低电平处于接收状态，发送数据时 TXD 低电平驱动 DE 变高，切换到发送模式。这种电路非常成熟，网上能找到很多参考，核心要点是方向切换延时一定要短，否则第一个字节的起始位会被截掉。如果自己画板子，调试时优先测一下发送时 A、B 之间的电平变化，确认方向切换是否正常。

不过自动收发电路也不是万能的。高波特率（比如 115200 以上）时，TXD 的电平变化频率非常高，三极管的开关速度如果跟不上，会导致信号畸变。我在一个项目里吃过亏，自动收发电路在 9600 波特率下一切正常，改成 115200 后从机完全收不到数据，后来换成高速开关管并调整了电路参数才稳定。有条件的项目，我更推荐在驱动层做 RTS 流控切换 DE，Linux 内核里可以把 RTS 和串口数据发送绑定起来，这样方向切换的时机非常精确，不过 Android 框架层需要做一些定制，后面可能会单独写一篇。

3. Android 层串口设备节点与权限配置

3.1 找到正确的设备节点

Android 系统的串口设备节点在/dev目录下，不同硬件平台的命名规则完全不一样。高通平台常见/dev/ttyS0、/dev/ttyS1，如果用的是高通自有 UART 控制器也可能是/dev/ttyHS*；联发科平台常见/dev/ttyMT0、/dev/ttyMT1；展锐平台可能是/dev/ttySV*。外接 USB 转串口芯片时，设备节点由内核的 usb-serial 驱动动态创建，通常是/dev/ttyUSB0、/dev/ttyUSB1，好一点的驱动还会创建/dev/ttyXRUSB0这类节点（FTDI 驱动）。

设备节点映射到哪个硬件接口，一般要看硬件原理图或者厂商的 BSP 文档。如果不确定，可以先遍历一下：

adb shell ls -l /dev/tty*

也可以查看内核 dmesg 日志看有没有串口驱动注册的信息：

adbadb shell dmesg | grep -i tty

推荐直接读串口设备的链接信息，比如ls -l /sys/class/tty/ttyS0/device/driver可以查到对应的驱动，有时也能反推是哪路 UART 控制器。

我遇到过一个比较坑的情况：同一款主板，部分批次 UART 引脚复用被改了，原来/dev/ttyS1对应外设 A，新批次变成/dev/ttyS2了，代码里写死节点就会出问题。后来我们改成通过设备树或者系统属性动态获取节点。

3.2 设备节点权限和 SELinux 策略问题

Android 的 SELinux 默认是 enforcing 模式，即使应用已经申请到了android.permission.READ_EXTERNAL_STORAGE之类的权限，直接打开/dev/ttyS0依然会 Permission Denied。原因是 SELinux 在 DAC 权限之上还做了一层强制访问控制，应用进程没有对应的 SELinux 域，无法访问设备节点。

开发阶段最简单的验证办法是先把 SELinux 设为 permissive 模式，确认业务逻辑没有问题后，再写正式的 sepolicy 策略：

adb root adb shell setenforce 0

正式方案一般有两种：一种是修改 sepolicy，给系统应用或者厂商应用添加对应设备节点的访问权限，通常在device/目录下新增.te文件，比如：

type myapp_domain, domain; type myapp_device, dev_type; allow myapp_domain myapp_device:chr_file { open read write ioctl };

另一种是把自己的 App 做成系统应用（预置到/system/priv-app或者/system/app），用系统签名，同时关闭 permissive 或者添加对应的 allow 规则。非系统应用通过 JNI 层直接操作设备节点，如果没有对应的 SELinux 规则，基本很难跑通。

设备节点本身的权限也要设置。开发时可以用chmod 666 /dev/ttyS0临时开放，但重启后失效；正式方案应该通过 ueventd 规则在设备创建时自动设置权限，在.rc文件或者 ueventd.rc 里配置。

3.3 波特率等串口参数的配置逻辑

串口通信参数包括波特率、数据位、停止位、校验位、流控方式。车载外设常见的组合是 9600 8 N 1（9600 波特率、8 数据位、无校验、1 停止位），也有用 19200、38400、115200 的。Android 的android-serialport-api在 open 时通过termios结构体配置这些参数，代码中比较关键的是cfsetispeed和cfsetospeed设置波特率，cfmakeraw设置原始模式（关闭回显和行缓冲）。

参数必须和外设严格一致，否则收上来的数据全是乱码。排查方法很简单：先用示波器看波形，或者用 USB 转串口模块接到电脑上，用串口调试工具按不同参数试，能收到正确数据就说明参数匹配。

流控方面，RS232 可能会用到硬件流控 RTS/CTS，如果外设要求硬件流控，代码里要手动打开 CRTSCTS；大多数车载外设都不启用硬件流控，保持默认关闭即可。特别提醒：如果打开了不必要的硬件流控，可能出现能发不能收、能收不能发的怪现象，因为对端没有拉 RTS/CTS 信号。

4. 串口数据通信实现：打开、读写与线程模型

4.1 基于 android-serialport-api 的串口访问方案

Android 上访问串口最流行的方案是开源的android-serialport-api，它用 JNI 封装了open()、read()、write()等 Linux 系统调用，Java 层只需要创建一个SerialPort对象，指定设备路径和波特率就能打开串口。这个开源库已经多年不维护了，但胜在稳定、简单，很多车载项目至今仍基于它二次开发。

使用方式大致如下：

SerialPort serialPort = new SerialPort(new File("/dev/ttyS0"), 9600, 0); OutputStream outputStream = serialPort.getOutputStream(); InputStream inputStream = serialPort.getInputStream();

这里第三个参数是打开标志位，一般传 0，如果设备需要非阻塞模式，可以传入O_NONBLOCK。需要注意的是，某些平台上new File()路径写错不会立刻报错，而是在 open 时抛异常，所以要把节点探测逻辑和异常处理放在一起。

开源库默认只支持部分波特率，如果你需要非标准波特率（比如 9600、115200 之外的 1000000），可能需要修改 JNI 层代码，增加cfsetispeed的支持，或者使用 Linux 下高精度波特率设置接口。另外，有的 Android 版本对 JNI 库的编译环境有要求，最好直接用 NDK 编译出对应架构的libserial_port.so，放到项目的src/main/jniLibs/下。

4.2 串口读写线程模型与缓冲区设计

打开串口后，要保证数据读写的稳定，不能直接在 UI 线程里做read()或者write()。read()是阻塞操作，如果收不到数据，线程会一直挂起，在 UI 线程里会直接导致 ANR。正确的做法是启动一个独立的读线程，循环调用read()，把读取到的数据放入一个线程安全的缓冲区（比如ByteArrayOutputStream或者ConcurrentLinkedQueue）；需要发送数据时，由业务层调用一个封装的send(byte[])方法，写入输出流。

读线程的伪代码逻辑大概是：

while (!stopFlag) { int size = inputStream.read(buffer); if (size > 0) { onDataReceived(buffer, size); } }

这里有一个很重要的设计细节：read()阻塞在没有数据时会一直等待，如果要退出读线程，需要关闭输入流或者 set stopFlag 后用一个超时机制打断阻塞。很多开源方案没有实现超时控制，导致退出不干脆。可以设置串口的读超时：Vmin=0、VTime=100，这样read()最多阻塞 10 秒（单位是 0.1 秒），配合停止标志位，退出就很顺畅。

发送数据时，如果外设响应速度慢，要注意多线程并发写的问题。我一般会在send()方法里加一个同步锁，避免多个业务线程同时写导致数据交叉错乱。尤其是一个主线程定时轮询、另一个线程处理用户指令的场景，不加锁的话两个指令可能会拼在同一个串口数据帧里，外设解析直接错乱。

4.3 JNI 层与 Java 层的数据交互优化

android-serialport-api的 JNI 层直接使用 Linux 的open()、read()、write()系统调用，每次读写都涉及用户态和内核态切换。好在车载串口的数据量一般不大，常见的外设一秒也就几十到几百字节，性能压力不大，不需要额外引入 DMA 或者零拷贝。

需要注意两点：一是read()的缓冲区大小要合理，一般 1024 或 4096 字节足够，不要定义成 1 字节，否则高频数据会导致频繁调用 JNI 影响性能；二是 JNI 的全局引用要在释放时处理干净，反复开关串口时，如果 JNI 资源没有释放，会出现文件描述符泄漏，时间长了系统会报 too many open files，串口就打不开了。

我自己的经验是，尽量把 JNI 层保持精简，只负责打开、关闭、读写、配置四个基础操作，所有协议解析、分包、组包逻辑都放在 Java 层。这样排查问题方便，也更容易做单元测试。之前有个项目为了省事，把 Modbus CRC 校验放到了 C 层，后面调试时改一次协议就得重新编译 so 库，太痛苦了。

5. 协议解析与常见问题排查

5.1 Modbus RTU 协议解析实战

车载项目中经常遇到需要对接 Modbus RTU 工业设备的情况，比如充电桩、环境监测仪、门禁控制器。Modbus RTU 报文格式固定：从站地址（1 字节）、功能码（1 字节）、数据区域（N 字节）、CRC16 校验（2 字节，低字节在前）。主机发送请求帧，从站根据地址判断是否是发给自己的，是则执行并返回响应帧。

解析从站响应时最头疼的是粘包和半包问题。串口数据是流式的，一次read()不一定能拿到完整的一帧，可能只收到一半，也可能一次收到了两帧。我的处理方式是维护一个字节缓冲区，每收到一段数据就追加进去，然后按帧结构扫描：

while (buffer.size() >= MIN_FRAME_LENGTH) { int frameLength = getFrameLength(buffer); if (frameLength == -1) { buffer.remove(0); // 帧头校验失败，丢弃一个字节重新找 continue; } if (buffer.size() < frameLength) { break; // 数据不够一帧，等待下次接收 } byte[] frame = buffer.subArray(0, frameLength); buffer.removeRange(0, frameLength); if (checkCRC(frame)) { handleFrame(frame); } }

这里的关键是帧长判断必须可靠。Modbus RTU 从响应可以大致算出帧长，但通常依赖于功能码和数据字节数。在严格场景下还得判断帧间隔，两个字节之间的间隔如果超过 3.5 个字符时间（比如 9600 波特率下约 4ms），就认为是一帧的边界。不考虑帧间隔的解析器在实际现场容易出问题，尤其是总线上设备多、环境干扰大、10ms 超时的场景。

CRC16 校验必须自己实现，Android 系统库没有现成的 Modbus CRC 接口。网上有很多实现，我可以提供一个常用的：

private int calculateCRC(byte[] data, int offset, int len) { int crc = 0xFFFF; for (int i = 0; i < len; i++) { crc ^= (data[offset + i] & 0xFF); for (int j = 0; j < 8; j++) { if ((crc & 0x0001) != 0) { crc = (crc >> 1) ^ 0xA001; } else { crc = crc >> 1; } } } return crc; }

很多新手在组帧发送的时候，把 CRC 高低字节顺序搞反了，导致外设不响应。Modbus 规范是低字节在前，需要注意。

5.2 常见问题速查表：从打不开到乱码

在车载串口项目里，我把这几年反复被同事问的问题整理成了一张表，基本上 90% 的故障都能对号入座：

排查问题有一个原则：先硬件后软件。很多开发者遇到问题第一反应是改代码，其实串口这种物理通信，先确认物理层（电平、线序、终端电阻）百分之百正确，再动软件层，能省很多时间。硬件没问题再确认软件配置，最后才是协议和代码。我有一次调了两天，最后的根因是调试线太差，USB 转串口模块接触不良。

5.3 一主多从 RS485 组网的轮询策略

车载场景下，如果一台 Android 主机要同时管理多台 RS485 从设备（比如同时采集多个传感器、控制多台电机），轮询策略很关键。典型的一主多从架构中，主站（Android 主机）负责发起所有通信，从站被动响应。同一时刻总线上只能有一个设备在发送数据，否则会冲突。

轮询策略通常有两种：固定周期轮询和事件触发轮询。固定周期适合定时采集数据，比如每 100ms 轮询一次从站 1 的温度，再轮询从站 2；事件触发适合控制类指令，比如用户按下一个按键就发送对应指令。实际项目里常常混合使用，采集类数据用固定周期，控制类指令用事件触发。注意：指令和轮询要排队发送，不能在轮询到一半时插入新的发送，否则丢帧率会很高。

轮询周期的确定要考虑从站的响应时间。标准 Modbus RTU 从站的响应延迟一般在 10ms 到 100ms 之间，取决于从站固件逻辑。如果轮询周期太短，上一帧还没响完下一帧就发出去了，总线会撞车。我在项目里一般先做一次完整的单帧请求-响应耗时测试，然后把这个值乘以 2 作为最小轮询间隔。比如从站 1 的响应耗时 20ms，则轮询该设备时，发送完请求后至少要等待 40ms 再发下一帧，避免从站响应被干扰。

5.4 STM32 从站与 Android 主机联调的经验

很多外设本身就是基于 STM32 开发的，主控通过 FreeModbus 库实现 Modbus RTU 从站。联调时有个容易踩的坑：FreeModbus 的波特率和参数默认配置可能和主机端不一致，尤其是一些 STM32 开发板用的晶振误差偏大，时间长了积累误差会导致 Modbus 帧间隔判断失败。遇到这种情况，先用逻辑分析仪抓一下波形，确认起始位和停止位是否标准。

我个人很推荐在联调阶段用一个串口调试助手做中间人：把从站的串口接到电脑，用 Modbus 调试工具直接发送读寄存器指令，如果从站能正常响应，说明从站逻辑没问题；再接 Android 主机发指令，这样分段定位问题非常高效。不要在整条链路没打通之前就去改协议代码。

还有一个经验：外设串口接口的连接器方向很容易弄反。RS485 端子的 A、B 标注在不同厂家之间并不统一，有的把 A 标成 D+，有的标成 RX+，拿到设备第一件事就是看说明书确认引脚定义，不要只看丝印。曾经因为在现场把 A、B 接反，排查了大半天，其实只要两根线对调一下就好了。

6. 一些刻在脑子里的踩坑心得

6.1 不要轻易相信代码里的默认配置

很多开源串口库的默认配置在车载场景下并不适用。android-serialport-api的 open 函数里写死了波特率 9600 和默认数据位，如果你拿到代码没仔细看，以为传了 115200 进去就自动生效，实际上 JNI 层可能用的是宏定义而非你传的参数。这种 bug 非常隐蔽，因为编译不报错，运行不崩溃，但数据就是错乱。改代码之前先把 JNI 源码翻一遍，确认参数传递链路是完整的。

另外，cfmakeraw这个函数会清空 ICANON、ECHO、ISIG 等标志位，但是不会自动消除某些平台特有的标志，比如 CRTSCTS（硬件流控）。如果你的外设不支持硬件流控，而内核里默认打开了 CTS/RTS 检测，那么发送数据时内核会一直等待 CTS 信号，数据发不出去。排查这种情况时，用stty -F /dev/ttyS0 -a查看当前串口参数，如果看到crtscts字样，说明硬件流控被打开了，需要在代码里调用tcsetattr时清掉 CRTSCTS 标志。

6.2 日志和调试工具是最后的救星

串口调试时我只推荐两类工具：一类是串口调试助手，用于和电脑联调，快速验证协议；另一类是逻辑分析仪或示波器，用于物理层信号分析。Android 侧代码循环打日志不是最优方法，因为日志本身可能影响串口时序，尤其是在高波特率或者要求严格帧间隔的 Modbus 场景下，日志打多了会让解析错乱。我习惯把收发数据打印到本地文件，控制大小后按需导出，而不是全部输出到 logcat。

还有一个工具值得推荐：busybox自带的microcom命令，可以在 adb shell 里直接打开串口收发数据，用于快速验证节点是否工作正常：

adb shell microcom /dev/ttyS0 -s 9600

输入字符直接发送，收到的数据显示在终端，非常适合在没有电脑可用的生产环境里临时排查问题。

6.3 优雅地处理异常和资源释放

串口在车载环境中可能会突然出问题，比如外设断电、总线短路、接口松动。代码里必须做好异常捕获和自动重连机制。读线程如果抛出 IOException，不能让它直接退出，而应该记录日志、关闭旧连接、延时后重试打开。重连时注意要完全释放旧的文件描述符和流对象，否则连接一点一点泄漏，最终导致系统级资源不足。

设备拔出或重新插上（比如 USB 转串口设备被系统杀掉又重新枚举），设备节点可能发生变化，/dev/ttyUSB0可能变成/dev/ttyUSB1。我处理这种问题时，会实现一个设备节点探测逻辑，动态扫描/sys/class/tty/下新增的 ttyUSB 设备，找到厂商 ID 和产品 ID 匹配的节点，再动态打开。

车载项目上线之前，最好做一次长时间压力测试：连续跑 72 小时收发、每小时统计丢包率和异常次数，同时监控文件描述符数量。这比写再多 review 文档都管用，能在发布前暴露大部分并发和泄漏问题。

串口开发看起来是老技术，但在车载 Android 项目里依然不可替代。这一路下来最深的体会是：串口本身就是个"物理世界"的接口，一定要先敬畏物理层，再谈协议栈。芯片选型、电平匹配、接地、屏蔽、终端电阻，这些硬件底子打好了，Android 层的代码反而变得很薄、很稳定。如果用一句来收尾：先把示波器用好，再谈怎么写代码。