var scroll = Titanium.UI.createScrollView({
contentWidth:320,
contentHeight:440,
minZoomScale:0.5,
});
scroll.add(img);
scrollView.addView(scroll);</code>
</pre>
<p>}</p>
<p>win.add(scrollView);<br>
So I noticed that every Scroll event free memory decreased by
2-3MB, looks like Titanium creates new view for current focused
view and there is NO way to release the memory. I don't understand
why memory consumes when I scroll to new view. All views already
loaded in that For cycle. I have app crash after 7-8 scrolls on my
iPhone 3G. 1.3.0 SDK</p></div>{html}

Activity

{html}<div><p>I can confirm this behaviour. Further information:</p>
<ul>
<li>Creating a new context (window.url) does not help to release
memory on close</li>
<li>Removing the window, the scrollable view or even every single
view/image (removeView) on close does not help to release
memory.</li>
<li>Setting every view to null or images to a smaller local image
does not help to release memory on close.</li>
<li>If you call the scrollable view a second time with the same
images (even in a new context), (almost) no further memory is
consumed, which is a hint that the views persist in memory.</li>
</ul>
<p>This is a show stopper for every App with a "gallery". Release:
1.4.0 on iPhone 4.0.1.</p></div>{html}

gero
added a comment - 14/Apr/11 7:52 PM {html}<div><p>I can confirm this behaviour. Further information:</p>
<ul>
<li>Creating a new context (window.url) does not help to release
memory on close</li>
<li>Removing the window, the scrollable view or even every single
view/image (removeView) on close does not help to release
memory.</li>
<li>Setting every view to null or images to a smaller local image
does not help to release memory on close.</li>
<li>If you call the scrollable view a second time with the same
images (even in a new context), (almost) no further memory is
consumed, which is a hint that the views persist in memory.</li>
</ul>
<p>This is a show stopper for every App with a "gallery". Release:
1.4.0 on iPhone 4.0.1.</p></div>{html}

{html}<div><p>This issue may be causing the application to crash. See ticket
reference: <a href=
"http://developer.appcelerator.com/helpdesk/view/73421">http://developer.appcelerator.com/helpdesk/view/73421</a></p>
<p>Does not crash on iPhone 4. Does Crash on iPad and previous
versions of iPhone. Does not crash on android.</p>
<p>Use attached app to test.</p></div>{html}

bowman9991
added a comment - 14/Apr/11 7:52 PM {html}<div><p>Same here. 20 images on the iPad in a scrollView crashes every
time, but iPhone works perfectly. Is a fix likely to make it into
1.6?</p></div>{html}

DanielAndre
added a comment - 14/Apr/11 7:52 PM {html}<div><p>Same issue here. I am tired to run around this problem. The
scrollableview is such a basic structure on an IPad. Please, i beg
you, change this priority to high.</p></div>{html}

{html}<div><p>Hi,</p>
<p>I don't think the issue is completely fixed. I am still
experiencing app crashing when scrolling through a decent number
number of hi-res images (necessary for my magazine app). Possibly a
more fundamental issue with Titanium's garbage collecting
routines?</p></div>{html}

{html}<div><p>I did some additional testing and here's what I discovered:</p>
<ul>
<li>When scrolling through a set of images, new images are loaded
to the cache, but the memory for previous (out of cache range)
images is not freed, at least until:</li>
<li>when the available memory is very low (less than 10M on a mac
running the iOS simulator), which is when GC seems to finally kick
in and free some of the resources.</li>
<li>When running on device, GC seems to kick in too late, by that
time it looks like iOS manages to force-quit the app that is
gobbling up memory.</li>
</ul>
<p>I think the GC system Titanium uses for iOS apps needs some
major improvements, and this is critical, as these issues make
Titanium largely unusable for many times of projects.
Unfortunately, I discovered this way too late (after investing more
than a month of my time into a project that is almost complete, but
still completely useless due to these memory issues).</p>
<p>Developers working on this - please advise when you expect those
major issues to be fixed? I realize the memory issues are scheduled
for the 1.7.0 release, but I for one cannot afford to wait a couple
of months on this, as I'm sure holds true to many others. I would
even be willing to chip in on the development process to accelerate
this, even though I am pretty new to Obj-C myself.</p></div>{html}

