[AC-6482] Memory leak on list view, with huge dataset [Android]
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | n/a |
Status | Open |
Resolution | Unresolved |
Affected Version/s | Appcelerator Studio 4.5.0 |
Fix Version/s | n/a |
Components | Titanium SDK & CLI |
Labels | n/a |
Reporter | Luke Lu |
Assignee | Abir Mukherjee |
Created | 2020-02-05T03:15:20.000+0000 |
Updated | 2020-02-12T03:28:10.000+0000 |
Description
Replication Step:
1. Created a new sample app
2. Updated the index.js as
function doClick(e) {
var win = Ti.UI.createWindow({
backgroundColor: 'red',
fullscreen: true
});
var listView = Ti.UI.createListView();
var section = Ti.UI.createListSection();
var sectionData = [];
for (var k = 0; k < 1000; k++) {
sectionData.push({
properties: {
title: 'Row ' + (k + 1)
}
});
}
section.setItems(sectionData);
listView.sections = [section];
win.add(listView);
win.open();
}
$.index.open();
If we open this app and profile the memory, you'll see there is a small memory loss each time, we click the list view. But in the code, if you change 1000 to 50000 (Which is our case where we have to show ~50000 items in the dropdown/list view), you can see significant memory leaks. Image attached to show app profile.
Image1: open list view with 1000 datasets 4 times
Image2: open list view with 50000 datasets 4 times
Attachments
File | Date | Size |
---|---|---|
Screen Shot 2020-02-05 at 1.52.04 pm.png | 2020-02-05T03:13:55.000+0000 | 66795 |
Screen Shot 2020-02-05 at 1.54.09 pm.png | 2020-02-05T03:15:06.000+0000 | 77899 |
Thanks for raising this bug! Is this only occurring on Android? I will raise this ticket internally. How are you closing the related window in this case? I only see the opening of a window, no close method. Separate of the issue a recommendation: don't display 50k items (or even 1k items) in a list, it is too much and no one will be able to search the list properly. Either start categorizing items (and let the user navigate the categories), or use pagination in combination with a searchfield instead. I'm happy to write up a sample for how to do that if you're interested.
Thanks, Rene Yeah, memory leak seems to be only on android, although slow no leaks on ios side. For the sample, I am closing it with back button, but have actually cleared all global variables, cleaned up listeners and $.destroy(), $.off() in the real app. In our app, we are using a listview along with a search bar. As mentioned earlier its fine till 1k but starts getting slower. Regarding the alternative solution, categorizing item not possible at the moment, but for the other one, if you could do a pagination sample, that would be great thanks.
This does not sound like a memory leak. This sounds like a "memory fragmentation" issue. Having that many little objects in memory at once is a lot for the garbage collector to manage. The Java heap manager might be favoring "growing" the heap when you display the
ListView
a 2nd time to allocate 50,000 objects instead of compacting/re-using the existing heap memory. If it was actually leaking, then you would eventually crash with anOutOfMemoryException
, but this isn't happening. The heap usage eventually tops-off. Once you hit that top-off point, the heap manager has no choice but to re-arrange memory to fit in the next set of 50,000 object... which unfortunately will be slow because there is likely 50,000 little gaps sprinkled in the heap. I would expect iOS to be faster at this because it would delete these 50,000 objects immediately since it is natively coded in Objective-C. That is, there is no garbage collector. Now, it can still cause memory fragmentation issues on iOS, but the immediate deletion of those objects immediately frees up that heap space which is a huge help. Versus native Android development involves Java and you would have to wait for the garbage collector to take its sweet time to analyze 50,000 objects before deciding to delete them from memory. That's the big difference. Anyways, that's my hot take on it.