Jianfeng Zhang

Results 24 comments of Jianfeng Zhang

> 与现有的 deploy/docker/requirements.txt 定位重复 确实,但是这个requirements.txt有一个魔改的mxnet版本。如果docker下的requirements.txt能较新的包版本,我也可以把mxnet版本魔改成1.6.0,然后直接合并到一起? > alas 需要支持 win7,所以不能依赖系统 webview,python 版本 chromium 版本也有限制 mac arm下python版本最低是3.8,所以这个打包锁死3.8了。不知chromium版本有什么限制?windows下会用系统的webview2,所以最低版本应该是有保证的。不用简易安装客户端的人大多都是浏览器访问,应该没什么问题吧? Edit: 确实win7无法运行,不过这个项目的目的也不是替代现有的官方安装包 > 你这个打包出来比现在的全套环境还大一倍,就有点。。。 没有专门优化大小,git repo是checkout的状态下包的。在完全checkout的情况下和easy install大小接近,所以猜测应该只是git管理的文件的差异。有空的时候我再优化大小吧。

附上自测截图: MuMu 12 on Windows: ![telegram-cloud-photo-size-5-6186140322866776347-w](https://github.com/user-attachments/assets/47b33b95-10d4-4e97-88d4-122f8782a417) Bluestacks 5 on Windows: ![telegram-cloud-photo-size-5-6186140322866776378-w](https://github.com/user-attachments/assets/df45f62e-5cab-4275-be81-2020574b0ba7) Bluestacks Air on MacOS: ![telegram-cloud-photo-size-5-6186140322866776355-y](https://github.com/user-attachments/assets/616911ef-523f-4642-a645-156394d3f103)

我自己进行了多次验证,发现即使 JPEG q98 的情况下,OCR识别也非常容易失败;而且基本上都是在大世界这个地方。 ``` ────────────────────────────────────────────────────── AFTER AUTO SEARCH ─────────────────────────────────────────────────────── INFO 00:47:45.118 │ AFTER AUTO SEARCH INFO 00:47:45.134 │ No EMP debuff on current fleet INFO 00:47:45.136 │ [HP] 98%...

目前的结论是 lz4 方式是同时好于原 DroidCast 和 DroidCast_raw,因为它压缩率不比 png 差多少,压缩编码开销极小,而减少的文件体积节省了内存带宽的使用,总体上cpu开销估计比raw更小。上图测试中所有情况下都比raw所耗时间更短。 在1300+张截图的测试中lz4压缩率为44%,png为68%。压缩率最好的是zstd 22,但这么极端的压缩时间快上秒了,没法实用。 这几个新增方法会仅保留lz4,DroidCast改成优先webp_lossless,fallback png,其它的都删掉。

![image](https://github.com/user-attachments/assets/f5ad3b7f-a857-4a46-84c2-6d38e1c8ad6c) 现在只留下lz4了

我在mac上的蓝叠有同样问题,表现为uiautomator2不能正确识别当前activity 简单绕过问题的方法是后台强行结束错误识别的这个应用 要彻底解决需要修uiautomator的逻辑 不过我怀疑是界面上有个overlay用来弹广告hhh

这里可能缺了个 `buffer.close()` https://github.com/Torther/DroidCast_raw/blob/DroidCast_raw/app/src/main/java/ink/mol/droidcast_raw/ScreenCaptorUtils.kt#L122 > The bitmap will keep a reference to the buffer so that callers can safely close the HardwareBuffer without affecting the Bitmap. https://developer.android.com/reference/android/graphics/Bitmap#wrapHardwareBuffer(android.hardware.HardwareBuffer,%20android.graphics.ColorSpace)

WebUI 是写死的 `127.0.0.1`: https://github.com/LmeSzinc/AzurLaneAutoScript/blob/5fcf1aee95e816f0fd94fa64555b8d8964044677/webapp/packages/main/src/config.ts#L14 我想知道应用场景是啥,如果需要远程访问那不是不应该使用本机的 WebUI 吗?我有另外用 tauri 做的一个 UI,为了防止非法访问服务端和客户端都是写死的 `127.0.0.1`

你这问题有点莫名其妙的,远程访问你要electron干啥?远程桌面开electron? 我不知道你怎么看的没利用的 https://github.com/LmeSzinc/AzurLaneAutoScript/blob/e74c0a5507e5caa376f98678b2c3c83f5d564b2c/webapp/packages/renderer/src/components/Alas.vue#L13

那IPv4不行吗……或者去开个需求让 `WebuiHost` 可以设置多个地址