this came from a partner as helpdesk item 41851, while we have\nother mem crashes for ipad, it seemed prudent to be sure this was\nnot a sperate issue.
\nresources and crash logs located on the internal drive @\nData/Users/Thomas/bugs/41851
\n1.install and launch app in any orientation.
\n2.once the app loads, tap the first item (\"frontpage\")
\n3.rotate device
\n4.tap \"overview\" along the bottom of the screen
\n5.if you've not yet crashed, rotate the device again
results:out of mem crash
Nay news on this?
Should of course be: \"Any news on this?\"
Gah. I'm sorry for not getting back sooner on this. Since the\n10th, there's been a lot of memory leaks fixed that may solve this\nissue, but I need to meet with Thomas on whether or not the crash\nstill happens.
Soon as I open a scrollable view containing webviews with remote\npages and change an orientation, the xCode console shows a Low\nmemory warning. I tried 1.4.1.1 but all the same. (1.4.1.1 actually\ndies completely on opening a view!)
\nI can send you the project resource folder to try it out.
1.4.1.1 actually is the same as 1.4.0 in terms of leaks and the\nlike. But I'm still looking into if there's any other leaks that\nstand out or could be contributing.
Okay, there were a few crashers I was able to catch and fix, but\nthere's still a problem that is not as solvable: Webviews are\nexpensive. Or rather, they can be very expensive with loaded\npages.
\nIf you load enough pages in Safari on an iPad, you'll notice\nthat the pages you return to reload. This is because iPad with\nApple's own Safari ran out of memory with web pages, and had to\njettison some web views. In Safari, when you zoom out to see all\npages, they're just thumbnail images. This way, Safari only needs\none web view in case memory gets tight. We can't do that.
\nBecause there is no way to save state (text fields filled,\njavascript values in the web view, etc) for a web view, we can't\njettison them like we can image views, even if they're offscreen.\nThis means that multiple web views can add up very quickly,\ncompared to any other view. 1.4.0 and 1.4.1.1 have
\nSo what is happening is that there's 6 web views for the\nsections, I assume another web view to actually read, and overview\nhas another dozen web views. With so many pages loaded, especially\nsince the images are still full size, it's no wonder that the\ndevice ran out of memory.
\nI don't suppose you have any control over the content server?\nThat is, the most effective solution is for the server to prerender\nthe pages into images that can be used as image views in sections\nand overview. You'll also see a performance boost with this.
\nIf this is unfeasible, then we'll have to figure out a custom\nview or new properties to mitigate the load of web views.
I was aware of loading all web views in the overview part (in\none scroll view) was probably to much it could handle. But even\nthough I leave the overview part out and only create 5-6 web views\nin the Scrollable view (Where I thought only 2-3 should be loaded\nat the time) it comes up with memory warning as soon as you swipe\nthrough or rotate the device. But maybe this is one of the fix you\nmade.
\nI guess I can live without the overview in this form. I was\nthough hoping I could create thumbnail images in the app, but then\nevery web view have to be displayed. I have some control over the\nbackend. But I'm not sure if there is a possibility to pre-render\nthe pages on the server. But again, that will only be feasible\nsolution for the overview. We need real web pages in the sections\nviews.
\nWhat is strange, is it was first in version 1.4.x that we\ndiscovered this memory problems. There was some instability in some\nof the earlier versions, but not all of them.
\nIs it possible to get a version with the fixes you have made, so\nI can try it out?
In speaking with others, there are some more possible\nmeasures.
\nThe first thing noticed is that the images could be reduced.\nThat is, the carnival photo is 1024 * 576 pixels in size, despite\nthe web page having it be half that size onscreen. With reduced\nresolution, that could save a lot of RAM.
\nThe second thing is that, instead of thumbnail images of pages,\nwhich admittedly is nontrivial, perhaps thumbnail or mobile pages\ncould be used in places where the page would otherwise be scaled\ndown. That is, for sections and especially overview, the pages\nthemselves are simpler versions, no javascript, no videos, no ads\n(The ads would be unreadable at that size anyways) and\nthumbnail-sized versions of the images and perhaps a summary of the\narticles that are on the page.
\nBy the way, the version with the fixes, or really, any version,\nis on our continuous build server:
\nThat is actually a very god idea of having a lighter version of\nthe pages in the overview! That will definitely be considered as a\npossible solution. But do you then mean, that web view in it self\nis not the memory heavy part but rather the content i.e. the web\npage it self?
\nI'm aware of the instrument possibility in xCode, but that is\nvery difficult way of measure actual memory usage in a running app.\nIs there a any way to write actual memory usage by the app in\nlog?
\nThe main worries is of course the scrollable view (the\nsections). That is where the articles are viewed and read. I was\nconvinced that web view was jettison when needed in the scrollable\nview, but if I understand your earlier post, they are not! Is that\ncorrectly understood? that would be a big problem and actually ruin\nthe main idea behind this solution! So what are the possibilities\nfor a new properties to mitigate the load of web views when close\nto memory limits as you mentioned?
\nThank you very much for the access to the daily build site. I\nwill go right on and download the latest build, that will be\nmobilesdk-1.4.2-20100924104824-osx.zip I suppose?
\nHope you can respond to this post before the weekend is over us,\nso I have some news at the monday status meeting.
As you suggested, we have reduced the size of the webpages,\nimages and made some changes to the app, remove the scaled down\npreviews in the overview etc. So now the app is little bit more\nstable. But we will definitely need the possibility to jettison\noffscreen web views as it still crashes in the section views. The\n\"Days in pictures\" section which have image views instead of web\nviews also crashes with low memory with only few images.
\nCan you provide an e-mail address so I can send you the revised\napp code?
Sure. bhamon@appcelerator.com ,\nalthough sending to Thomas would also work. With image views, it\nmight be because we have to hold onto remote images, and don't have\nan on-disk cache. I'll look into what can be done to mitigate\nit.
Okay, I've done some more researching and here's a few\ntechniques:
\ntoImage() is a function of views (Including webviews) that\ngenerates an image based on the view at that moment. Images that\nare stored only in memory have to stay in memory. Images that are\nstored as files can be purged because the file is on disk.
\nSo, the avenues you have open are to save remote images to disk\n(The temporary folder if need be) and then point the image views to\nthe file paths. For small web views like in overview, after a page\nloads, you could call toImage, and replace the web view with an\nimage view. The scroll views without clipping example has something\nsimilar with table views. If there still is too much memory issues,\nI suppose you could move these images to files as well.
Thank you for the suggestion. I was aware of most of these\ntechnics and have experiment a great deal with it. (Scroll views\nwithout clipping, I'm not sure what that is) Downloading images\nusing image views are only possible when images are in view. And in\naddition, quite a heavy process.
Web views converted to images are only feasible for a preview\npurpose. (i have removed the overview possibility, so we don't need\nit there) - Our solution needs active web views! And we desperately\nneed a possibility to purge/mitigate offscreen web views and remote\nimages. This is vital for our solution.
\nIt was my conviction that offscreen web views and image views\nwas purged. So I was quite amazed when I found out that was not the\ncase. What are the possibilities to have a property for purging\nremote content from memory?
\nThank you in advance.
Blain
\nI have changed the way web views are loaded and displayed in the\napp. A Scrollable view is created with known count of standard\nviews. For every scroll in the view, a Web view with remote link is\nadded to the current view. Before that happens, the previous Web\nview is removed, null'ed and overwritten with the new Web View.\nThat is done in the certain, that web views are destroyed after the\nare null'ed (That should be the case, is in it?).
\nNow the app can run extensible longer, but eventually memory\nwarning, level 1 and 2, appears and the app is killed.
\nDebugging and running Allocation and Leak trace instruments in\nXCode does not seems to show any heavy leaks or memory use! Or are\nwhat? (Check the attached screen dumps from XCode and the Console\nlog).
\nAny idea what's going on here?
Support case no 48561 http://developer.appcelerator.com/helpdesk/view/48561\nis related to this ticket.
Rotating and scrolling the page do not crash the iPad any more.\nMarking fixed for Thomas to verify.
quite a but of work around this. Thor, have you had a chance to\ntry the latest CI build?
This is quite a long defect (and related HD ticket)
\nThere has been a deep technical investigation and collaboration\nbetween engineering and a customer, and many helpful pointers and\napp restructuring.
\nIt seems from my reading that we have even looked at performance\nof native code which has the same symptoms.
\nThe last action is for Thomas to verify, and I don't think we\nshould leave it open as needs-more-info.
\nIf we cannot repro, as our problem and not an issue that also\noccurs when writing native apps, then I want to see this\nclosed.
\nI am placing this back to \"fixed-in-qa\", under the 1.5.1\nrelease.
\n~Ralf
not crashing in todays 1.6.0 pull [INFO] Titanium SDK version: 1.6.0 (01/13/11\n08:11 7ca73a3)