Memory Leak Every Time Uiscrollview Is Released

Memory leak every time UIScrollView is released

What you are seeing is a known bug in iOS 5.1 and is being discussed in the iOS Developer Forums as such. You can find the relevant thread by searching in the forums for "strdup". See the thread titled "Elements App Memory Leak". Search for the post from an Apple employee.

Memory leak when scrolling UIScrollView

I'm opening a new response for this one. It's the simple solution we all missed.

From the code you posted, this is just a table view on its side. So, you don't have to build your own tiled scroll view.

Here's a bit of code to get you started. When you set up the table view, rotate it by 90 degrees, set the row height and eliminate the separator lines:

tableView.transform = CGAffineTransformMakeRotation(0.5 * M_PI);
tableView.rowHeight = 120.0;
tableView.separatorStyle = UITableViewCellSeparatorStyleNone;

You'll have to set the table view's frame so that it's in the correct position after rotation. Essentially, it's the same as your current scroll view's frame, or as that frame on its side.

Here are a couple of the table view's data source methods:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 1;
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return [appDelegate.itemArray count];
}

The table cells can be very simple custom table cells that just have a single image view and a button on that image view. You might also rotate the image view so that the image is displayed correctly, not on its side. Or, you could rotate all your images in a photo editor or image editor before loading them.

That's pretty much it. The table view, as always, will take care of recycling your cells and optimizing your memory usage.

Am I leaking memory in my UIScrollView implementation?

The code you show has a few alloc calls. After each one, you set a property, and release. I assume that the property is declared as retain.

If so, then eventually, you need to release these properties. Usually in the dealloc message implementation.

Your classes with retained properties need a dealloc like this

 -(void) dealloc() {
self.prop = nil; // calls release
self.prop2 = nil;
[super dealloc];
}

If your properties are declared like this

  @property (nonatomic, retain) Type* prop;

Then when you reassign the property with either the set message or self.prop syntax, the previous value has release called on it. If you just use prop = newVal;, then you are accessing the field directly and not calling the set message, so release will not be called.

Generally, always use the set message or dot syntax, so that you don't need to worry about it -- it's the main reason you declare the property as retain, so take advantage of it.

Memory leak even though every alloc is released

NSMutableArray *zettelPannedOrigins = [[[[NSUserDefaults standardUserDefaults] objectForKey:@"zettelPannedOrigins"] mutableCopy] retain];

This will have a retain count of 2, as mutableCopy retains it once and you are calling retain on it again. Don't call retain here.

Remember, if you call a method with new, alloc, retain or copy in the name, you then own that object and the retain count goes up.

UITableView scrolling slow, memory leak issue

The first thing you could do is try to reuse UILabels in createPopularLinkLabels. Right now, you are just removing them before adding more.

But if the number of popular links is not the same in all the cells, then you will have to remove the remaining ones or hide them and there will be no way to avoid memory allocations.

A better solution would be to insert a custom UIView inside your scroll view and draw all the texts manually instead of creating tons of subviews.

Hope this helps,
Thomas



Related Topics



Leave a reply



Submit