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

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

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

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 就是一组样本数据中的总评估帧数。

反正 top 一次性展示全了，干脆把 cpu 占用率大于 0 的全保存了，当然 busybox 的除外。

正则错误是你需要注意一点，命令行和脚本中需要的转译符数量不太一样，放到``执行符中需要多加一个转译符\，而命令行直接执行就需要把多加的转译符去掉，要不就会报错。

新作的框架流程是，优势结合的目的：
1、shell 擅长设备端离线后台执行的管理
2、busybox 扩展了 shell 脚本的能力
3、shell 可以管理所有命令行能执行的方法
4、PC 端对结果的二次处理与分析统计更有优势

所以：
1、由 shell 设计统一的设备端后台执行脚本，解析外部的 csv 配置完成不同的测试需求
2、shell 脚本的监控方案可以按需配合测试执行不同的监控需求，cpu、内存、帧率、电量、电压等等
3、既可以由 shell 写用例方法函数，也可以用 uiautomator 写方法，所有的调用都放在 csv 中配置维护
4、固定结果存储目录和文件结构，测试完成取出后交由 PC 端进行统一整理输出 html 报告，并可结合 highcharts 做监控图（shell 端有结果信息的预处理，都变成 csv 数据形式）

busybox 的 top 不同版本 cpu 所在的列不是固定的，为了适应这个，提前判定了下 cpu 在第几列。还有就是输出的格式有很多特殊情况会多出空格导致列顺序不对，主要是为了容错这些特殊情况。比如 mtk 有些底层进程的进程名是 [mtk th] 之类的，具体名字忘了。

不过目前这套方案早被我迭代了，现在在做一套更灵活的方案，把监控、shell 脚本、uiautomatorcase，命令行方法统一到一个框架模式中来设计管理，shell 负责执行过程的统一控制管理，具体的 case 全变成 csv+ 配参维护。目标是测试开发维护公共方法，执行人员按需配参。执行维护的人无需懂代码，只需了解配参意义。测试开发维护公共方法函数的实现。随着公共方法需求的收敛，解放出测试开发的精力做更进一步的方案设计。

电池膨胀大多是由于长时间过冲，很多手机是有过冲保护的，对于没有过程保护的手机也可以在数据线上加上可以防止过冲的 usb 电压电流表

我自己写的 fps 计算方法和打分规则，用户体验角度讲，实践后明显 10 分一档，每 10 分跨度都会有体验差异。还有两个维度数据的定向性能问题 highlight：1、硬件掉帧；2、一组采样数据中 100ms≤帧间隔≤500ms 的比例
分别对应推进对应的体验优化，如果是游戏体验，会调整统计 50ms≤帧间隔≤500ms 的比例

这个还真不担心，锤子还有钱继续做项目，而且做技术的就是看平台环境可以给自己带来多大的提升。不是高层管理也不会和公司存活关联的紧密，毕竟没那么多股票期权。
现在的年代很少有在一家公司干一辈子的，有合适的平台发展并积累职场竞争力很关键。能力到了，实际个人对项目价值产出体现到位了，就有了争取更高个人收益的资本。职场还是和客观的，主要是平台和环境适不适合发展，毕竟都是双向选择。

是，四月底入职的。

看 dumpsys gfxinfo 源码分析的文章看到过，而且实际试验了，确实 SurfaceView 的都没记录。dumpsys gfxinfo 取的是每个 app，所有 activity 的绘制数据记录，统计数据累计，最多保存历史 127 帧绘制数据。

北京
具体位置：北京市朝阳区中国数码港大厦

step1: open the app
step2: adb shell dumpsys SurfaceFlinger
step3: find the window name in Allocated buffers

The window name has been added more info. Such as #?, the ? is a window's numbr for a same window name. For SurfaceFlinger has buffer to save the last 127 frames' info for each window. I design this scripts is for get fps by those frames' vsync time.

有点千篇一律的总结，实践中根本不是这么一回事，描绘的思路太大了。测试实践中需要的是方案细节，把控标准，项目测试中的专项测试把控阶段的选择，及不同阶段的回归策略。经历过实际性能问题优化的会知道：
1、OOM 不仅是 java 虚拟机的 heap，还有 nativie 方法的额外占用，anon 匿名内存的使用，引用的开源库的线程管理回收
2、最明显的内存问题是 views 数量的管理，不管好堆积下来能破万以上，内存随之增长
3、kernel 限制不控制一样出问题，FD 数量限制是 1024，32 位系统单进程可用地址空间 3G，超了一样挂
4、移出当前画面不代表停止绘制，只有静置状态 SurfaceFlinger 不在继续绘制才是正确的，否则得看谁再给它供 buffer
6、安卓 5.0 之前有 GC 慢的问题，想监控内存增长得放长 dumpsys meminfo 包名/pid 的执行间隔，要不获取时触发 GC 就掩盖了问题
7、卡顿问题头号是 IO 处理不合理，iowait 的占比有时明显说明瓶颈点
8、绘制慢，除了硬件绘制能力差这种配置不够，大多是资源过大及动效设计问题，布局优化本身就应该是 UI 设计的基本功了。

不做成图形化交互，其实我是有自己的考虑的，对内是开放脚本源码的，引导测试执行了解执行步骤细节，并进一步看看有没有手工人员主动看源码，问问题，有这类积极度高的人可看基础情况培养下，毕竟测试开发不好招。

测试开发主要的两大类，其一是研发路子转的，另一类是我这样从功能测试转自动化后又转负责性能专项设计到现在负责非功能测试。各有各的优缺点，从功能测试转的对业务熟，了解测试执行的痛点，设计方案时会倾向解决问题和使用的易用性。而研发路子代码基础强一些，但缺乏做事做方案的设计思路，听安排实现自动化需求，更适合测试工具开发而非自动化测试方案设计。作为团队来说是希望两类人都有的，优势互补。

再有现在更倾向于 CI 线上交互，线上维护代码避免通知和线下使用的测试工具版本参差不齐。

默认匿名，其实没必要，跟上贴，不匿名。

毕竟产品是老罗主导，需求上插不上话，我还是做好本职把控和专项设计。其实老罗只是在倡导个交互方式，至于最终能否用起来还得发展的角度看，毕竟就算不靠语音对应的操作也是能实现的，只是效率不同。在我看来随着手机性能的提高，替代一些办公场景会是发展趋势，做的更高效的会主导交互设计上的发展。所以我也投入进了这类项目中，尽早实践下。

这是安卓的统计节点，目前都有，只是看谷歌 P 介绍会限制 app 对此节点的读取。

基于/proc/net/xt_qtaguid/stats 解析就好了，只要 UID 是独立的就可以统计。shell+busybox 可以解决通用性