应聘时应该能听出来的，负责人明确说了是招技术强做技术创新的，换言之就是目前公司内测试技术落后需要有个人推动改善。本来招你就是为了干这事，指着别人就别想了。
所谓的技术创新就是看你能不能引入自动化等手段改善目前的工作方式，是要你主动尝试并尝试推广的。其实算是个有挑战但有空间的职位，毕竟没自动化积累，只要你引入并实现了，你就是该公司的测试技术负责人了。

设备端 atx-agent 真有必要？shell 脚本后台执行也可以解决同样的需求，网络 adb 下起后台脚本管理测试执行的过程和具体的调用，shell 脚本还能额外开发功能能力。

安卓做语音测试挺简单，sendevent+stagefright，sendevent 负责做指定位置的按下抬起，stagefright 负责按下抬起之间播放 wav/mp3 样本。

窗口名错了，你取的是 activity 名，实际上窗口名是 “SurfaceView - com.youzu.unity.test/com.unity3d.player.UnityPlayerActivity”，有空格传参需加双引号

还有就是 adb 一行命令执行，双引号需转译，要不就 adb shell 之后再获取。

流畅度是按场景把控的，主要是滑动列表场景、动效场景等，具体看你们的把控范围要求。流畅度是硬指标，手机屏幕是 60 帧、MTK 有些 59 帧屏的产品。UI 交互场景帧率一般良好体验是要 50 帧以上的，重点关注帧间隔大于 100ms 的卡顿，游戏的话大于 50ms 的卡顿就很严重了，具体看是否锁帧，锁帧的一般是 30 帧，不锁的都是 40 帧起步，50 帧以上良好。

每一帧绘制都是由 vsync 通知开始，我这个方式就是用 vsync 间隔来衡量的 fps，刨除重复绘制相同画面这种异常情况（如反复刷布局），实际 vsync 就是和用户看到的帧一一对应的。gfxinfo 是和帧绘制耗时相关的，你可以打开开发者模式中的显示数据到屏幕看到，每一帧的数据展示是实际开销，有小于 vsync 间隔的也有大于的，这部分并不是实际画到屏幕上的时间点。

理解下原理，数据源是安卓 SurfaceFlinger 的接口，安卓系统源生的数据，每个窗口都是独立的数据，只要窗口显示就会一直保存历史 127 帧的绘制数据。而获取数据上我的脚本是间隔 1.6 秒累计的从窗口创建到退出一直在统计。

下面回了好几次了，测试窗口要和目标测试的一致，而且安卓 7.1 后窗口名改了，手机打开要测的窗口，实际获取后再测试。这种情况主要就是窗口名配错。

是这个格式，这个是实时窗口查看，也可以存文件出图。具体的窗口名得打开游戏用 adb shell dumpsys SurfaceFlinger 实际看下。

一样用，就是换下窗口名。一般游戏引擎开发的都是在 SurfaceView 中绘制，安卓 7.0 以下直接监控 SurfaceView 窗口，安卓 7.0 之后有了分屏，名字被改了。变成 SurfaceView - 包名 #0 这种，具体取一下传进去就可以用，只是注意有空格需要英文双引号。

搭个 dzzoffice 还能文档协同

PC 端是 jenkins 任务，这事在之前乐视时就开始做了，没 app 在 IOS 上的单发目前没测 ios

我设计的脚本方案，思路上是脱机执行的，jenkins（搭建在 ubuntu）用 bash 写 shell 脚本连接设备，至于是 usb 还是通过网络 adb 看具体需求。设备端起后台脚本-》PC 端周期判定是否执行完成（后台脚本是否退出）-》等待完成后 pull 结果并生成测试报告-》按需邮件发送

单纯软件层面的话优化动态壁纸下的 cpu 占用吧。增加的绘制开销毕竟是必不可少的。

拆机接 powermonitor，测场景功耗，直接同版本对比静态壁纸和动态壁纸的耗电电流增量。

