香橙派RK3588双路视觉方案：线程池与NPU上下文隔离实战

1. 双路视觉方案的整体设计思路

1.1 为什么要在香橙派RK3588上做双路视觉

单路摄像头跑yolov5s，在RK3588上其实已经能跑得比较舒服了。RK3588自带NPU，算力标称6TOPS，yolov5s这种体量的模型量化成INT8之后，单路1080p输入做到30帧以上并不难。但真正到了项目落地阶段，单路往往不够用——比如做立体视觉、双目测距、多角度监控、前后景同时分析，都需要两路摄像头同时工作。

问题就出在这里。很多人第一次做双路方案，直接把单路代码复制一份，开两个进程或者两个线程，结果发现帧率直接腰斩，甚至掉到个位数。原因不复杂：两路视觉任务在CPU侧要做的事情太多了——图像采集、格式转换、缩放、推理前处理、后处理画框、编码推流，这些如果全挤在一起抢资源，RK3588的8核A76/A55也扛不住。

所以这个项目的核心不是“怎么再跑一路”，而是“怎么让两路互不干扰地跑”。我最终采用的方案是：每路视觉任务独立一个线程池，两路之间通过资源隔离和任务队列解耦。这个思路听起来简单，但里面有不少细节值得展开讲。

1.2 线程池方案选型的背后考量

为什么用线程池，而不是简单的多线程或者多进程？

先说多进程。多进程的好处是隔离彻底，一路崩了不影响另一路。但RK3588的NPU资源是共享的，多进程同时调用RKNN的NPU接口，上下文切换和内存拷贝的开销会明显上升。而且多进程之间传递图像数据要走共享内存或者管道，1080p的RGB帧一帧就是6MB左右，两路30帧就是360MB/s的数据量，这个拷贝成本在嵌入式平台上很致命。

再说裸多线程。每路开固定的几个线程，比如采集一个、推理一个、后处理一个，看起来也行。但问题是每路任务的处理耗时是波动的——NPU推理有时候快有时候慢，后处理画框的耗时也跟检测到的目标数量有关。如果线程之间用简单的队列通信，队列一满就阻塞，阻塞就会拖慢整条流水线。

线程池的好处在于任务和线程解耦。我把每路视觉任务拆成若干个可独立执行的任务单元，扔进该路专属的线程池队列里，线程池自己调度。这样即使某一帧的推理慢了，后续的采集任务也不会被卡死，因为线程池里还有其他线程在跑。而且线程池的队列可以设置容量和拒绝策略，相当于给系统加了一个缓冲带。

注意：这里说的“两路各一个线程池”，不是两个线程池共用一个队列，而是每路完全独立。这一点很关键，后面会详细说为什么。

1.3 两路独立线程池的架构拆解

整个方案的数据流是这样的：

• 第1路：MIPI摄像头采集 → 图像预处理 → NPU推理 → 后处理 → 显示/推流
• 第2路：USB摄像头采集 → 图像预处理 → NPU推理 → 后处理 → 显示/推流

每一路内部，我把任务分成三类：采集任务、推理任务、后处理任务。这三类任务都提交到该路自己的线程池里执行。线程池的线程数量根据任务类型动态调整——采集任务IO密集，线程可以少一点；推理任务吃NPU，线程数要跟NPU的并行能力匹配；后处理任务吃CPU，线程可以适当多一点。

两路之间唯一的共享资源是NPU。RK3588的NPU虽然只有一个，但RKNN的运行时支持多上下文。我的做法是给每一路创建一个独立的RKNN上下文，而不是共用一个。这样两路的推理请求在NPU驱动层会排队，但不会互相踩内存。实测下来，两路同时推理的NPU利用率大概在70%到80%之间，还有余量。

2. 线程池的核心参数与配置细节

2.1 线程池大小的确定方法

线程池开多少个线程，这个问题没有标准答案，但有一个靠谱的估算方法。

对于采集任务，它大部分时间在等IO，属于IO密集型。IO密集型任务的线程数可以设为2 * CPU核心数。RK3588有8个核，但实际可用的大核是4个A76加4个A55。采集任务我建议跑在A55小核上，线程数设4到6个就够了。因为MIPI和USB的采集带宽是有限的，开太多线程反而增加上下文切换开销。

