gpt4 book ai didi

iphone - iOS 应用程序因常驻内存使用量很少而被抛弃

转载 作者:行者123 更新时间:2023-12-03 19:18:42 26 4
gpt4 key购买 nike

很抱歉这篇文章很长……我有写得很冗长的习惯。 :-P

我的 iOS 应用程序遇到了一个奇怪的问题,用户已经报告了几个月了。我已经研究过几次了,但一直遇到障碍。该应用程序已被废弃,但在废弃时似乎并未使用太多内存。例如,这是来自用户的一份日志(应用程序名称和标识符已更改):

Incident Identifier: OMIT
CrashReporter Key: OMIT
Hardware Model: iPhone2,1
OS Version: iPhone OS 4.3.5 (8L1)
Kernel Version: Darwin Kernel Version 11.0.0: Sat Jul 9 00:54:20 PDT 2011; root:xnu-1735.47~1/RELEASE_ARM_S5L8920X
Date: 2011-10-01 09:50:03 +0100
Time since snapshot: 41 ms

Free pages: 710
Wired pages: 10076
Purgeable pages: 416
Largest process: SpringBoard

Processes
Name UUID Count resident pages
MY_APP <f01c118296fe329899981e37e00c6cc3> 2258 (jettisoned) (active)
MobileMusicPlaye <c26fcc882cf130f09979f9ca08521fce> 1024 (jettisoned)
MobilePhone <d3042adf269630daa58e43d0ba5eeb54> 649 (jettisoned)
MobileMail <573ff3a3e09334c7aa51d8568c845e11> 716 (jettisoned)
lsd <3fafa485b73836acb973d50feabd963a> 148
notifyd <9966082842de313a8e05a001c783faf4> 117
BTServer <01550e9527353eecae41ebee0f889603> 182
CommCenter <7d9446365b4836968ae361626ef8f939> 440
SpringBoard <5c55c6fba0843b0e924e116413b8c9d4> 3305 (active)
accessoryd <d30e340e36df356bbde3347a6ed1ef87> 160 (jettisoned)
apsd <47ffc9ce9f84371588bd3f937aaa20bb> 278
configd <a6d457fca42732d9ba809d03a2b3e3ae> 427
fairplayd.N88 <46c1d3fbe93a370089f783f96a5cf531> 177
locationd <9088e845dcbe37d890c8758655bf34c6> 1065
mDNSResponder <caf94711b8093dc5bc5736306f8ae818> 200
mediaremoted <21af791e80823c9f90f0be2b77a3d885> 251
mediaserverd <c731263114c33a07aef7bccdcf667271> 1512
lockdownd <1c7f2b41744c35dc92f679e90a73e240> 278
syslogd <d81669e7bdb93f9b9012020beac826f4> 99
usbethernetshari <25130d2f9a0334e3ae28780250343144> 110
launchd <e2d41e07a0743a089eadbae765709c82> 88

**End**

这是来自 3GS 设备,从我所看到的 LowMemory 日志来看,那里没有太多运行内容(13484 页...大约 55MB?)。我们的应用程序是第二大的,但 9.3MB 的驻留量并不算大。受影响的用户使用大约 15 分钟后也会经常发生这种情况(但是,受影响的用户列表非常小)。

从日志中可以明显看出,该应用程序处于事件状态(手机处于顶部锁定状态),与报告时的情况一样。我们在被抛弃之前确实收到了低内存警告,并在所有 View 中正确实现了 viewDidUnload 和 didReceiveMemoryWarning。它似乎也释放了内存,因为 9.3MB 比正常的约 12MB 占用空间要小。而且,根据 Apple 的指南,该应用程序在顶部锁定时不会更新任何 View (因为这只是一个好主意。:-P)。我们不会在内存中保留很多东西......大多数都位于数据库中,仅在需要时才获取然后释放。我们可能为 UI 图像使用的内存比任何东西都多(应该在 viewDidUnload 中为加载的 View 释放内存)。

通过广泛的内存泄漏测试以及通过虚拟机统计和分配检查内存使用情况,我非常有信心没有内存泄漏,也没有过高的内存峰值或使用率(至少在我测试过的 3G 和 3GS 设备上) )。脏内存大小也不会显得过高(跟踪时通常约为 11 MB,总驻留内存为 12 MB)。低内存日志反射(reflect)了这一点。而且,因为我很偏执,我什至让用户受此讨论的启发而运行内存日志记录:iPhone app uses 150 MB memory and still no low memory warning! 。日志记录似乎证实了内存使用率较低(在上述抛弃之前,应用程序驻留内存报告为 9,773,056 字节)。虚拟大小很大(342,740,992),但是......它是虚拟的。 :-P

这只会影响一小部分用户,而且我只在 3GS 设备上看到过它的报告(iOS 4.x...版本各不相同,但我认为似乎是从 4.​​2 开始的)。而且,对于受影响的用户来说,这种情况总是在大约 15 分钟后发生。

我尝试让用户在报告后以最简单的用例使用该应用程序,以防出现一些奇怪的行为导致问题,但它仍然发生。这让我相信这是用户手机的问题,但我不想告诉他们如果没有任何东西可以指出这可能就是问题所在。我无法在我的 3GS 或 3G 测试设备上重现它。

这似乎不是任何常见的罪魁祸首(高脏内存使用、内存泄漏等),所以我对如何解决这个问题感到非常困惑。有什么建议么?或者至少是我可以采取的进一步调查的途径? :-P

最佳答案

切换到使用 LLVM3 后(因为 iOS 5 不支持 vanilla gcc),这个问题似乎已经消失了。更新中也有一些小的代码更改,LLVM3 的静态分析器也确实发现了一些 gcc 和泄漏都没有检测到的小内存泄漏,所以我不能明确地说问题是 gcc(在 iOS 上)特定的。但是,切换到 LLVM 3 似乎可以通过更好的静态分析直接或间接解决问题。 :-P

希望这对其他人有帮助。

关于iphone - iOS 应用程序因常驻内存使用量很少而被抛弃,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7691009/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com