IOS中判断卡顿的方案总结

FPS

FPS (Frames Per Second) 是图像领域中的定义,表示每秒渲染帧数,通常用于衡量画面的流畅度,每秒帧数越多,则表示画面越流畅,60fps 最佳,一般我们的APP的FPS 只要保持在 50-60之间,用户体验都是比较流畅的。

监测FPS也有好几种,这里只说最常用的方案,我最早是在YYFPSLabel中看到的。实现原理实现原理是向主线程的RunLoop的添加一个commonModes的CADisplayLink,每次屏幕刷新的时候都要执行CADisplayLink的方法,所以可以统计1s内屏幕刷新的次数,也就是FPS了,下面贴上我用Swift实现的代码:

class WeakProxy: NSObject {

weak var target: NSObjectProtocol?

init(target: NSObjectProtocol) {
self.target = target
super.init()
    }

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

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

class FPSLabel: UILabel {
var link:CADisplayLink!
//记录方法执行次数
var count: Int = 0
//记录上次方法执行的时间,通过link.timestamp - _lastTime计算时间间隔
var lastTime: TimeInterval = 0
var _font: UIFont!
var _subFont: UIFont!

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

override init(frame: CGRect) {
super.init(frame: frame)
if frame.size.width == 0 && frame.size.height == 0 {
self.frame.size = defaultSize
        }
self.layer.cornerRadius = 5
self.clipsToBounds = true
self.textAlignment = NSTextAlignment.center
self.isUserInteractionEnabled = false
self.backgroundColor = UIColor.white.withAlphaComponent(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: WeakProxy.init(target: self), selector: #selector(FPSLabel.tick(link:)))
        link.add(to: RunLoop.main, forMode: .commonModes)
    }

//CADisplayLink 刷新执行的方法
@objc func tick(link: CADisplayLink) {

guard lastTime != 0 else {
            lastTime = link.timestamp
return
        }

count += 1
let timePassed = link.timestamp - lastTime

//时间大于等于1秒计算一次,也就是FPSLabel刷新的间隔,不希望太频繁刷新
guard timePassed >= 1 else {
return
        }
        lastTime = link.timestamp
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")
        text.addAttribute(NSAttributedStringKey.foregroundColor, value: color, range: NSRange(location: 0, length: text.length - 3))
        text.addAttribute(NSAttributedStringKey.foregroundColor, value: UIColor.white, range: NSRange(location: text.length - 3, length: 3))
        text.addAttribute(NSAttributedStringKey.font, value: _font, range: NSRange(location: 0, length: text.length))
        text.addAttribute(NSAttributedStringKey.font, value: _subFont, range: NSRange(location: text.length - 4, length: 1))
self.attributedText = text
    }

// 把displaylin从Runloop modes中移除
deinit {
        link.invalidate()
    }

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

}

RunLoop

其实FPS中CADisplayLink的使用也是基于RunLoop,都依赖main RunLoop。我们来看看

先来看看简版的RunLoop的代码

// 1.进入loop
__CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled)

// 2.RunLoop 即将触发 Timer 回调。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
// 3.RunLoop 即将触发 Source0 (非port) 回调。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
// 4.RunLoop 触发 Source0 (非port) 回调。
sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle)
// 5.执行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);

// 6.RunLoop 的线程即将进入休眠(sleep)。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);

// 7.调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort)

// 进入休眠

// 8.RunLoop 的线程刚刚被唤醒了。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting

// 9.如果一个 Timer 到时间了,触发这个Timer的回调
__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())

// 10.如果有dispatch到main_queue的block,执行bloc
 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);

// 11.如果一个 Source1 (基于port) 发出事件了,处理这个事件
__CFRunLoopDoSource1(runloop, currentMode, source1, msg);

// 12.RunLoop 即将退出
__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);

我们可以看到RunLoop调用方法主要集中在kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting之间,有人可能会问kCFRunLoopAfterWaiting之后也有一些方法调用,为什么不监测呢,我的理解,大部分导致卡顿的的方法是在kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting之间,比如source0主要是处理App内部事件,App自己负责管理(出发),如UIEvent(Touch事件等,GS发起到RunLoop运行再到事件回调到UI)、CFSocketRef。开辟一个子线程,然后实时计算 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 两个状态区域之间的耗时是否超过某个阀值,来断定主线程的卡顿情况。

