我有一个具有多个视图的应用程序。它工作得很好,没有任何泄漏或崩溃。但是当你使用performance tool来检查漏洞时,我发现当我切换到多个视图并返回到主屏幕时,我的应用程序的整体大小就增加了。比如,在访问了4-5个不同的视图并返回屏幕后,其1.53MB的消耗会增加到1.58MB或更少,但肯定会超过1.53MB。我试着解决这个问题,但由于没有内存泄漏,我找不到哪里出了问题。
有人知道问题出在哪里吗?
苹果会以此为由拒绝我的申请吗?
发布于 2009-09-09 17:57:28
我会在屏幕之间来回切换很多次(至少一百次)。如果内存在这段时间内继续(线性地)增长,那么就有问题了。如果记忆力稳定下来,你可能会好起来。
发布于 2009-09-09 18:03:06
一定要不断尝试修复内存泄漏问题。但如果它很小,我怀疑苹果会注意到这一点。我的意思是,他们自己的应用程序也泄露了一些。当然,你可能会因此而被拒绝。但实际上,这里和那里的几个字节的泄漏不应该阻止批准本身。
(来源,两个应用程序获得批准,其中一个有相同的问题,一个小小的内存泄漏,我无法追踪。我提交了它并被批准了。不久之后,我找到并修复了它,并将其作为更新的一部分发布)。
发布于 2011-08-18 19:42:21
如果一个应用程序在一个已知的稳定状态上有越来越多的内存占用,例如在进入和返回状态B之后名为A,这应该不会对状态A有持续的影响,并且没有内存泄漏,这个问题被称为(据我所知)延迟内存。
检查清单,以确定您是否有挥之不去的内存问题:
当由Instruments.
要发现并解决此问题,请使用仪器分析您的应用程序。但是,您应该监视分配和总内存,而不是监视泄漏。每次你的应用程序到达状态A时,包括开始,获取一个内存快照。(有一个这样的按钮:D)在快照之后,转到状态B,状态C,并按预期使用您的应用程序。在返回到根状态后,在本例中为状态A,拍摄另一个快照。仪器将显示快照之间的内存分配和总内存中的差异增量。如果可能的话,它还会给出内存为哪个对象分配的信息以及分配的时间。如果是你的代码,你可能会看到类的类型和分配点。工具不能帮助您何时释放对象,但当您获得延迟对象或内存时,计算出释放点应该容易得多。
但!不要忘记:操作系统和框架代码可能像每个操作系统一样存在泄漏和挥之不去的内存问题。如果您确定这不是您的代码泄漏或在内存中徘徊,那么一切都很好。在我的应用程序中就是这样,它得到了批准(应用程序: Tusudoku)。系统函数通常使用额外内存(如果有),但当收到内存警告时,它们会立即释放内存。虽然设备的内存有限,但如果仍然不使用就是一种浪费,而且使用内存并不会使内存芯片使用的电流明显增加。使用内存达到性能极限,并在有人确实需要它时立即释放它,这是可能的最佳实践。这些缓存不会随着时间的推移呈线性增长,但你应该在每次应用程序进入根状态时强制发出内存警告,在这个例子中是状态A。这样你就可以确定系统或框架分配的任何缓存都会被释放,然后你就可以获取快照了。
App Store®上的大多数应用程序都存在内存泄漏和其他内存问题。问题是这对用户有什么影响。非线性延迟记忆在速度增加时加速迅速下降,通常不会成为拒绝的理由。计算一个完美工作的应用程序的内存使用量为15MB,但如果它工作了,没有问题,假设它将达到20MB的最大限制,你就可以继续工作了。所以你可以在以后修复你的记忆问题。但是,如果您的应用程序的内存使用量呈线性或更糟糕的增长,并且不能在需要时释放内存,这将是一个严重的问题。
有关内存使用的更多信息,请考虑阅读官方文档和观看WWDC视频(在那里我了解了使用Instruments修复内存的所有信息)。
https://stackoverflow.com/questions/1401092
复制相似问题