我看到我的应用程序在与分配工具一起使用时崩溃了。查看设备日志时,我可以看出它是“低内存”崩溃。除了我的应用程序使用的其他应用程序进程外,我的应用程序进程被放弃了。以下是设备日志的外观:
MyAPP <09da004ccd82e7a2c54e0ea6ab4eab24> 1990 (jettisoned) (active)
MobilePhone <6d3241e15be58311a76700272febc6d4> 635 (jettisoned)
accessoryd <6a25188f645a24b167cda5e0a86d486a> 121 (jettisoned)
当应用程序在没有乐器的情况下运行时,我没有遇到任何崩溃,并且用户认为该应用程序具有高性能。我一直专注于解决这个问题几天(几乎所有的代码都被评论以找到问题)。
我的问题是 - 当与乐器一起使用时,应用程序崩溃会给最终用户带来问题吗?或者这只会在调试内存问题时引起问题?
注1:在使用乐器时,我没有与应用程序进行交互。它加载一个视图控制器,进行异步服务调用,返回结果,然后填充到两个tableview中。由于仍然需要对象,因此解除分配的次数不多。
注意2:以下是应用程序崩溃时Allocations Instruments的LIVE对象列表片段(按照desc顺序按大小排序)。正如你所看到的,MYAPP并不是主要的罪犯(貌似)
Size(bytes) Responsible Library Responsible Caller
131072 UIKit -[UIView(Internal) _subclassImplementsDrawRect]
45056 CoreGraphics zone_malloc
16384 libCGFreetype.A.dylib ft_allocate
11264 Foundation NSPopAutoreleasePool
8192 libCGFreetype.A.dylib ft_allocate
8192 Foundation NSLogv
7680 libCGFreetype.A.dylib ft_allocate
7680 libCGFreetype.A.dylib ft_allocate
7680 CoreGraphics argb32_mark_constmask
5120 CoreGraphics CGDataProviderCreateWithCopyOfData
4608 libCGFreetype.A.dylib ft_allocate
4608 libCGFreetype.A.dylib ft_allocate
4608 libCGFreetype.A.dylib ft_allocate
4096 libSystem.B.dylib __stack_chk_fail
4096 QuartzCore CA::Transaction::create()
4096 Foundation NSPushAutoreleasePool
4096 MYAPP -[CJSONScanner scanNotQuoteCharactersIntoString:]
由于
答案 0 :(得分:0)