Rene Aavik
added a comment - 14/Apr/11 7:52 PM {html}<div><p>I did some additional testing and here's what I discovered:</p>
<ul>
<li>When scrolling through a set of images, new images are loaded
to the cache, but the memory for previous (out of cache range)
images is not freed, at least until:</li>
<li>when the available memory is very low (less than 10M on a mac
running the iOS simulator), which is when GC seems to finally kick
in and free some of the resources.</li>
<li>When running on device, GC seems to kick in too late, by that
time it looks like iOS manages to force-quit the app that is
gobbling up memory.</li>
</ul>
<p>I think the GC system Titanium uses for iOS apps needs some
major improvements, and this is critical, as these issues make
Titanium largely unusable for many times of projects.
Unfortunately, I discovered this way too late (after investing more
than a month of my time into a project that is almost complete, but
still completely useless due to these memory issues).</p>
<p>Developers working on this - please advise when you expect those
major issues to be fixed? I realize the memory issues are scheduled
for the 1.7.0 release, but I for one cannot afford to wait a couple
of months on this, as I'm sure holds true to many others. I would
even be willing to chip in on the development process to accelerate
this, even though I am pretty new to Obj-C myself.</p></div>{html}

{html}<div><p>renx - I agree this is not fixed...we are experiencing the same
issues with the latest build for 1.7. Also this is even worse with
table views that have a lot of images...big showstoppers.</p></div>{html}

Brian
added a comment - 14/Apr/11 7:52 PM {html}<div><p>renx - I agree this is not fixed...we are experiencing the same
issues with the latest build for 1.7. Also this is even worse with
table views that have a lot of images...big showstoppers.</p></div>{html}

{html}<div><p>I'm sorry, I should have posted the sample code. I also forgot
to specify, that my ScrollableView does not consist of pure
ImageViews, but instead of Views <strong>containing</strong>
ImageViews (this is because my design requires there to be two
images side-by-side in landscape view).</p>
<p>However, it looks like memory is now being correctly released in
the latest build of 1.7.0. I suspect the following commit did the
trick:</p>
<p><a href=
"https://github.com/appcelerator/titanium_mobile/commit/b2209783baaee620d7600b7f8ef0117b87321d47">https://github.com/appcelerator/titanium_mobile/commit/b2209783baae...</a></p>
<p>as it seems to correct to properly detach all child views of a
view being detached. This probably fixes this for situations where
ImageViews are used as children in the ScrollableView.views
array.</p>
<p>I will do some additional testing on device and report back with
sample code if I discover additional problems in this regard,
however, for now it seems the memory leak issue has been fixed.</p></div>{html}

Rene Aavik
added a comment - 14/Apr/11 7:52 PM {html}<div><p>I'm sorry, I should have posted the sample code. I also forgot
to specify, that my ScrollableView does not consist of pure
ImageViews, but instead of Views <strong>containing</strong>
ImageViews (this is because my design requires there to be two
images side-by-side in landscape view).</p>
<p>However, it looks like memory is now being correctly released in
the latest build of 1.7.0. I suspect the following commit did the
trick:</p>
<p><a href=
"https://github.com/appcelerator/titanium_mobile/commit/b2209783baaee620d7600b7f8ef0117b87321d47">
https://github.com/appcelerator/titanium_mobile/commit/b2209783baae ...</a></p>
<p>as it seems to correct to properly detach all child views of a
view being detached. This probably fixes this for situations where
ImageViews are used as children in the ScrollableView.views
array.</p>
<p>I will do some additional testing on device and report back with
sample code if I discover additional problems in this regard,
however, for now it seems the memory leak issue has been fixed.</p></div>{html}

Stephen Tramer
added a comment - 14/Apr/11 7:52 PM {html}<div><p>Yes. Master is the latest and should be considered unstable and
not generally suitable for release software, unless you absolutely
require fixes from it.</p></div>{html}