三、内存及cpu监控方案
　　1、测试方案选择
　　（1）测试流程内集成监控方案收集数据
　　数据可视化展示及分析数据，形成报告产出bug
　　->下一个版本测试流程内回归验证修改（如有特定需求，可定制专项测试，测试版本验证）
　　适用条件
　　有成型测试模型和测试流程的，并且版本测试周期内测试时间充分的项目
　　说明
　　我这边的测试需求是系统软件版本整体的测试，也包括重点进程的测试监控，既要监控java层的进程也包括Native层的进程，还有集成so的NDK开发的应用进程。而且有成型的版本测试模型和流程，每部分测试都有指定的测试组负责。所以自己设计了监控方案集成到测试流程内，提供可视化分析方法便于交付。
　　集成监控测试的场景例举
　　Daily Smoke自动化脚本；MTBF稳定性测试；新增功能性能评估；专项测试评估；稳定性压力测试评估；OOM crash类bug复现数据分析等。
　　成本开销
　　增加分析结果，验证复现的定位分析投入。
　　（2）细化测试用例粒度，选择重点风险用例采集数据评估具体的操作细节。
　　适用条件
　　测试周期短，人力投入有限，没有长期稳定的测试流程的项目。
　　说明
　　没做过这类测试，未实践尝试，只是个人认为此类测试应该是这个思路。
　　2、我所实践的监控方案设计
　　（1）采集数据：
　　Ⅰ、总CPU和进程cpu
　　来源：busybox top -b -n 1
　　选择原因：比top命令执行响应速度高，耗时0.2S左右，top -t需要3s左右；并且精度到0.1，花括号内有正在处理的子进程参考
　　Ⅱ、总内存
　　来源： /proc/meminfo
　　取关注的项：MemFree，Buffers，Cached，Active，Inactive，Active(anon)，Inactive(anon)，Active(file)，Inactive(file)，Dirty，Writeback，Mapped，Slab，包含CMA模块的增加CMA Free
　　Ⅲ、进程内存
　　来源：dumpsys meminfo 进程PID
　　获取：Native Heap Size；Native Heap Alloc；Native Heap Free；Dalvik Heap Size；Dalvik Heap Alloc；Dalvik Heap Free；Totle Pss；Dalvik Pss；Dalvik
　　来源备选：如果native进程取不到则用cat /proc/进程pid/smaps|grep Pss求和取Pss
　　Ⅳ、获取时刻显示的Activity
　　来源： dumpsys window w|grep mFocusedApp|busybox awk '{print $5}'|busybox tr -d '}'
　　Ⅴ、获取时刻的时间
　　来源： date +%Y/%m/%d" "%H:%M:%S
　　Ⅵ、系统启动后运行时间
　　来源： busybox awk -F. 'NR==1{print $1}' /proc/uptime
　　注：用于分析执行监控的时刻及准确的获取数据间隔
　　（2）数据格式化输出
　　Ⅰ、总cpu——cpu.csv
　　Loop:10，Time，Activity，usr，sys，nic，idle，io，irq，sirq，Data Time
　　注：10是设定的间隔，使每个csv可以直接取到间隔用于计算时间；Time是开机已运行时间
　　Ⅱ、进程cpu——cpuinfo.csv
　　Loop:10，Time，PID，%CPU，Command，Thread/avgs
　　注：Thread/avgs是花括号{}内的子进程，或命令行后的参数，都有的情况优先取命令行参数。
　　Ⅲ、总内存——mem.csv
　　Time:10，MemFree，Buffers，Cached，Active，Inactive，Active(anon)，Inactive(anon)，Active(file)，Inactive(file)，Dirty，Writeback，Mapped，Slab
　　注：选择在cpu.csv中记录loop是由于需要有列loop数据判定脚本抓取数据是不是连续正常的，而这里可以用行号计算。
　　Ⅳ、进程内存——meminfo.csv　Loop:10，Time，PID，Process_Name，Pss，Native_Heap(Size)，Native_Heap(Alloc)，Native_Heap(Free)，Dalvik_Heap(Size)，Dalvik_Heap(Alloc)，Dalvik_Heap(Free)，Dalvik_Pss，Avgs
　　注：Avgs是进程的命令行参数，/proc/进程PID/cmdline取的数据
　　（3）数据可视化展示——highcharts
　　Ⅰ、控制每张图的数据量
　　显示数量在400以内，时间段切片显示，默认按照1小时，根据间隔变化调整
　　原因：由于数据量限制一张图默认多展示1000个点，加上数据点越多打开及交互响应慢
　　Ⅱ、所有图共用数据
　　每个点显示：Activity；系统时间
　　Ⅲ、进程CPU数据线和内存数据线总体设计
　　不存在数据的阶段断开；PID更换的红点；同一时间点同名进程存在的同颜色数据画线
　　Ⅳ、进程CPU数据图
　　按峰值降序排列显示top5；可多选交互更新；有参数数据的查看点信息时进程同颜色展示；
　　Ⅴ、总内存图：
　　总内存图：剩余内存=MemFree+Buffer+Cache，Active，Inactive，io=Dirty+Writeback，Mapped，Slab；
　　剩余内存图：剩余内存，MemFree，Buffer，Cache，如有CMA则增加CMAFree
　　Dirty和Writeback图：Dirty和Writeback
　　Active和Inactive图：Active，Inactive，Active(anon)，Inactive(anon)，Active(file)，Inactive(file);
　　Mapped和Slab图：Mapped，Slab
　　Ⅵ、进程内存PSS多选展示图：
　　按每张图数据，进程PSS峰值降序排列
　　Ⅶ、单进程内存数据展示图：
　　按进程PSS极值差降序排列；java进程显示heap详细数据，native进程只显示PSS
　　Ⅷ、附加
　　数据双横轴切换：sleep*loop传参数的计算时间；Time是精确每个取数据命令获取的开机已运行时间；
　　更换图标主题和生成图片的highcharts功能
　　3、方案采取的脚本设计
　　（1）shell脚本获取数据：
　　按顺序获取
　　->显示的Activity
　　->系统时间
　　->CPU
　　->总内存
　　->进程内存（大限制并发5子进程获取）
　　注：监控所有进程采集数据开销大，当前优化后的逻辑也需要6-8S采集一次，随进程增多会增长；单进程获取可以在1S完成。
　　（2）Python转换数据为json：
　　按显示模板设计生成指定形式的json文件，并和模板文件一起打包成zip
　　（3）node-webkit框架数据展示：
　　由于需要加载本地json文件，后选取了此框架展示，以解决浏览器本地文件读取限制问题及处理性能问题。
　　4、效果展示


　　考虑了下，还是把工具放出来吧，有想尝试的可以实际试下效果。
　　1.关于兼容：只是适配了乐视项目情况，是否适用所有兼容机情况没什么把握
　　2.关于使用前提：需要root+busybox
　　3.平台说明：已打包了windows下的exe；shell脚本可以直接push使用不涉及平台兼容；CSVtoJson.exe是将output.py打包成了exe；MCM结果显示.exe是打包了node-webkit框架的win32版本，由于此框架本身是跨平台的，可自行解决跨平台需求。
　　4、如果想修改为在线版本加载json，需要修改Html模板中的json加载部分，MCM_HTML/head/mcm.js里node加载json的语句为在线获取。