v2.4.7 (Build 26J01)

JadeView 2.4.7 修掉两类「看起来没反应」的问题：在 jade.invoke 回调或事件回调里调用退出接口会卡住不返回；页面跑在 https 站点上时，jade 通讯（invoke、事件、大文件分片）全部失效。

退出流程 修复

• 修复在 jade.invoke 回调或事件回调里调用 jadeview_exit() 退不出去。 宿主回调是在 JadeView 的内部工作线程上执行的，而退出收尾原本会等待这些工作线程结束，等于线程在等自己结束，一直卡到超时后返回失败，宿主看到的就是「调了退出但没反应」。现在识别到这种情况会立即返回，收尾改到独立线程完成，窗口与线程在后台清理干净。
• 顺带加固：任何路径下收尾都不会再去等待当前线程自己，避免以后新增的回调场景再踩同一个坑。

前端通讯 修复

• 修复页面跑在 https 站点上时 jade 通讯全部失效。 Windows 上自定义协议无法真正注册，JadeView 的请求实际走的是 http://jade.<应用签名>/... 这种伪装地址；在 https 页面里这类请求会被浏览器自动升级成 https，从而绕过 JadeView 的拦截、发到真实网络，表现为 invoke、事件推送、大文件分片传输全部没有响应。现在协议固定为 https 形式，请求协议与 https 页面一致，不会被升级，也不会被当作混合内容拦截。
• 桥接请求地址改为固定写法，不再跟随页面协议。 此前写成跟随页面协议的形式，页面是 http 时会解析成 http 地址、同样匹配不到拦截规则；现在统一解析到 https 地址，本地页面、http 站点、https 站点三种情况下都能命中。
• 页面内引用 https://jade.<应用签名>/... 的本地资源（窗口图标等）仍按本地资源解析，不会误判成远程地址去联网下载。
• 自定义协议现在以 https 形式提供，页面属于安全上下文。 创建窗口、页面跳转时传 https://jade.<应用签名>/index.html 与传 JADE://<应用签名> 等价，前端里直接引用 https://jade.<应用签名>/... 的资源同样命中本地服务。请求在发出前就被拦截，不走真实网络，也不涉及证书。
• 用 https 形式地址创建的窗口现在能被正确识别为本地页面。 此前本地页面识别只认 jade<应用签名> 这一种写法，用 https 形式地址建窗口时会被当成外部站点，PostMessage 要走来源白名单；现在两种写法都能识别。
• 协议域段改为 <应用签名>.v。 此前域段就是应用签名本身，Windows 上会被伪装成 https://jade.<应用签名>；如果签名正好撞上一个真实域名（例如签名 run → jade.run），页面里访问该域名的资源会被本地处理器截走。加上 .v 后缀后落在不存在的域名空间，功能不受影响。
• 签名里的中文等非 ASCII 字符会做 URL 编码后再拼进地址，此前直接拼进 URL 会导致地址解析失败（本地页面识别失灵、页面来源判断不准）。

兼容性提示

• 本地页面的来源由 http://jade.<应用签名> 变为 https://jade.<应用签名>.v。 宿主或前端里若硬编码了这类地址，需要一并更新；推荐只使用 set_protocol_service_path 返回的 JADE://<域段> 地址，由底层负责转换。
• 本地页面不需要写进通讯来源白名单。 本地页面自己发出的请求与页面地址同源，浏览器不会带来源头，来源检查直接放行；PostMessage 一侧对本地页面同样是直接放行、不看白名单。白名单只用于远程站点页面跨源调用本库接口的场景，本次改动不影响，也无需把自定义协议地址加进去。
• 页面本身是 http（例如本地开发服务器）不受影响：http 页面中加载 https 子资源是允许的。

平台说明

• 本次协议调整只涉及 Windows —— 自定义协议在该平台上必须走伪装地址；Linux 使用原生 jade:// 协议，行为不变。