APP开发中性能问题无疑是很重要的一点，有几项指标可以看出APP的性能是否存在问题，内存使用量，FPS，以及CPU使用率。在开发阶段这些数据的测试很容易，有一些在Xcode编译项目时就会有显示，而剩下的则可以使用Instruments来进行监控。可以说在线下的监控Instruments为我们考虑到了方方面面，但是光是线下监控是完全不够的，因为APP上线后运行的环境是十分复杂的，我们在测试时不可能模拟的面面俱到，因此就需要针对线上的性能问题进行监控。
内存使用量
内存使用是很重要的一点，如果我们的内存使用量过大，APP就会被系统杀掉，给用户的表现就是闪退，这是很严重的一个问题，而我们的APP如果被系统强杀会产生一个叫jetsam的日志，这个日志可以通过手机中设置 -> 隐私 -> 分析中看到相关日志。
现代的进程在虚拟内存中的运行是以分页形式存在的，这样做可以节省内存空间，因为APP在运行的时候只有一部分会映射到虚拟内存中，而不是整个APP都会被加载到虚拟内存上，只有使用到的部分才会被映射，而jetsam日志就是以页数为单位来衡量一个APP使用的内存是否超过限制。
"rpages" : 89600,
"reason" : "per-process-limit",
像这样，表明我们使用了89600个内存页，超出了单进程的内存限制，如果可以知道一页的大小就可以知道系统对单个进程的内存限制是多少。注意这个限制不是固定的，而是系统根据当前内存情况来决定的。
可以看到一页的大小是16384，这样就可以计算出当前 App 的内存限制值：pageSize * rpages / 1024 /1024 =16384 * 89600 / 1024 / 1024 得到的值是 1400 MB，即 1.4G。
iOS系统会使用一个优先级最高的线程vm_pressure_monitor来监控系统内存压力的情况，并通过一个堆栈来维护所有的APP进程，如果发现某个进程的内存快要超出限制了就会发出通知，内存有压力的APP就会执行代理，也就是熟悉的didReceiveMemoryWarning，在这里面可以写一个释放内存的方法，这是最后的机会去避免APP被强杀。
不过很遗憾APP在上限后我们是无法去获取jetsam日志的，这属于每个用户的隐私，我们的权限是无法获得的，但是iOS还为我们提供了其他的方法去获取内存的使用情况，以供我们在APP内存收到警告时查看当前内存的使用情况。
我们可以写一个文件导入如下头文件
#import <mach/mach.h>
从头文件的名称就可以看出这个是系统级的方法，iOS系统提供了一个函数task_info可以获得当前进程的使用情况
struct mach_task_basic_info info;
mach_msg_type_number_t size = sizeof(info);
kern_return_t kl = task_info(mach_task_self(), MACH_TASK_BASIC_INFO, (task_info_t)&info, &size);
float used_mem = info.resident_size;
NSLog(@"使用了 %f MB 内存", used_mem / 1024.0f / 1024.0f)
MACH_TASK_BASIC_INFO这个结构体中定义了一系列和内存有关的变量
struct mach_task_basic_info {
mach_vm_size_t virtual_size; /* virtual memory size (bytes) */
mach_vm_size_t resident_size; /* resident memory size (bytes) */
mach_vm_size_t resident_size_max; /* maximum resident memory size (bytes) */
time_value_t user_time; /* total user run time for
* terminated threads */
time_value_t system_time; /* total system run time for
* terminated threads */
policy_t policy; /* default policy for new threads */
integer_t suspend_count; /* suspend count for task */
};
但是这样测出来和Xcode中实际显示的出入较大，后来苹果的开发者大会说task_vm_info结构体中的phys_footprint才是真正的物理内存使用量
struct task_vm_info {
mach_vm_size_t virtual_size; // 虚拟内存大小
integer_t region_count; // 内存区域的数量
integer_t page_size;
mach_vm_size_t resident_size; // 驻留内存大小
mach_vm_size_t resident_size_peak; // 驻留内存峰值
...
/* added for rev1 */
mach_vm_size_t phys_footprint; // 物理内存
...
由此就可以写一个简单的内存使用量的检测方法
- (float)getMemoryUse{
//TASK_VM_INFO中存储物理内存使用信息
int64_t memoryUsageInByte = 0;
task_vm_info_data_t vmInfo;
mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
kern_return_t kernReturn = task_info(mach_task_self(), MACH_TASK_BASIC_INFO, (task_info_t)&info, &size);
if (kernReturn != KERN_SUCCESS) { return NSNotFound; }
memoryUsageInByte = (int64_t) vmInfo.phys_footprint;
return memoryUsageInByte/1024.0/1024.0;
}
为了测试我写了一个方法，每隔一秒生成1000个对象装入类中的可变数组，保证其不会被释放，测试内存使用量。
- (void)startMonitor{
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
//创建一个定时器（dispatch_source_t本质上还是一个OC对象）
self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue);
//设置定时器的各种属性
dispatch_time_t start = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0*NSEC_PER_SEC));
uint64_t interval = (uint64_t)(1.0*NSEC_PER_SEC);
dispatch_source_set_timer(self.timer, start, interval, 0);
//设置回调
__weak typeof(self) weakSelf = self;
dispatch_source_set_event_handler(self.timer, ^{
//定时器需要执行的操作
self->usedMemory = [[BZMemoryMonitor shareInstance] getMemoryUse];
[weakSelf increaseMemory];
dispatch_async(dispatch_get_main_queue(), ^(void){
//Run UI Updates
weakSelf.useLabel.text = [NSString stringWithFormat:@"使用内存：%f",self->usedMemory];
});
});
//启动定时器（默认是暂停）
dispatch_resume(self.timer);
}
- (void)increaseMemory{
for (int i = 0; i < 1000; i++) {
NSObject *obj = [[NSObject alloc] init];
[self.array addObject:obj];
}
}
工具使用效果如下：
和Xcode中显示的内存使用基本一致。
FPS监控
提到FPS监控很多人可能都会知道使用CADisplayLink，什么是CADisplayLink呢？
CADisplayLink是CoreAnimation提供的另一个类似于NSTimer的类，它总是在屏幕完成一次更新之前启动，它的接口设计的和NSTimer很类似，所以它实际上就是一个内置实现的替代，但是和timeInterval以秒为单位不同，CADisplayLink有一个整型的frameInterval属性，指定了间隔多少帧之后才执行。默认值是1，意味着每次屏幕更新之前都会执行一次。但是如果动画的代码执行起来超过了六十分之一秒，你可以指定frameInterval为2，就是说动画每隔一帧执行一次（一秒钟30帧）或者3，也就是一秒钟20次，等等。
CADisplayLink可以以屏幕刷新的频率调用指定selector，而且iOS系统中正常的屏幕刷新率为60Hz（60次每秒），那只要在这个方法里面统计每秒这个方法执行的次数，通过次数/时间就可以得出当前屏幕的刷新率了。
由此可以写出一个FPS监控的工具：
- (void)setupDisplayLink{
// 初始化CADisplayLink
_displayLink = [CADisplayLink displayLinkWithTarget:self selector:@selector(fpsCount:)];
// 把CADisplayLink对象加入runloop
[_displayLink addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
}
// 方法执行帧率和屏幕刷新率保持一致
- (void)fpsCount:(CADisplayLink *)displayLink {
if (_lastTimestamp == 0) {
_lastTimestamp = self.displayLink.timestamp;
} else {
_performTimes++;
// 开始渲染时间与上次渲染时间差值
NSTimeInterval useTime = self.displayLink.timestamp - _lastTimestamp;
if (useTime < 1) return;
_lastTimestamp = self.displayLink.timestamp;
// fps 计算
float fps = _performTimes / useTime;
NSLog(@"%f",fps);
_performTimes = 0;
}
}
但是我发现这种方式与Instrument检测出来的差距有些大，我的demo中滑动已经十分卡顿，但是这个工具依旧显示fps在57左右，后来参考这篇文章才发现其原因。
引用文章内容：
iOS中每一帧画面的生成是一个复杂的过程，但简单来说需要经过以下步骤：
1、系统根据你的代码，设置布局各个元素的位置（frame、AutoLayout）、属性（颜色、透明度、阴影等）。
2、CPU对需要提前绘制的元素、图形使用Core Graphics进行绘制。
3、CPU将一切需要绘制到屏幕上的内容（包括解压后的图片）打包发送到GPU
4、GPU对内容进行计算绘制，显示到屏幕上。
我使用的demo是一个很大的CollectionView，然后为cell添加了圆角以及阴影，并且使用了大图片，所以我和这篇文章中出现的现象一致。
1、滑动列表时（即使是慢速滑动），GPU都需要计算图像、文本的动态阴影的位置和形状来进行阴影的绘制，此时GPU将成性能瓶颈，能明显观察到FPS的下降。
2、快速滑动列表时Cell每次在显示前都需要通过imageWithContentsOfFile从硬盘加载图片并解压，此时文件的IO，图片的解压让CPU也遇到性能瓶颈，使主线程无法流畅执行，让FPS雪上加霜。
原因：
CADisplayLink运行在主线程RunLoop之中，RunLoop中所管理的任务的调度时机受任务所处的RunLoopMode和CPU的繁忙程度所影响。
在第二个原因中受文件IO、解压图片的影响，RunLoop 自然无法保证CADisplayLink被调用的次数达到每秒60次，这里的调用频率正是我们的FPS指示器中所显示FPS。
而在第一个原因中主要瓶颈在于GPU，即使RunLoop能保持每秒60次调用CADisplayLink，也无法说明此时的屏幕刷新率能达到60FPS（Core Animation通过与OpenGl打交道控制GPU进行屏幕绘制），也正因为这样FPS指示器显示55+的FPS，但Instrument中的Core Animation FPS 却很低。
总结来说，我的fps一直保持在很高，只是说明runloop保持了CADisplayLink的高频率调用，但是并不能说明屏幕的刷新率也很高。这种方法在一些特殊场景下的检测并不准确，所以这种方法我不是很推荐，可以使用微信开源的matrix来进行fps的监控。
CPU使用率检测
一个进程运行的基本单位就是线程，因此一个进程中所有线程的使用率加起来就是CPU的使用率，iOS系统为我们提供了这些方法，还是需要导入#import <mach/mach.h>头文件，首先thread_basic_info为我们提供了单个线程的各种属性，其中一项就是cpu_usage。
struct thread_basic_info {
time_value_t user_time; /* user run time */
time_value_t system_time; /* system run time */
integer_t cpu_usage; /* scaled cpu usage percentage */
policy_t policy; /* scheduling policy in effect */
integer_t run_state; /* run state (see below) */
integer_t flags; /* various flags (see below) */
integer_t suspend_count; /* suspend count for thread */
integer_t sleep_time; /* number of seconds that thread
* has been sleeping */
};
task_threads这个函数又为我们提供了获取当前所有线程的方法，接下来的事情就很简单了。
- (integer_t)cpuUsage {
thread_act_array_t threads; //int 组成的数组比如 thread[1] = 5635
mach_msg_type_number_t threadCount = 0; //mach_msg_type_number_t 是 int 类型
const task_t thisTask = mach_task_self();
//根据当前 task 获取所有线程
kern_return_t kr = task_threads(thisTask, &threads, &threadCount);
if (kr != KERN_SUCCESS) {
return 0;
}
integer_t cpuUsage = 0;
// 遍历所有线程
for (int i = 0; i < threadCount; i++) {
thread_info_data_t threadInfo;
thread_basic_info_t threadBaseInfo;
mach_msg_type_number_t threadInfoCount = THREAD_INFO_MAX;
if (thread_info((thread_act_t)threads[i], THREAD_BASIC_INFO, (thread_info_t)threadInfo, &threadInfoCount) == KERN_SUCCESS) {
// 获取 CPU 使用率
threadBaseInfo = (thread_basic_info_t)threadInfo;
if (!(threadBaseInfo->flags & TH_FLAGS_IDLE)) {
cpuUsage += threadBaseInfo->cpu_usage;
}
}
}
assert(vm_deallocate(mach_task_self(), (vm_address_t)threads, threadCount * sizeof(thread_t)) == KERN_SUCCESS);
return cpuUsage;
}
这样就可以获取CPU的使用率了。
个人推荐如果是想简单的进行一个性能方面的线上监控，使用这些简单的小方法就够了，如果是想对APP进行一个全量的内存监控，那么可以使用微信的Matrix。
