iOS Abort问题系统性解决方案
一、背景
崩溃(Crash),即闪退,多指移动设备(如iOS、Android设备)在打开/使用应用程序的过程中,突然出现意外退出/中断的情况。如果App线上版本频繁发生崩溃,会极大地影响用户体验,甚至导致用户流失,以及收益减少。因此,崩溃问题是客户端稳定性团队需要重点解决的问题。
然而,对于所有崩溃场景,仅25%的崩溃可通过信号量捕获,实施相应改进;另有75%的崩溃则难以识别,从而对App的用户体验,造成了巨大的潜在影响。
Facebook的工程师将App退出分为以下6个类别:
1.App内部主动调用exit()或abort()退出;
2.App升级过程中,用户进程被杀死;
3.系统升级过程中,用户进程被杀死;
4.App在后台被杀死;
5.App在前台被杀死,且可获取堆栈;
6.App在前台被杀死,且无法获取堆栈。
对于第1~4类退出,属于App的正常退出,对用户体验没有太大影响,无需进行相应处理;对于第5类退出,可通过堆栈代码级定位崩溃原因,对此业界已形成比较成熟的解决方案,推荐免费试用阿里云的崩溃分析服务,即可快速定位、解决此类崩溃问题;对于第6类退出,可能的原因很多,包括但不限于:系统内存不足时继续申请内存、主线程卡死20s以上、CPU使用率过高Stack Overflow等,在此我们统一称之为iOS客户端的“Abort问题”。
Abort问题无法被堆栈捕获,且发生频次远高于可被捕获的崩溃(下称“堆栈崩溃”)。从历史数据来看,手淘(电商类超级App代表)的Abort问题数量一般是堆栈崩溃数量的3倍左右;优酷Pad(视频类超级App代表)的Abort问题数量一般是堆栈崩溃数量的5倍左右。可见,Abort问题对用户的使用体验造成巨大影响。
本文将针对iOS客户端的Abort问题,进行根因定位分析,并提出系统性解决方案。
二、Abort问题的原因分类
形成Abort问题的原因主要包括以下4个。
2.1 内存Jetsam
移动端设备的物理内存资源紧张,但App仍不断申请内存。因此系统signal 9杀死进程,造成异常退出。
{ "memoryPages" : { "active" : 24493, "throttled" : 0, "fileBacked" : 24113, "wired" : 13007, "anonymous" : 12915, "purgeable" : 127, "inactive" : 10955, "free" : 2290, "speculative" : 1580 }, "uncompressed" : 125795, "decompressions" : 143684 }, "largestProcess" : "Taobao4iPhone", "processes" : [ { ... { "rpages" : 2050, "states" : [ "frontmost", "resume" ], "name" : "Taobao4iPhone", "pid" : 1518, "reason" : "vm-thrashing", "fds" : 50, "uuid" : "5103a88a-917f-319e-8553-c0189dd1abac", "purgeable" : 127, "cpuTime" : 4.619693, "lifetimeMax" : 3557 }, }
2.2 主线程死锁
A/B两个线程同时等待对方完成某些操作,因而无法继续执行,形成死锁,造成异常退出。
Exception Type: 00000020 Exception Codes: 0x000000008badf00d Highlighted Thread: 0 Application Specific Information: com.myapp.myapp failed to scene-create in time Elapsed total CPU time (seconds): 4.230 (user 4.230, system 0.000), 10% CPU Elapsed application CPU time (seconds): 1.039, 3% CPU Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0: 0 libsystem_kernel.dylib 0x36360540 semaphore_wait_trap + 8 1 libdispatch.dylib 0x36297eee _dispatch_semaphore_wait_slow + 186 2 libxpc.dylib 0x364077b8 xpc_connection_send_message_with_reply_sync + 152 3 Security 0x2b8dd310 securityd_message_with_reply_sync + 64 4 Security 0x2b8dd48c securityd_send_sync_and_do + 44 5 Security 0x2b8ea452 __SecItemCopyMatching_block_invoke + 166 6 Security 0x2b8e96f6 SecOSStatusWith + 14 7 Security 0x2b8ea36e SecItemCopyMatching + 174
2.3 启动/重启超时
App由于启动/重启的时间超过系统允许的时间限制,造成异常退出。
scene-create watchdog transgression: app exhausted real (wall clock) time allowance of 19.93 seconds, Elapsed total CPU time (seconds): 21.050 (user 21.050, system 0.000)
2.4 CPU打爆
主线程死锁、启动/重启超时,都可能间接导致CPU打爆,造成异常退出。
三、Abort问题的根因定位
Abort问题常常没有明显线索进行问题定位,因此,解决难度比较大。手淘曾经历过很多次Abort问题数量飙升,但无从下手的事故,甚至还有一两次发生在双11前不久,但往往以“一群人苦逼的众测复现、复现之后也无法确定是否真的复现”收场。
因此,我们迫切需要基于已有经验,形成一套完整的解决方案,快速、准确地定位/解决问题。这就需要我们从以下几个方面着手进行考虑:
1.Abort问题发生的场景:例如,哪个页面、什么操作。
2.Abort问题发生的原因:例如,内存Jetsam、主线程死锁、启动/重启超时、CPU打爆。
3.对于内存Jetsam,需进一步定位到是否发生了内存泄露以及泄露的循环引用(Retain Cycle)。
4.对于主线程死锁,需进一步定位到卡死的堆栈。
5.对于启动/重启超时,以及CPU打爆,需进一步定位到堆栈。
接下来,我们以手淘的主线程死锁问题为例,进行根因分析。首先,来看一下某版本手淘Abort问题数据的总体视图:
由于Abort问题出现之前,内存、CPU使用量正常,因此初步判断造成异常退出的原因为主线程死锁。
查看相关日志文件,验证时间、线索吻合,因此可最终确定造成异常退出的原因为主线程死锁。
四、Abort问题的系统性解决方案
4.1 Abort系统性解决方案难点:现场捕获
为实现Abort问题的系统性解决方案,需充分考虑以下问题:
1.通过signal 9杀死进程造成的Abort问题,往往难以通过信号量捕获至堆栈。在这种情况下,应如何尽可能完整地捕获崩溃现场的关键信息?具体包含哪些信息?
2.App崩溃时系统处于极不稳定的状态,应如何保证崩溃现数据稳定落盘?
3.在信息采集、数据捕获的过程中,需对大量数据进行写入操作,应如何保证日志高性能写入?
4.在数据量较大的情况下,数据的存储、上传可能对系统造成较大压力,应如何保证数据的高压缩率?
基于以上考虑,我们提出并设计了一套基于mmap的高性能、高压缩率、高一致性、可自解释的trace文件协议,作为iOS端高可用体系的数据载体。
4.1.1 mmap数据存储层保证数据写入的高性能和高一致性
1.通过mmap将一个文件或者其它对象映射到进程的地址空间,对内存的操作会由内核将数据写到对应的磁盘文件上;数据写入的性能与内存操作相当(略比内存操作高)
2.用户进程崩溃之后,这块映射区仍由内核管理,可以保证数据的一致性
4.1.2 二进制编码协议保证数据压缩率最高
1.具体编码协议
2.实测编码在压缩率能达到80%以上,或者直观一点说,使用50k的内存可以记录下用户二十分钟内详细的使用记录,包括页面访问记录、系统事件、秒级别的内存、CPU数据。
4.1.3 尽可能多的记录系统多维度指标及异常事件
包括:
1.性能数据,包括CPU、内存数据,用于判断应用当前是不是处理overload状态
2.大内存申请
3.Retain Cycle,用于定位Jetsam Event
4.卡顿,用于定位watch dog kill
5.当前存活VC实例数量
五、总结
在App的世界里,功能层面的差异已经越来越难以体现。在这种情况下,良好的用户体验,往往是App致胜的关键。而Abort问题对于每一个App而言,都是对用户体验的最大挑战,需要App开发者给予足够的重视。
为了更好地发现解决崩溃问题,构建异常“感知-定位-恢复”的运维能力闭环,提升 App 使用体验,建议接入阿里云崩溃分析,支持各类异常事件采集,支持现场回溯分析,帮助您更好的提高iOS App稳定性。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【云栖号直播】本周重磅:阿里云“升舱计划”重磅发布
云栖号在线课堂,及时了解行业动态!阿里云推出疫情专题方案,为企业业务护航,让你足不出户了解行业动态。 在这里可以走近阿里云基础产品,了解更多应用方案,还能遇见大咖分享洞见及故事!也可以通过视频的形式让你高效、生动的了解场景化的上云最佳实践。 本周重磅推荐 标题:阿里云“升舱计划”重磅发布 简介:数字经济时代,企业数据存在海量、实时、多元化等明显的特征。传统数据仓库因存在扩展性瓶颈、计算场景单一、数据类型有限等原因,无法满足企业诉求。本议题围绕云原生数据仓库,重磅发布'升舱计划',为企业提供从传统数仓全面升级至云原生数据仓库的一站式解决方案,助力企业快速构筑新一代数字化业务体系。 观看直播 标题:LOGO设计,让品牌“智”成一派 简介:如何快速设计一款品牌LOGO,阿里云智能LOGO设计,仅需10秒一键生成"对味儿"的LOGO。 观看直播 标题:快速提升跨域应用访问体验 全球应用加速新品发布 简介:全球应用加速方案面向泛互联网、企业办公应用需求,基于阿里云全球智能广域网基础设施,一站式提供跨地域加速网络。分钟简易部署,无缝集成安全与智能解析调度能力,确保应用安全。 观看直播 标题:全站加...
- 下一篇
用这10个小技巧加速Python编程
点击上方“小白学视觉”,选择加"星标"或“置顶” 重磅干货,第一时间送达 编码很有趣,而Python编码更有趣,因为有很多不同的方法可以实现相同的功能。但是,大多数时候都有一些首选的实现方法,有些人将其称为Pythonic。这些Pythonic的共同特征是实现的代码简洁明了。 用Python或任何编码语言进行编程不是像火箭一样的科学,而主要是关于技巧。 如果有意尝试使用Pythonic编码,那么这些技术将很快成为我们工具包的一部分,并且我们会发现在项目中使用它们变得越来越自然。 因此,让我们探索其中的一些简单技巧。 1.负索引 人们喜欢使用序列,因为当我们知道元素的顺序,我们就可以按顺序操作这些元素。在Python中,字符串、元组和列表是最常见的序列数据类型。我们可以使用索引访问单个项目。与其他主流编程语言一样,Python支持基于0的索引,在该索引中,我们在一对方括号内使用零访问第一个元素。此外,我们还可以使用切片对象来检索序列的特定元素,如下面的代码示例所示。 >>> # Positive Indexing... numbers = [1, 2, 3, 4, 5,...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7设置SWAP分区,小内存服务器的救世主
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- 2048小游戏-低调大师作品