QMT 平台 subscribe_quote 行情订阅函数的运行机制与常见问题

关于 QMT 平台中 subscribe_quote 订阅函数的运行机制，以下是针对您两个问题的详细解答：

1. 策略多次启停后的订阅数量

回答：是的，最后一次启动时，依然是订阅了 10 个。

原理解析：

• 生命周期管理：在 QMT 平台中，策略的运行是有生命周期的。当您点击“停止”策略时，平台底层会自动清理该策略在运行期间申请的资源，包括通过 subscribe_quote 发起的行情订阅。
• 重新启动：当您再次点击“启动”时，策略会重新从 init 函数开始执行，重新发起那 10 个标的的订阅请求。
• 最佳实践：虽然平台会自动清理，但为了代码的健壮性，建议您在策略的 stop(ContextInfo) 函数中，显式调用 unsubscribe_quote(subId) 来反订阅，或者使用 ContextInfo.get_all_subscription() 检查当前订阅状态。

2. 多策略并发订阅的数量计算

回答：从策略逻辑层面来看，是的，发起了 100 次订阅请求；但从底层网络请求来看，QMT 会进行去重优化。

原理解析：

• 逻辑层面（100个）：如果您启动了 10 个独立的策略，每个策略代码里都写了订阅 10 个标的，那么这 10 个策略确实各自维护了 10 个订阅回调，总计 100 个逻辑订阅。
• 底层优化（去重机制）：QMT 的底层 C++ 核心对行情数据有统一的调度和分发机制。如果这 10 个策略订阅的标的有重复（例如都订阅了 000300.SH），QMT 底层只会向行情服务器发起一次网络请求。当该标的的数据到达本地后，QMT 会将数据分发给所有订阅了该标的的策略的回调函数（callback）。
• 性能影响：如果订阅的是 100 个完全不同的标的，那么底层确实会维护 100 个标的的行情推送。只要您的电脑性能和网络带宽允许，100 个标的的 tick 级别推送在 QMT 中是完全可以轻松处理的。

补充：相关 API 用法回顾

如果您需要管理订阅，可以使用以下 API：

• 订阅：subId = ContextInfo.subscribe_quote(stock_code, period, dividend_type, callback)
• 反订阅：ContextInfo.unsubscribe_quote(subId)
• 查看所有订阅：ContextInfo.get_all_subscription() 返回当前所有的行情订阅信息字典。