对于推理任务，它吃的是NPU，不是CPU。线程数应该跟NPU的并行推理能力匹配。RK3588的NPU支持多核并行，但yolov5s这个体量的模型，单次推理大概占用NPU的一个核心。我实测下来，推理线程数设为2比较合适——一路一个，两路各一个，正好把NPU的两个核心用满。如果设成4个，反而会因为NPU内部调度导致单次推理延迟上升。

对于后处理任务，它纯粹吃CPU，属于计算密集型。计算密集型任务的线程数应该等于CPU核心数。但后处理任务只在推理完成后才触发，不是持续满载，所以线程数可以适当少一点。我设的是每路3个后处理线程，两路一共6个，加上采集和推理线程，总线程数控制在16个以内，对RK3588来说压力不大。

下面这张表是我实际测试后确定的参数，可以直接参考：

2.2 阻塞队列的选择与容量计算

线程池的阻塞队列选什么类型，直接决定了系统的抗压能力。

Java的ThreadPoolExecutor提供了几种队列：ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue、PriorityBlockingQueue。在嵌入式视觉场景下，我推荐用有界队列，具体来说是ArrayBlockingQueue或者LinkedBlockingQueue带容量限制。

为什么不用无界队列？因为无界队列在任务积压时会无限增长，最后把内存吃光。RK3588的开发板通常只有4GB或8GB内存，1080p的帧数据一帧6MB，队列里积压100帧就是600MB，两路加起来直接爆内存。所以队列必须有界。

队列容量怎么算？以采集任务为例，采集帧率是30fps，推理帧率假设是20fps，那么每秒会有10帧的差距。如果我希望系统能缓冲2秒的波动，队列容量就是10 * 2 = 20。但实际我不需要缓冲这么久，因为丢弃旧帧比延迟处理更合理——视觉任务里，过期的帧没有意义。所以我把采集队列容量设为8，大概缓冲0.27秒，超过就丢弃最旧的帧。

推理队列容量设为4，因为推理是瓶颈，队列太长只会增加延迟。后处理队列设为16，因为后处理速度快，可以多缓冲一些。

提示：队列的拒绝策略一定要显式设置。默认的AbortPolicy会抛异常，在视觉流水线里抛异常会导致整路崩溃。我用的自定义策略是：采集队列满了就丢弃队列头部的旧帧，推理队列满了就阻塞等待，后处理队列满了也丢弃旧帧。

2.3 线程工厂与命名规范

这个细节很多人忽略，但在调试双路方案时特别有用。

默认的线程工厂创建的线程名字是pool-1-thread-1这种，两路混在一起根本分不清哪个线程属于哪一路。我的做法是自定义ThreadFactory，给每路的线程加上前缀。比如第1路的采集线程叫cam1-capture-1，第2路的推理线程叫cam2-infer-1。

这样在top -H或者htop里看线程CPU占用时，一眼就能定位到是哪一路的哪个环节在吃CPU。调试的时候省了太多时间。

另外，线程的优先级也值得设置。推理线程的优先级可以稍微高一点，因为NPU推理是流水线的关键路径。采集线程优先级低一点，丢几帧没关系。后处理线程优先级中等。

3. 双路视觉的实操过程与核心环节

3.1 环境准备与依赖确认

在开始写代码之前，先把环境确认一遍。我用的系统是Ubuntu 20.04，内核版本5.10，这是RK3588比较稳定的一个组合。NPU驱动用的是RKNN-Toolkit2对应的运行时库，版本1.5.0以上。

需要确认的几个点：

• NPU驱动是否加载：ls /dev/rknpu*，应该能看到/dev/rknpu设备节点。
• RKNN运行时库是否安装：ldconfig -p | grep rknn，应该能看到librknnrt.so。
• OpenCV是否支持MIPI摄像头：v4l2-ctl --list-devices，确认/dev/video0和/dev/video1都在。
• 线程池用的语言是C++，我用的标准是C++17，因为要用到std::future和std::packaged_task。

如果NPU驱动没加载，需要先加载驱动模块。如果RKNN运行时库版本不对，推理会直接报错。这些基础环境问题不解决，后面写再多代码也没用。

3.2 每路线程池的初始化代码

下面是我实际用的线程池初始化代码，基于C++17的标准库实现。先看第1路的初始化：

