固然iPhone的性能越来越好,但App的功用也越来越复杂,性能历来都是移动开发的中心关注点之一。我们说一个App性能好,不是简单指觉得运转速度快,而应该是指应用启动快速、UI反响响应及时、列表滚动操作流利、内存运用合理,当然更不能呈现简单的crash了。 那么iOS的性能测试是什么? 资源耗费 内存走漏 流量耗费 耗电功率 渲染效果 加载时间 。。。 以下将分离iPhone阅读器从启动时间、加载时间、内存占用、CPU和流利度等维度引见如何完成一个iOS App的性能测试。其中会用到Apple的性能剖析神器“Instruments”。 启动时间 移动应用的启动时间是用户体验的一个重要方面,苹果不时倡议尽可能的缩短启动时间,避免用户不愿意运用它们。关于阅读器而言,由于程序启动时还会有教育页和闪屏的下发,因而启动时间的获取显得尤为重要。 启动时间分为冷启动时间和热启动时间,所谓的“冷启动”,就是一个完整没有运转的应用的启动时间,与热启动(应用曾经在后台运转,某个事情将其带至前台)相比,由于此时系统尚未树立缓存,因而冷启动常常要较平常(热启动)耗费更长的时间。 要获取精确的App启动所需时间,最简单的就是经过性能打点的措施。首先在main.c中添加如下代码: CFTimeIntervalstartTimeLog; int main(int argc, char*argv[]) { startTimeLog = CACurrentMediaTime(); 然后在AppDelegate的回调措施application:didFinishLaunchingWithOptions中添加: dispatch_async(dispatch_get_main_queue(), ^{ CGFloat launchTime = CACurrentMediaTime() - startTimeLog; NSLog(@"launch:%f", launchTime); }); 可能你会疑问为什么这样能够取得系统启动的时间,由于这个dispatch_async中提交的工作会在App主线程启动后的下一个runloop中运转,此时App曾经完成了载入并且将要显现第一帧画面,也就是系统会运转到-[UIApplication _reportAppLaunchFinished]之前。 下图是用Instruments工具Time Profiler跑的调用栈信息。 图 1 所以运用Time Profiler同样能够查看App的启动时间,细致措施如下:
为了拿到真实的用户数据,追踪版本之间的数据变更,目前阅读器线上版本中启动时间已作为性能埋点上传,这样我们就能够计算出每日不同机型不同OS的平均启动时间,以辅佐愈加实时有效的监控线上的性能质量数据。 网页加载时间 据Google Analytics数据,目前移动网页平均加载时间至少需求7秒,Google的目的是把这个时间降至1秒,由于参考Nielsan Norman Group 的调查研讨结果:假如移动网页加载时间超越 1 秒,用户就不愿停留在页面上了。 在目前的技术基础上,在几百毫秒内加载数个网页简直是不可能完成的,但在1秒内完成移动网页首页内容加载是有可能的,而剩余内容则慢慢加载。因而网页加载首屏展示时间成为了权衡手机阅读器的一个重要性能指标,计算措施为从开端加载网页到首屏内容全部展示所用的时间。 网页加载时间同样能够基于打点的措施取得。移动网页的加载都是从Webview的url央求开端的,webview的操作都会有UIWebviewDelegate的措施代理完成,因而经过对webview代理措施的研讨(见下图),选取正确的措施作为开端时间和终了时间,即可获取网页的首屏加载展示时间和网页加载完成时间。 图 2 关于竞品,我们则能够在越狱机型上经过动态库hook的措施中止加载时间的计算,简单引见如下:
关于如何运用运转时剖析及动态库注入,这里就不细致阐明了。 当然,加载时间的查看也能够借助于Apple的性能剖析神器Instruments。当我们发现App有点卡的时分,就能够经过Time Profiler来查看耗时在哪里,如图突出的范围就是步骤耗费的时间。 图 3 在这里同时分享一个基于摄像+剖析的快速中止启动时间和加载时间计算的措施。当前手机的摄像头基本上都支持高FPS的拍摄,拍下来的MP4文件能够经过免费的Avidemux工具来看细致的帧信息,也能够看到帧的时间戳,依据拍摄的格式,目前我测试的视频能够抵达30毫秒级别,完整满足性能测试的需求。 内存测试 iOS系统中内存限制是较为严厉的,因而内存优化也就成了iOS App不时以来的难题。关于内存测试的措施有很多,能够直接用Xcode真机Debug查看,也能够经过Instruments中内存相关的模板Activity Monitor取得。 图 4 Xcode调试查看内存 图 5 Activity Monitor查看内存 在实践性能测试中,内存测试常常会分场景中止,经过脚本模仿用户常用场景操作,剖析该场景下的内存占用状况。
$ instruments -w ${UDID} -t ${template}${APP} -e UIA ${} > .input.log 2. 解析ActivityMonitor模板的trace文件,生成对应的json格式数据 $ instruments_parser -p process_name -i result.trace 其中一个json块数据格式参照如下: 3. 统计ResidentSize、VirtualSize字段,运用python的matplotlib图形库生成内存变更图表。 但是关于内存测试,假如你觉得只是需求跟踪App的内存运用状况,那么你就错了。一套完好的内存管理测试计划需求关注的点其实还有很多,好比运用Leaks剖析内存走漏,运用Allocations剖析内存糜费,运用Zombie剖析野指针,运用VMTracker测试虚拟内存,代码中能否仍运用ARC机制等等。 其中关于虚拟内存的测试或许是最容易被疏忽的,阅读器就曾经发现过实践内存占用不高,但虚拟内存上涨很快,从而招致App由于内存缺乏被系统kill的问题。 那么如何剖析App的虚拟内存呢?我们能够经过Instruments的VM Tracker中止查看。VM Tracker主要用于记载App的虚拟内存分配,该模板会显现App中分配了多大的虚拟内存空间,其中多少是Dirty的内存,有多少是被映射到实践物理内存中,并且能够显现细致的虚拟内存分配状况。 图 6 VM Tracker查看虚拟内存 关于上图中的dirty size,这里引见一下dirty& clean的概念。 在程序运用的内存page中,iOS分辨两种内存,一种为clean,一种为dirty。 clean page的概念为一切能够被废弃并且重重生成的page,例如二进制代码等从磁盘读取的文件,例如不曾读写过的page,或者被标识为可擦除的内存等。 dirty page的概念为无法重重生成的page,即App生成的,并且曾经写入过的page,例如运用malloc分配的heap内存,全局变量,stack内存等。 当系统发现可用内存较少时,会将resident中的clean page中止肃清,当有需求运用时直接从磁盘读取就行。系统不能卸载掉dirtymemory,由于iOS是没有内存置换机制的。当dirty memory抵达一个上限时,应用会被kill,由系统回收内存。 说到上限,这里可能有人会问,在iOS设备中翻开很多App后,翻开被测App,该App占用内存的上限能抵达多少呢?我们能够经过demo App,手动malloc内存,也能够经过instruments查看,察看内存正告时,App被kill时的日志输出。 下表列出了对各种设备中止测试后得到的数值,供大家参考。 图 7 不同设备内存占用限制 CPU测试 CPU测试的措施和内存较为相似,能够经过Instruments中的Activity Monitor模板查看,也能够经过客户端打点的措施获取。 在阅读器性能测试中,重点模块的CPU测试还需求针对不同机型不同Architecture指令集中止兼容。例如在iPhone阅读器播放内核库的测试中就需求兼容armv7、armv7s、arm64、i386、x86-64五种CPU上都经过测试。 流利度 关于阅读器而言,会存在着较多网页阅读、动画显现等操作,这时能否存在卡顿关于用户体验就显得较为重要。关于流利度的测试我们能够经过运用instruments的core animation工具,阅读网页或加载动画,查看fps的帧数。普通而言,当用户操作时,假如fps帧数小于40,则阐明存在卡顿的情形。 图 8 Core Animation查看fps帧数 小编引见个更快速有效的措施哦: 你也能够直接选择在百度移动云测试平台_MTC上中止性能测试。模仿典型运用场景及状态,全面取得启动时长、电量、流量、CPU、内存等性能数据,并提取行业对标数据。重要的是:限时新用户免费,老用户5折优惠! 区区几文钱就能够得到下面这样的讲演 样例讲演
本文系百度独家内容,转载请在文章开头显眼处注明出处“百度QA” |