4

I have an iPad app (IOS 4.3 & 5.0) that is creating a UIView with at least 2 subviews every time the user pages forward or backward. The 2 subviews are UIWebView objects.

On every relevant swipe the old UIWebViews are removed and deallocated properly (removeFromSuperview then stopLoading and set delegate to nil) and the parent UIView is deallocated. I can confirm that both parent UIView and the 2 child UIWebViews are absolutely gone.

I can see the retain count on the webviews as they are being removed and I am quite sure that they are indeed removed every time. However my memory allocation continues to increase on every swipe by ~200-350k . No leaks in instrument but I can see the memory usage going up slowly. On iPad 1 the app eventually (within 6-10 minutes of moderate usage) receives multiple memory warnings and is terminated. LowMemory crash log...etc is generated.

We use stringByEvaluatingJavaScriptFromString and loadRequest to populate the Webviews. Memory usage creeps up even when nothing is injected or loaded into the webViews.

Is anybody experiencing this kind of behavior with UIWebViews ? Has anyone dealt with this successfully ?

Thoughs, comments & answers would be greatly appreciated.

smaura777
  • 326
  • 1
  • 3
  • 10
  • You're removing from superview, stop loading, and setting the delegate to nil, but are you *sure* you don't have an extra retain on those webviews? Possibly you're not accounting for `@property (nonatomic, retain)`? – Tim Jan 20 '12 at 19:09
  • Hi, did you have any luck fighting this? – Dan Abramov Oct 22 '12 at 17:17
  • 1
    Circular reference. One of my views was still hanging on to a controller. Pretty classic memory stuff after all, but tough to deal with in a large codebase. – smaura777 Jan 28 '13 at 01:10

3 Answers3

1

Try to use Instruments but with the "Allocations" template and watch the "# Living" columns for UIWebView. I usually use it like this:

  1. Profile app with Allocations template
  2. "Warn up" the app by going thru all tabs, scroll around etc.
  3. Press "Mark Heap", this will create a "Baseline" heapshot
  4. Do the thing you think causes objects to stay around
  5. Press "Mark Heap" again, this will create a "Heapshop #" heapshot
  6. Inspect the objects in "Heapshop #" which will show size and number of objects created and alive since the last heapshot.
  7. Goto 4
Mattias Wadman
  • 11,172
  • 2
  • 42
  • 57
  • I've been doing that for the past week and it's pretty evident that something in the webviews is still hanging around even after the webview is released. Once I disabled all webviews the problem is pretty much gone. – smaura777 Jan 20 '12 at 21:36
  • Ok, so you see that #living constantly goes up for a lot of objects? – Mattias Wadman Jan 20 '12 at 21:55
0

Not aware of any leak, but if you are destroying and re-creating the same view hierarchy every swipe, why not store the views and re-use them instead?

Regardless of whether they leak, webviews are computationally expensive to set up, so re-using them and just reloading the content should give you a performance boost, and may solve your leak as well.

Nick Lockwood
  • 40,865
  • 11
  • 112
  • 103
  • That's not really an option here, and yes I did that initially and memory allocations still went up on every swipe – smaura777 Jan 20 '12 at 21:33
0

are you still seeing this issue? I traced something which looks like unbounded memory usage (not necessarily a leak, but I get low memory warnings and eventual process termination) by calling stringByEvaluatingJavaScriptFromString over and over:

[webview stringByEvaluatingJavaScriptFromString:@"something()"];

It seems like there is something odd there.

1800 INFORMATION
  • 131,367
  • 29
  • 160
  • 239
  • I'm using that method a lot, and I am seeing that as well. Unfortunately I can't replace it with something else. – smaura777 Jan 25 '12 at 03:41