SoFunction
Updated on 2025-04-04

Summary of the solution for stuttering judgment in IOS

FPS

FPS (Frames Per Second) is a definition in the field of images, representing the number of frames per second rendered. It is usually used to measure the smoothness of the picture. The more frames per second, the smoother the picture. 60fps is the best. Generally, as long as the FPS of our APP is kept between 50-60, the user experience is relatively smooth.

There are several types of monitoring FPS. Here we only talk about the most commonly used solutions. I was the first toYYFPSLabelSeen in. The implementation principle is to add a commonModes CADisplayLink to the main thread's RunLoop. Each time the screen refreshes, the CADisplayLink method must be executed, so you can count the number of screen refreshes within 1s, that is, FPS. The following is the code I implemented with Swift:

class WeakProxy: NSObject {

weak var target: NSObjectProtocol?

init(target: NSObjectProtocol) {
 = target
()
    }

override func responds(to aSelector: Selector!) -> Bool {
return (target?.responds(to: aSelector) ?? false) || (to: aSelector)
    }

override func forwardingTarget(for aSelector: Selector!) -> Any? {
return target
    }
}

class FPSLabel: UILabel {
var link:CADisplayLink!
//Record method execution timesvar count: Int = 0
//Record the time of the last method execution, calculate the time interval through - _lastTimevar lastTime: TimeInterval = 0
var _font: UIFont!
var _subFont: UIFont!

    fileprivate let defaultSize = CGSize(width: 55,height: 20)

override init(frame: CGRect) {
(frame: frame)
if  == 0 &&  == 0 {
 = defaultSize
        }
 = 5
 = true
 = 
 = false
 = (0.7)

        _font = UIFont(name: "Menlo", size: 14)
if _font != nil {
            _subFont = UIFont(name: "Menlo", size: 4)
        }else{
            _font = UIFont(name: "Courier", size: 14)
            _subFont = UIFont(name: "Courier", size: 4)
        }

        link = CADisplayLink(target: (target: self), selector: #selector((link:)))
        (to: , forMode: .commonModes)
    }

//CADisplayLink refresh execution method@objc func tick(link: CADisplayLink) {

guard lastTime != 0 else {
            lastTime = 
return
        }

count += 1
let timePassed =  - lastTime

//Time is greater than or equal to 1 second, which is the interval of FPSLabel refresh. Do not want to refresh too frequentlyguard timePassed >= 1 else {
return
        }
        lastTime = 
let fps = Double(count) / timePassed
count = 0

let progress = fps / 60.0
let color = UIColor(hue: CGFloat(0.27 * (progress - 0.2)), saturation: 1, brightness: 0.9, alpha: 1)

let text = NSMutableAttributedString(string: "\(Int(round(fps))) FPS")
        (, value: color, range: NSRange(location: 0, length:  - 3))
        (, value: , range: NSRange(location:  - 3, length: 3))
        (, value: _font, range: NSRange(location: 0, length: ))
        (, value: _subFont, range: NSRange(location:  - 4, length: 1))
 = text
    }

// Remove displaylin from Runloop modesdeinit {
        ()
    }

required init?(coder aDecoder: NSCoder) {
fatalError("init(coder:) has not been implemented")
    }

}

RunLoop

In fact, the use of CADisplayLink in FPS is also based on RunLoop, and they all rely on main RunLoop. Let's take a look

Let's take a look at the simple version of RunLoop code

// 1. Enter loop__CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled)

// The Timer callback will be triggered soon.__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
// The Source0 (non-port) callback will be triggered soon.__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
// Trigger the Source0 (non-port) callback.sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle)
// 5. Execute the added block__CFRunLoopDoBlocks(runloop, currentMode);

// The thread is about to enter sleep.__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);

// 7. Call mach_msg to wait for the message to accept mach_port.  The thread will go to sleep until it is awakened by one of the following events.__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort)

// Go to sleep
// The thread has just been awakened.__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting

// 9. If time comes to time, trigger the callback of this Timer__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())

// 10. If there is a block dispatch to main_queue, execute bloc __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);

// 11. If a Source1 (based on port) issues an event, handle this event__CFRunLoopDoSource1(runloop, currentMode, source1, msg);

// Quitting soon__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);

We can see that RunLoop calling methods are mainly concentrated between kCFRunLoopBeforeSources and kCFRunLoopAfterWaiting. Some people may ask that there are some method calls after kCFRunLoopAfterWaiting. Why not monitor? My understanding, most of the methods that cause lag are between kCFRunLoopBeforeSources and kCFRunLoopAfterWaiting. For example, source0 mainly deals with internal events of the App, and the App is responsible for managing (departure), such as UIEvent (Touch event, etc., GS initiates RunLoop run and then the event callback to the UI), CFSocketRef. Develop a child thread, and then calculate in real time whether the time spent between the two state areas of kCFRunLoopBeforeSources and kCFRunLoopAfterWaiting exceeds a certain threshold to determine the main thread's lag.

The method here is a bit different.iOS real-time stutter monitoring3. Set 5 consecutive times to timeout for 50ms and think it is stuck, Dai Ming isGCDFetchFeedThe code set in 4 is a code that timeouts for 80ms in a row and is considered to be stuttered. The following is the code provided in iOS real-time stutter monitoring:

- (void)start
{
if (observer)
return;

// Signal    semaphore = dispatch_semaphore_create(0);

// Register RunLoop Status ObservationCFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    observer = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                       kCFRunLoopAllActivities,
YES,
0,
                                       &runLoopObserverCallBack,
                                       &context);
CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);

// Monitor the duration on the child threaddispatch_async(dispatch_get_global_queue(0, 0), ^{
while (YES)
        {
long st = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC));
if (st != 0)
            {
if (!observer)
                {
                    timeoutCount = 0;
                    semaphore = 0;
                    activity = 0;
return;
                }

if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting)
                {
if (++timeoutCount < 5)
continue;

                    PLCrashReporterConfig *config = [[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeBSD
                                                                                       symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll];
                    PLCrashReporter *crashReporter = [[PLCrashReporter alloc] initWithConfiguration:config];

NSData *data = [crashReporter generateLiveReport];
                    PLCrashReport *reporter = [[PLCrashReport alloc] initWithData:data error:NULL];
NSString *report = [PLCrashReportTextFormatter stringValueForCrashReport:reporter
                                                                              withTextFormat:PLCrashReportTextFormatiOS];

NSLog(@"------------\n%@\n------------", report);
                }
            }
            timeoutCount = 0;
        }
    });
}

Child thread ping

However, since the main thread's RunLoop is basically in the Before Waiting state when it is idle, this detection method can always determine that the main thread is in the standstill state even if there is no lag. The general idea of ​​this lag monitoring solution is: create a child thread to ping the main thread through the semaphore, because the main thread must be between kCFRunLoopBeforeSources and kCFRunLoopAfterWaiting when pinging. Set the marker bit to YES each time the detection is detected, and then dispatch the task to the main thread to set the marker bit to NO. Then the child thread sleeps in timeout threshold, and determines whether the flag bit is successfully set to NO. If it does not indicate that the main thread has stuttered.ANREyeIn 5, it uses child thread ping to monitor lags.

@interface PingThread : NSThread
......
@end

@implementation PingThread

- (void)main {
    [self pingMainThread];
}

- (void)pingMainThread {
while (!) {
@autoreleasepool {
dispatch_async(dispatch_get_main_queue(), ^{
                [_lock unlock];
            });

CFAbsoluteTime pingTime = CFAbsoluteTimeGetCurrent();
NSArray *callSymbols = [StackBacktrace backtraceMainThread];
            [_lock lock];
if (CFAbsoluteTimeGetCurrent() - pingTime >= _threshold) {
                ......
            }
            [NSThread sleepForTimeInterval: _interval];
        }
    }
}

@end

Here is what I implemented using Swift:

public class CatonMonitor {

enum Constants {
static let timeOutInterval: TimeInterval = 0.05
static let queueTitle = ""
    }

private var queue: DispatchQueue = DispatchQueue(label: )
private var isMonitoring = false
private var semaphore: DispatchSemaphore = DispatchSemaphore(value: 0)

public init() {}

public func start() {
guard !isMonitoring else { return }

        isMonitoring = true
         {
while  {

var timeout = true

 {
                    timeout = false
()
                }

(forTimeInterval: )

if timeout {
let symbols = (.main)
for symbol in symbols {
print()
                    }
                }
()
            }
        }
    }

public func stop() {
guard isMonitoring else { return }

        isMonitoring = false
    }
}

CPU exceeds 80%

This isMatrix-iOS stutter monitoringReferred to:

We also believe that too high CPU may also cause application lag, so while the child thread checks the main thread status, if it detects that the CPU is too high, it will capture the current thread snapshot and save it to the file. Currently, WeChat applications believe that the single-core CPU occupies more than 80%, and the CPU occupies at this time is too high.

This method cannot be used alone as lag monitoring, but it can work together like WeChat Matrix.

Dai Ming also captures the function call stack if the CPU occupies more than 80% in GCDFetchFeed. The following is the code:

#define CPUMONITORRATE 80

+ (void)updateCPU {
thread_act_array_t threads;
mach_msg_type_number_t threadCount = 0;
const task_t thisTask = mach_task_self();
kern_return_t kr = task_threads(thisTask, &threads, &threadCount);
if (kr != KERN_SUCCESS) {
return;
    }
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) {
            threadBaseInfo = (thread_basic_info_t)threadInfo;
if (!(threadBaseInfo->flags & TH_FLAGS_IDLE)) {
integer_t cpuUsage = threadBaseInfo->cpu_usage / 10;
if (cpuUsage > CPUMONITORRATE) {
//cup prints and records stacks when consumption is greater than set value                    NSString *reStr = smStackOfThread(threads[i]);
                    SMCallStackModel *model = [[SMCallStackModel alloc] init];
                     = reStr;
//Record in the database                    [[[SMLagDB shareInstance] increaseWithStackModel:model] subscribeNext:^(id x) {}];
//                    NSLog(@"CPU useage overload thread stack：\n%@",reStr);
                }
            }
        }
    }
}

Stack information of the stuttering method

When we get the stuttering point, we must immediately get the stuttering stack. There are two ways: traverse the stack frame. The implementation principle isiOS gets arbitrary thread call stack7 is written in detail, and the code RCBacktrace is open sourced. Another way is to obtain any thread call stack through Signal. I wrote the implementation principle when I got any thread call stack through Signal handling (signal processing). The code is backtrace-swift, but this method is more troublesome when debugging. It is recommended to use the first method.

The above is the detailed summary of the solution to judge lag in IOS. For more information about IOS lag detection, please pay attention to my other related articles!