嵌入式 Linux 智慧屏：从原型到量产，跨越三个工程断层

嵌入式 Linux 智慧屏的项目曲线有一个典型形态：前两周进展飞快，屏幕点亮、UI 跑通、视频能播，看起来离交付只差“打磨”。然后团队会在某个节点突然停下来——4K 播放时音画不同步，开机要等二十几秒，或者安全评审问了一句“根文件系统被篡改怎么发现”，而这三个问题没有一个能靠改几行 UI 代码解决。原型和量产之间的鸿沟，不在于功能多少，而在于那些在原型阶段被临时绕过、在量产阶段必须正面解决的工程断层。本文聚焦三个最典型的断层：多媒体管线的零拷贝与图层仲裁、启动时间与系统完整性的联合设计、以及 NPU 推理从“跑通 demo”到“稳定嵌入业务循环”。

断层一：多媒体管线，GStreamer 能跑通不等于架构正确

智慧屏的视频播放常被当作“调一个 GStreamer pipeline”来处理。快速验证确实只需要一行命令：

gst-launch-1.0 filesrc location=sample.mp4 ! qtdemux ! \
  v4l2slh264dec ! videoconvert ! kmssink

这条 pipeline 能出画面，但它暴露了一个在量产中致命的问题：videoconvert 在用户空间做了一次完整的像素搬运和格式转换。对于 1080p 尚可接受，4K 下 CPU 占用和内存带宽的代价会直接挤占 UI 渲染和业务逻辑的预算。更隐蔽的问题是图层仲裁：当本地播放和投屏接收各自建立独立的显示通道时，两个路径会争抢 DRM plane，导致画面撕裂、音画不同步，或者投屏一启动本地 UI 就掉帧。

正确的架构是解封装/收流 → 硬解码 → DMA-BUF 帧 → 统一送 DRM 合成上屏，让 CPU 不参与像素搬运。在 RK3568 这类平台上，硬解的用户态核心是 MPP，GStreamer 的 mpph264dec/mpph265dec 插件只是它的一层封装。如果对 buffer 生命周期和显示时序有严格要求，绕过插件直接调用 V4L2 M2M 是更可控的选择。核心的零拷贝链路只有三步：从解码器导出 DMA-BUF fd，把 fd 导入 DRM 生成 framebuffer，然后把 framebuffer 挂到 plane 上：

/* v4l2_drm_zerocopy.c：解码帧 → DMA-BUF → DRM plane */
struct v4l2_buffer buf = {
    .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
    .memory = V4L2_MEMORY_MMAP
};
ioctl(dec_fd, VIDIOC_DQBUF, &buf);

struct v4l2_exportbuffer exp = { .type = buf.type, .index = buf.index };
ioctl(dec_fd, VIDIOC_EXPBUF, &exp);          /* exp.fd 即 DMA-BUF */

uint32_t handle;
drmPrimeFDToHandle(drm_fd, exp.fd, &handle);
uint32_t pitch = w, offset = 0, fb_id;
drmModeAddFB2(drm_fd, w, h, DRM_FORMAT_NV12,
              &handle, &pitch, &offset, &fb_id, 0);
drmModeSetPlane(drm_fd, plane_id, crtc_id, fb_id, 0,
                0, 0, 0, 0, 0, 0, w << 16, h << 16);

这段代码真正需要审慎对待的不是函数调用本身，而是 plane 的所有权。如果 UI 和视频各自调用 drmModeSetPlane，它们会在同一个 CRTC 上互相覆盖。量产架构必须有一个统一的合成器持有 DRM master，视频路径只负责把新的 DMA-BUF 提交给合成器，由合成器决定当前帧的 plane 分配。GStreamer 的 kmssink 在原型阶段可以充当这个角色，但一旦引入投屏或画中画，就需要把 kmssink 替换为项目自己的合成层，否则两个 kmssink 实例会直接竞争同一个 DRM 设备。

断层二：启动时间不是孤立指标，它和完整性校验共享预算

智慧屏的开机速度直接影响“上电即用”的体验。systemd-analyze blame 能列出耗时最长的服务单元，systemd-analyze critical-chain 则给出到达 multi-user.target 的关键路径。一个常见的优化动作是砍掉不必要的 After= 依赖、并行化可并行的单元、把不阻塞 UI 的服务推迟到 UI 就绪之后。这些操作本身并不复杂，但有一个容易被忽略的代价：dm-verity 的哈希树校验会增加启动时间，而安全评审通常要求在量产版本中开启它。

