前言
使用以及相关文档 -> https://sonic-cloud.cn/ide/re-ide.html
Sonic IDE 是Sonic平台打造的IDE编辑器，可以支持直接调试内部Sonic平台的设备，如果您不习惯Sonic提供的无脚本自动化方案，那么IDE或许是你的选择。 目前包含以下多种功能
- 远程控制设备
- 实时控件获取
- 支持多种语言编程
- 等等...
目前IDE还是一个很初版的形态，我们也承诺会继续保持免费，还需大家多多提建议，我们一起把他做得更好
show733ae6cf.mp47MB
背景
我们Sonic开源以来，我们发现我们用户类型越来越多，以前我们主要服务于UI自动化小白和开发产品等等角色。但是随着开源时间变长，我们发现了部分想使用Sonic，但是又不能与公司内部已有的大量自动化脚本结合而放弃了Sonic的用户。于是，我们构想出一种仅仅只是将Sonic用作设备管理角色，但是UI自动化还是用公司已有的框架的方式。
一、REST API暴露
第一步，Sonic自身需要暴露REST API可远程暴露连接的方式，这个功能在v2.5.0已经加上了。效果是用户调用相关接口后，设备会进入占用状态并且返回远程adb连接地址和其他可选的服务地址，这样很方便可以跟已有脚本结合放到Jenkins等CICD中执行
二、IDE设计
第二步，设计一个Sonic专属的IDE，可以使得用户一边进行自动化编程，一边观察设备运行情况。
在公司内部运用场景与分工大概如下：
运维人员负责部署好Sonic Server与Agent相关信息，QA只需下载好Sonic IDE，在里面登录至内部Sonic平台即可。
我们通过这种方式，可以减少QA的使用门槛，直接在IDE中获取设备的控件信息和远程控制，有利于提升编写脚本的效率。
于是我们开始了漫长的技术拉锯战...
误区
有意思的是，我们发现目前还是仍有非常大量的用户并不清楚Appium的技术原理，包括ATX的uiautomator2和appium的uiautomator2很多人以为是同一个东西，所以有时候用户将instrument相关的UI自动化框架应用到Sonic时遇到问题会无从下手。
Sonic目前采用的是Appium的uiautomator2-server，而且写了相关的java api ，可以参考这里 https://github.com/SonicCloudOrg/sonic-driver-core
对比Appium的好处是不需要再启动一个本地Appium Server和多一层转发服务，直接跟uiautomator2交互。所以当自己的第三方UI自动化框架冲突时，或许直接用adb杀掉uiautomator2是个不错的方式。（当然我们REST API也可以控制uiautomator2是否启动
未来展望
最近ChatGPT是一个很火的东西，不少人希望能利用到工作中提升自己的效率。我们也有计划后面加入到IDE中，其余的会逐渐迁移Sonic更多Web版功能到IDE上。
