最近看了runloop应用中监控卡顿的一些博客，很多人都提到了通过kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting状态判定卡顿，当时很迷惑，通过分析明白了原因，特此记录下。
网上大部分代码和下面基本相同，自己理解的难点是 RunLoop 监控卡顿为什么要用kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting状态判定，在网上找答案也没有很好的解释，通过自己的分析明白了下面代码的意义。
先说一下我对主线程卡顿的理解，就是主线程在 Runloop 的某个阶段进行长时间的耗时操作。
RunLoop 顺序
1、进入
2、通知Timer
3、通知Source
4、处理Source
5、如果有 Source1 调转到 11
6、通知 BeforWaiting
7、wait
8、通知afterWaiting
9、处理timer
10、处理 dispatch 到 main_queue 的 block
11、处理 Source1、
12、进入 2
13、退出
理清楚Runloop的运行机制，就很容易明白处理事件主要有两个时间段 kCFRunLoopBeforeSources 发送之后和 kCFRunLoopAfterWaiting 发送之后。
dispatch_semaphore_t 是一个信号量机制，信号量到达、或者 超时会继续向下进行，否则等待，如果超时则返回的结果必定不为0，信号量到达结果为0。
利用这个特性我们判断卡顿出现的条件为 在信号量发送 kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting后进行了大量的操作，在一段时间内没有再发送信号量，导致超时。也就是说主线程通知状态长时间的停留在这两个状态上了。转换为代码就是判断有没有超时，超时了，判断当前停留的状态是不是这两个状态，如果是，就判定为卡顿。
这样就能解释通为什么要用这两个信号量判断卡顿。这么一个简单的问题，思路转不过来就绕进去了，现在回看感觉这个很简单，也是耗了一天时间。
代码如下：
头文件
+ (instancetype)shareInstance;
- (void)beginMonitor;
- (void)stopMonitor;
m文件变量定义
@interface YMSubThreadMonitor()
{
CFRunLoopObserverRef ymObserver;
@public //@public 外部能访问到
CFRunLoopActivity currentRunloopActivity;
dispatch_semaphore_t semaphore;
}
@end
@implementation YMSubThreadMonitor
+ (instancetype)shareInstance{
static dispatch_once_t onceToken;
static YMSubThreadMonitor *monitor;
dispatch_once(&onceToken, ^{
monitor = [YMSubThreadMonitor new];
});
return monitor;
}
主要代码
- (void)beginMonitor{
if (ymObserver) {
return;
}
//创建观察者
/**
typedef struct {
CFIndex version;
void * info;
const void *(*retain)(const void *info);
void (*release)(const void *info);
CFStringRef (*copyDescription)(const void *info);
} CFRunLoopObserverContext;
*/
CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL,NULL};
/**
CFRunLoopObserverRef CFRunLoopObserverCreate(
CFAllocatorRef allocator,
CFOptionFlags activities,
Boolean repeats,
CFIndex order,
CFRunLoopObserverCallBack callout,
CFRunLoopObserverContext *context
);
*/
ymObserver = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &mObservercallBack, &context);
//向主线程添加 观察者
CFRunLoopRef mainLoop = CFRunLoopGetMain();
CFRunLoopAddObserver(mainLoop, ymObserver, kCFRunLoopCommonModes);
//创建子线程开始监控
dispatch_queue_t monitorQueue = dispatch_queue_create("com.ym.monitorQueue", DISPATCH_QUEUE_CONCURRENT);
//创建同步信号量
semaphore = dispatch_semaphore_create(0);
dispatch_async(monitorQueue, ^{
//开一个持续的 loop
while (YES) {
//超时时间设置
dispatch_time_t outTimer = dispatch_time(DISPATCH_TIME_NOW, 2 * NSEC_PER_SEC);
//信号量到达、或者 超时会继续向下进行，否则等待、
long result = dispatch_semaphore_wait(semaphore, outTimer);
if (result != 0) {
//超时，判断最后停留的信号量是哪一个，是否处理为卡顿现象。
if (!ymObserver) {
NSLog(@"--NO ymObserver---");
semaphore = 0;
currentRunloopActivity = 0;
return ;
}
//判断当前 监听到的 信号(也就是说上一个信号量超过2秒没有更新，故卡顿)
/**
RunLoop 顺序
1、进入
2、通知Timer
3、通知Source
4、处理Source
5、如果有 Source1 调转到 11
6、通知 BeforWaiting
7、wait
8、通知afterWaiting
9、处理timer
10、处理 dispatch 到 main_queue 的 block
11、处理 Source1、
12、进入 2
13、退出
由上可知，主要处理任务阶段为 AfterWaiting 之后、通知Source之后
如果 发送 AfterWaiting 后在限定时间内没有发送其他信号量，
可以认为这中间存在耗时操作,判定为卡顿。
同理 通知Source之后 超时也可以判定为卡顿。
*/
if (currentRunloopActivity == kCFRunLoopBeforeSources || currentRunloopActivity == kCFRunLoopAfterWaiting) {
//出现卡顿、进一步处理
NSLog(@"--卡顿啦----From 卡顿监控线程");
// log current stack info
continue;
}
}
NSLog(@"--系统运行良好--From 卡顿监控线程");
}
});
}
- (void)stopMonitor{
if (!ymObserver) {
return;
}
CFRunLoopRemoveObserver(CFRunLoopGetMain(), ymObserver, kCFRunLoopCommonModes);
CFRelease(ymObserver);
ymObserver = NULL;
}
#pragma mark -Private Method
/**
* 观察者回调函数
*/
static void mObservercallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){
//每一次监测到Runloop发送通知的时候，都会调用此函数
//在此过程修改当前的 RunloopActivity 状态，发送同步信号。
YMSubThreadMonitor *monitor = (__bridge YMSubThreadMonitor *)info;
monitor->currentRunloopActivity = activity;
dispatch_semaphore_t tempSemaphore = monitor->semaphore;
dispatch_semaphore_signal(tempSemaphore);
}
网友评论