Xcode tools: THE GOOD PARTS
All the tools available to us for use with Xcode are divided into 3 types: tools for testing applications under Mac OS X, tools for testing applications developed under iOS, and tools accessible only when testing in a simulator. We mention this so that the beginning developer will understand that some serious problems can only be caught using a simulator (for example: zombies), while other problems can only be detected on a device.
Now, primarily we are interested in how, using the tools, we can quickly and easily find the serious problems arising during application creation. Today we will talk about memory.
Activity Monitor Tool
All this tool does is collect the information on current system activity. Using this tool, we can learn about the application’s consumption of system resources.
This is the window of our document with the Activity Monitor tool. I have highlighted what is necessary for us to pay attention to. Let's examine in detail what is shown in the marked areas.
Tables visually demonstrate a system condition, which is why they are very useful.
Real Mem
The numbers in this column refer to the size of physical memory which is required by the app for its work at the current time. What is meant by “Virtual Mem”
Virtual memory is the memory allocated to store a part of real memory data temporarily, thereby releasing real memory and then to return the data from virtual memory to the real memory. On that point, the story about virtual memory could be ended, but...
One of employees was interested in my work and he asked: ”And who looks at this virtual memory at all ?”.
Really, why should we look at it? Now the system allows the use of 18 exabytes of virtual memory and it is hard enough to fill it completely within the limits of one application. (Download VirtualMemory).
Let's find a line in a code:
test = (char *) malloc (1024*1024*400);
Here we request the amount of the memory to be allocated… for a film, for example. Start the application together with the tool and we can see. What is wrong here? The space for the film is situated in virtual memory where it waits to be addressed. That’s it! As soon as we address this memory space – it will be transferred from virtual memory to the real memory! It seems to me that the device won't be happy to have the whole film in operative memory.
Have you noticed the button in the interface of the app? :) There is a method in a code which makes the reference to virtual memory. Here it is:
- (void) letsDoThis1 {
for (int i = 0; i <1024 * 1024 * 400; i + = 4 * 1024) {
test [i] = i;
}
}
This code writes down a certain bit of information in every 4th kilobyte of the memory. Thus we transform the memory into real memory. I took each step in 4 kilobytes intentionally. Try to change the value from 4 to a lower value, for example to 2 or 1.
You might expect that the occupied memory should increase, but that is not true and the tool will confirm it. This is characteristic of memory paging . For those who are interested, you can read about it in detail here:
These are the basic concepts that are necessary to know for estimating the work of the application using the Activity Monitor tool. It is possible to start application testing on the device.
Memory Warnings
The application starts to receive memory warnings when there is not enough memory for it to work. There are 5 levels of memory consumption.
typedef enum {
OSMemoryNotificationLevelAny = -1,
OSMemoryNotificationLevelNormal = 0,
OSMemoryNotificationLevelWarning = 1,
OSMemoryNotificationLevelUrgent = 2,
OSMemoryNotificationLevelCritical = 3
} OSMemoryNotificationLevel;
When a 1st level warning occurs, the operating system closes various background apps. For example if your app does not require the Internet, the Internet connection can be dropped by the system.
At the occurrence of the 2nd memory warning, the system will close your application.
At the occurrence of the 3rd , the system can be rebooted.
To determine at what level of memory consumption the memory warnings will start to appear is difficult - no one can tell for sure. It depends on how many tasks are working at the moment on the device and what the tasks are. For example, an app can receive a memory warning by working with pictures of a greater size than the maximum as specified in the documentation. Also these limits vary on different iOS versions. You could see that the same app on a 4th generation device will work normally, and here on the 3rd generation device it will not work at all because of memory warnings.
The same thing will occur on different versions of one system.
IOS works with the memory more frugally than Mac OS, therefore the data received on a simulator will differ from the data received on the device with a limit.
Not to be confused, I have written an unpretentious, but very useful application. Using it you can learn:
1) How much free memory the device has available.
2) The limits for the different memory warnings.
Features of work:
1) App works only on the device.
2) The application cache is important to its work. Simply start once again and see the collected information. (Download MemWarningTest).
Allocations Tool
Unlike the Activity Monitor, Allocations works with separate processes, instead of the entire system. The purpose of this tool is to collect the information on the created objects or memory blocks using color histograms.
The color of the histogram shows the relationship of the existing allocated objects to the peak allocation. If the color is yellow or red, the suggestion to reduce the number of created objects will be made.
But it isn't critical. The normal color of the histogram is dark blue. On the whole, the tool is useful when it is necessary to define precisely on what object too much memory is spent. The tool also allows you to receive the most detailed information on an object up to an event in a code that resulted in memory selection.
Allocations is often used together with the Activity Monitor, and there is a question while application testing : ”Why do the tools show different values? They all measure the same thing!”. That’s not true. Allocations shows only the memory which is occupied by the objects created by the app. This memory is only a part of the general memory that the app occupies. It is the important point to understand. You can only judge the system resources consumption of our app by using the Activity Monitor tool!
Memory Leaks Tool
Just as described in earlier tools, the information is displayed in tables with a detail pane and an extended detail pane.
On screen:
1. On the table the peak of red color means that a memory leak has been found.
2. Actual objects. It is possible to click on an object in the list and see the code.
3. Adjustment of the time for one step of scanning.
To understand how the tool works, where it will help us, and where it will appear useless, it is necessary to understand what a “Memory Leak” is. This phenomenon arises when, for any reason, the program loses access to the allocated section of memory in such a manner that memory is still allocated to the app, but can't be accessed any more.
The tool, over the defined intervals of time, checks the created and released memory sizes. If it finds an allocated section of memory, and access to this memory is lost, we receive a notice about the discovered leak. The important conclusion is that the tool won't specify all existing errors in the code, but only those connected with memory management.
Bad memory usage programming practices.
I suggest that you download the app since you can use it to practice absolutely harmlessly (Download app MemoryLeaks).
The app is simple and consists of 2 methods initiated by pressing 2 buttons and the main method UIViewController “viewDidLoad”.
Now, the app doesn't contain memory leaks. Probably, while looking through a code, your eyes will stop on a line:
NSString *saveButtonTitle = [[NSString alloc] init];
If you look at this method a bit more, you won't see the expected:
[saveButtonTitle release];
A good opportunity for us to check out the new tool, isn’t it?
Now, we can start the application with the Memory Leaks tool. As the line is in the method viewDidLoad, we should just wait while the app loads and the tool analyses сreated objects.
The tool hasn't found a memory leak.
Well, let's check up on another class. Let it be NSObject. You can find a line below:
//NSObject * obj = [[NSObject alloc] init];//LEAK!
Just uncomment it. (obj is also not released).
Yes, I almost forgot that after each change in a code I recommend that you rebuild.
The tool literally identifies the memory leak immediately. The feature is that some classes, such as NSString, NSArray and others are created in the special way.
You can find more detailed information here:
http://www.mulle-kybernetik.com/artikel/Optimization/opti-2.html
(I would like to point out that [saveButtonTitle release] won’t hurt anything and use of this line is a good practice for managing the memory).
And now, we simply need to address the memory allocated under saveButtonTitle:
NSString* str = [saveButtonTitle stringByAppendingString:@"blah-blah"];
The volume in virtual memory will be copied into real memory and the Memory Leaks tool will point to the long-awaited leak.
Now I would like to speak in more detail about bad practices in memory use. Catching such an oversight can take a lot of time and energy, especially if the project is big enough.
Let's find such place in an app code:
NSMutableArray* superArray = nil;
//NSObject* obj;
- (void) RemoveButtons {
if (superArray) {
NSLog(@"count = %d", [superArray count]);
for (UILabel* button in superArray) {
[button removeFromSuperview];
}
[superArray removeAllObjects];
//!
[superArray release];
//!
superArray = nil;
}
aButton.enabled = NO;
aButton.alpha = 0.5;
buttonInit.enabled = YES;
buttonInit.alpha = 1;
}
We will start the application now, and click the buttons. Leaks of memory aren't present.
The tool is right – leaks of memory aren't present, but the array is kept in memory. If we connect to the Activity Monitor testing tool now, we will see a rise in the application’s consumption of memory. Now uncomment the line:
superArray = nil;
Now we have lost the reference to our array and it still takes up space in memory since it hasn't been released. Rebuild the app and start the Memory Leaks and Activity Monitor tools. We press the “Create a file” button and then the “to Release a file” button. With the Activity Monitor tool we see the volume of consumed memory increase. Over the established interval of time the Memory Leaks tool analyzes the created objects and comes across the lost reference to an array then shows the presence of a memory leak on the schedule and detailed information about it in the detail pane.
I have deliberately increased the quantity of created objects in different classes so that you can play with them and fully understand how this remarkable tool works.
Now a few words about code analysis during the build time.
The usage of the Memory Leaks tool is not the only one way to check a code for memory leaks.