dm-verity 的工作方式是在块设备层对每个数据块做哈希校验，根哈希由启动链（U-Boot 或内核命令行）传入。它保护的是根文件系统的完整性，让任何对只读分区的篡改在挂载时即被拒绝。代价是首次访问数据块时需要计算哈希，对于启动过程中大量小文件读取的场景，累积延迟不可忽视。优化的方向不是关闭 verity，而是把校验尽量推后到非关键路径：让 UI 和多媒体服务依赖的单元排在 verity 设备就绪之后尽早启动，把日志、遥测、非关键的守护进程放到 multi-user.target 之后异步拉起。

在镜像构建阶段，生成 verity 元数据和根哈希的命令是标准的：

# 生成哈希树，输出 root hash
veritysetup format rootfs.ext4 rootfs.hash \
  --hash-offset=$(( $(stat -c%s rootfs.ext4) )) > verity_params.txt

# 启动时打开 verity 映射（initramfs 或内核命令行阶段）
veritysetup open /dev/mmcblk0p5 rootfs \
  /dev/mmcblk0p5 rootfs.hash $(cat root_hash.txt)

如果使用 Android Verified Boot 的工具链，avb_sign.py 可以把哈希树、签名和 vbmeta 结构一次性附加到镜像上，并通过 CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG 让内核校验根哈希的签名。这里的工程判断是：verity 的启动开销应该被纳入启动时间预算来统一优化，而不是在安全评审前临时加上去。一个在原型阶段没有 verity、量产阶段才补上的项目，往往需要在启动流程上做第二轮返工。

断层三：NPU 推理，从 demo 脚本到业务循环之间隔着资源管理

RK3568 内置的 NPU 提供 1TOPS 级别的 INT8 算力，RKNN 工具链支持把 ONNX、TensorFlow、PyTorch 等模型转换为 RKNN 格式，在板端通过 C API 推理。在智慧屏场景中，NPU 的典型用途不是跑大模型，而是低延迟的轻量推理：人脸检测唤醒屏幕、手势识别、或者画面质量分类。这些任务的共同特征是推理必须嵌入在摄像头或视频流的帧循环中，而不是作为一个离线脚本运行。

一个 RKNN C API 推理的最小骨架如下，关键在于输入输出的内存生命周期与帧循环对齐：

/* rknn_infer.c：在帧循环中执行推理 */
rknn_context ctx;
rknn_init(&ctx, model_data, model_size, 0, NULL);

rknn_input inputs[1] = {0};
inputs[0].index = 0;
inputs[0].type = RKNN_TENSOR_UINT8;
inputs[0].fmt = RKNN_TENSOR_NHWC;
inputs[0].size = w * h * 3;
inputs[0].buf = frame_nv12_to_rgb(frame);  /* 复用缓冲区 */

rknn_inputs_set(ctx, 1, inputs);
rknn_run(ctx, NULL);

rknn_output outputs[1] = {0};
outputs[0].want_float = 1;
rknn_outputs_get(ctx, 1, outputs, NULL);
/* 处理 outputs[0].buf，然后必须显式释放 */
rknn_outputs_release(ctx, 1, outputs);

rknn_outputs_get 之后忘记 rknn_outputs_release，是 NPU 集成中最常见的泄漏来源。在 demo 中跑几百帧不会暴露，在智慧屏上连续运行数小时后，内存耗尽会导致整个图形栈崩溃。此外，NPU 和 VPU 共享内存带宽，当 4K 硬解与 NPU 推理同时运行时，两者的帧率都可能下降。量产设计需要明确 NPU 推理的触发频率和优先级：例如只在检测到画面变化时触发推理，而不是每一帧都跑；推理任务使用独立的线程和受控的缓冲区池，避免与视频解码路径竞争 DMA-BUF 分配。

收束

嵌入式 Linux 智慧屏的量产难点，很少落在“某个功能能不能实现”上。GStreamer 能播视频，systemd-analyze 能看启动耗时，RKNN 能跑推理，这些在原型阶段都已经验证过了。真正把项目拖住的是原型中那些“能跑就行”的临时决策在量产约束下失效：用 videoconvert 规避了零拷贝的复杂性，用单 kmssink 规避了图层仲裁，用 demo 脚本规避了 NPU 的资源管理。跨越这些断层的办法不是引入更多框架，而是在架构阶段就把显示所有权、启动预算和推理生命周期作为一等约束纳入设计，让“能跑”从一开始就走在“能交付”的路径上。