• 怎么才能让循环更稳定，控制更多的资源和状态？

那么，提升稳定性的一个重要的工作，就是当服务(机器人)发生意外时，能及时的通知运维(开发者/用户)查看问题，进行操作。

就是当机器停顿，无法继续，甚至ID死亡时，以方便的手段通知用户，记录问题现场，恢复程序执行。

这也是一个标准的运维工作。

所以我建议参考现在主流的运维工作流程。

邮件形式

Hellclient最早是支持嵌入STMP信息，提供了内建方法可以发送电子邮件。

但在实际使用时，基本处于被废弃状态。

因为现在主流的运维通知终端是手机，安卓或者iOS。

邮件通知在手机上面临了一下问题

• 手机设备上，邮件客户端无法保证后台常驻，实时性往往有很大问题。
• 邮件客户端又有各种实现，对于链接的处理形式不同，无法保证唤起我的APP端。
• 邮件的安全级别很高，所有各个邮件服务器的安全设置很复杂，对用户并不友好。

通知服务

我的Hellclient UI项目曾经实通过腾讯推送实现过原生的推送功能。

但现在这个功能已经被废弃了。

通知服务会涉及到几个难点

• 用户识别问题。安卓客户端还能自行申请推送服务，iOS不现实，发布时就绑定应用ID。
• 保活问题。对于国内环境，国产安卓是绕不过去的槛。各种手机的保护和续航是很麻烦的点，只是做一个mud相关的app没法投入这么多精力去处理

这写严重的问题随着新的方案出现，对于Hellclient UI项目属于验证的得不偿失，所以废弃了这个功能。

Webhook

目前的运维主流的通知手段其实还是webhook的形式。

就是在各种工作流软件中，会提供一个标准的，地址带身份验证token的http接口。

主要对这个接口发送特殊格式的内容，就会通过服务器向对应的手机APP发送一条通知。

处于这个通知的专用型，一般都能确保拉起手机中注册过的APP直接处理。

可以说完美的适合了Mud机器人，作为一个标准意义上的服务的运维要求。

而且webhook形式的要求最低，基本不需要客户端做特殊支持，只要提供标准的HTTP接口和JSON支持就可以了。

国内比较常见的Webhook供应商为

• 企业微信
• 钉钉
• 飞书

国外知名的有

• Slack

根据我自己的使用体验和经验，我的机器人使用的飞书通知。目前使用体验良好。

如果不喜欢单独安装App的话，也可以考虑使用企业微信。企业微信可以绑定到微信内，我个人有其他业务是使用企业微信通知的。