基于 iOS 平台的性能检测方案

栏目: IOS · 发布时间: 5年前

导语

在开发过程中,功能不仅要满足业务需求,也要关注功能对 App 性能带来的一些问题。开发人员在开发阶段检测性能比较容易, iOS 端可以直接通过 instruments 工具进行检测。但是在测试阶段,测试人员要检测性能需要下载开发 工具 成本比较高。如果客户端能够将性能数据上传到服务端并且通过一些界面进行展示,对测试人员来说是一种可以检测性能的比较好的方法。

本文章主要介绍 iOS 如何通过代码采集性能数据,其中包括电池数据, CPU 数据,内存数据,卡顿数据,流量数据以及冷启动时间等。

电池数据

首先来看一下电池数据,iOS 电池数据采集方案主要有以下三种方案: UIDevice IOKit ,越狱。

1、UIDevice:提供了获取设备电池的相关信息,包括当前电池的状态以及电量。获取电池信息之前需要先将 batteryMonitoringEnabled 属性设置为 YES,然后就可以通过 batteryState 和 batteryLevel 获取电池信息。

优点:api简单,易于使用。

缺点:粗粒度,能够采集到的数据较少,不符合需求。

2、 IOKit: 是一个iOS 系统的私有框架,它可以被用来获取硬件和设备的详细信息,也是与硬件和内核服务通信的底层框架。通过它可以获取设备电量信息,精确度达到1%。

优点:可以获取较多的电池相关的数据。

缺点:因为要访问私有api,不能通过苹果审核,只能在线下取值。 获取到的值是设备的电池数据,无法达到应用级别的数据获取。

3、 越狱方案:通过iOSDiagnosticsSupport 私有库,Runtime 拿到 MBSDevice 实例,获取电量日志信息表,日志信息表中包含了 iOS 系统采集的小时级别的耗电量。

优点:可以获取到应用的耗电量。

缺点:获取到的耗电量是以小时为单位的,时间间隔太长,不符合需求。

最后,为了能够采集更多的电池数据,我们选择的方案是通过访问IOKit的私有api获取数据,并且在提交到app store时将这部门代码从包里移除掉,以免影响app的审核结果。

核心代码如下:

void *handle = dlopen("/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit",RTLD_LAZY);
s_IORegistryEntryCreateCFProperties = dlsym(handle,"IORegistryEntryCreateCFProperties");
s_kIOMasterPortDefault = dlsym(handle, "kIOMasterPortDefault");
s_IOServiceMatching= dlsym(handle, "IOServiceMatching");
s_IOServiceGetMatchingService = dlsym(handle,"IOServiceGetMatchingService");
if(s_IORegistryEntryCreateCFProperties && s_IOServiceMatching &&s_IOServiceGetMatchingService) {
g_powerSourceService = s_IOServiceMatching("IOPMPowerSource");
g_platformExpertDevice =s_IOServiceGetMatchingService(*s_kIOMasterPortDefault,g_powerSourceService);
foundSymbols = (g_powerSourceService && g_platformExpertDevice);
}
CFMutableDictionaryRef prop = NULL;
s_IORegistryEntryCreateCFProperties(g_platformExpertDevice,∝,0,0);

通过以上方式可以获取到的数据包括但不限于:

当前充电状态

电量

是否连接USB(支持iOS10以下系统)

是否有电池

最大值

电压

温度(支持iOS10以下系统)

CPU数据

iOS的线程技术是基于Mach 线程技术实现的,在 Mach 层中thread_basic_info 结构体提供了线程的基本信息,并且每个线程中包含线程的cpu_usage。获取当前App的占用率就是所有线程的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 包含多个线程,在内核提供了 task_threads API 调用获取指定 task 的线程列表以及线程个数,也就是target_task 任务中的所有线程保存在 act_list 数组中,数组中包含 act_listCnt 个条目。然后可以通过 thread_info API 调用来查询指定线程的信息。

{
task_t target_task,
thread_act_array_t *act_list,
mach_msg_type_number_t *act_listCnt
};

因此,获取当前APP的CPU占用率需要遍历所有线程,将cpu_usage求和。

接下来就是获取当前设备的CPU总占用率。 iOS中CPU状态一般包括CPU_STATE_USER, CPU_STATE_SYSTEM, CPU_STATE_IDLE 和 CPU_STATE_NICE等四种。

1、CPU_STATE_USER:运行在用户态空间或者说是用户进程。

