转载

检测iOS的APP性能的一些方法

首先如果遇到应用卡顿或者因为内存占用过多时一般使用Instruments里的来进行检测。但对于复杂情况可能就需要用到子线程监控主线程的方式来了，下面我对这些方法做些介绍：

Time Profiler

可以查看多个线程里那些方法费时过多的方法。先将右侧Hide System Libraries打上勾，这样能够过滤信息。然后在Call Tree上会默认按照费时的线程进行排序，单个线程中会也会按照对应的费时方法排序，选择方法后能够通过右侧Heaviest Stack Trace里双击查看到具体的费时操作代码，从而能够有针对性的优化，而不需要在一些本来就不会怎么影响性能的地方过度优化。

Allocations

这里可以对每个动作的前后进行Generations，对比内存的增加，查看使内存增加的具体的方法和代码所在位置。具体操作是在右侧Generation Analysis里点击Mark Generation，这样会产生一个Generation，切换到其他页面或一段时间产生了另外一个事件时再点Mark Generation来产生一个新的Generation，这样反复，生成多个Generation，查看这几个Generation会看到Growth的大小，如果太大可以点进去查看相应占用较大的线程里右侧Heaviest Stack Trace里查看对应的代码块，然后进行相应的处理。

Leak

可以在上面区域的Leaks部分看到对应的时间点产生的溢出，选择后在下面区域的Statistics>Allocation Summary能够看到泄漏的对象，同样可以通过Stack Trace查看到具体对应的代码区域。

监控卡顿的方法

还有种方法是在程序里去监控性能问题，这样在上线后可以通过这个程序将用户的卡顿操作记录下来，定时发到自己的服务器上，这样能够更大范围的收集性能问题。众所周知，用户层面感知的卡顿都是来自处理所有UI的主线程上，包括在主线程上进行的大计算，大量的IO操作，或者比较重的绘制工作。如何监控主线程呢，首先需要知道的是主线程和其它线程一样都是靠NSRunLoop来驱动的。可以先看看CFRunLoopRun的大概的逻辑

int32_t __CFRunLoopRun() {     __CFRunLoopDoObservers(KCFRunLoopEntry);     do     {         __CFRunLoopDoObservers(kCFRunLoopBeforeTimers);         __CFRunLoopDoObservers(kCFRunLoopBeforeSources); //这里开始到kCFRunLoopBeforeWaiting之间处理时间是感知卡顿的关键地方          __CFRunLoopDoBlocks();         __CFRunLoopDoSource0(); //处理UI事件          //GCD dispatch main queue         CheckIfExistMessagesInMainDispatchQueue();          //休眠前         __CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);          //等待msg         mach_port_t wakeUpPort = SleepAndWaitForWakingUpPorts();          //等待中          //休眠后，唤醒         __CFRunLoopDoObservers(kCFRunLoopAfterWaiting);          //定时器唤醒         if (wakeUpPort == timerPort)             __CFRunLoopDoTimers();          //异步处理         else if (wakeUpPort == mainDispatchQueuePort)             __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()          //UI，动画         else             __CFRunLoopDoSource1();          //确保同步         __CFRunLoopDoBlocks();      } while (!stop && !timeout);      //退出RunLoop     __CFRunLoopDoObservers(CFRunLoopExit); }

根据这个RunLoop我们能够通过CFRunLoopObserverRef来度量。用GCD里的dispatch_semaphore_t开启一个新线程，设置一个极限值和出现次数的值，然后获取主线程上在kCFRunLoopBeforeSources到kCFRunLoopBeforeWaiting再到kCFRunLoopAfterWaiting两个状态之间的超过了极限值和出现次数的场景，将堆栈dump下来，最后发到服务器做收集，通过堆栈能够找到对应出问题的那个方法。

static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {     MyClass *object = (__bridge MyClass*)info;     object->activity = activity; }  - (void)registerObserver {     CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};     CFRunLoopObserverRef observer = CFRunLoopObserverCreate(kCFAllocatorDefault,                                                             kCFRunLoopAllActivities,                                                             YES,                                                             0,                                                             &runLoopObserverCallBack,                                                             &context);     CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes); }  static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {     MyClass *object = (__bridge MyClass*)info;      object->activity = activity;      dispatch_semaphore_t semaphore = moniotr->semaphore;     dispatch_semaphore_signal(semaphore); }  - (void)registerObserver {     CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};     CFRunLoopObserverRef observer = CFRunLoopObserverCreate(kCFAllocatorDefault,                                                             kCFRunLoopAllActivities,                                                             YES,                                                             0,                                                             &runLoopObserverCallBack,                                                             &context);     //检测主线程     CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);      semaphore = dispatch_semaphore_create(0);      //开始开启一个新线程来监控主线程两个状态消耗的时间     dispatch_async(dispatch_get_global_queue(0, 0), ^{         while (YES)         {             //设置30ms连续3次就报卡顿             long semaphoreWait = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 30*NSEC_PER_MSEC));             if (semaphoreWait != 0)             {                 if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting)                 {                     if (++timeoutCount < 3)                         continue;                     //dump堆栈，上报服务器的处理放在这                 }             }             timeoutCount = 0;         }     }); }

有时候造成卡顿是因为数据异常，过多，或者过大造成的，亦或者是操作的异常出现的，这样的情况可能在平时日常开发测试中难以遇到，但是在真实的特别是用户受众广的情况下会有人出现，这样这种收集卡顿的方式还是有价值的。

开发时需要注意如何避免一些性能问题

NSDateFormatter

通过Instruments的检测会发现创建NSDateFormatter或者设置NSDateFormatter的属性的耗时总是排在前面，如何处理这个问题呢，比较推荐的是添加属性或者创建静态变量，这样能够使得创建初始化这个次数降到最低。还有就是可以直接用C，或者这个NSData的Category来解决 https://github.com/samsoffes/sstoolkit/blob/master/SSToolkit/NSData%2BSSToolkitAdditions.m

UIImage

这里要主要是会影响内存的开销，需要权衡下imagedNamed和imageWithContentsOfFile，了解两者特性后，在只需要显示一次的图片用后者，这样会减少内存的消耗，但是页面显示会增加Image IO的消耗，这个需要注意下。由于imageWithContentsOfFile不缓存，所以需要在每次页面显示前加载一次，这个IO的操作也是需要考虑权衡的一个点。