关于订阅函数 subscribe_quote
有几个问题：
1. 一个策略，订阅10个，启动--停止--启动--停止--启动，最后一次是订阅了几个？10个吗
2. 如果每个策略都是订阅10个，是不是意味着，启动10个策的话就是100个？
问题描述
解决方案
关于 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()返回当前所有的行情订阅信息字典。