Hello. I investigated the memory leak issue. I have such code\n(modified KitchenSink):
\nvar scrollView = Titanium.UI.createScrollableView({
\nviews:[],\nshowPagingControl:true,\npagingControlHeight:30,\nmaxZoomScale:2.0,\ncurrentPage:1,\n\n});
\nvar dir =\nTitanium.Filesystem.getFile(Titanium.Filesystem.resourcesDirectory+'/hires');
var files = dir.getDirectoryListing();
for(i=0;i<files.length;i++)
\n{
\nvar img = Titanium.UI.createImageView({\n backgroundImage:'../hires/'+files[i],\n width:640,\n height:880,\n left:0,\n top:0,\n});\n\nvar scroll = Titanium.UI.createScrollView({\n contentWidth:320,\n contentHeight:440,\n minZoomScale:0.5,\n});\n\nscroll.add(img);\n\nscrollView.addView(scroll);\n\n}
\nwin.add(scrollView);
\nSo I noticed that every Scroll event free memory decreased by\n2-3MB, looks like Titanium creates new view for current focused\nview and there is NO way to release the memory. I don't understand\nwhy memory consumes when I scroll to new view. All views already\nloaded in that For cycle. I have app crash after 7-8 scrolls on my\niPhone 3G. 1.3.0 SDK
I can confirm this behaviour. Further information:
\nThis is a show stopper for every App with a \"gallery\". Release:\n1.4.0 on iPhone 4.0.1.
Same problem here.
The TiUIImageView.m is missing a [imageView release] at line\n308, I believe:
\n\nhttp://github.com/appcelerator/titanium_mobile/blob/master/iphone/C...
Possibly already resolved by scrollview fixes to load/unload\nmemory. Requires R&D.
This issue may be causing the application to crash. See ticket\nreference: http://developer.appcelerator.com/helpdesk/view/73421
\nDoes not crash on iPhone 4. Does Crash on iPad and previous\nversions of iPhone. Does not crash on android.
\nUse attached app to test.
Same here. 20 images on the iPad in a scrollView crashes every\ntime, but iPhone works perfectly. Is a fix likely to make it into\n1.6?
Any news? This is critical to me!
Same issue here. I am tired to run around this problem. The\nscrollableview is such a basic structure on an IPad. Please, i beg\nyou, change this priority to high.
Just to add some perspective. This bug is at least 8 months\nold.
\n\nhttp://developer.appcelerator.com/question/46061/serious-memory-leak
Traces / Instrument files here.
\nCrash Log and Console Log:
\nhttp://pastie.org/1618663
\nhttp://pastie.org/1618660
There's another HD ticket for this: http://developer.appcelerator.com/helpdesk/view/64751
(from [01937daa0e8379bb256b7b5d1e5a9ce675df397d])\n[#1441 state:fixed-in-qa] Scollable view now\nunloads offscreen views. \nhttps://github.com/appcelerator/titanium_mobile/commit/01937daa0e83...
(from [d000310a5b15c8cc03033617398835732178879d])\n[#1441] Add adjustable caching to allow rendering\nperformance/memory tradeoff. Sometimes the end dev knows best!\n\nhttps://github.com/appcelerator/titanium_mobile/commit/d000310a5b15...
(from [beb41c2c62bf67aac4d990b1d6e61dc31679724f])\n[#1441] Fix for senseless caching values. Hat tip\nto Blain. \nhttps://github.com/appcelerator/titanium_mobile/commit/beb41c2c62bf...
(from [757143515c9fef46bda05f0a703b179dd360ff66])\n[#1441] When clearing the views array, actually\ndeallocate the views \nhttps://github.com/appcelerator/titanium_mobile/commit/757143515c9f...
Hi,
\nI don't think the issue is completely fixed. I am still\nexperiencing app crashing when scrolling through a decent number\nnumber of hi-res images (necessary for my magazine app). Possibly a\nmore fundamental issue with Titanium's garbage collecting\nroutines?
I did some additional testing and here's what I discovered:
\nI think the GC system Titanium uses for iOS apps needs some\nmajor improvements, and this is critical, as these issues make\nTitanium largely unusable for many times of projects.\nUnfortunately, I discovered this way too late (after investing more\nthan a month of my time into a project that is almost complete, but\nstill completely useless due to these memory issues).
\nDevelopers working on this - please advise when you expect those\nmajor issues to be fixed? I realize the memory issues are scheduled\nfor the 1.7.0 release, but I for one cannot afford to wait a couple\nof months on this, as I'm sure holds true to many others. I would\neven be willing to chip in on the development process to accelerate\nthis, even though I am pretty new to Obj-C myself.
renx - I agree this is not fixed...we are experiencing the same\nissues with the latest build for 1.7. Also this is even worse with\ntable views that have a lot of images...big showstoppers.
We will be unable to address these specific issues without\nsample code.
I'm sorry, I should have posted the sample code. I also forgot\nto specify, that my ScrollableView does not consist of pure\nImageViews, but instead of Views containing\nImageViews (this is because my design requires there to be two\nimages side-by-side in landscape view).
\nHowever, it looks like memory is now being correctly released in\nthe latest build of 1.7.0. I suspect the following commit did the\ntrick:
\n\nhttps://github.com/appcelerator/titanium_mobile/commit/b2209783baae...
\nas it seems to correct to properly detach all child views of a\nview being detached. This probably fixes this for situations where\nImageViews are used as children in the ScrollableView.views\narray.
\nI will do some additional testing on device and report back with\nsample code if I discover additional problems in this regard,\nhowever, for now it seems the memory leak issue has been fixed.
Forgive me, but how are you downloading \"the latest build of\n1.7.0\" ? I only see the latest nightly/continuous build here:\nhttp://builds.appcelerator.com.s3.amazonaws.com/index.html
You are able to download and build from our github repository:\nhttp://github.com/appcelerator/titanium_mobile.
ok, is the github \"master\" branch considered 1.7.0-continuous at\nthe moment?
Yes. Master is the latest and should be considered unstable and\nnot generally suitable for release software, unless you absolutely\nrequire fixes from it.