前言
使用以及相关文档 -> 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上。