When replacing HTML elements in a webView, large images for\r\nexample, the memory used by the previous element is not release\r\ncausing an overall memory usage by the webView to rise every\r\ntime.
\r\nThere is a HD ticket with a sample code:
\r\nhttp://developer.appcelerator.com/helpdesk/view/70741
Tested on Ti SDK 1.6 (Feb 7 2011 11:29 r160f5dc)
\r\niPhone Simulator with Xcode's Instruments Tools
Even MORE memory madness...
Unfortunately, this is not something we have control over. I\neven tested in a native app outside of Titanium, and the web view's\nmemory footprint is its own thing. There's no API on web views for\ncontrolling memory. Worse yet, NSURLCache, which the docs implies\nthe web views would use, was not used at all, so there was nothing\nto cache.
Thanks for looking into it. IIRC I can't work around this by\ncreating a new webview at the moment, because the webview memory is\nnot freed when the JS object is deleted. Is this something that\nwill be addressed in 1.7?
There have been quite a few memory circular retains that have\nbeen fixed for 1.7, and you'll see this most when you have a lot of\nnon-web views and the like, especially with addEventListener.\nHowever, while the webview itself is released, the caching itself\nis not kept to the web view, but follows the beat of a different\ndrummer.
\nIncluded is the test app I made. It is all native Obj-C, no\ntitanium, to make sure it wasn't just an artifact of Titanium. It\nsimply is a viewcontroller (similar to a Ti.UI.window) with a web\nview, and two buttons: One button to open up another view\ncontroller with a web view, another to try to purge the\nNSURLCache.
\nIf you play with this with the allocations monitor on it, you'll\nsee the memory jump around, sometimes almost of its own accord. One\nthing you'll notice is the memory behavior is quite different on\nsimulator as opposed to on device, especially the footprint of\nwebkit. Hitting the back does free up some memory, but not as much\nor as predictably as you expect. Worse yet, this memory size is\ncompletely unaffected by the Cache button.
That's disappointing news, but I understand it's not Titanium's\nfault, and appreciate you investigating. I wonder if \nhttp://blog.techno-barje.fr/post/2010/10/04/UIWebView-secrets-part1...\nis at all related?
\"WebKitCacheModelPreferenceKey\"? Innnnteresting. I'll see what I\ncan do with this, and more importantly, if Apple considers it\nprivate API or not. (You'd think something like a string wouldn't\ntrip them off, but a long while ago, they claimed a well-documented\nPOSIX string library that's been around since the 80s was 'private\nAPI'.)
Okay, an update. I didn't see much of a change in setting that\nkey, as in it still grows as it desires, although it did seem like\nit might be more conservative in grabbing memory.
\nEither way, the NSUserDefaults is exposed in Titanium as\nTi.App.properties. So to recreate the solution proposed, use the\nfollowing JS in your app.js (NOT in the web page):
\n\nTitanium.App.Properties.setInt('WebKitCacheModelPreferenceKey',0);
\nI don't know if setting that NSUserDefault will help things, but\nit at least is a means to try it. Good luck.
Thanks for trying it. I'm really busy at the moment and won't\nhave time to play around with the code you provided for a while as\nI really need to learn some more objC first, but I appreciate you\nproviding it, and do plan to return to this issue when I have a\nchance.
Due diligence has been performed and we're placing this on hold\nas an Apple bug. Will redress for 1.8.