1. 从“窗口存在”到“角色在线”为什么简单的进程检测不够用很多刚接触易语言配合大漠插件做自动化辅助的朋友第一个想到的判断在线方法就是查进程。打开任务管理器看到游戏进程还在就认为角色在线脚本继续跑进程没了就认为掉线了。这个思路在单开、短时间挂机的场景下勉强能用但只要稍微复杂一点问题立刻暴露出来。我最早做的一个小工具就是栽在这上面的。当时逻辑很简单进程_是否存在(game.exe)返回真就继续执行打怪流程返回假就弹窗提示。结果有一次网络波动游戏客户端进程还在但角色已经被踢回登录界面了。脚本对着登录界面疯狂点击“开始游戏”按钮的位置因为那个坐标恰好是登录按钮反而误打误撞重新登录进去了但更多时候是点在了空白处白白浪费几个小时。更隐蔽的情况是游戏进入了“断线重连”的转圈界面进程活着窗口也在但角色根本不在游戏世界里这时候任何基于游戏内坐标的操作都是无效的。所以判断“在线”这件事本质上要区分三个层次进程层、窗口层、角色层。进程层只能说明客户端启动了窗口层能说明游戏窗口没被关闭只有角色层才能确认你的角色真正站在地图上、可以接受操作。大漠插件之所以在这个场景里被广泛使用就是因为它提供了从窗口句柄到图色识别的完整能力链让你能从最表面的进程检测一路深入到像素级的在线状态确认。这篇文章面向的是已经会用易语言写基本逻辑、也听说过大漠插件但还没系统用过它做状态判断的开发者。我会把从找窗口、绑窗口到用图色和字库判断角色是否在线这条链路完整拆开重点讲清楚每一步为什么这么做、参数怎么调、遇到异常怎么排查。所有代码和思路都基于易语言加大漠插件的常见实践你可以直接对照着自己的项目改。2. 大漠插件在易语言里的注册与基础对象创建2.1 为什么必须先注册插件而不是直接创建对象大漠插件是一个COM组件易语言要调用它第一步不是创建对象而是注册。这个顺序很多人会搞反导致后面所有调用都返回空或者直接报错。注册的本质是把插件的类型库信息写入系统让易语言的COM机制能够找到这个组件。你可以把它理解成“先给系统发一张名片告诉它有这么个东西存在”之后才能凭这张名片去创建实例。注册命令本身很简单但有几个细节决定了后续能不能稳定运行。第一个是插件文件的位置。我习惯把dm.dll放在易语言程序的运行目录下然后用相对路径注册。这样打包发给别人的时候整个文件夹拷过去就能用不会因为绝对路径变化而失效。第二个是注册的返回值判断。很多人写完注册命令就直接往下走不检查返回值结果插件没注册成功后面创建对象失败排查半天找不到原因。.版本 2 .支持库 spec .子程序 初始化大漠, 逻辑型 .局部变量 注册结果, 逻辑型 .局部变量 dm, 对象 注册结果 注册插件 (取运行目录 () “\dm.dll”, 真) .如果真 (注册结果 假) 信息框 (“大漠插件注册失败请检查dm.dll是否存在”, 0, , ) 返回 (假) .如果真结束 dm 创建对象 (“dm.dmsoft”, ) .如果真 (dm 空) 信息框 (“大漠对象创建失败可能是系统权限或插件版本问题”, 0, , ) 返回 (假) .如果真结束 返回 (真)注意注册插件时第二个参数填真表示强制重新注册。如果你在调试过程中换了不同版本的大漠插件一定要用真否则系统可能还在用旧版本的缓存信息导致新版本的功能调用异常。2.2 对象创建后的版本确认与权限设置对象创建成功不代表就能直接干活了。我习惯在初始化阶段加一步版本确认调用dm.Ver()拿到插件版本号打印到调试输出里。这一步看起来多余但在多台机器部署时非常有用。有一次我在开发机上一切正常换到另一台机器上死活绑不上窗口最后发现是那台机器上残留了一个很老版本的大漠插件注册时被优先加载了。版本号一对比问题立刻定位。权限设置是另一个容易被忽略的点。大漠的很多操作尤其是涉及窗口绑定和后台键鼠的需要插件有足够的权限。dm.SetDisplayInput和dm.SetKeypadDelay这类设置虽然不直接决定在线判断但会影响后续操作的稳定性。我的习惯是在初始化阶段统一设置好避免在业务逻辑里到处写设置代码。.子程序 配置大漠基础参数, , , 初始化时调用一次 .局部变量 版本号, 文本型 版本号 dm.Ver () 调试输出 (“当前大漠插件版本” 版本号) 设置键盘鼠标的模拟方式0为硬件模拟1为软件模拟 在线判断阶段用不到键鼠但提前设好避免后续切换 dm.SetKeypadDelay (“normal”, 30) dm.SetMouseDelay (“normal”, 30) 设置图色识别的默认超时时间单位毫秒 dm.SetDict (0, “”) 先清空字库后面按需加载这里有个经验SetKeypadDelay和SetMouseDelay的参数不要设得太小。我见过有人为了追求速度设成5毫秒结果在配置差一点的机器上按键消息还没被游戏窗口处理完下一个操作就发出去了导致操作丢失。30毫秒是一个比较稳妥的起点具体可以根据目标程序的响应速度微调。3. 窗口查找与绑定在线判断的前置条件3.1 用类名和标题组合定位游戏窗口大漠的窗口查找命令有好几个最常用的是FindWindow和FindWindowEx。FindWindow按类名和标题查找顶层窗口FindWindowEx可以在指定父窗口下查找子窗口。对于游戏来说通常用FindWindow就够了因为游戏主窗口一般是顶层窗口。关键问题在于类名和标题怎么填。类名是Windows给窗口分的类别比如“Notepad”是记事本的类名。游戏窗口的类名通常比较特殊比如某些引擎会用“UnityWndClass”或者自定义的字符串。标题就是窗口标题栏上显示的文字。我的做法是先用一个窗口探测工具比如系统自带的Spy或者大漠自带的工具拿到准确的类名和标题然后再填到代码里。.子程序 查找游戏窗口, 整数型 .局部变量 窗口句柄, 整数型 方式一类名标题精确查找 窗口句柄 dm.FindWindow (“UnityWndClass”, “某游戏窗口标题”) .如果真 (窗口句柄 0) 方式二只用类名查找标题用空字符串匹配任意 窗口句柄 dm.FindWindow (“UnityWndClass”, “”) .如果真结束 .如果真 (窗口句柄 0) 方式三遍历所有窗口用标题关键字模糊匹配 窗口句柄 dm.FindWindowByProcess (“game.exe”, “”, “”, 0) .如果真结束 返回 (窗口句柄)这里要强调一个坑不要用标题做唯一匹配条件。很多游戏的窗口标题会动态变化比如带上当前地图名、角色等级或者在线时长。你今天用“某游戏 - 主城”能匹配到明天角色去了野外标题变成“某游戏 - 野外”你的查找就失败了。类名相对稳定优先用类名如果类名也找不到再用进程名去反查窗口。3.2 绑定模式的选择与在线判断的关系找到窗口句柄之后必须绑定才能进行图色操作。大漠的绑定命令是BindWindow参数包括窗口句柄、显示模式、鼠标模式、键盘模式和附加模式。绑定模式的选择直接影响到你后面能不能正常截图和找图。对于在线判断这个场景我推荐用dx系列模式比如dx.graphic.3d或dx.graphic.2d因为大多数游戏用的是DirectX渲染用GDI模式截图可能会得到黑屏或者花屏。但dx模式对系统和显卡驱动有一定要求如果绑定失败可以降级到gdi模式试试。.子程序 绑定游戏窗口, 逻辑型 .参数 窗口句柄, 整数型 .局部变量 绑定结果, 整数型 尝试dx模式绑定 绑定结果 dm.BindWindow (窗口句柄, “dx.graphic.3d”, “windows”, “windows”, 0) .如果真 (绑定结果 0) dx失败降级到gdi模式 绑定结果 dm.BindWindow (窗口句柄, “gdi”, “windows”, “windows”, 0) .如果真结束 .如果真 (绑定结果 0) 调试输出 (“窗口绑定失败错误码” 到文本 (dm.GetLastError ())) 返回 (假) .如果真结束 返回 (真)绑定成功后建议立刻做一次截图测试确认能拿到正常的画面。dm.Capture或者dm.GetColor都可以。如果截出来是全黑或者全白说明绑定模式不对需要换模式重试。这个测试步骤花不了几秒钟但能避免后面所有图色判断都基于错误画面进行。提示绑定窗口后如果游戏窗口被最小化dx模式通常无法正常截图。如果你的脚本需要长时间运行建议在绑定前先检查窗口是否最小化如果是用dm.SetWindowState恢复窗口。或者改用支持后台截图的模式但后台模式的兼容性因游戏而异需要实测。4. 角色在线状态的多维度判断策略4.1 用特征色判断是否在游戏世界最直接的在线判断方法是在游戏画面的固定位置找一个“只有在线时才会出现”的颜色。比如很多游戏的血条、小地图边框、技能栏背景这些UI元素在登录界面和游戏世界里的颜色是不同的。你只需要在绑定窗口后用dm.GetColor取那个坐标的颜色和预设值对比即可。选特征点有几个原则。第一这个点的颜色要稳定不能是动态变化的。比如血条会随着血量变化就不能用血条中间的颜色但可以用血条外框的颜色。第二这个点要在所有地图、所有场景下都存在。小地图的某个固定角落通常是不错的选择。第三颜色值要取多个样本确认。我一般会在不同时间、不同地图下各取几次确保颜色值一致。.子程序 是否在游戏世界_颜色判断, 逻辑型 .局部变量 当前颜色, 文本型 .局部变量 基准颜色, 文本型 基准颜色 “1A2B3C” 这是提前取好的小地图边框颜色 当前颜色 dm.GetColor (100, 200) 假设小地图边框在(100,200) .如果真 (当前颜色 基准颜色) 返回 (真) .如果真结束 返回 (假)颜色判断的优点是速度快一次GetColor调用几乎不耗时。缺点是抗干扰能力弱。如果游戏更新了UI颜色变了判断就失效了。另外如果游戏有半透明效果或者动态光影同一个位置的颜色可能会有细微波动。这时候可以用dm.GetColorNum或者dm.CmpColor来做模糊匹配允许一定的颜色偏差。4.2 用找图判断关键UI是否存在比颜色更可靠的是找图。找图的逻辑是截取一小块“只有在线时才会出现”的UI图片作为模板然后在游戏画面的指定区域内搜索这个模板。找到了就说明在线找不到就说明不在线。模板图片的选择很关键。我通常选这几类一是游戏主界面的某个固定按钮比如“背包”图标二是小地图的某个特征图案三是角色血条旁边的等级数字。这些元素在登录界面和断线重连界面都不会出现。.子程序 是否在游戏世界_找图判断, 逻辑型 .局部变量 查找结果, 整数型 .局部变量 返回坐标, 文本型 在屏幕左上角区域查找背包图标 查找结果 dm.FindPic (0, 0, 800, 600, “背包图标.bmp”, “101010”, 0.9, 0, 返回坐标) .如果真 (查找结果 ≥ 0) 返回 (真) .如果真结束 返回 (假)FindPic的参数里相似度0.9是一个经验值。设得太高比如0.99游戏画面稍微有点压缩或者色彩偏差就找不到了设得太低比如0.7又容易把相似的图案误判为目标。我一般从0.85开始试如果经常找不到就降到0.8如果经常误判就升到0.95。偏色参数101010表示每个颜色通道允许的偏差对于大多数游戏画面够用了。找图的缺点是比颜色慢。一次FindPic在大区域里搜索可能要几十毫秒甚至上百毫秒。如果你的在线判断需要高频执行比如每秒一次建议把搜索区域缩小到最小必要范围或者先用颜色做快速筛选颜色通过了再找图确认。4.3 用字库识别判断是否在登录界面有时候反向判断更有效识别画面上有没有“登录”“开始游戏”“服务器列表”这些文字。如果识别到了说明角色不在线。大漠的字库功能就是干这个的。字库的建立需要先用大漠综合工具抓取文字点阵生成字库文件然后在代码里用dm.SetDict加载。这个过程稍微繁琐但一旦建好识别率很高。我通常只建几个关键词的字库比如“登录”“断开”“重连”不需要建全字库。.子程序 是否在登录界面, 逻辑型 .局部变量 识别结果, 文本型 dm.SetDict (0, “登录相关字库.txt”) 加载字库文件 识别结果 dm.Ocr (300, 400, 500, 500, “ffffff-000000”, 0.9) .如果真 (寻找文本 (识别结果, “登录”, , 假) ≠ -1) 返回 (真) .如果真结束 .如果真 (寻找文本 (识别结果, “重连”, , 假) ≠ -1) 返回 (真) .如果真结束 返回 (假)字库识别的颜色格式ffffff-000000表示文字是白色背景是黑色。实际游戏里文字颜色和背景千变万化需要根据具体情况调整。我的经验是先用大漠工具取色确定文字的主色调和背景色然后多截几张不同场景的图测试识别率。如果识别率不稳定可以尝试用dm.OcrEx或者调整相似度参数。4.4 组合判断把误判率压到最低单独用任何一种方法都有漏洞。颜色可能因为UI更新失效找图可能因为分辨率变化失败字库可能因为字体渲染差异识别错误。我的做法是把三种方法组合起来用“与”和“或”的逻辑做综合判断。具体策略是先用颜色做快速初筛如果颜色判断为“不在线”再用找图确认如果找图也找不到最后用字库识别登录界面文字。只有颜色、找图、字库三者都指向“不在线”时才最终判定为掉线。这样虽然多花了一点时间但误判率大幅降低。.子程序 综合判断是否在线, 逻辑型 .局部变量 颜色结果, 逻辑型 .局部变量 找图结果, 逻辑型 .局部变量 登录界面结果, 逻辑型 颜色结果 是否在游戏世界_颜色判断 () .如果真 (颜色结果 真) 返回 (真) 颜色通过直接认为在线 .如果真结束 找图结果 是否在游戏世界_找图判断 () .如果真 (找图结果 真) 返回 (真) 找图通过认为在线 .如果真结束 登录界面结果 是否在登录界面 () .如果真 (登录界面结果 真) 返回 (假) 明确识别到登录界面判定不在线 .如果真结束 三种方法都无法确认在线保守判定为不在线 返回 (假)这个组合逻辑的核心思想是宁可误判为掉线也不要误判为在线。因为误判为在线会导致脚本对着无效画面继续操作可能产生更严重的后果比如误点充值按钮。而误判为掉线最多是脚本停下来等你处理损失可控。5. 掉线后的处理流程与脚本恢复逻辑5.1 分级处理从重连到重启客户端检测到掉线只是第一步怎么处理才是完整方案。我的做法是分三级处理根据掉线的严重程度逐级升级。第一级是等待自动重连。很多游戏在短暂网络波动后会自己重连回游戏世界。检测到掉线后先等待10到15秒然后重新判断。如果恢复了脚本继续跑什么都不用做。这一级能解决大部分临时性掉线。第二级是模拟点击重连按钮。如果等待后还在登录界面用找图找到“重连”或“开始游戏”按钮模拟点击。点击后再等待几秒重新判断。这一级能解决客户端还在、只是需要手动确认的重连场景。第三级是重启游戏客户端。如果点击后仍然无法进入游戏世界说明客户端可能已经卡死或者崩溃了。这时候用dm.SendString或者系统命令关闭游戏进程然后重新启动客户端走完整的登录流程。这一级最重但也是最后的保障。.子程序 处理掉线, , , 检测到掉线后调用 .局部变量 等待次数, 整数型 .局部变量 重连按钮坐标, 文本型 第一级等待自动重连 .计次循环首 (3, 等待次数) 延时 (5000) .如果真 (综合判断是否在线 () 真) 返回 () 已恢复直接返回 .如果真结束 .计次循环尾 () 第二级尝试点击重连按钮 .如果真 (dm.FindPic (0, 0, 1024, 768, “重连按钮.bmp”, “101010”, 0.85, 0, 重连按钮坐标) ≥ 0) dm.MoveTo (取坐标X (重连按钮坐标), 取坐标Y (重连按钮坐标)) dm.LeftClick () 延时 (8000) .如果真 (综合判断是否在线 () 真) 返回 () .如果真结束 .如果真结束 第三级重启客户端 重启游戏客户端 ()5.2 重启客户端时的进程清理与启动参数重启客户端这一步有几个细节要注意。首先是进程清理要彻底。有些游戏关闭主窗口后后台还有残留进程直接启动新客户端会导致多开冲突或者登录失败。我通常用dm.SendString发送关闭命令然后循环检查进程是否还在如果超过一定时间还在就强制结束。.子程序 重启游戏客户端, , .局部变量 等待计数, 整数型 尝试正常关闭 dm.SendString (窗口句柄, “{ESC}”) 有些游戏按ESC会弹出退出确认 延时 (1000) 循环等待进程退出 .计次循环首 (10, 等待计数) .如果真 (进程_是否存在 (“game.exe”) 假) 跳出循环 () .如果真结束 延时 (1000) .计次循环尾 () 如果进程还在强制结束 .如果真 (进程_是否存在 (“game.exe”) 真) 进程_结束 (“game.exe”) 延时 (3000) .如果真结束 启动新客户端 运行 (取运行目录 () “\game.exe”, 假, ) 延时 (15000) 等待客户端启动完成 重新查找窗口并绑定 窗口句柄 查找游戏窗口 () .如果真 (窗口句柄 ≠ 0) 绑定游戏窗口 (窗口句柄) .如果真结束启动后的等待时间要根据游戏的实际启动速度调整。15秒是一个保守值有些大型游戏可能需要30秒甚至更久。我的做法是在启动后循环检测窗口是否出现而不是固定等待一个时间。这样既不会等太久浪费时间也不会因为等太短而绑定失败。5.3 记录掉线日志与频率控制掉线处理本身也要有日志记录。我习惯在每次检测到掉线时把时间、掉线前的操作、处理结果写到一个文本文件里。这样跑一段时间后可以分析掉线规律。比如是不是每到整点就掉线服务器定时维护或者是不是在特定地图容易掉线地图资源加载问题。频率控制也很重要。如果脚本在短时间内反复检测到掉线并重启客户端可能说明游戏本身有问题或者你的判断逻辑有误判。我设置了一个保护机制如果10分钟内掉线超过3次就停止脚本并弹窗提示而不是无限重启。这样避免因为误判导致客户端被反复重启反而触发游戏的安全机制。.子程序 记录掉线日志, , .局部变量 日志文件, 整数型 .局部变量 日志内容, 文本型 日志内容 到文本 (取现行时间 ()) “ 检测到掉线处理结果” 处理结果 #换行符 日志文件 打开文件 (取运行目录 () “\掉线日志.txt”, , ) 移到文件尾 (日志文件) 写出文本 (日志文件, 日志内容) 关闭文件 (日志文件)6. 实测中容易踩的坑与排查思路6.1 绑定成功但截图全黑显示模式与显卡兼容性这个问题我遇到过不止一次。BindWindow返回成功但Capture截出来的图全黑导致所有图色判断都失效。原因通常是显示模式选错了。dx.graphic.3d和dx.graphic.2d适用于大多数DirectX游戏但有些游戏用的是OpenGL或者Vulkan渲染这两种模式就截不到画面。排查方法是先用dm.GetColor取一个已知有颜色的坐标看看返回的颜色值是不是全零。如果是换gdi模式再试。如果gdi也黑试试dx.graphic.3d.window或者dx.graphic.2d.window这些带窗口后缀的模式。大漠的显示模式有十几种不同游戏适配不同没有万能选项只能逐个试。还有一个容易被忽略的点是显卡驱动。有些老机器的显卡驱动不支持某些DirectX特性导致dx模式绑定失败。这种情况下更新显卡驱动通常能解决。如果无法更新驱动就只能用gdi模式但gdi模式对后台窗口的支持较差可能需要保持窗口在前台。6.2 颜色判断时对时错动态光影与半透明UI颜色判断最怕的就是游戏画面有动态变化。比如某些游戏的角色血条有呼吸灯效果颜色会在两个值之间循环渐变或者小地图有半透明背景背后的场景颜色会透过来影响取色结果。解决这个问题的思路是选稳定的特征点。血条外框通常比血条内部稳定因为外框是固定颜色不随血量变化。小地图的边框比小地图内部稳定因为内部会显示地图内容。如果实在找不到完全稳定的点就用dm.CmpColor做范围匹配允许颜色在一定范围内波动。.子程序 颜色范围判断, 逻辑型 .参数 坐标X, 整数型 .参数 坐标Y, 整数型 .参数 基准颜色, 文本型 .参数 允许偏差, 整数型 .局部变量 当前颜色, 文本型 .局部变量 当前R, 整数型 .局部变量 当前G, 整数型 .局部变量 当前B, 整数型 .局部变量 基准R, 整数型 .局部变量 基准G, 整数型 .局部变量 基准B, 整数型 当前颜色 dm.GetColor (坐标X, 坐标Y) 当前R 十六到十 (取文本中间 (当前颜色, 1, 2)) 当前G 十六到十 (取文本中间 (当前颜色, 3, 2)) 当前B 十六到十 (取文本中间 (当前颜色, 5, 2)) 基准R 十六到十 (取文本中间 (基准颜色, 1, 2)) 基准G 十六到十 (取文本中间 (基准颜色, 3, 2)) 基准B 十六到十 (取文本中间 (基准颜色, 5, 2)) .如果真 (取绝对值 (当前R 基准R) ≤ 允许偏差 且 取绝对值 (当前G 基准G) ≤ 允许偏差 且 取绝对值 (当前B 基准B) ≤ 允许偏差) 返回 (真) .如果真结束 返回 (假)允许偏差设多少要看具体情况。如果画面压缩比较厉害偏差可能到20甚至30如果画面很清晰偏差5以内就够了。我的经验是从15开始试根据实际误判情况调整。6.3 找图相似度调不好模板质量比参数更重要很多人找图失败时第一反应是调相似度参数从0.9降到0.8再降到0.7结果误判越来越多。其实问题往往出在模板图片本身。模板图片如果截取时带了背景杂色或者分辨率和你实际运行时的分辨率不一致相似度再低也找不到。正确的做法是模板图片要干净、要匹配当前分辨率。截取模板时尽量选背景单一、图案清晰的区域。如果游戏支持多种分辨率最好为每种分辨率单独做模板或者用大漠的SetPicSize功能在运行时缩放模板。还有一个技巧是用FindPicEx代替FindPic。FindPicEx可以返回多个匹配结果你可以取相似度最高的那个而不是只要超过阈值就返回第一个。这样能减少误判。.子程序 找图并取最佳匹配, 逻辑型 .局部变量 查找结果, 文本型 .局部变量 结果数组, 文本型, , 0 .局部变量 最佳相似度, 双精度小数型 .局部变量 当前相似度, 双精度小数型 .局部变量 i, 整数型 查找结果 dm.FindPicEx (0, 0, 1024, 768, “背包图标.bmp”, “101010”, 0.8, 0) .如果真 (查找结果 “”) 返回 (假) .如果真结束 结果数组 分割文本 (查找结果, “|”, ) 最佳相似度 0 .计次循环首 (取数组成员数 (结果数组), i) 当前相似度 到数值 (取文本中间 (结果数组 [i], 寻找文本 (结果数组 [i], “,”, , 假) 1, 5)) .如果真 (当前相似度 最佳相似度) 最佳相似度 当前相似度 .如果真结束 .计次循环尾 () .如果真 (最佳相似度 ≥ 0.85) 返回 (真) .如果真结束 返回 (假)6.4 字库识别率低点阵提取与颜色过滤字库识别不准九成问题出在点阵提取环节。大漠综合工具提取点阵时如果背景色和文字色对比不明显提取出来的点阵就是一团糊识别率自然低。我的做法是先用取色工具确定文字的确切颜色和背景色然后在提取点阵时手动指定颜色范围。比如文字是纯白色FFFFFF背景是深蓝色000080那就把颜色过滤设成只保留白色附近的像素。这样提取出来的点阵干净识别率高。另外字库文件不要贪大。只建你实际需要识别的那些字字库越小识别越快越准。我见过有人建了几百个字的字库结果识别时经常把形近字搞混。其实在线判断只需要识别“登录”“重连”“断开”这几个关键词建十几个字的字库就够了。7. 性能优化与长时间运行的稳定性建议在线判断这个逻辑通常是在脚本主循环里周期性执行的。如果判断本身太慢会拖累整个脚本的节奏。我的优化思路是分级检测按需深入。具体来说主循环里每轮只做最快的颜色判断。颜色判断通过就继续执行游戏操作不通过才进入找图和字库的慢速判断。这样在绝大多数正常在线的情况下每轮只花一次GetColor的时间几乎不影响性能。只有疑似掉线时才做完整判断这时候多花几百毫秒是可以接受的。.子程序 主循环, , .局部变量 循环计数, 整数型 .判断循环首 (脚本运行中 真) 循环计数 循环计数 1 每轮快速颜色检测 .如果真 (是否在游戏世界_颜色判断 () 假) 颜色异常做完整判断 .如果真 (综合判断是否在线 () 假) 处理掉线 () .如果真结束 .如果真结束 每10轮做一次完整判断防止颜色判断长期误判 .如果真 (循环计数 10 0) .如果真 (综合判断是否在线 () 假) 处理掉线 () .如果真结束 .如果真结束 延时 (500) 主循环间隔500毫秒 .判断循环尾 ()长时间运行还要注意内存和句柄泄漏。大漠对象在创建后如果一直不释放长时间运行可能会占用越来越多资源。我的习惯是在脚本退出时调用dm.UnBindWindow解绑窗口然后释放对象。虽然易语言的垃圾回收最终会处理但显式释放更稳妥。另外如果脚本需要连续运行几天建议每隔几小时做一次“软重启”解绑窗口、重新查找窗口、重新绑定。这样能避免因为窗口句柄变化或者插件内部状态累积导致的问题。我有个脚本连续跑了72小时没重启后面就出现了截图越来越慢的情况加了定时软重启后就没再出现过。提示软重启的间隔不要太短太频繁的重绑定反而可能触发游戏的安全检测。我的经验是4到6小时一次比较合适具体可以根据游戏的检测严格程度调整。最后说一个关于判断频率的经验。在线判断不需要太频繁500毫秒到1秒一次足够了。判断太频繁不仅浪费CPU还可能因为截图操作过于密集而被游戏注意到。我一般设500毫秒既能在掉线后快速响应又不会给系统太大压力。如果游戏对截图特别敏感可以放宽到2秒一次掉线后最多晚2秒发现对大多数挂机场景来说完全可以接受。
