如何解决内存崩溃问题

发布于 2024-12-07 03:47:42 字数 441 浏览 3 评论 0原文

我正在创建一个具有多个动画的应用程序。 有 50 页,每页都有一个不同的动画,每个动画都使用许多图像。

我使用 UIPresentModelViewController 来呈现视图和 我正在使用 NSTimer 更改图像。

当我连续滑动时,应用程序崩溃并显示以下消息:-

Program received signal:  “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. 

(Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")

我进行了很多搜索,但找不到此问题的任何正确解决方案。

I'm creating an application which features having multiple animations.
There are 50 pages and on each page there is a different animation and each animation uses many images.

I'm using UIPresentModelViewController for presenting the views and
am changing images using NSTimer.

When I swipe continuously the application crashes with this message:-

Program received signal:  “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. 

(Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")

I searched a lot but couldn't find any proper solutions to this issue.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

池木 2024-12-14 03:47:42

只需在您的代码中检查一下您每次添加新视图但忘记释放它时是否犯了一些错误...

Just check within your code that you are making some mistake by adding new view every time but forgot to release it...

小嗲 2024-12-14 03:47:42

当崩溃时,您需要查看(也许还需要发布)堆栈跟踪。以及更改图像的代码。这听起来像是内存膨胀(并不是真正的泄漏,因为有人仍在引用内存)。 “分析”菜单项可能会捕获某些内容(并且您绝对应该运行它),但您可能需要运行“分配”工具并查看堆检查。请参阅

You need to look at (and perhaps post) the stack trace when you crash. And the code that changes the image. This sounds like memory bloat (not a true leak in that someone is still referring to memory). The Analyze menu item might catch something (and you should definitely run it), but you may need to run the Allocation instrument and look at heap checks. See http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ for more.

‘画卷フ 2024-12-14 03:47:42

对我来说这听起来像是堆栈溢出。在项目 C/C++ 语言设置的“其他 C 标志”部分中,添加“-fstack-check”标志,看看是否会出现任何不需要的递归。

This sounds like a stack overflow to me. In the "Other C Flags" section of the project's C/C++ language settings add a flag for "-fstack-check" and see if that turns up any unwanted recursion.

智商已欠费 2024-12-14 03:47:42

信号 0 通常是由于应用程序使用过多内存而导致内存不足。检查是否调用了内存警告方法。

数据格式化程序无法加载可能是由于没有足够的内存来加载它。

Signal 0 is usually due to memory low as the app using too much memory. Check whether memory warning method is called or not.

The data formatter thingy failed to load might be due to there's not enough memory to load it..

星星的軌跡 2024-12-14 03:47:42

像你描述的 50 个视图听起来像是一个巨大的内存消耗者。所以我怀疑内存管理正在卸载一些视图。然后,当您的程序需要视图时,它们不在那里,您的程序就会崩溃。错误消息不太符合这一点,但它可能无法准确地告诉您问题是什么。

考虑以下可能的场景,并查看它是否适合您编写该程序的方式。

为了让操作系统管理内存,它可以卸载视图并根据需要重新加载它们。完成此操作后,将调用 viewDidUnload、loadView 和 viewDidLoad 方法。

查看已卸载:

此方法被称为 viewDidLoad 方法的对应方法。当视图控制器需要释放其视图以及与该视图关联的任何对象以释放内存时,在内存不足的情况下会调用它。由于视图控制器通常存储对视图和其他与视图相关的对象的引用,因此您应该使用此方法放弃这些对象的所有权,以便可以回收它们的内存。您应该只对以后可以轻松重新创建的对象执行此操作,无论是在 viewDidLoad 方法中还是从应用程序的其他部分。您不应使用此方法来发布用户数据或任何其他无法轻松重新创建的信息。

加载视图:

当请求视图属性但当前为 nil 时,视图控制器调用此方法。如果您手动创建视图,则必须重写此方法并使用它来创建视图。如果您使用 Interface Builder 创建视图并初始化视图控制器(即,使用 initWithNibName:bundle: 方法初始化视图,直接设置 nibName 和 nibBundle 属性,或者在 Interface Builder 中创建视图和视图控制器)那么你不能覆盖这个方法。

检查 UIView 类参考 --

viewDidLoad:

此方法在视图控制器将其关联的视图加载到内存后调用。无论视图是存储在 nib 文件中还是在 loadView 方法中以编程方式创建,都会调用此方法。此方法最常用于对从 nib 文件加载的视图执行额外的初始化步骤。

您可能无意中在 init 方法而不是 loadView 方法中初始化了这些视图。如果您这样做,那么当操作系统卸载视图时(您将看到 viewDidUnload 被调用),与该视图和所有子视图(所有图像和动画)关联的内存将被卸载。这可以节省内存,但是当您需要重新出现其中一个已卸载的视图时,如果该视图之前已被卸载,则将首先调用 loadView 。如果您的视图设置是在 init 方法中而不是在 loadView 中完成的,则视图将不会再次设置。但如果视图设置是在loadView方法中完成的,则可以在内存管理卸载它后恢复。

50 views like you describe sounds like a big memory hog. So I suspect memory management is unloading some views. Then when your program needs the views, they are not there and your program crashes. The error message doesn't quite fit this, but it may not be accurately telling you what the problem is.

Consider the following possible scenario, and see if it fits how you coded this program.

In order for the OS to manage memory, it can unload views and reload them as needed. When this is done, the methods viewDidUnload, loadView, and viewDidLoad are called.

viewDidUnload:

This method is called as a counterpart to the viewDidLoad method. It is called during low-memory conditions when the view controller needs to release its view and any objects associated with that view to free up memory. Because view controllers often store references to views and other view-related objects, you should use this method to relinquish ownership in those objects so that the memory for them can be reclaimed. You should do this only for objects that you can easily recreate later, either in your viewDidLoad method or from other parts of your application. You should not use this method to release user data or any other information that cannot be easily recreated.

loadView:

The view controller calls this method when the view property is requested but is currently nil. If you create your views manually, you must override this method and use it to create your views. If you use Interface Builder to create your views and initialize the view controller—that is, you initialize the view using the initWithNibName:bundle: method, set the nibName and nibBundle properties directly, or create both your views and view controller in Interface Builder—then you must not override this method.

Check the UIView Class Reference --

viewDidLoad:

This method is called after the view controller has loaded its associated views into memory. This method is called regardless of whether the views were stored in a nib file or created programmatically in the loadView method. This method is most commonly used to perform additional initialization steps on views that are loaded from nib files.

You may have inadvertently initialized these views in your init methods rather than in your loadView methods. If you did this, then when the OS unloads a view (you will see viewDidUnload is called) the memory associated with the view and all subviews (all of the images and animations) will be unloaded. This saves memory, but when you need one of those unloaded views to reappear, loadView will be called first if the view had been previously unloaded. If your view setup is done in the init methods rather than in loadView, then the view will not be setup again. But if the view setup is done in loadView method, it can be recovered after memory management unloads it.

且行且努力 2024-12-14 03:47:42

有一种简单的方法可以找出通过泄漏仪器等很难找到的泄漏 - Zombies 分析仪。它显示程序中每个未链接的内存,您可以在几分钟内轻松检测泄漏并优化代码。

There is one and easy way to find out leaks that is hard to find via leaks instruments and so on - Zombies analyser. It shows every unlinked memory in your program, and you can easily detect leaks and optimize code in minutes.

や莫失莫忘 2024-12-14 03:47:42

如果您在一个动画中使用大量图像,那么您就错了。您应该有一个或多个非常大的图像,然后只显示该图像的一部分。这样您可以加载很少的图像,但具有与加载许多图像相同的效果。

研究一下 cocos2d 或其他制作游戏时流行的框架,因为它们对于动画来说比 UIKit 更高效。

If you're using lots of images for a single animation you're doing it wrong. You should have one, or several very large images and then just show a portion of that image. This way you can load very few images, but have the same affect of having many images.

Look into cocos2d or other frameworks that are popular for making games, as they will be much more efficient for animations than just UIKit.

淡墨 2024-12-14 03:47:42

使用仪器工具找出内存崩溃的原因,然后使用推荐的设计模式的最佳实践重构代码。对此没有唯一的解决方案。谢谢。

Find out the reason for memory crash using instrument tool and then refactor the code with best practises with recommended design pattern. There is no unique solution for this. Thanks.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文