夜雨聆风做 Android App 的时候，我们通常面对的系统比较简单：
Android App↓HTTPS / WebSocket↓云端服务器
但是到了服务机器人项目里，系统一下子就变复杂了。
机器人里面不仅有 Android，还有 Linux 主控、MCU、底盘、电机、传感器；机器人外面还有手机 App 和云端平台。
一个比较典型的服务机器人，整体可能是这样的：
云端平台↑MQTT / HTTPS / WebSocket↓Linux 机器人主控↑ ↓TCP 串口 / CAN↑ ↓Android 控制屏 MCU↓电机 / 灯光 / 柜门传感器 / 底盘 / 执行器
理解这张图，基本就理解了服务机器人软件架构的一半。
这也是这一季首先要解决的问题：
一台服务机器人里面，到底有哪些计算单元，它们分别负责什么？
一、为什么机器人里面会同时存在 Android、Linux 和 MCU？
刚开始接触机器人项目的时候，很容易产生一个疑问：
既然机器人上已经有 Android 平板了，为什么不能所有功能都直接由 Android 来控制？
比如：
Android↓控制电机↓读取传感器↓控制灯光↓控制柜门
理论上不是完全做不到。
但在真正的机器人系统里，一般不会这么设计。
原因在于：
机器人不同的软件模块，对实时性、稳定性、硬件访问能力和业务复杂度的要求完全不同。
所以通常会把系统拆成不同层级。
业务交互层Android↓机器人控制层Linux 主控↓硬件控制层MCU↓物理设备电机 / 传感器 / 灯光 / 柜门 / 底盘
每一层解决不同的问题。
而不是让一个系统把所有事情全干了。
二、Android：机器人的业务与交互控制端
服务机器人上最容易看到的部分，通常就是机身上的 Android 屏幕。
比如：
首页 任务选择 地图展示 视频画面 设备状态 用户交互 设置页面 运维页面
这些功能非常适合 Android。
所以在整个机器人架构里，Android 更像是：
机器人上层业务控制端 + 人机交互端。
它负责的是“业务”。
例如用户点击：
前往会议室Android 并不会直接告诉左轮：
左轮转速 120rpm右轮转速 115rpm
它更可能发送的是：
GO_TO_POINTpointId = meeting_room_01
也就是说，Android 关心的是：
机器人要做什么而不是：
电机具体怎么转这两个层级一定要分开。
因此在你的这套系列规划里，Android 被明确定位为业务与交互控制端，而不是底盘控制器。
三、Linux 主控：机器人的“大脑”
Android 下面通常还有一块真正的机器人主控。
很多机器人主控运行 Linux。
这一层可以理解为：
机器人的核心控制中心。
比如 Android 发出：
导航到 A 点真正处理这个任务的通常不是 Android。
而是 Linux 主控。
它可能需要协调：
地图定位导航底盘传感器任务状态异常状态
整个过程可能类似：
Android││ GO_TO_POINT↓Linux 主控│├── 查询当前定位├── 获取地图├── 计算/调用导航├── 控制底盘移动├── 检测障碍物└── 判断任务是否完成
然后主控再把状态告诉 Android：
NAVIGATION_STARTNAVIGATINGARRIVEDNAVIGATION_FAILED
Android 根据这些状态更新 UI。
所以两者的职责其实非常清楚：
Android负责：用户想让机器人做什么Linux 主控负责：机器人怎么把这件事情完成
四、MCU：真正贴近硬件的一层
再往下，就是 MCU。
例如：
STM32ESP32其他单片机
MCU 更接近真实硬件。
它可能负责：
电机编码器灯光传感器柜门锁控托盘急停电源
这些设备往往通过：
UARTRS485CANGPIO
之类的方式连接。
所以机器人里面很常见的一条链路就是：
Android↓ TCPLinux 主控↓ 串口 / CANMCU↓硬件
例如用户在 Android 上点击：
打开柜门真正的执行链路可能是：
Android↓OPEN_DOOR↓Linux 主控↓转换成底层硬件指令↓MCU↓驱动锁控模块↓柜门打开
执行完成以后，再逐层回传：
MCU↓Linux 主控↓Android
最终界面显示：
柜门已打开这就是一个非常典型的机器人控制链路。
五、为什么 Android 不直接控制 MCU？
看到这里，很容易想到：
既然 Android 最后还是要控制 MCU，那能不能直接变成：
Android↓串口↓MCU
有些简单设备确实可以这么做。
但对于完整机器人来说，一般还是会保留 Linux 主控这一层。
因为一旦系统复杂起来，Android 很快就会承担过多职责。
例如：
地图导航定位底盘传感器任务硬件协议UI视频网络云端
全部堆到 Android 上，系统会变得非常难维护。
而引入 Linux 主控以后，就可以形成非常清晰的职责边界。
┌──────────────────────┐│ Android ││ UI / 业务 / 用户交互 │└──────────┬───────────┘│ TCP┌──────────▼───────────┐│ Linux 主控 ││ 导航 / 任务 / 设备控制│└──────────┬───────────┘│ CAN / 串口┌──────────▼───────────┐│ MCU ││ 实时硬件控制 / IO │└──────────┬───────────┘↓真实硬件
这样每一层只负责自己擅长的事情。
六、云端在机器人系统里负责什么？
除了机器人本体，还有一个非常重要的部分：
云端平台。
云端和机器人本体的职责又不一样。
比如：
设备管理用户管理机器人绑定远程任务历史记录告警OTA日志远程状态
这些能力通常不会只存在机器人本地。
而是放到云端。
因此整个系统开始变成：
手机 App│HTTPS│↓云平台│MQTT / HTTPS│↓Linux 主控│┌────────┴────────┐│ │TCP 串口 / CAN│ │↓ ↓Android 控制屏 MCU│↓硬件
这时候实际上已经出现了三个控制入口：
机身 Android 屏手机 App云端平台
后面甚至还会有：
机器人自主任务所以服务机器人并不是简单的：
App → 机器人而是一个多端协同系统。
七、服务机器人实际上存在三条控制链路
从整体架构来看，可以把机器人控制大致理解成三条链路。
第一条是：
1. 本地控制
Android 控制屏↓ TCPLinux 主控↓机器人
例如：
点击开始巡航打开柜门回充停止任务切换模式
特点是：
距离近、实时性高、不依赖公网。
第二条是：
2. 机器人自主运行
Linux 主控↓任务系统↓导航 / 底盘 / 传感器
例如：
自主巡航自动回充自动避障执行预设路线
这时候即使 Android 页面退出了，机器人也不应该停止工作。
因为真正执行任务的是机器人主控。
第三条是：
3. 远程云控
手机 App↓云端↓机器人主控
例如：
远程查看状态远程创建任务远程查看视频远程控制设备
这三条链路，也是你这份第二季规划里第一篇要先建立起来的整体认知。
八、一个完整指令到底是怎么跑起来的？
例如用户站在机器人面前，在 Android 屏幕点击：
“前往前台”
整个过程可能是：
① Android用户点击：前往前台↓② Android 业务层构造指令：GO_TO_POINTpointId = FRONT_DESK↓③ TCP发送给机器人主控↓④ Linux 主控接收指令↓创建导航任务↓启动定位 / 导航↓控制机器人移动↓⑤ MCU / 底盘控制电机读取传感器↓⑥ Linux 主控持续产生状态NAVIGATINGARRIVED↓⑦ TCP状态回传 Android↓⑧ Android更新页面：正在前往前台↓已到达前台
从这个过程就能看到：
Android 并没有控制电机。
它做的是：
用户交互↓业务指令↓状态展示
Linux 主控负责：
真正执行任务MCU负责：
真正驱动硬件九、理解这套分层以后，很多机器人问题都会变简单
以前看机器人项目，很容易感觉：
TCPMQTTCAN串口AndroidLinuxMCU云端
东西特别多。
但把它们放进软件分层以后，其实就清楚了。
用户 / 运维人员↓┌─────────────────────┐│ Android / 手机 App ││ 业务与交互层 │└──────────┬──────────┘↓┌─────────────────────┐│ Linux 主控 ││ 机器人核心控制层 │└──────────┬──────────┘↓┌─────────────────────┐│ MCU ││ 硬件控制层 │└──────────┬──────────┘↓电机 / 底盘 / 灯光 / 柜门 / 传感器
云端则在机器人之外，为整个机器人系统提供：
设备任务状态数据远程控制
能力。
这也是为什么服务机器人软件不能只从 Android App 的角度去理解。
真正的软件架构，是：
Android + Linux 主控 + MCU + 云端共同组成的一套系统。
十、总结
这一篇最重要的不是记住某一种协议。
而是先建立服务机器人软件的分层模型：
Android负责业务与人机交互↓Linux 主控负责机器人任务与核心控制↓MCU负责实时硬件控制↓硬件负责真正执行动作
同时：
云端负责设备、任务、状态和远程管理
因此，一台完整的服务机器人，本质上并不是一个 Android 设备。
它更像一个由多个计算单元组成的分布式小型系统。
而 Android，只是其中非常重要的一层。
理解了这一层关系以后，下一个问题自然就出现了：
Android 控制屏和 Linux 机器人主控之间，到底应该怎么通信？
在实际服务机器人项目里，一个非常典型的方案就是：
Android↕TCP 长连接↕Linux 主控
那么问题来了：
为什么这里经常选择原生 TCP，而不是 HTTP、WebSocket 或 MQTT？
这就是下一篇要讲的内容：
下一篇
《Android 控制屏为什么与机器人主控使用 TCP 长连接？》