2、CPU_STATE_SYSTEM:在内核空间运行的分配内存、IO操作、创建子进程……等。

3、CPU_STATE_IDLE:空闲状态。

4、CPU_STATE_NICE:用户空间进程的CPU的调度优先级。

因此,除了空闲状态都属于CPU占用状态,因此当前CPU的总使用率为(用户+系统+调度)/(用户+系统+调度+空闲)。通过host_statistics获取host_cpu_load_info结构体数据,该结构体中 cpu_ticks 包含了 CPU 运行时四种不同该状态的时钟脉冲的数量,并且根据这四个不同状态的时间脉冲,计算出CPU的总占用率。

int  totalUsage= (int)(user + nice + system) * 100.0 / total;

内存数据

获取内存数据同样也可以通过mach_task_basic_info结构获取resident_size值作为当前App已占用的内存大小。

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中的内存数据对不上,往往差好几兆甚至好几十兆。因此通过查找资料,有一篇文章介绍通过逆向Xcode来获取Xcode计算内存方法以及结构体。该方法获取到的已占用内存大小与Xcode的值几乎一致,可以作为一个判断标准。具体参考代码如下:

-(uint64_t)getCurMemory{

mach_msg_type_number_tinfo_count;
task_vm_info_data_t vm_info;
uint64_t curMem;
info_count = TASK_VM_INFO_COUNT;

kern_return_t kr = task_info(mach_task_self(), TASK_VM_INFO_PURGEABLE, (task_info_t)&vm_info,&info_count);
if (kr ==KERN_SUCCESS) {
curMem; = vm_info.internal + vm_info.compressed -vm_info.purgeable_volatile_pmap;
}
return curMem;
}

接下来,如果要获取当前设备可以使用的空闲内存,首先要了解iOS系统的内存分配。

基于 iOS 平台的性能检测方案

Free Memory:未使用的 RAM 容量,随时可以被应用分配使用。

Wired Memory:用来存放内核代码和数据结构,它主要为内核服务,如负责网络、文件系统之类的;对于应用、framework、一些用户级别的软件是没办法分配此内存的。但是应用程序也会对 Wired Memory 的分配有所影响。

Active Memory:活跃的内存,正在被使用或很短时间内被使用过。

Inactive Memory:最近被使用过,但是目前处于不活跃状态。

Purgeable Memory:可以理解为可释放的内存,主要是大对象或大内存块才可以使用的内存,此内存会在内存紧张的时候自动释放掉。

因此,空闲内存看成总内存大小减去 Wired Memory大小,Active Memory大小以及Inactive Memory大小。在32位系统通过这种方式获取空闲内存与Xcode数据作比较误差范围较小,而在64位系统上的数据与Xcode数据一比较误差较大,同样找到一个逆向Xcode获取Xcode的计算内存方法。64位系统获取空闲内存的具体代码如下:

vm_statistics64_data_t vminfo;
mach_msg_type_number_t count = HOST_VM_INFO64_COUNT;
host_statistics64(mach_host_self(), HOST_VM_INFO64, (host_info64_t)&vminfo,&count);

uint64_t total_used_count = (physical_memory /pagesize) - (vminfo.free_count - vminfo.speculative_count) - vminfo.external_page_count - vminfo.purgeable_count;
uint64_t free_size = ((physical_memory / pagesize) -total_used_count) * pagesize;

通过以上方式获取到的内存值与Xcode上的数据几乎一致。

卡顿数据

检测卡顿数据的方式通常有两种:一种是FPS卡顿检测,另一种是主线程卡顿检测。

FPS卡顿检测:检测当前页面的帧率,帧率越高意味着界面越流畅,通过计算丢帧率来检测当前页面的卡顿情况。

主线程卡顿检测:通过开辟一个子线程来监控主线程的RunLoop,当两个状态区域之间的耗时大于阈值时,就记为发生一次卡顿。

一、FPS卡顿检测

目前我们要采集的方主要是基于CADisplayLink以屏幕刷新频率同步绘图的特性,观察屏幕当前帧数的指示器,若帧率少于指定的帧率看成一个FPS卡顿。具体代码如下:

- (void)setupDisplayLink{
if (!_displayLink){
//创建CADisplayLink,并添加到当前run loop的NSRunLoopCommonModes
_displayLink = [CADisplayLink displayLinkWithTarget:selfselector:@selector(linkTicks:)];
[_displayLink addToRunLoop:[NSRunLoop currentRunLoop]forMode:NSRunLoopCommonModes];
}
}

