反正 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 可以解决通用性

monkey 的 log 中有

要先搞明白三列的意思，第二列是 vsync 时间，是通知上层准备帧数据的信号通知；第一列是帧数据交给 SurfaceFlinger 绘制的起始时间点；第三列是 SurfaceFlinger 绘制完成的时间点。其中第一列和第三列只有经过 openGL 绘制的才有时间，比如系统动效这两列只是相等的最大正整数。
vsync 可用于帧率的统计计算，而第三列和第一例的差值可以衡量 SurfaceFlnger 绘制的性能。帧率高低用于评估流畅度，可 SurfaceFlnger 绘制的性能只是为了说明硬件性能承担不了绘制的帧数据大小，需要优化 framework 层的绘制性能及精简布局和图片，减轻 SurfaceFlnger 绘制压力。

7.0 是因为分屏，8.0 是悬浮窗口，在 SurfaceView 的分辨上做的区分，格式都有调整

安卓 7.0 之后具体的窗口名在 adb shell dumpsys SurfaceFlinger 最后的 Allocated buffers 中有，打开目标窗口实际取下就知道了

7.0 以上 SurfaeViev 窗口名改了，包名的窗口并没有变，需要注意下取 SurfaeViev 的窗口需要把实际窗口名补全，对帧率监控没影响，就是得注意传参。 SurfaceView 的应该是 “SurfaceView - org.videolan.vlc/org.videolan.vlc.gui.video.VideoPlayerActivity#0” 有空格注意加引号，其他的 UI 主窗口并没有变。

安卓 7.0 之后，就是不知哪个开发看 meminfo 的格式不爽加了千分位，和内存单位，我只是把内存监控重新适配了下。

1、xxx 系统能直接按特性发布版本，不需要人工回归测试。
——回归测试用例自动化及逐步精简控制总体测试时间
2、提升 xxx 系统的发版节奏，开发完 1，2 个特性就能发，可以做到一周 2 发 (周一、周三) 甚至更多。
——完整版本发布测试验证覆盖量大，可优化测试策略为增量测试，控制测试总时间
3、上线后的质量提升，生产缺陷下降。
——推进埋点质量数据收集及线上数据监控，可接三方 sdk 方案

哦，原来指的是算法能力上能支持高速点击。实际压测还是要分压测场景和压测目的具体平衡事件比例，过快的操作更多考验的是未完成事件的中断，往往会发生用户正常操作不会遇到的 bug。
而针对内存占用的压力还是需要图片加载，视频缓冲，合理节奏下的 GC 释放场景的正常测试。对 app 压测评估、对 app 压测 bug 补漏、通过 app 压测系统和底层服务等不同目的的方案设计还是有区别的。建议针对不同场景的使用可以做下建议性参数配置实例。

高速点击不应该是核心测试需求的诉求吧，实际的压测需要有页面缓冲、动效显示、图片加载的处理间隔，还应有等待回收逻辑处理完成，所以还是模拟用户行为间隔更重要。否则会引起研发不认可的 bug 及内存泄露压力不够的问题。

我们团队从 13 年下半年开始做自动化，一步步过来，主要就是这样：局部专项的自动化方案落地-->由于人力缩减、预算缩减带来了自动化旺盛的需求，恨不得能自动化的就不要手动-->日常/周常自动化的 jenkins CI 部署-->统一管理测试需求和测试结果的平台建设。