我正在研究IOS应用程序。在Xcode中,我将分析应用程序Run-> analyze 它显示了47个潜在的内存泄漏我检查了所有情况,在大多数情况下,不可能释放内存,在appstore中启动应用程序时会出现任何问题吗? 我已经彻底检查了它在任何地方都没有崩溃的应用程序,也没有在任何地方显示低内存警告。 因为我是IOS开发的新手,请向我建议我能做些什么呢
是否足以在viewDidUnload方法中释放内存以避免内存泄漏?
答案 0 :(得分:2)
如果它没有显示任何内存警告,则可能不会被拒绝。但是构建具有泄漏的应用程序通常不是很好的编程。你为什么不解决这些泄漏?没有一种情况您无法释放您的分配。使用自动释放或将释放消息传递给任何需要的元素。
此外,为了更好地分析您的应用,使用INSTRUMENTS运行应用程序,它会让您更好地了解泄漏的来源。
编辑:如何使用Instruments运行应用程序。
当您在Xcode中时,单击顶部菜单栏中的“运行”。在本部分中,进入使用效果工具运行,然后选择泄漏。
要了解如何使用乐器,请转here。
答案 1 :(得分:2)
注意:我没有机会玩一些像ARC这样的最新功能,所以现在可能会或可能不会过时。
是的,这可能是一个问题。根据Apple的说法,这是他们检查的一件事。然而,似乎没有什么能保证苹果审核团队的拒绝(或接受)。或许更重要的是,您希望自己作为应用程序开发人员的声誉良好,您希望能够让人们的手机更好地为他们工作
。如果做得好,您将始终释放使用new或alloc创建的任何对象。
但是要防止,追踪并消除您需要使用的内存泄漏:
分析
2.仪器泄漏
3.您自己的分析,以及需要时的同行评审
4.清洁编码,最佳实践和模式
使用Instruments Leaks性能分析工具时,请使用您的应用并尝试点击所有不同的执行路径。查看对象是否显示为泄漏。我通常优先考虑泄漏的总大小(物体大小*泄漏次数),然后向下工作直到没有泄漏出现。单击该对象将显示最近分配对象的位置附近。
我发现即使是仪器也可能无法明确捕获所有内存泄漏。
在这方面可能有帮助的另一个技巧是推断你可以在你的应用程序中做出一些不同的“循环”,一旦你返回“home”,你的应用程序应该具有与上次你相同的内存占用在那里。例如,从主屏幕开始,执行活动X,然后执行活动Y,然后返回主屏幕。让我们假设您希望,在第一个周期后,第二次和第三次返回主屏幕时,内存占用量应该相同。然后,您可以使用连接的仪器和分配的数量来练习它。这可以为您提供一些有价值的信息。
保留周期可能会发生一些有趣的事情,这可能发生在类之间存在循环依赖关系时,并且在尝试使用块执行某些操作时很容易发生。
当对象在应用程序的生命周期(如单例)中持续存在时,您可能会忽略有关内存泄漏的警告。我的意见是消除警告并在某处清除对象,作为清洁问题。
在构建时,您也会对编译器零和分析器零警告感到非常满意!
答案 2 :(得分:1)
如果您正在模拟器上进行测试,那么您可能永远不会看到低内存警告。但无论如何,所有内存泄漏都应该是可以修复的,除了那些存在于Apple框架中的内存(其中可能并不多)。
Analyze返回了哪些信息?