iOS目前版本自动化已经没什么大病了，但是远控投屏的卡顿和触控延迟是很大的问题，因此定制了以下计划，作为一个长期指标。替换tidevice（已完成） tidevice十分优秀，但是Sonic目前主要依赖java环境与node环境（因为appium和adbkit，要是以后这两个被替代了，那node环境也可以去掉了），这时让用户额外部署python环境来搭tidevice就显得浪费了，加上iOS的电池温度信息不能从tidevice获取到，因此Sonic会自研一个基于gidevice跨平台的iOS通信工具（类似libimobiledevice），并且通信速度，报错信息等等更完善（已完成）脱离wda实现投屏 appium版的wda自带mjpegserver虽然能实现投屏，这也是目前sonic的投屏方案，但是mjpegserver带来的带宽很不理想，fps我拉高后带宽吃很多，所以只能舍弃画质，这是不太好的，因此Sonic会自研一个类似ios版的scrcpy，用swift实现，目前进度0% 更好的触控方案目前触控通过wda的http协议来交互，还是会稍慢，比直接跟设备通信多了一层转发，方案还在摸索中。 iOS的在线webview调试这个已经有方案了，实现起来不大困难实时iOS日志查询这个已经有方案了，实现起来不大困难一键获取iOS设备崩溃日志这个已经有方案了，实现起来不大困难

Sonic后续对iOS远控方面的计划

iOS目前版本自动化已经没什么大病了，但是远控投屏的卡顿和触控延迟是很大的问题，因此定制了以下计划，作为一个长期指标。

替换tidevice（已完成）
tidevice十分优秀，但是Sonic目前主要依赖java环境与node环境（因为appium和adbkit，要是以后这两个被替代了，那node环境也可以去掉了），这时让用户额外部署python环境来搭tidevice就显得浪费了，加上iOS的电池温度信息不能从tidevice获取到，因此Sonic会自研一个基于gidevice跨平台的iOS通信工具（类似libimobiledevice），并且通信速度，报错信息等等更完善（已完成）
脱离wda实现投屏
appium版的wda自带mjpegserver虽然能实现投屏，这也是目前sonic的投屏方案，但是mjpegserver带来的带宽很不理想，fps我拉高后带宽吃很多，所以只能舍弃画质，这是不太好的，因此Sonic会自研一个类似ios版的scrcpy，用swift实现，目前进度0%
更好的触控方案
目前触控通过wda的http协议来交互，还是会稍慢，比直接跟设备通信多了一层转发，方案还在摸索中。
iOS的在线webview调试
这个已经有方案了，实现起来不大困难
实时iOS日志查询
这个已经有方案了，实现起来不大困难
一键获取iOS设备崩溃日志
这个已经有方案了，实现起来不大困难

当然后面不是都在做iOS远控的啊，后面的版本还会有权限监控、一键装包、Jenkins插件等等非常多的内容，这个帖子仅仅是说iOS方面的规划