-(void)linkTicks:(CADisplayLink *)link{
_scheduleTimes++; //执行次数
if(_timestamp== 0){//当前时间戳
_timestamp = link.timestamp;
}

CFTimeIntervaltimePassed = link.timestamp - _timestamp;
if(timePassed>= 1.f){//一秒采集一次
CGFloat fps = _scheduleTimes/timePassed;
_fps = fps;
_timestamp = link.timestamp;
_scheduleTimes = 0;
}
}

但是基于CADisplayLink实现的 FPS 在生产场景中只有指导意义,不能代表真实的 FPS,它无法完全检测出当前Core Animation的性能情况。

二、主线程卡顿检测

在主线程在Runloop的某个阶段进行长时间的耗时操作,因此主要思路就是开辟一个子线程去计算kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting两个状态区域之间的耗时是否超过某个阀值来断定主线程的卡顿情况。

那么,为什么要用 kCFRunLoopBeforeSourceskCFRunLoopAfterWaiting 状态进行判定呢?首先 要理清楚Runloop的运行机制,以下为RunLoop 顺序:

基于 iOS 平台的性能检测方案

看完RunLoop顺序,就可以看到处理事件主要有两个时间段 — kCFRunLoopBeforeSources 发送之后与 kCFRunLoopAfterWaiting 发送之后。dispatch_semaphore_t 是一个信号量机制,信号量到达或者超时会继续向下进行。若超时则返回的结果必定不为0,若信号量到达返回的结果为0。利用这个特性我们判断卡顿出现的条件为在信号量发送 kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting后进行了大量的操作,在一段时间内没有再发送信号量,看成超时。也就是主线程长时间的停留在这两个状态上。转换为代码就是判断有没有超时,若超时了,再判断当前停留的状态是不是这两个状态,如果是,就判定为卡顿。具体参考代码如下:

_observer= CFRunLoopObserverCreate(kCFAllocatorDefault,
kCFRunLoopAllActivities,
YES,
0,
&runLoopObserverCallBack,
&context);

dispatch_async(dispatch_get_global_queue(0, 0),^{
while (!weakSelf.needStop){
// 假定单次超时250ms,看成卡顿
long st = dispatch_semaphore_wait(_semaphore,dispatch_time(DISPATCH_TIME_NOW, 250*NSEC_PER_MSEC));
if (st != 0){
if (_activity==kCFRunLoopBeforeSources || _activity == kCFRunLoopAfterWaiting){
NSLog(@"看成一个等待时间超多250ms的卡顿");
}
}
...
}
});

流量数据

流量数据主要统计在当前App内发生的所有网络请求相应的数据大小。首先,先通过facebook提供的sonar框架捕捉app内的所有request和response。在实际的网络请求中 Request 和 Response 不一定是成对的,如果网络断开、或者突然关闭进程,都会导致不成对现象,如果将 Request 和 Response 记录在同一条数据,将会对统计造成偏差。因此request和response分开统计流量。若有对SonarKit框架感兴趣的同学可以直接访问官网进一步了解,官网:https://fbsonar.com/docs/getting-started.html

一、统计Request流量

首先需要了解请求报文的组成,如图:

基于 iOS 平台的性能检测方案

那么,Request所花费的流量就是将把Line的大小,Header的大小,空格以及Body大小累加的合。

1、Line大小的统计

Line没有可以直接转换成 CFNetwork相关数据的私有接口,但是我们很清楚 HTTP 请求报文 Line 部分的组成,因此可以手动计算Line的大小。

- (uint64_t)wbge_getLineLength {
NSString *lineStr =[NSString stringWithFormat:@"%@ %@ %@\n", self.HTTPMethod,self.URL.path, @"HTTP/1.1"];
NSData *lineData =[lineStr dataUsingEncoding:NSUTF8StringEncoding];
return lineData.length;
}

2、Header 大小统计

通过request.allHTTPHeaderFields 拿到的头部数据是有很多缺失的,并不是完整的数据。同时 由于无法直接转换到 CFNetwork 层,所以一直拿不到完整的 Header 数据。 缺少的数包括但不限于以下几个字段: Accept,Connection,Host, 当前Request的Cookie。由于 基本上缺失的都是固定的几个字段,忽略这几个字段对统计的结果影响不大。 因此主要针对cookie的数据并且手动大小进行补全。 因此总Header 的大小可以看成request.allHTTPHeaderFields数据大小加上cookie大小。