#include <thread> #include <vector> #include <queue> #include <mutex> #include <condition_variable> #include <functional> #include <future> class VisionThreadPool { public: VisionThreadPool(size_t capture_threads, size_t infer_threads, size_t post_threads, const std::string& prefix) : stop_(false), prefix_(prefix) { // 采集线程池 for (size_t i = 0; i < capture_threads; ++i) { workers_.emplace_back([this, i] { std::string name = prefix_ + "-capture-" + std::to_string(i); pthread_setname_np(pthread_self(), name.c_str()); capture_worker(); }); } // 推理线程池 for (size_t i = 0; i < infer_threads; ++i) { workers_.emplace_back([this, i] { std::string name = prefix_ + "-infer-" + std::to_string(i); pthread_setname_np(pthread_self(), name.c_str()); infer_worker(); }); } // 后处理线程池 for (size_t i = 0; i < post_threads; ++i) { workers_.emplace_back([this, i] { std::string name = prefix_ + "-post-" + std::to_string(i); pthread_setname_np(pthread_self(), name.c_str()); post_worker(); }); } } // 提交采集任务 template<typename F> auto submit_capture(F&& f) -> std::future<decltype(f())> { return submit_to_queue(capture_queue_, capture_mutex_, capture_cv_, std::forward<F>(f)); } // 提交推理任务 template<typename F> auto submit_infer(F&& f) -> std::future<decltype(f())> { return submit_to_queue(infer_queue_, infer_mutex_, infer_cv_, std::forward<F>(f)); } // 提交后处理任务 template<typename F> auto submit_post(F&& f) -> std::future<decltype(f())> { return submit_to_queue(post_queue_, post_mutex_, post_cv_, std::forward<F>(f)); } private: std::vector<std::thread> workers_; std::queue<std::function<void()>> capture_queue_; std::queue<std::function<void()>> infer_queue_; std::queue<std::function<void()>> post_queue_; std::mutex capture_mutex_, infer_mutex_, post_mutex_; std::condition_variable capture_cv_, infer_cv_, post_cv_; std::atomic<bool> stop_; std::string prefix_; void capture_worker() { while (!stop_) { std::function<void()> task; { std::unique_lock<std::mutex> lock(capture_mutex_); capture_cv_.wait(lock, [this] { return stop_ || !capture_queue_.empty(); }); if (stop_ && capture_queue_.empty()) return; task = std::move(capture_queue_.front()); capture_queue_.pop(); } task(); } } // infer_worker 和 post_worker 结构类似，省略 };

这段代码的关键点在于：每类任务有独立的队列和条件变量。采集任务不会因为推理队列满而被阻塞，推理任务也不会因为后处理慢而卡住。三个队列之间通过任务提交的顺序来保证流水线逻辑。

第2路的初始化完全一样，只是prefix改成cam2。两路线程池对象互相独立，互不干扰。

3.3 两路数据流的串联与NPU上下文隔离

线程池初始化好之后，接下来要把数据流串起来。

第1路的流程是：采集线程从MIPI摄像头读一帧，提交一个推理任务到推理队列；推理线程从队列取出帧，调用RKNN推理，推理完成后提交一个后处理任务到后处理队列；后处理线程画框、编码、推流。

第2路同理，只是摄像头换成了USB。

这里有一个关键细节：两路的RKNN上下文必须独立。RKNN的rknn_init函数会创建一个上下文，如果两路共用一个上下文，推理时会互相干扰。我的做法是每路在初始化时各自调用一次rknn_init，得到两个独立的rknn_context。

// 第1路初始化 rknn_context ctx1; int ret1 = rknn_init(&ctx1, model_data, model_size, 0, nullptr); // 第2路初始化 rknn_context ctx2; int ret2 = rknn_init(&ctx2, model_data, model_size, 0, nullptr);

两个上下文各自绑定到各自的推理线程。实测下来，两路同时推理时，NPU的利用率在75%左右，单路推理延迟从单路时的25ms上升到35ms左右，但两路总吞吐量接近单路的1.7倍。这个表现是可以接受的。

注意：如果发现两路推理时NPU利用率上不去，或者延迟飙升，大概率是RKNN运行时库的版本问题。建议用1.5.0以上的版本，对多上下文支持更好。

4. 常见问题与排查技巧实录

4.1 帧率上不去、CPU占用飙高的排查思路

这是双路方案最常见的问题。表现是：单路跑得好好的，加了第二路之后，两路帧率都掉到10帧以下，top一看CPU占用接近100%。

排查顺序是这样的：

第一步，先看是不是采集环节的问题。用v4l2-ctl --stream-mmap --stream-count=100单独测试每个摄像头，看采集帧率是否正常。如果采集本身就慢，那跟线程池没关系，是摄像头驱动或者USB带宽的问题。