这里做法又有点不同,iOS实时卡顿监控3 是设置连续5次超时50ms认为卡顿,戴铭在 GCDFetchFeed4 中设置的是连续3次超时80ms认为卡顿的代码。以下是iOS实时卡顿监控中提供的代码:

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

// 信号
    semaphore = dispatch_semaphore_create(0);

// 注册RunLoop状态观察
CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    observer = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                       kCFRunLoopAllActivities,
YES,
0,
                                       &runLoopObserverCallBack,
                                       &context);
CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);

// 在子线程监控时长
dispatch_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;
        }
    });
}

子线程Ping

但是由于主线程的RunLoop在闲置时基本处于Before Waiting状态,这就导致了即便没有发生任何卡顿,这种检测方式也总能认定主线程处在卡顿状态。这套卡顿监控方案大致思路为:创建一个子线程通过信号量去ping主线程,因为ping的时候主线程肯定是在kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting之间。每次检测时设置标记位为YES,然后派发任务到主线程中将标记位设置为NO。接着子线程沉睡超时阙值时长,判断标志位是否成功设置成NO,如果没有说明主线程发生了卡顿。ANREye5中就是使用子线程Ping的方式监测卡顿的。

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

@implementation PingThread

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

- (void)pingMainThread {
while (!self.cancelled) {
@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

以下是我用Swift实现的:

public class CatonMonitor {

enum Constants {
static let timeOutInterval: TimeInterval = 0.05
static let queueTitle = "com.roy.PerformanceMonitor.CatonMonitor"
    }

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

public init() {}

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

        isMonitoring = true
        queue.async {
while self.isMonitoring {

var timeout = true

DispatchQueue.main.async {
                    timeout = false
self.semaphore.signal()
                }

Thread.sleep(forTimeInterval: Constants.timeOutInterval)

if timeout {
let symbols = RCBacktrace.callstack(.main)
for symbol in symbols {
print(symbol.description)
                    }
                }
self.semaphore.wait()
            }
        }
    }

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

        isMonitoring = false
    }
}

CPU超过了80%

这个是Matrix-iOS 卡顿监控提到的:

我们也认为 CPU 过高也可能导致应用出现卡顿,所以在子线程检查主线程状态的同时,如果检测到 CPU 占用过高,会捕获当前的线程快照保存到文件中。目前微信应用中认为,单核 CPU 的占用超过了 80%,此时的 CPU 占用就过高了。

这种方式一般不能单独拿来作为卡顿监测,但可以像微信Matrix一样配合其他方式一起工作。

戴铭在GCDFetchFeed中如果CPU 的占用超过了 80%也捕获函数调用栈,以下是代码:

#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 消耗大于设置值时打印和记录堆栈
                    NSString *reStr = smStackOfThread(threads[i]);
                    SMCallStackModel *model = [[SMCallStackModel alloc] init];
                    model.stackStr = reStr;
//记录数据库中
                    [[[SMLagDB shareInstance] increaseWithStackModel:model] subscribeNext:^(id x) {}];
//                    NSLog(@"CPU useage overload thread stack:\n%@",reStr);
                }
            }
        }
    }
}

卡顿方法的栈信息

当我们得到卡顿的时间点,就要立即拿到卡顿的堆栈,有两种方式一种是遍历栈帧,实现原理我在iOS获取任意线程调用栈7写的挺详细的,同时开源了代码RCBacktrace,另一种方式是通过Signal获取任意线程调用栈,实现原理我在通过Signal handling(信号处理)获取任意线程调用栈写了,代码在backtrace-swift,但这种方式在调试时比较麻烦,建议用第一种方式。

以上就是IOS中判断卡顿的方案总结的详细内容,更多关于IOS卡顿检测的资料请关注我们其它相关文章!

(0)

