[TIMOB-1786] (Partner) iPad out of mem crash on rotation

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 10th, there's been a lot of memory leaks fixed that may solve this issue, but I need to meet with Thomas on whether or not the crash still happens.

Soon as I open a scrollable view containing webviews with remote pages and change an orientation, the xCode console shows a Low memory warning. I tried 1.4.1.1 but all the same. (1.4.1.1 actually dies completely on opening a view!)
I 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 like. But I'm still looking into if there's any other leaks that stand out or could be contributing.

Okay, there were a few crashers I was able to catch and fix, but there's still a problem that is not as solvable: Webviews are expensive. Or rather, they can be very expensive with loaded pages.

If you load enough pages in Safari on an iPad, you'll notice that the pages you return to reload. This is because iPad with Apple's own Safari ran out of memory with web pages, and had to jettison some web views. In Safari, when you zoom out to see all pages, they're just thumbnail images. This way, Safari only needs one web view in case memory gets tight. We can't do that.

Because there is no way to save state (text fields filled, javascript values in the web view, etc) for a web view, we can't jettison them like we can image views, even if they're offscreen. This means that multiple web views can add up very quickly, compared to any other view. 1.4.0 and 1.4.1.1 have

So what is happening is that there's 6 web views for the sections, I assume another web view to actually read, and overview has another dozen web views. With so many pages loaded, especially since the images are still full size, it's no wonder that the device ran out of memory.

I don't suppose you have any control over the content server? That is, the most effective solution is for the server to prerender the pages into images that can be used as image views in sections and overview. You'll also see a performance boost with this.

If this is unfeasible, then we'll have to figure out a custom view or new properties to mitigate the load of web views.

I was aware of loading all web views in the overview part (in one scroll view) was probably to much it could handle. But even though I leave the overview part out and only create 5-6 web views in the Scrollable view (Where I thought only 2-3 should be loaded at the time) it comes up with memory warning as soon as you swipe through or rotate the device. But maybe this is one of the fix you made.

I guess I can live without the overview in this form. I was though hoping I could create thumbnail images in the app, but then every web view have to be displayed. I have some control over the backend. But I'm not sure if there is a possibility to pre-render the pages on the server. But again, that will only be feasible solution for the overview. We need real web pages in the sections views.

What is strange, is it was first in version 1.4.x that we discovered this memory problems. There was some instability in some of the earlier versions, but not all of them.

Is it possible to get a version with the fixes you have made, so I can try it out?

In speaking with others, there are some more possible measures.

The first thing noticed is that the images could be reduced. That is, the carnival photo is 1024 * 576 pixels in size, despite the web page having it be half that size onscreen. With reduced resolution, that could save a lot of RAM.

The second thing is that, instead of thumbnail images of pages, which admittedly is nontrivial, perhaps thumbnail or mobile pages could be used in places where the page would otherwise be scaled down. That is, for sections and especially overview, the pages themselves are simpler versions, no javascript, no videos, no ads (The ads would be unreadable at that size anyways) and thumbnail-sized versions of the images and perhaps a summary of the articles that are on the page.

By the way, the version with the fixes, or really, any version, is on our continuous build server:

http://builds.appcelerator.com.s3.amazonaws.com/index.html">http://builds.appcelerator.com.s3.amazonaws.com/index.html

That is actually a very god idea of having a lighter version of the pages in the overview! That will definitely be considered as a possible solution. But do you then mean, that web view in it self is not the memory heavy part but rather the content i.e. the web page it self?

I'm aware of the instrument possibility in xCode, but that is very difficult way of measure actual memory usage in a running app. Is there a any way to write actual memory usage by the app in log?

The main worries is of course the scrollable view (the sections). That is where the articles are viewed and read. I was convinced that web view was jettison when needed in the scrollable view, but if I understand your earlier post, they are not! Is that correctly understood? that would be a big problem and actually ruin the main idea behind this solution! So what are the possibilities for a new properties to mitigate the load of web views when close to memory limits as you mentioned?

Thank you very much for the access to the daily build site. I will go right on and download the latest build, that will be mobilesdk-1.4.2-20100924104824-osx.zip I suppose?

Hope you can respond to this post before the weekend is over us, so I have some news at the monday status meeting.

As you suggested, we have reduced the size of the webpages, images and made some changes to the app, remove the scaled down previews in the overview etc. So now the app is little bit more stable. But we will definitely need the possibility to jettison offscreen web views as it still crashes in the section views. The "Days in pictures" section which have image views instead of web views also crashes with low memory with only few images.

Can you provide an e-mail address so I can send you the revised app code?

Sure. bhamon@appcelerator.com , although sending to Thomas would also work. With image views, it might be because we have to hold onto remote images, and don't have an on-disk cache. I'll look into what can be done to mitigate it.

Okay, I've done some more researching and here's a few techniques:

toImage() is a function of views (Including webviews) that generates an image based on the view at that moment. Images that are stored only in memory have to stay in memory. Images that are stored as files can be purged because the file is on disk.

So, the avenues you have open are to save remote images to disk (The temporary folder if need be) and then point the image views to the file paths. For small web views like in overview, after a page loads, you could call toImage, and replace the web view with an image view. The scroll views without clipping example has something similar with table views. If there still is too much memory issues, I suppose you could move these images to files as well.

Thank you for the suggestion. I was aware of most of these technics and have experiment a great deal with it. (Scroll views without clipping, I'm not sure what that is) Downloading images using image views are only possible when images are in view. And in addition, quite a heavy process.

Web views converted to images are only feasible for a preview purpose. (i have removed the overview possibility, so we don't need it there) - Our solution needs active web views! And we desperately need a possibility to purge/mitigate offscreen web views and remote images. This is vital for our solution.

It was my conviction that offscreen web views and image views was purged. So I was quite amazed when I found out that was not the case. What are the possibilities to have a property for purging remote content from memory?

Thank you in advance.

Blain

I have changed the way web views are loaded and displayed in the app. A Scrollable view is created with known count of standard views. For every scroll in the view, a Web view with remote link is added to the current view. Before that happens, the previous Web view is removed, null'ed and overwritten with the new Web View. That is done in the certain, that web views are destroyed after the are null'ed (That should be the case, is in it?).

Now the app can run extensible longer, but eventually memory warning, level 1 and 2, appears and the app is killed.

Debugging and running Allocation and Leak trace instruments in XCode does not seems to show any heavy leaks or memory use! Or are what? (Check the attached screen dumps from XCode and the Console log).

Any idea what's going on here?

Support case no 48561 http://developer.appcelerator.com/helpdesk/view/48561">http://developer.appcelerator.com/helpdesk/view/48561 is related to this ticket.

Rotating and scrolling the page do not crash the iPad any more. Marking fixed for Thomas to verify.

quite a but of work around this. Thor, have you had a chance to try the latest CI build?

This is quite a long defect (and related HD ticket)

There has been a deep technical investigation and collaboration between engineering and a customer, and many helpful pointers and app restructuring.

It seems from my reading that we have even looked at performance of native code which has the same symptoms.

The last action is for Thomas to verify, and I don't think we should leave it open as needs-more-info.

If we cannot repro, as our problem and not an issue that also occurs when writing native apps, then I want to see this closed.

I am placing this back to "fixed-in-qa", under the 1.5.1 release.

~Ralf

not crashing in todays 1.6.0 pull [INFO] Titanium SDK version: 1.6.0 (01/13/11 08:11 7ca73a3)