Keyboard leak

Question

I have a view controller showing a UITextField. Here i bring the keyboard

- (void)viewDidAppear:(BOOL)animated { [wordTextField becomeFirstResponder]; } 

Then I have a button that drops the keyboard without closing the controller itself:

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

After that, the tools will show a leak on

 # Category Event Type Timestamp RefCt Address Size Responsible Library Responsible Caller 0 Malloc 128 Bytes Malloc 00:11.239 1 0x3b82550 128 UIKit UIKeyboardInputManagerClassForInputMode 

Somewhere on the stack [wordTextField resignFirstResponder] indicated.

Even if I do not bring the keyboard and do not allow the user to start it, I still have a leak. In this case, there is nothing from my code mentioned on the stack.

Answer 1

The Leaks tool shows you memory that will not be free in the normal course of the application (because there are no links to it). This in itself is not a biggie, it will be free when the application exits. Most of the frame code will allocate and leave these very small chunks of allocated memory. I have no idea if they are bugs or are important for the application to work. Be that as it may, we must admit that they are completely normal.

Leaks will identify these chunks of memory as “Leaks,” and it sounds bad, but it's not really “leaks” that the tool helps you identify.

"Real" leaks are in code that can be run many times and allocated some memory that is never freed, so more and more memory will be consumed over time until all memory is used and your application crashes.

So, if you have an application that no matter how long you use it or no matter how you use it, it “leaks” 128 bytes in the Apple framework, which you don’t need to worry about at all.

However, if you have an application that says, every time you click a button, it highlights a new line that is never released - no matter how many bytes it is - a line - if the user pressed the button enough, it will consume all the memory available to the application, and ultimately crashing. These are the leaks that you need to follow.

The leak tool realistically cannot tell the difference between the two views, but you must be able to. For example, you might need some singleton object, for example, that there is only one instance that must exist throughout the life of your application. You create an object when the application starts, and you really do not need to free this object, it can be killed when the application exits. Leaks will designate this as a leak, and some other developers you work with that suggest that you don’t know what you are doing will run to your boss like a little kid and say, “He writes really missing code, and that reeeeally bad. " And your boss, who is not a programmer, will take him seriously because he sounds bad, and in any case, he scraped 2.2 in CS from a reputable university so that he knows what he is talking about. When really it is quite reasonable and exactly what you wanted to do.

So, use the Leaks tool to find errors in the code that will ruin your application. Do not worry that every byte has detected a “leak” in the Apple frame.