3、通信协议基础：Socket通信原理、TCP/UDP协议对比、JSON数据格式解析
各位同学，咱们今天聊点实在的。
做车载多屏互动，说白了就是让几个屏幕之间能「说话」。那它们怎么说话？靠的就是通信协议。我刚开始接触这块时，也以为很玄乎，后来发现，核心就三样东西：Socket、TCP/UDP、JSON。搞懂这三样，你就能让中控屏和仪表盘、后排娱乐屏聊起来。
3.1 Socket通信原理：屏幕之间的「电话线」
Socket是什么？我习惯把它理解成「电话线」。你想跟另一块屏幕通信，就得先拨号（建立连接），然后说话（发送数据），最后挂断（关闭连接）。
在车载系统里，Socket通信分两步走：
- 服务端：等着别人来连。比如中控屏作为服务端，监听一个端口。
- 客户端：主动去连别人。比如后排娱乐屏作为客户端，去连中控屏。
我举个例子。你在中控屏上点了一下「导航」，想把目的地发给仪表盘。这时候中控屏就是客户端，它主动把数据发出去；仪表盘是服务端，它一直在监听，收到数据后立刻显示。
核心要点：Socket通信是双向的。服务端和客户端一旦建立连接，两边都能发数据。不是只有客户端能发。
代码长什么样？我贴一段最基础的Socket通信示例，你们感受一下：
// 服务端（仪表盘）
ServerSocket serverSocket = new ServerSocket(8888);
Socket socket = serverSocket.accept(); // 等着客户端来连
InputStream input = socket.getInputStream();
// 读取数据...
// 客户端（中控屏）
Socket socket = new Socket("192.168.1.100", 8888);
OutputStream output = socket.getOutputStream();
output.write("导航目的地: 北京".getBytes());
嗯，这里要注意：IP地址和端口号必须配对。我在项目中遇到过，两台设备IP不在同一网段，折腾了半天才发现是网络配置问题。你想想看，电话拨错了号码，能通吗？
3.2 TCP vs UDP：一个像快递，一个像广播
搞清楚了Socket，接下来就是选协议。车载多屏互动里，最常用的就是TCP和UDP。我简单说说它们的区别。
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（先握手） | 无连接（直接发） |
| 可靠性 | 可靠，丢包会重传 | 不可靠，丢了就丢了 |
| 速度 | 相对慢 | 快 |
| 适用场景 | 文件传输、指令控制 | 视频流、实时数据 |
说白了，TCP就像顺丰快递——保证送到，但慢一点。UDP就像广播喇叭——喊一嗓子，谁听到算谁的，但快。
在车载场景里，我个人的习惯是：
- 关键指令用TCP：比如「切换驾驶模式」、「发送导航路线」。这些数据丢了会出大事，必须可靠。
- 实时数据用UDP：比如仪表盘上的车速、转速，或者后排娱乐屏的视频流。丢一帧没关系，但延迟高了体验就差了。
我的经验：曾经有个项目，后排娱乐屏播放视频时用了TCP，结果画面卡顿严重。换成UDP后，虽然偶尔花屏，但整体流畅度大幅提升。用户反馈说「能接受偶尔闪一下，但不能接受一直转圈」。你看，选对协议多重要。
3.3 JSON数据格式解析：屏幕之间的「共同语言」
好了，现在两台设备能通信了，也选好了协议。但还有个问题：它们说的「话」得互相能听懂。这就轮到JSON出场了。
JSON说白了就是一种轻量级的数据交换格式。它用键值对的方式组织数据，人类能看懂，机器也能解析。我给你们看个例子：
{
"command": "navigate",
"destination": "北京",
"latitude": 39.9042,
"longitude": 116.4074,
"priority": 1
}
这段JSON的意思是：执行导航命令，目的地是北京，经纬度是xxx，优先级为1。中控屏发出这个JSON，仪表盘收到后一解析，就知道该干什么了。
为什么车载系统偏爱JSON？我个人觉得有几点：
- 可读性强：调试时一眼就能看出问题。不像二进制协议，还得拿工具解码。
- 扩展性好：加个字段就行，不用改协议结构。我在项目中遇到过，后期需求变更，加了个「途经点」字段，JSON里直接加一行就搞定。
- 解析库成熟：C++有nlohmann/json，Java有Gson，Python有json模块，几乎每个语言都有现成的。
避坑指南：我曾经在项目里犯过一个低级错误——JSON里用了中文键名。结果某些解析库对中文支持不好，导致乱码。后来我统一用英文键名，比如用"destination"而不是"目的地"。记住了，键名用英文小写+下划线，这是行业惯例。
再给你们看一个实际的车载多屏互动JSON示例：
{
"source": "center_console",
"target": "instrument_cluster",
"event_type": "media_control",
"data": {
"action": "play",
"track_name": "晴天",
"artist": "周杰伦",
"progress": 120
}
}
这个JSON的意思是：中控屏告诉仪表盘，播放周杰伦的《晴天》，当前进度是120秒。仪表盘收到后，就可以在界面上显示歌曲信息了。
3.4 实战中的组合拳
讲完了三个基础概念，咱们把它们串起来。一个典型的多屏互动流程是这样的：
- 中控屏（客户端）通过Socket连接仪表盘（服务端），使用TCP协议。
- 中控屏将指令封装成JSON格式，通过Socket发送出去。
- 仪表盘收到数据后，用JSON解析库提取字段，执行对应操作。
- 如果需要反馈，仪表盘也发一个JSON回去，比如{"status": "ok"}。
你想想看，是不是很简单？其实就是「Socket搭桥，TCP/UDP选路，JSON传话」。我在多个项目里都是这么干的，稳定又高效。
总结一下：
- Socket是通信的基础，负责建立连接和传输数据。
- TCP可靠但慢，适合指令；UDP快但不可靠，适合实时数据。
- JSON是数据格式，让不同设备能互相理解。
这三样东西，是车载多屏互动的基石。搞懂了它们，后面的开发就顺了。
好，这一章就到这里。下一章咱们聊聊「多屏同步机制」，看看怎么让几个屏幕的画面保持一致。到时候我会分享一个我踩过的坑——仪表盘和中控屏的时间戳不同步，导致动画卡成PPT。嗯，那都是后话了。
公众号:蓝海资料掘金营，微信deep3321