键盘上的内存泄漏消失

Pab*_*blo 6 iphone memory-leaks

我有一个显示UITextField的视图控制器.我在这里带键盘

- (void)viewDidAppear:(BOOL)animated
{
    [wordTextField becomeFirstResponder];
}
Run Code Online (Sandbox Code Playgroud)

然后我有按钮,它关闭键盘而不关闭控制器本身:

- (void)cancel:(id)sender
{
    if([wordTextField isFirstResponder])
    {
        [wordTextField resignFirstResponder];
    }

}
Run Code Online (Sandbox Code Playgroud)

在此仪器将显示泄漏

#   Category    Event Type  Timestamp   RefCt   Address Size    Responsible Library Responsible Caller
0   Malloc 128 Bytes    Malloc  00:11.239   1   0x3b82550   128 UIKit   UIKeyboardInputManagerClassForInputMode
Run Code Online (Sandbox Code Playgroud)

[wordTextField resignFirstResponder]提到的堆栈中的某个地方.

即使我自己不带键盘并让用户触发它,我仍然有泄漏.在这种情况下,堆栈中提到的代码没有任何内容.

iPh*_*Dev 8

Leaks仪器显示在应用程序的正常过程中不会被释放的内存(因为没有任何引用它).这本身并不重要,当应用程序退出时它将是免费的.许多框架代码将分配并留下分配的这些非常小的内存块.我不知道它们是错误还是应用程序运行的必要条件.无论如何,我们必须接受它们是完全正常的.

泄漏会将这些记忆块识别为"泄漏"并且听起来很糟糕,但这并不是仪器可以帮助您识别的"泄漏".

"真正的"泄漏是在代码中可以运行多次并且分配一些永远不会释放的内存,因此随着时间的推移将消耗越来越多的内存,直到使用所有内存并且您的应用程序将崩溃.

因此,如果您有一个应用程序,无论您使用它多长时间,或者无论您如何使用它,它在苹果框架中"泄漏"128个字节,您通常不必担心.

但是,如果您有一个应用程序说,每次单击一个按钮时,它会分配一个永远不会释放的新字符串 - 无论字符串有多少字节 - 如果用户按下按钮足够多次,这将占用所有可用内存应用程序并最终崩溃.这是你需要注意的那种泄漏.

泄漏仪器实际上无法区分这两种,但你需要能够.您可能需要一种单例对象,例如,只有一个实例,并且需要在应用程序的整个生命周期中存在.您在应用启动时创建对象,实际上您永远不需要释放此对象,它可以在应用程序退出时被终止.泄漏会将其标记为泄漏,而与您合作的其他一些开发人员认为这意味着您不知道自己在做什么会像小孩子一样向老板跑去并说"他写的是真正漏洞的代码,那就是不合时宜的".你的老板,不是程序员,会认真对待他,因为听起来确实很糟糕,无论如何他从一所着名的大学中取得了2.2分的CS,所以他必须知道他是什么 谈论.什么时候它真的是完全合理的,而且正是你的意思.

因此,使用Leaks工具查找代码中会破坏应用程序的错误.不要担心在Apple框架中发现'泄漏'的每个字节.