实现之后还有一个更重要的环节:如何让模拟器自动捕获多语言App内页面。这个问题解决之后,我的“自动出商店页截图”工程才算是完成大半。一般的思路就是:英语截完,让模拟器切成德语;德语截完,再切法语;法语截完,再切西语,如此循环。这个思路原则上没有问题,但真正跑起来以后,会带来几个实际问题:- 速度慢。每种语言都要等系统切换、App重启,这个时间比直接通过locale参数渲染页面长得多。
- 整个链路变长。 一个步骤变成六七个步骤,任何一步慢一点,整个任务都变慢。
- 稳定性下降。 App重启、系统语言切换、模拟器状态恢复,这几个都是最容易偶发卡顿、超时、Crash的地方。语言越多,跑得越久,失败概率越高。
- 不好增量重跑。 比如只改了法语一句文案,你理论上只需要重新生成法语。但如果流程绑定模拟器语言,你还是要完整经历一次语言切换→重启→等待。
比如我要截一个旅行日记页面。英语版本截完以后,切成德语,接下来还要重新:用deeplink打开日记页加载截图用的sample data切到正确日期放行Pro状态隐藏广告等页面加载完成调整到需要的滚动位置再截图
这才仅仅是一个页面而已。如果有5个页面、10种语言、3种设备尺寸,这套“切语言—重启App—重新进入页面—重新准备状态”的过程会被重复很多次。在这个思路下,所谓的“自动化多语言捕获屏幕”流程,把大量时间花在了”准备环境”上,而不是”生成结果”上,意义不大。之前是:把模拟器语言环境切成德语-打开App-进入目标页面-截图如果语言只是模拟器设置,每次截图前都要先在App外部准备环境。如果语言是截图target的一部分,工具就可以直接告诉App:screen=diarylocale=de-DEdata=demo-travelpro=trueads=false
App收到这个target以后,直接用德语渲染目标页面,同时加载对应的示例数据和截图状态。这样,从英语换到德语,不再是“改模拟器设置,然后重做一遍准备工作”,而只是把target里的locale=en-US换成locale=de-DE。自动化工作流不是让机器把人工操作完整做一遍,而是先重新设计适合机器的流程,再交给机器执行。