[TIMOB-3071] iOS: WebView memory is not freed

Even MORE memory madness...

Unfortunately, this is not something we have control over. I even tested in a native app outside of Titanium, and the web view's memory footprint is its own thing. There's no API on web views for controlling memory. Worse yet, NSURLCache, which the docs implies the web views would use, was not used at all, so there was nothing to cache.

Thanks for looking into it. IIRC I can't work around this by creating a new webview at the moment, because the webview memory is not freed when the JS object is deleted. Is this something that will be addressed in 1.7?

There have been quite a few memory circular retains that have been fixed for 1.7, and you'll see this most when you have a lot of non-web views and the like, especially with addEventListener. However, while the webview itself is released, the caching itself is not kept to the web view, but follows the beat of a different drummer.

Included is the test app I made. It is all native Obj-C, no titanium, to make sure it wasn't just an artifact of Titanium. It simply is a viewcontroller (similar to a Ti.UI.window) with a web view, and two buttons: One button to open up another view controller with a web view, another to try to purge the NSURLCache.

If you play with this with the allocations monitor on it, you'll see the memory jump around, sometimes almost of its own accord. One thing you'll notice is the memory behavior is quite different on simulator as opposed to on device, especially the footprint of webkit. Hitting the back does free up some memory, but not as much or as predictably as you expect. Worse yet, this memory size is completely unaffected by the Cache button.

That's disappointing news, but I understand it's not Titanium's fault, and appreciate you investigating. I wonder if http://blog.techno-barje.fr/post/2010/10/04/UIWebView-secrets-part1-memory-leaks-on-xmlhttprequest"> http://blog.techno-barje.fr/post/2010/10/04/UIWebView-secrets-part1... is at all related?

"WebKitCacheModelPreferenceKey"? Innnnteresting. I'll see what I can do with this, and more importantly, if Apple considers it private API or not. (You'd think something like a string wouldn't trip them off, but a long while ago, they claimed a well-documented POSIX string library that's been around since the 80s was 'private API'.)

Okay, an update. I didn't see much of a change in setting that key, as in it still grows as it desires, although it did seem like it might be more conservative in grabbing memory.

Either way, the NSUserDefaults is exposed in Titanium as Ti.App.properties. So to recreate the solution proposed, use the following JS in your app.js (NOT in the web page):

Titanium.App.Properties.setInt('WebKitCacheModelPreferenceKey',0);

I don't know if setting that NSUserDefault will help things, but it at least is a means to try it. Good luck.

Thanks for trying it. I'm really busy at the moment and won't have time to play around with the code you provided for a while as I really need to learn some more objC first, but I appreciate you providing it, and do plan to return to this issue when I have a chance.

Due diligence has been performed and we're placing this on hold as an Apple bug. Will redress for 1.8.