iPad1内存神秘与我纹理密集的游戏应用程序 [英] iPad1 memory mystery with my texture-intensive game app

问题描述

对于模糊标题很抱歉，但不太确定如何总结这一点。

事实是：

• 我有一个已经获得Apple批准并在App Store上的游戏。


• 这是一个通用的应用程序。它使用在小屏幕上为320x480设计的纹​​理，并在视网膜和iPad屏幕上使用较大的纹理（大约4倍大）。


• 在开发时，我有时会看到低内存警告在控制台日志，但阅读后，这些似乎他们经常有点虚假/不重要，在任何情况下，我没有崩溃，我的测试者在各种设备（iPod Touch第2代，iPod Touch第4代，


• 当我开始通过TestFlightApp将应用程序分发给更多的beta测试人员时，我收到了一些人看到崩溃的报告应用程序正在加载，或者在用户从主菜单中选择了一个级别之后，应用程序正在加载级别纹理。我们发现，如果这些用户刚刚重新启动他们的设备，他们没有问题了。因为这是我们第一次看到这样的问题，我们把它归因于TestFlightApp正在做的事情，一些有趣的状态，它是在安装后离开设备（我们谈到了TestFlightApp这个，他们从来没有听说过这样的事情）。


• 如上所述，苹果批准了该应用，它在App Store上。不久之后，我们收到了一些iPad1用户的报告，说它在应用程序加载时崩溃了，或者很快以后，就像某些TestFlightApp用户看到的一样。再次类似于TestFlightApp用户，这些客户报告重新启动通常会解决问题。但它不是那么好，因为问题倾向于再次出现。其中一个用户给我发送了几个LowMemory ...日志文件，她下来她的电脑，同步她的iPad。有大约10个这样的文件，并且无他们列出我的程序在进程列表中。相反，它显示其他程序标记为（活动）或（放弃），最大的过程可以是从MobileSafari到Kobo，但是我的应用程序从来没有列出。所以，我不明白，但底线似乎是，至少对于这个用户，有些东西正在推动内存超过某些限制，我的应用程序将无法正常运行。


• 我后来回到了一个TestFlightApp beta测试人员，结果他确实有时会让应用程序崩溃，所以它不只是TestFlightApp的一些残留。但是，对他来说，崩溃的频率要比这个客户少得多。


• 其他iPad1游戏测试者从来没有遇到过麻烦。他们报告说，他们每天玩游戏几个小​​时，使用他们的iPad与几个其他应用程序之间，很少关闭它。同样，我从来没有与我的iPod Touch第四代碰撞，这是类似于iPad1在它有一个高分辨率屏幕，但只有256k RAM。

所以，对我来说，这些特定用户的iPad可能有什么不同，这是非常神秘的。这是神秘的游戏工作后的设备重新启动，但后一些应用程序已经运行游戏（有时）加载有麻烦。我的理解是，如果我的游戏需要内存，操作系统将自动关闭任何其他应用程序正在运行，以有效地使内存量恢复到新的重新启动的设备可用的量。我唯一的结论是，在运行一些应用程序后，设备处于较少内存可用状态，因为操作系统无法回收某些内存块或关闭某些应用程序。

不幸的是，我没有这些行为不端的设备之一。我可以想到做的是尝试减少我的应用程序的内存需求一定量，并发送给其中一个用户谁有麻烦，看看是否修复的东西。

解决方案

任何人都有更好的想法。 / div>

听起来像纹理加载过程中的内存尖峰是什么导致应用程序在一些设备上终止。它可以在之后使用比在初始加载结束时更少的内存。这可以通过将事物推送到虚拟存储器来解释，而直接纹理加载可能以太多分配来轰击RAM。我的建议是：

• 在加载期间摧毁临时数据结构更加积极（ release 临时结构，其所有有用的值已被其他事物读取/提取）


• 对于 autorelease d对象，始终保持 NSAutoreleasePool ;你甚至可以在一种方法的过程中多次尝试 drain 和re alloc c> d。


• 这可能听起来很愚蠢..有意减慢您的加载过程。如果你摆脱并行化的加载（一次加载多个对象）或可能在加载线程/方法中插入手动时间延迟，这可能会给操作系统更多的时间推送到虚拟内存，因此看门狗不会检测到应用程序

编辑：一种可能的策略来实现更慢的加载：if / when you receive低内存警告，暂停或缓慢加载几秒钟，以使其他应用程序有时间降低内存使用率，然后以正常速度继续加载。