第二步，看是不是NPU推理排队太严重。在推理线程里加日志，打印每次推理的耗时。如果单次推理耗时超过50ms，说明NPU在排队。这时候要检查是不是两路共用了RKNN上下文，或者NPU驱动版本不对。

第三步，看是不是后处理太慢。后处理里如果有画框、缩放、编码这些操作，很容易吃满CPU。我遇到过一种情况：后处理里用了OpenCV的cv::resize把1080p缩放到640p，单次耗时8ms，两路30帧就是480ms/s的CPU时间，直接吃掉半个核。后来改成用RGA硬件缩放，耗时降到1ms以内。

第四步，看线程池的队列是不是积压了。如果采集队列一直满，说明推理跟不上；如果推理队列一直满，说明后处理跟不上。根据积压的位置定位瓶颈。

下面这张表是我整理的问题速查表：

4.2 线程池队列积压与内存泄漏的坑

队列积压这个问题，我在第一次做双路方案时踩得很惨。

当时用的是无界队列，跑了一个小时之后，开发板直接卡死。用free -m一看，内存只剩几十MB。原因是第2路的USB摄像头偶尔会掉帧，采集线程疯狂往队列里塞任务，推理线程处理不过来，队列越积越长，每个任务里都持有一帧图像数据，内存就这么被吃光了。

后来改成有界队列，并且加了拒绝策略。采集队列满了就丢弃最旧的帧，这样内存占用就稳定了。但这里还有一个坑：丢弃帧的时候要确保帧数据被正确释放。如果帧数据是cv::Mat，它自带引用计数，丢弃时自动释放。但如果用的是裸指针或者malloc的内存，就必须手动free，否则就是内存泄漏。

我的做法是统一用std::shared_ptr<cv::Mat>来传递帧数据，这样无论队列怎么丢弃，内存都会被正确回收。

提示：在嵌入式平台上，任何手动管理的内存都要格外小心。能用智能指针就用智能指针，能不用裸指针就不用。

4.3 NPU推理偶发失败的定位方法

两路同时推理时，偶尔会出现推理失败，返回错误码。这个问题的定位比较麻烦，因为不是必现。

我的排查步骤是：

先确认错误码。RKNN的错误码在rknn_api.h里有定义，比如RKNN_ERR_DEVICE_UNAVAILABLE表示设备不可用，RKNN_ERR_TIMEOUT表示超时。根据错误码缩小范围。

如果是RKNN_ERR_DEVICE_UNAVAILABLE，通常是NPU驱动的问题。检查dmesg里有没有NPU相关的报错。我遇到过一种情况：两路推理的并发请求太多，NPU驱动的请求队列溢出，导致部分请求被拒绝。解决办法是在推理线程里加一个信号量，限制同时提交给NPU的请求数量不超过2个。

如果是RKNN_ERR_TIMEOUT，说明推理超时。这时候要检查是不是某一帧的图像数据有问题，比如尺寸不对、格式不对。RKNN对输入数据的尺寸和格式很敏感，如果前处理没做好，推理就会失败。

还有一种情况是内存不足。RK3588的NPU有自己的内存池，如果两路同时推理，内存池可能不够用。这时候需要调整RKNN的内存配置，或者降低输入分辨率。

4.4 双路方案的实际性能数据与调优建议

最后分享一下我实测的性能数据，供参考。

测试条件：RK3588开发板，8GB内存，Ubuntu 20.04，yolov5s INT8量化模型，输入640x640。

从数据可以看出，双路方案下每路帧率大概是单路的60%到70%，这个损耗主要来自NPU的排队和CPU的上下文切换。如果对帧率要求高，可以考虑把输入分辨率降到416x416，帧率能提升30%左右。

调优建议就三条：第一，能用硬件加速的环节（缩放、编码）尽量用RGA和VPU，别用CPU硬扛；第二，队列容量宁小勿大，视觉任务里旧帧没有价值；第三，推理线程数不要超过NPU的并行能力，多了反而添乱。

我个人在实际操作中的体会是，双路视觉方案的核心难点不在“怎么跑起来”，而在“怎么跑得稳”。线程池只是一个工具，真正决定系统稳定性的是对资源瓶颈的准确判断和合理的任务拆分。把采集、推理、后处理这三段解耦开，每段独立调度，系统就有了缓冲的余地。这个思路不仅适用于RK3588，换到其他嵌入式平台也一样管用。