把监控这个很简单的事搞的复杂了，最不厚道的是要上传生成报告。安卓上做监控不建议用 apk 的形式，主要的问题是：
1、监控是要后台持续运行的，而国内五花八门的系统都会有一个后台查杀策略，跑在安卓层面的监控是受管理的
2、cpu、内存、fps、gpu、电量、温度、屏幕亮度、cpu 主频等数据无非是 dumpsys 取服务信息或 proc 节点，取出来保存为 csv 本身就是挺简单的事，技术点是获取数据的代码逻辑效率
3、至于生成趋势图就更不是大问题了，python+highcharts 框架直接解决

最初我搞 fps 计算方案就是看不上 gamebench，取个帧率还做个 app 还要登陆收费，做个测试工具不能开放些？本身就不是什么有技术壁垒的事

悬浮窗的方式有利有弊，优势是操作中随时可关注，弊端是额外增加了绘制开销。

技术只是基础，摆一些会哪些的实际意义并不太大，关键是能独立承担哪些事情。

个人观点：有独立产出的实际案例，解决方案，属于自己的解决问题套路很关键。

公司层面招个人是承担角色任务的，面试上很大程度是要展示自己能承担的任务能力和承担的责任范畴。建议自己思考下能承担多大的事；以及以往的工作经验中，个人贡献的成果及产出的通用项目经验。
还有一点测试圈子并不大，几年经验后大部分是圈子内的熟人推荐，个人在同事中 “靠谱” 认可度也是对换工作及职位升迁有帮助的。

13 年我在你这年龄阶段也是感觉遇到自己的职场瓶颈，逼着自己转自动化，后转设备端性能专项等方向。当时给自己定的目标就是：思考解决方案思路，设计自己的脚本方案和解决套路，根本设计要求是实用及低资源成本投入。之后就是持续两年多的方案设计积累，凭借实际成果产出转型成功了。经验之谈：认准个适合的领域，持续积累个人的成功案例和解决问题套路，只要同样的事比别人做的好且更省资源，工作中会很抢手的。

可以把 csv 和生成后的文件夹分享个链接给我，我看下结果。没看到具体情况，看不出问题，可以试下换火狐浏览器查看看下。

你看下 awk 语法吧，很多语法理解不太对，好好理解下文本流处理的意思，awk 是一套逻辑逐行处理。匹配每一行后会按代码逻辑处理数据。
原理就是处理了下三列数据的计算统计，主题逻辑中做了不同安卓版本的兼容，和异常数据情况的处理。再有就是累计的统计、输出时刻的设计。

得看报错信息，一般是没按具体的要求执行。

看下面回复，你这手机是安卓 8.0 的？窗口名需要看 framebuffer 中完整的，后面又 #0 这种，要不取不到。本身这个方案是 16 年写的，当然后续的 7.0/8.0 也能用，就是 android 的窗口名命名规则和 SurfaceFlinger 输出信息的格式变了。

自己换行就好看了，我是不想再搞个.awk 文件，就放到一行执行了，有时我自己写也是先写好再删换行符。awk -f 文件名.awk 也是可以执行，就是多了零碎的文件。

是的。
这个方案是两年前发的，后续陆续有些优化调整，并变成独立函数集成到了不同专项需求中，根本原理没变。

你是锤子手机自动化的人?注册时间点很巧合，还是直接来看的我两年前这几篇分享。

帧耗时和帧间隔不是一个概念，现在动辄双 framebuffer 及三 framebuffer，framebuffer 的准备时间都是提前预处理的，实际帧绘制开销我只是关注了 jank，就是三列数据中第三列减第一列，在低端芯片的优化上有帮助，可以看到芯片能力的限制，推动 framework 优化及布局精简。
而帧间隔（抛去刷相同帧画面的情况）和人眼看到的间隔是差不多的。所以用它来参考屏幕实际流畅度体验。
MFS 是最大一次帧间隔时间（小于 500ms，因为我把大于 500ms 的算做了静置，没计算 fps 的意义）为了评估最卡一次有多卡
Frames 就是一组样本数据中的总评估帧数。