一、在线性能监控的必要性
现在市面上有各种品牌的手机，有高端机，也有低端机，手机的配置、性能、运行的系统版本都是不一样的，APP在有的手机上运行流畅，而在有的手机上运行却会卡顿，所以有的用户会抱怨APP用的时候怎么这么卡，这样就会暴露出我们的代码写得可能有性能问题，从而有必要收集一些信息，找出卡顿的原因。收集到这些信息，有利于我们分析并解决，在下一个版本发布后，给用户带来更好的使用体验。
二、性能监控的指标
一般从几下几个方面监控应用的性能：
1、CPU：如果长时间的使用CPU，会极大的消耗电量，手机也会发热，影响用户体验。一般是程序 中有BUG或是写的代码性能很差，需要优化。
2、内存：内存使用过大容易被系统杀掉，也容易出现OOM而使应用崩溃，一般是程序中出现了内存泄漏，或者没有对内存做过优化。
3、帧率FPS：如果帧率小于60帧每秒，就会造成应用卡顿，也是影响用户体验的。一般是由于过渡绘制造成的，需要对绘制的代码进行优化。
三、各平台（IOS/Android）对各个指标监控的实现方案
3.1、Android指标监控实现方案
CPU的使用率
Android中可以获取CPU总的使用时间，每个进程所用CPU时间以及进程中每个线程的CPU使用时间，它没有提供API接口，可以直接在应用中读取/proc/stat，/proc/pid/stat，/proc/pid/task/tid/stat这几个文件来获取，不需要root权限。一些开源的性能统计工具也是通过这种方法来显示CPU使用率的，比如网易的Emmagee。
1、获取CPU总使用率
在proc/stat中有详细的CPU使用情况.详细格式如下:
CPU 16394633 4701297 9484146 36314562 70851 1797 202347 0 0 0
CPU后面的几位数字分别是
user从系统启动开始累计到当前时刻，处于用户态的运行时间，不包含nice值为负进程。
nice从系统启动开始累计到当前时刻，nice值为负的进程所占用的CPU时间
system从系统启动开始累计到当前时刻，处于核心态的运行时间
idle从系统启动开始累计到当前时刻，除IO等待时间以外的其它等待时间
iowait从系统启动开始累计到当前时刻，IO等待时间
irq从系统启动开始累计到当前时刻，硬中断时间
softirq从系统启动开始累计到当前时刻，软中断时间
在某个时间T1的CPU总时间为：
totalCpuTime1 = user1 + nice1 + system1 + idle1 + iowait1 + irq1 + softirq1
在时间T2的CPU总时间为（T2 > T1）：
totalCpuTime2 = user2 + nice2 + system2 + idle2 + iowait2 + irq2 + softirq2
CPU总使用率的算法是：
100*((totalCpuTime2-totalCpuTime1) - (idel2-idel1)) / (totalCpuTime2-totalCpuTime1)
2、获取进程的CPU使用率
/proc/pid/stat中则是该pid进程的CPU使用情况.详细格式如下:
2757 (zenmen.palmchat) S 549 549 0 0 -1 1077952832 1674191 173040 7885 4062265 19589 99 49412
其中粗体的四位数字分别是:
utime 该任务在用户运行状态的时间
stime 该任务在核心运行的时间
cutime 所有已死线程在用户状态运行状态的时间
cstime 所有已死线程在核心的运行时间
所以进程的CPU使用时间processCpuTime为这个四个属性的和.
在T1时，processCpuTime1 = utime1 + stime1 + cutime1 + cstime1
在T2时，processCpuTime2 = utime2 + stime2 + cutime2 + cstime2
所以进程所占CPU的使用率算法是：
100*(processCpuTime2-processCpuTime1) / (totalCpuTime2-totalCpuTime1)
3、获取进程中线程的CPU使用率
/proc/pid/task/tid/stat中是该pid进程中tid线程的CPU使用情况，格式和进程CPU使用的格式是一样的，
3810 (fileDecodingQue) S 549 549 0 0 -1 1077952576 269 173040 0 40 0 0 99 494 20 0
线程的CPU时间为：threadCpuTime = utime + stime
线程的CPU使用率算法是：
100*(threadCpuTime2-threadCpuTime1) / (totalCpuTime2-totalCpuTime1)
内存使用
Android提供有API可以获取系统总内存大小及当前可用内存大小，以及获取应用中内存的使用情况。
1、获取系统总内存大小及可用内存大小
ActivityManager.MemoryInfo有以下几个Field:
totalMem：表示总内存大小
availMem：表示系统剩余内存
2、获取应用使用的内存大小
Debug.MemoryInfo.getTotalPss()，返回的是KB
监控帧率FPS
Android系统从4.1(API 16)开始加入Choreographer这个类来控制同步处理输入(Input)、动画(Animation)、绘制(Draw)三个操作。其实UI显示的时候每一帧要完成的事情只有这三种。Choreographer接收显示系统的时间脉冲(垂直同步信号-VSync信号)，在下一个帧渲染时控制执行这些操作。收到VSync信号后，顺序执行3个操作，然后等待下一个信号，再次顺序执行3个操作。假设在第二个信号到来之前，所有的操作都执行完成了，即Draw操作完成了，那么第二个信号来到时，此时界面将会更新为第一帧的内容，因为Draw操作已经完成了。否则界面将不会更新，还是现实上一个帧的内容，表示丢帧了。丢帧是造成卡顿的原因。
通过 Choreographer 类设置它的 FrameCallback，可以在每一帧被渲染的时候记录下它开始渲染的时间，每一次同步的周期为16ms，代表一帧的刷新频率，一次界面渲染会回调 FrameCallback的doFrame(longframeTimeNanos)方法，如果两次 doFrame 之间的间隔大于16ms说明丢帧了。用这种方法，可以实时监控应用的丢帧情况。
四、监控日志上传
对于CPU，可以每隔一段时间去获取APP进程CPU时间，也可以针对一些场景手动获取。可以设定一个阈值，比如大于50%的时候，将各个线程名及线程占用的CPU时间一起保存到日志中。
对于内存，在加载图片、视频、声音等这些比较耗费内存的资源的时候去获取一次应用内存占用及系统剩余内存保存到日志中。
帧率FPS是可以在程序中实时监控的，可以在Activity start时开始监控，当检测到丢帧时保存丢帆的个数，在Activity stop时停止监控，取最大的丢帧个数，再将Activity类名一起保存到日志中。
