导语：定位爆内存crash原因—iOS App性能中影响各位开发友人发量的重要问题，我们通过对QAPM上报的一例sigkill有效个例的分析,为大家提供一些思路。
问题背景
在iOS App中，爆内存导致杀进程，一直是业界的难以定位的问题。App使用的内存超出设备限制，系统将强制挂起App，挂起所有后台操作、线程，直到再次点击App之后才会继续运行，而强制挂起时系统不会产生Crashlog，也无法记录Flurry。
于是就出现这种情况：爆内存导致频繁闪退，且无法获得堆栈信息进行有效定位。
通过iOS官方的工具Instruments->Allocations里的Heapshot功能来查找原因，不一定能定位到问题堆栈，还相当耗时。而QAPM-SIGKILL就能做到监控app爆内存场景，并且及时定位到问题关键堆栈信息，还能实时上报数据。
通过以下相册管家（ios）案例来说明。
案例起源
相册管家（ios）在发版前进行了灰度测试，且有开启了SIGKILL监控功能，有添加白名单进行监控。监控到一例SIGKILL问题。
案例分析
进行一轮测试后，发现有白名单用户的崩溃个例的SIGKILL上报，且已经有特征场景显示出来。
进入到相应堆栈的【详情】，分析具体SIGKILL场景堆栈。
开发同学根据上报的堆栈信息结合代码分析，马上定位到了问题原因：对尺寸过大的图片进行解码时会导致爆内存。
解决思路
根据反馈，了解到目前解决此场景爆内存的思路是：根据不同的机型内存，设定一个内存的边界值，没超过的话直接解码图片，超过则对原图片进行缩放以减少占用内存空间，并且解码图片时会把原始的图片数据分成多个tail进行解码。
感谢相册管家iOS项目同学的支持~
QAPM在不断成长中，欢迎大家多提意见，分享想法！
如果你们的iOS应用也在受到内存问题困扰或者你也对iOS内存监控技术感兴趣，那么来了解下我们的QAPM吧！
如有兴趣或任何疑问，请联系在线客服：QAPM
