乐于分享
好东西不私藏

模拟器自动捕获多语言App内页面

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