3、Body大小统计

最后是body部分,通过resquest.HTTPBody来计算Body大小。这里要注意的地方就是通过 NSURLConnection 发出的网络请求 resquest.HTTPBody 拿到的是 nil。需要通过 HTTPBodyStream 读取 stream 来获取 request 的 Body 大小。

最后,将Line大小,Header大小,Body大小相加就是当前request所话费的流量。

二、统计Response流量

请求报文的组成如下:

基于 iOS 平台的性能检测方案

那么Response所花费的流量就是将把Status Line的大小,Header的大小,空格以及Body大小累加的合。

1、StatusLine大小

NSURLResponse没有接口能直接获取报文中的 Status Line。因此,最后通过转换到 CFNetwork 相关类拿到了Status Line 的数据后计算它的大小,这其中可能涉及到了读取私有 API,因此需要注意审核问题。

2、Header大小

通过 httpResponse.allHeaderFields拿到 Header 字典,转换成 NSData 计算大小。

3、Body大小

对于 Body 的计算,采用 expectedContentLength 或者去 NSURLResponse 对象的 allHeaderFields 中获取 Content-Length 值,其实都不够准确。Content-Length 只是表示 Body 部分的大小,因此采取直接获取body大小的方式。还有一个需要注意对 gzip 情况进行区别分析。我们知道 HTTP 请求中,客户端在发送请求的时候会带上 Accept-Encoding,这个字段的值将会告知服务器客户端能够理解的内容压缩算法。而服务器进行相应时,会在 Response 中添加 Content-Encoding 告知客户端选中的压缩算法。若Content-Encoding使用了 gzip,则模拟一次 gzip 压缩,再计算字节大小。

冷启动时间

App的冷启动就是,当应用启动时,后台没有该应用的进程,这时系统会重新创建一个新的进程分配给该应用, 这个启动方式就叫做冷启动(后台不存在该应用进程)。下面先看看苹果官方文档给的应用的启动时序图,图中可以看到冷启动是一个User taps app icon到Final initialization(applicationDidFinishLaunching: withOptions:)的过程,所以冷启动时间就是从用户唤醒App开始一直到App已启动所消耗的时间。

基于 iOS 平台的性能检测方案

因此,冷启动时间 =DidLauching时间 - main()函数执行之前的时间。类的+ load方法在main函数执行之前调用,所以我们采取在+ load方法记录开始时间的方案。具体参考代码如下:

+(void)load{
NSTimeIntervalstartTime = [[NSDate date] timeIntervalSince1970];
NSString* appStartTime = [NSStringstringWithFormat:@"%0.0f",startTime*1000.0];
NSLog(@"main()函数执行之前的时间为 %@",appStartTime);
}

当applicationDidFinishLaunching:withOptions:方法执行完毕后,添加一个回调获取App DidFinishLaunching后的 时间。并且将开始时间与load开始时间相减作为应用冷启动时间。

总结

以上介绍了iOS中通过代码采集性能数据的方案,目前还在继续优化采集方案,希望本文章能够帮助大家对iOS性能数据采集的了解。

参考文章:

https://fbsonar.com/docs/getting-started.html

http://www.cocoachina.com/ios/20170629/19680.html

http://www.cocoachina.com/ios/20180606/23691.html

https://cloud.tencent.com/developer/article/1006222

https://www.jianshu.com/p/6c10ca55d343

http://ddrccw.github.io/2017/12/30/2017-12-30-reverse-xcode-with-lldb-and-hopper-disassembler/

https://www.jianshu.com/p/8e764d05275b?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

基于 iOS 平台的性能检测方案


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

未来是湿的

未来是湿的

[美] 克莱·舍基 / 胡泳、沈满琳 / 中国人民大学出版社 / 2009-5 / 39.80

一位妇女丢掉了手机,但征召了一群志愿者将其从盗窃者手中夺回。一个旅客在乘坐飞机时领受恶劣服务,她通过自己的博客发动了一场全民运动。在伦敦地铁爆炸案和印度洋海啸中,公民们用可拍照手机提供了比摄影记者更完备的记录。世界上最大的百科全书是由管理甚少的参与者们撰写的…… 不论在何处,你都能看见人们走到一起彼此分享,共同工作,或是发起某种公共行动。一部集众人之力的百科全书、一个丢失手机的传奇,这些事情......一起来看看 《未来是湿的》 这本书的介绍吧!

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具