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

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

这是安卓的统计节点，目前都有，只是看谷歌 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 部署-->统一管理测试需求和测试结果的平台建设。

不建议一上来就把落地自动化规划的很大，可以先从局部的手工专项自动化实施落地，最后攒在一起就可以了。

jenkins 更多的是配置脚本和执行脚本的管理，其实 jenkins 很大的优势就是对不同脚本语言的包容，无论什么语言的脚本，只要执行配置归于 shell、批处理，就可以部署在 jenkins 上执行。并不是所有功能实现都局限在 jenkins 插件去实现，需要统一的是结果报告数据的格式和数据表定义，方便将测试报告统一规划设计。

至于数据可视化部分也没多难，简单落地就是测试结果按 csv 格式存储，python 用 pandas 库做数据处理，highcharts 可以做可交互的各种图。

具体实施来说：
1、测试开发实现手工测试团队自动化需求（任何脚本本语言，能实现即可），并向 jenkins 提供执行配置脚本，其中包括结果处理输出的脚本，邮件脚本（可 python 实现）
2、组织人手设计统一的测试结果存储和展示平台，第一步可各自建立 job 各自邮件通知测试结果，在平台搭建好后在发邮件前做数据上传到展示平台的工作。

我们现在就是在落地结果统一收集展示平台搭建这块，各专项能自动化的都做了自动化方案的设计实施。

自动化实施最主要的就是老板的态度，得向老板充分展示出自动化带来的人力节省和部门成本预算上的节省。拉个有活力的新的测试开发团队推进，同时扩展测试覆盖范围给节省的人力提供更多的业务需求。

你需要搞清楚帧数据来源和原理，gfxinfo 的数据都是 UI 主进程绘制的数据，SurfaceView 的绘制帧数据是不包含在内的。还有一点是如果 app 使用了系统动效，系统动效这部分数据也不包含在内。
1、dumpsys gfxinfo 包名 framestats 命令只能获取除了 SurfaceView 和系统动效的帧数据；
2、获取 SurfaceView 和系统动效需要用到 dumpsys SurfaceFlinger --latency 包名；不加包名即是系统动效的帧数据

你搞反了，0x0 是总流量 tag、其他的 tag 是线程流量。不是去掉 0x0 而是只统计这个 tag。如果想了解详情才分别去看是哪些线程使用了流量。

新的内部使用没分享呢，具体的 case 也只是适配的内部项目，再有就是没在管手机业务的基础体验测试后，手机的脚本一直也没维护，主要维护的 TV 的。外部分享得改不少内容，犯懒有时间没写分享了。

内部有维护，现在是按 case 分组自动统计的方式进行测试，CI 部署测试，整体逻辑上有调整，就是还没整理分享。
统计页

单 case 监控数据

这个时间就是为了对应下 log 时间点加的算了下结束帧对应时间，之前脚本没加时区的 8 小时，后来优化了逻辑和算法，见正文。

那就是手机的温控没做好，我们之前这么放电没问题，温控有优化。费电的就是摄像头，补光灯，屏幕，马达。可以用耗电 app，打开补光灯（手电筒），常亮屏幕震动

主要是解决大部分功耗 case 的自动化：PowerMonitor 自身控制脚本 + 手机端 case 后台操作脚本（uiautomator、shell）+ 数据线加继电器改造（继电器控制通断脚本）+ 报告统计脚本。
主要执行步骤：
1、初始化 PowerMonitor 电源参数（由外部变量状态控制监控数据的存储，最初用的环境变量后改成了文件便于多设备并发，监控文件已 csv 保存），初始化手机的必要设置及环境状态
2、调度用的主脚本用于执行用例后断开数据线的继电器，之后修改文件内变量（通知 PowerMonitor 开始保存监控数据到 case 结果文件夹）
3、等待用例操作结束 (预调试好的等待时间)，通知 PowerMonitor 停止记录并恢复数据线连接及获取 case 执行结果和 log 到 case 结果文件夹
4、回到第二步按照配置的 loop 和 case list 完成测试
5、此时的测试结果是分 case 文件夹保存的，包括 PowerMonitor 监控结果、case 执行结果和 log；通过报告脚本统计分析生成报告。（传入可配置的 goal 值 csv 文件用于统计）

当时试跑报告形式如下，可选 case 及 loop 数查看该次的 PowerMonitor 电流数据图

异常的快速耗电损坏电池，影响电池使用寿命。正常高耗电场景循环操作吧，最典型的就是开补光灯的 4K 模式录像/拍照

再有就是 python 一样，建议注意下文本流处理的意识，逐行过一遍文本信息直接通过逻辑处理拿到最终结果。awk 就是这个思路，逐行处理中已完成逻辑判定和处理。

你试下这几行命令就清楚了，再有就是取数据能一次获取的不要循环抓，dumpsys package packages 可一次性拿到所有 app 的 uid，就是文本得后处理下

其实最主要是研发认可测试结果，研发提出需要至少 PowerMonitor 的测试结果，做硬件及 rom 不同于 app，硬件数据上有精度和底线需求。