#15 楼 @andyguo 是的，shell 脚本在设备端后台运行，不需要长时间连 PC。需要用到 busybox，而且有些设备自身没 root 权限连 monkey 都跑不起来。单就逻辑来说对于无 root 但可以正常执行 monkey 的安卓设备，可以写 PC 端的脚本进行控制，不过没有设备端后台脚本方便。

#32 楼 @zongguanxian 只考虑了测试数据抓取和引导分析数据的方向，主要目的是像过筛子一样，先过第一道筛子：
1、PSS 峰值越高可优化空间越大，PSS 峰值降序排列，可以优先看优化利益大的进程。
2、PSS 极值差越大，被怀疑内存泄露的可能性越大，极值差降序排列优先看风险最高的。
3、单进程走势图分析，观察 PSS 波动大的部分的 Activity 变化，及对应 log 时间分析操作，进一步确定导致内存波动的操作；可以针对这些操作做进一步测试和跟踪分析。

所谓大浪淘沙，得先让沙子沉下来，再取沙子来分析。

#2 楼 @zongguanxian 这是有局限的，只限于有句柄变化的测试场景，误差就是取次 SurfaceFlinger 数据的差异，而且每次取数据都是开销差不多的时间做减法后精度在 0.01 吧。SurfaceFlinger 是显示帧的管理，屏幕完全显示出来就看屏幕硬件驱动的性能了，基本可忽略。
视频类合成的帧是独立显示的 HWC_FRAMEBUFFER_TARG 代表了合成的图像，至于它的句柄变化没细研究变化的规律。
adb shell
time tmp=`cat /proc/uptime&&dumpsys SurfaceFlinger|grep "|....|"
0m0.02s user 0m0.01s system
time echo "$tmp"|busybox awk '{if(NR==1){print $1 }else{print $0}}'|busybox awk -F "|" '{if(NR==1){t=$1}else{if(NR>2){print t","substr($1,2,length($1)-2)","substr($2,2,length($2)-2)","substr($NF,2,length($NF)-3)}}}'
0m0.00s real 0m0.00s user 0m0.00s system

log 筛查处理的是用-v time 格式获取的 log。

再有，如果是在 windows 上编辑 shell 脚本，需要注意文档格式为 unix，字符编码为 utf8，使用 Notpad++ 转一下文档格式就好了。

#9 楼 @babyshine 注释了，需要修改 monkey 语句，设备端的脚本用到了 busybox，本身脚本是去除了，moneky 测试逻辑，毕竟这个是和测试目的和设备相关的，需要按需定制。

#2 楼 @jennyhui Highcharts 做的 HTML 模板，python 使用 pandas 完成 csv 到 js 数据文件的生成，生成的 Html 交互图。

#10 楼 @happystone
#10 楼 @happystone
1.两个方式，一个是判定是否有退出的确定框弹出，有的话就取消。再一个是 uiautomator dump 取布局的 xml 分析
dumpsys SurfaceFlinger|grep "|....|" 可以取到当前显示的情况，可以取到是否有确定弹出框的布局。
uiautomator dump /sdcard/check.xml 出的 xml，busybox sed -i 's/<node/\n<node/g' /sdcard/check.xml node 前加回车就很好分析了。而且对于很多 apk 会把设置状态保存在/data/data/包名 下会有对应的 xml，可以查下你要测试的又没有，取文件判定登陆状态也是个思路
2.初始化其实就是可以用 shell 控制在哪也操作，monkey 就负责点就是了，配下操作事件类型和比例。shell 控制当前操作的 activity。跑乱了就听掉 monkey，不退 app 直接从当前状态切换回登陆状态。
这个实现思路可以用 case 语句，对每种情况绑定恢复初始状态的操作，这样不论需要初始化时状态是什么都可以恢复初始页面。

#5 楼 @happystone 比如你所说的保持登录状态，后台轮询脚本可以判定 app 显示状态，如果是退出框则点取消，如果这样还被退，就在判定账号退出后，执行初始化重新登录。

#4 楼 @happystone 数据可视化可以用 highcharts 框架，python 处理数据，我的监控方案及很多数据展示的需求都是这么做的。本来我也计划着要写下 shell 控制 monkey 执行配合监控抓取数据，轮询筛查 log 精简 log 量，最终脚本筛查统计 log 便于进一步分析，写完再发。对于需要 monkey 保持特定场景执行，简单的做法就是 shell 中做控制及当前状态判定。保持登录状态不好控制，但处于未登录状态初始化重新登录时可行的。

monkey 的 log 对 ANR 和 crash 的输出在 2 输出流，结果重定向最好 1> /mnt/sdcard/monkey_test.txt 2>&1 &； 这样在 monkey_test.txt 就可以筛查到 ANR 和 crash，并且知道异常前的操作

#30 楼 @seveniruby 哎，测试行业混迹 8 年了，从手游到安卓 TV，从 java 功能机到智能机，从功能到自动化再到性能，折腾来折腾去。这是总结在乐视实践性能优化的过程，一个人从零到搭建方案建立流程，持续调整优化改善。根本目标是控制用户体验改善和版本性能情况监控。性能优化本身不是测试一个部门搞得定的，所以致力于推动多部门间的合作。总结的就是推动的办法，及收集数据作为推动的证据。设计测试筛查方案引导研发资源投入到明显改善用户体验的点上。

工具更新了几个问题：
1、获取 activity 的源数据格式 TV 和手机格式不同，按正向第五个取数据而不是之前的倒数取数据
mFocusedApp=AppWindowToken{425a3510 token=Token{42665e80 ActivityRecord{42665d30 u0 com.letv.leso/.activity.SearchBoardActivity}}}
mFocusedApp=AppWindowToken{2a336cc7 token=Token{18b95356 ActivityRecord{a3b7971 u0 com.android.settings/.UsbSettings t34}}}
2、在手机系统性能慢的时候，退出 app 存在虚拟机退出和进程退出之间存在时间差，” dumpsys meminfo 进程 PID “未取到数据但” cat /proc/进程 pid/smaps|grep Pss 求和取 Pss“取到了。最终处理 csv 到 json 过程有处理错误。

我的系统性能测试方案
性能测试之用例得分评价和 CPU 内存数据监控
对于性能测试，个人看法是：
1、性能测试方案主要目的是引导研发资源投入产出比最高的性能优化点。
2、对于实际项目中的性能测试方案设计，需要根据目的控制测试范围，有所取舍。

对于测试手段：
1、UI 操作偏向用户实际效果的方式，执行测试 case 并录像算帧
2、偏向和研发配合收集性能数据分析则需要埋 log 获取时间，自动化脚本完成执行和数据收集统计形成报告
3、基于显示变化的 case，自动化判定结束状态可以从 SurfaceFlinger 数据变化入手基于变化取性能响应时间尝试
4、CPU，内存，电量监控可以集成到常规测试任务同时进行。包括功能验证，压力测试，专项测试

对于内部标准及推动解决：项目中需要有个能下结论做决策的人（有话语权）推进研发认可标准并跟进解决，制定的标准需要完全站在用户体验角度考虑。

对于竞品对比数据，完全就是为了展示产品和说服研发对性能差的部分进行优化用的。

游戏的 gameplay 测试很大程度上还是拼人力投入的，再有就是公司对游戏质量的态度。正因为人力投入大，Gameloft 在 12 年就把测试放到了越南和马尼拉。Gameloft 对兼容测试的态度还是很值得认可的，保证发售地区使用量 Top100 机型的兼容测试，IOS 还包括多个历史重点系统版本的测试，因为有很多人的 iphone 系列手机到手后都不知道升级。

游戏测试还是需要足够人力保证的，我在 Gameloft 时，标准 gameplay 测试组就是 10 人，还有声音中断组，版本提交前还有其他工作室专门的组负责 double check。
说道具体的测试：
1、首先要过的就是 rules 类检查，规定的标准设计准则，和是否符合用户使用习惯，是否符合应用商店上架标准
2、肯定是要过一遍游戏所有的内容和文本的，这里就需要作弊码做全部内容显示和文本的验证了。测试中发现功能 bug 则需要在不开作弊码情况下再次验证。
3、然后就是需要过音视频的触发，保证触发时刻
4、Gameplay 自由测试就要靠人员手工测试的能力了，再有就是探索测试形式的有针对的引导测试方向
5、兼容类测试就设计分辨率比例显示兼容，适配手机的系统版本兼容的真机测试。
6、压力及性能测试保证稳定性及 cpu，内存，流量开销
如果是网游类，还会涉及后台接口及后台压力测试相关内容

游戏测试除了固定 case 的功能验证，还真不适合做自动化，对于游戏的频繁改动自动化持续维护的方式人力成本代价和时间成本太高

@lihuazhang 本不想把这个工具做成开源项目，也是为了将工具和文章关联在一起，展示的是设计思路。
写这篇文章，起因主要是两点，一个是本身我在 testerhome 群里讨论过两次监控的事了，第一次也展示过我的设计思路和截图效果。第二次又开始讨论就感觉自己需要写一下了，要不每次见到性能测试相关讨论就想吐槽点什么，而结果又是反复说类似的事情，不如一次写清。
本身写出来也是为了从我现在做的事情来讨论框架思路，和设计思路。工具展示出来也是想展示成品效果，及我对数据可视化的设计。
展示出我当前设计的性能测试框架思路，也是希望在更多人的讨论中，可以扩展实际可落实到流程的想法。更多人的想法碰撞，可能会出火花的。

已放出工具，我也是整体设计完逻辑，按逻辑需求直接拼凑代码逻辑完成的。python，html，js，highcharts 和 node-webkit 也是没怎么深入了解直接上手搜实例参考，上手直接写。遇到 bug 和改善意见，可以在这里回复，以便进一步优化下。