即使我'm错误（如果 LowMemory ... log 文件显示虚拟+物理使用，因此您的应用程序甚至没有这么多），我建议，然后集成错误报告作为 QuincyKit ，以便您通过电子邮件发送回溯跟踪和崩溃说明bug在野外遇到。

Sorry for the vague title, but not quite sure how to summarize this one.

The facts are:

• I have a game that's been approved by Apple and is on the App Store.
• It is a universal app. It uses textures designed for 320x480 on small screens, and uses larger textures (roughly four times as large) on retina and iPad screens.
• While developing it, I would sometimes see low-memory warnings in the console log, but after reading about these it seemed like they were often somewhat spurious/unimportant, and in any event I was not having crashes, and my testers on a variety of devices (iPod Touch 2nd gen, iPod Touch 4th gen, iPhone3, iPhone4, iPad1, iPad2) were not seeing crashes.
• When I started distributing the app to a wider set of beta testers through TestFlightApp, I got reports of some people seeing crashes as the app was loading, or very early after the user had chosen a level from the main menu and the app was loading the level textures. We discovered that if these users just restarted their devices, they didn't have problems any more. Since this was the first time we had seen problems like this, we attributed it to something TestFlightApp was doing, some funny state it was leaving the device in after the install (we talked to TestFlightApp about this and they had never heard of such a thing).
• As stated, Apple approved the app and it's on the App Store. Soon after it went live, we got reports from some iPad1 users that it was crashing for them on app load, or soon thereafter, same kind of thing as we saw with certain TestFlightApp users. And again similar to the TestFlightApp users, these customers reported that restarting would often fix the problem. But it wasn't as nice because the problem tended to appear again. One of these users sent me several LowMemory...log files that she got off her PC after synching her iPad. There were about 10 such files, and none of them listed my program in the Processes list. Instead it showed other programs marked as either (active) or (jettisoned), and the "Largest Process" could be anything from MobileSafari to Kobo, but again my own app was never listed. So, I didn't understand that, but the bottom line seems to be that, for this user at least, something is pushing the memory over some limit where my app won't run well.
• I have since gone back and talked to one of the TestFlightApp beta testers, and it turns out that he does indeed sometimes get the app crash again, so it wasn't just some residue from TestFlightApp. However, for him the crash is much less frequent than it is for this customer.
• Other iPad1 testers of the game have never had any trouble. They report that they play the game for hours each day, use their iPad with several other apps in between, and rarely power it down. Similarly, I never had a crash with my iPod Touch 4th gen, which is similar to the iPad1 in the at it has a hi-res screen but only 256k RAM.

So, it's very mysterious to me what could be so different about these particular users' iPads. It's mysterious that the game works after the device is restarted, but then after some apps have been run the game (sometimes) has trouble loading. My understanding was that if my game demands memory, the OS will auto-close whatever other apps are running, as necessary, to effectively bring the amount of memory back up to the amount that's available on a freshly restarted device. My only conclusion is that after running some apps the device is left in a state where less memory is available because the OS cannot reclaim certain memory blocks or shut down certain apps.

Unfortunately I don't have one of these "misbehaving" devices to develop with. All I can think to do is try to reduce the memory needs of my app by a certain amount, and send it to one of these users who is having trouble and see if it fixes things. That seems like a potentially inefficient approach, however.

Anybody have a better idea?

解决方案

Sounds like the memory spike during texture loading is what's causing the app to be terminated on some devices. It may well use less memory after everything's loaded than it does right near the end of initial loading. This could be explained by things being pushed to virtual memory, whereas direct texture loading could be bombarding the RAM with way too many allocations. My suggestions would be to:

• Be more aggressive with destroying temporary data structures during loading (release a temporary structure the instant all of its useful values have been read/extracted by other things)
• For autoreleased objects, keep an NSAutoreleasePool around at all times; you may even want to drain and realloc a pool several times over the course of one method if you use an exceedingly high number of autoreleased objects.
• This may sound silly.. intentionally slow down your loading process. If you get rid of parallelized loads (loading multiple objects at once) or possibly insert a manual time delay in your loading thread/methods, this may give the OS more time to push things to virtual memory and thus Watchdog will not detect the app as being a RAM hog.

EDIT: One possible tactic to implement slower loading: if/when you receive a low memory warning, pause or slow loading down for a few seconds to give other apps time to lower their memory usage, then continue loading at normal speed.

Even if I'm wrong (if LowMemory...log files show Virtual+Physical usage and thus your app isn't even doing that much), I would suggest then integrating bug reporting such as QuincyKit so that you get emailed a backtrace and crash description when this bug IS encountered in the wild.

这篇关于iPad1内存神秘与我纹理密集的游戏应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！