相关推荐

  • iOS中3DTouch预览导致TableView滑动卡顿问题解决的方法

    1.发现问题 今天一早来公司,一个同事举着他的6p对我们说:"你看看这是嘛啊...怎么划不动啊..."我一看,果然,滑两下TableView,大概加载2页多就卡飞了...顿时想以是他机子太老了,物理内存不够用balabala等等原因回怼时...人家后面又说了一句:"你看人家今日头条怎么滑都没事~". 好吧,我看看好吧. 虽然是在iPhone X上录的,但上下滑动卡顿依旧非常明显 2.排除问题 没错,我和你想的一样,十有八九应该是那几个老问题导致的: Cell高度计算

  • iOS性能优化教程之页面加载速率详解

    前言 我认为在编码过程中时刻注意性能影响是有必要的,但凡事都有个度,不能为了性能耽误了开发进度.在时间紧急的情况下我们往往采用"quick and dirty"的方案来快速出成果,后面再迭代优化,即所谓的敏捷开发.与之相对应的是传统软件开发中的瀑布流开发流程. 卡顿产生的原因 在 iOS 系统中,图像内容展示到屏幕的过程需要 CPU 和 GPU 共同参与.CPU 负责计算显示内容,比如视图的创建.布局计算.图片解码.文本绘制等.随后 CPU 会将计算好的内容提交到 GPU 去,由 GP

  • iOS程序性能优化的技巧

    1. 用ARC管理内存 ARC(Automatic ReferenceCounting, 自动引用计数)和iOS5一起发布,它避免了最常见的也就是经常是由于我们忘记释放内存所造成的内存泄露.它自动为你管理retain和release的过程,所以你就不必去手动干预了.忘掉代码段结尾的release简直像记得吃饭一样简单.而ARC会自动在底层为你做这些工作.除了帮你避免内存泄露,ARC还可以帮你提高性能,它能保证释放掉不再需要的对象的内存. 2.尽量把views设置为透明 如果你有透明的Views你

  • iOS App使用GCD导致的卡顿现象及解决方法

    最近在调研 iOS app 中存在的各种卡顿现象以及解决方法. iOS App 出现卡顿(stall)的概率可能超出大部分人的想象,尤其是对于大公司旗舰型 App.一方面是由于业务功能不停累积,各个产品团队之间缺乏协调,大家都忙着增加功能,系统资源出现瓶颈.另一方面的原因是老设备更新换代太慢,iOS 设备的耐用度极好,现在还有不少 iPhone 4S 在服役,iPhone 6 作为问题设备持有量很高,据估计,现在 iPhone 6s 以前的设备占有比高达 40%. 所以,如果尝试在线上 App

  • IOS 性能优化中离屏渲染

    GPU屏幕渲染有以下两种方式: On-Screen Rendering 意为当前屏幕渲染,指的是GPU的渲染操作是在当前用于显示的屏幕缓冲区中进行. Off-Screen Rendering 意为离屏渲染,指的是GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作. 特殊的离屏渲染: 如果将不在GPU的当前屏幕缓冲区中进行的渲染都称为离屏渲染,那么就还有另一种特殊的"离屏渲染"方式: CPU渲染. 如果我们重写了drawRect方法,并且使用任何Core Graphics的技术进行了

  • iOS 无卡顿同时使用圆角、阴影和边框的实现

    在 iOS 开发中,最怕看到设计稿里圆角.阴影和边框同时出现,这三兄弟简直就是性能杀手. 优化的方法百度一下有很多,虽然方法不同但是原理都一样. 分享一个我自己一直使用的方法:在一个 View 里只应用一种效果,然后通过组合的方式达到效果. override init(frame: CGRect) { super.init(frame: frame) imageView = UIImageView(image: UIImage(named: "img")) imageView.laye

  • iOS实现高性能简单易用的星星评分控件

    前言 做为老司机的你们有没有遇到过这样的需求?每个商品或者商家的item都有个星级或者其他评分,大概像以下的效果图 实现方案: 大神自己写个通用空间(在时间充足的情况下) 网上找个比较好的第三方 (时间比较紧凑的情况下) 更直接的,自己直接放几个ImageView或者Layer 思考:功能是实现了,但是性能好像有点受影响.具体原因要看第三方框架的实现原理,当然了也有做的很好的.我是个性能控,当我拿到这个需求的时候,也尝试用一些第三方,但结果不尽人意.最后XWStarView就此产生了. XWSt

  • IOS中判断卡顿的方案总结

    FPS FPS (Frames Per Second) 是图像领域中的定义,表示每秒渲染帧数,通常用于衡量画面的流畅度,每秒帧数越多,则表示画面越流畅,60fps 最佳,一般我们的APP的FPS 只要保持在 50-60之间,用户体验都是比较流畅的. 监测FPS也有好几种,这里只说最常用的方案,我最早是在YYFPSLabel中看到的.实现原理实现原理是向主线程的RunLoop的添加一个commonModes的CADisplayLink,每次屏幕刷新的时候都要执行CADisplayLink的方法,所

  • iOS中判断Emoji表情问题

    先给大家说下问题描述 服务器端不支持Emoji表情,因此客户端在上传用户输入时,不能包含Emoji表情. 解决方案 在客户端发送请求前,判断用户输入中是否含有表情,如果含有表情,则提示用户重新输入.这个过程关键是如何判断字符串中是否含有Emoji表情.要判断是否含有Emoji表情,必须先了解什么是Emoji. Emoji 是一套起源于日本的12x12像素表情符号,由栗田穣崇(Shigetaka Kurit)创作,最早在日本网络及手机用户中流行,自苹果公司发布的iOS 5输入法中加入了emoji后

  • 浅析iOS中视频播放的几种方案

    1.AVPlayer (1) 优缺点 优点:可以自定义 UI, 进行控制 缺点:单纯的播放,没有控制 UI(进度,暂停,播放等按钮),而且如果要显示播放界面, 需要借助AVPlayerLayer, 添加图层到需要展示的图层上 (2)实现远程视频播放 实现播放功能(只有声音) 1.导入框架 #import <AVFoundation/AVFoundation.h> 2.通过远程 URL 创建 AVPlayer 对象 NSURL *remoteURL = [NSURL URLWithString:

  • IOS 解决UIButton 点击卡顿/延迟的问题

    前言 一开始还以为代码写的有问题,点击事件里面有比较耗时卡主线程的代码,逐一删减代码发现并不是这么回事. 正文 和参考文章里说的情况不完全相同,UIButton 并没有放在 UIScrollView 或 UITableView 上,但是 ViewController 是支持滑动返回的. ------------------华丽的分割线,搜索猜测解题中------------------ 解决办法:也没什么好办法,换成 ImageView 加 UITapGestureRecognizer 吧,另外

  • iOS中如何判断中英文混合的字符长度

    废话不多说,直接给大家贴代码了. 一,代码. - (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view. //第一种方法 NSLog(@"--first-%i",[self convertToInt:@"123我爱你"]); //第二种方法 NSLog(@"--second--%ld",[self getToInt:@&

  • Android使用ViewPager快速切换Fragment时卡顿的优化方案

    当ViewPager切换到当前的Fragment时,Fragment会加载布局并显示内容,如果用户这时快速切换ViewPager,即Fragment需要加载UI内容,而又频繁地切换Fragment,就容易产生卡顿现象(类似在ListView快速滑动的同时加载图片容易卡顿). 优化方案: 1.Fragment轻量化 如果ViewPager加载的Fragment都比较轻量,适当精简Fragment的布局,可提高Fragment加载的速度,从而减缓卡顿现象. 2.防止Fragment被销毁 ViewP

  • el-table渲染慢卡顿问题最优解决方案

    1.如下图,需要绑定两个id,第一个id是需要浮动的元素,加上scroll方法监听滑块变化,第二个id是其子元素. 2.给eagleMapContainer设置overflow属性和滑块样式,CSS参考如下 #eagleMapContainer{ overflow-y: auto; margin-top: 10px; min-height: 150px; max-height: 600px; } #eagleMapContainer::-webkit-scrollbar { width: 6px

  • iOS 中使用正则表达式判断身份证格式及银行卡号格式是否正确(推荐)

    1.有时候我们会用到上传身份证号,或者银行卡号,这个时候就需要我们对身份证号以及银行卡号,进行基本的判断. 下面便是身份证号的判断返回YES是合法,反之不合法 #pragma mark 判断身份证号是否合法 - (BOOL)judgeIdentityStringValid:(NSString *)identityString { if (identityString.length != 18) return NO; // 正则表达式判断基本 身份证号是否满足格式 NSString *regex2

随机推荐