{ "id": "174691", "key": "AC-6482", "fields": { "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false }, "project": { "id": "12217", "key": "AC", "name": "Appcelerator - INBOX", "projectCategory": { "id": "10000", "description": "", "name": "Customer Service" } }, "resolution": null, "resolutiondate": null, "created": "2020-02-05T03:15:20.000+0000", "labels": [], "versions": [ { "id": "17038", "name": "Appcelerator Studio 4.5.0", "archived": false, "released": false } ], "issuelinks": [], "assignee": { "name": "amukherjee", "key": "amukherjee", "displayName": "Abir Mukherjee", "active": true, "timeZone": "America/Los_Angeles" }, "updated": "2020-02-12T03:28:10.000+0000", "status": { "description": "The issue is open and ready for the assignee to start work on it.", "name": "Open", "id": "1", "statusCategory": { "id": 2, "key": "new", "colorName": "blue-gray", "name": "To Do" } }, "components": [ { "id": "14548", "name": "Titanium SDK & CLI", "description": "Please enter tickets related to the MobileSDK here." } ], "description": "Replication Step:\r\n1. Created a new sample app\r\n2. Updated the index.js as\r\n\r\n{code:javascript}\r\nfunction doClick(e) {\r\n\tvar win = Ti.UI.createWindow({\r\n\t\tbackgroundColor: 'red',\r\n\t\tfullscreen: true\r\n\t});\r\n\tvar listView = Ti.UI.createListView();\r\n\tvar section = Ti.UI.createListSection();\r\n\tvar sectionData = [];\r\n\r\n\tfor (var k = 0; k < 1000; k++) {\r\n\t\tsectionData.push({\r\n\t\t\tproperties: {\r\n\t\t\t\ttitle: 'Row ' + (k + 1)\r\n\t\t\t}\r\n\t\t});\r\n\t}\r\n\tsection.setItems(sectionData);\r\n\tlistView.sections = [section];\r\n\twin.add(listView);\r\n\twin.open();\r\n}\r\n\r\n$.index.open();\r\n{code}\r\n\r\nIf 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. \r\n\r\nImage1: open list view with 1000 datasets 4 times\r\nImage2: open list view with 50000 datasets 4 times\r\n", "attachment": [ { "id": "67263", "filename": "Screen Shot 2020-02-05 at 1.52.04 pm.png", "author": { "name": "luke_lu", "key": "luke_lu", "displayName": "Luke Lu", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2020-02-05T03:13:55.000+0000", "size": 66795, "mimeType": "image/png" }, { "id": "67262", "filename": "Screen Shot 2020-02-05 at 1.54.09 pm.png", "author": { "name": "luke_lu", "key": "luke_lu", "displayName": "Luke Lu", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2020-02-05T03:15:06.000+0000", "size": 77899, "mimeType": "image/png" } ], "flagged": false, "summary": "Memory leak on list view, with huge dataset [Android]", "creator": { "name": "luke_lu", "key": "luke_lu", "displayName": "Luke Lu", "active": true, "timeZone": "America/Los_Angeles" }, "subtasks": [], "reporter": { "name": "luke_lu", "key": "luke_lu", "displayName": "Luke Lu", "active": true, "timeZone": "America/Los_Angeles" }, "environment": "Operating System\r\n Name = Mac OS X\r\n Version = 10.14.6\r\n Architecture = 64bit\r\n # CPUs = 4\r\n Memory = 17179869184\r\n\r\nNode.js\r\n Node.js Version = 10.15.3\r\n npm Version = 6.4.1\r\n\r\nTitanium CLI\r\n CLI Version = 5.2.2\r\n\r\nTitanium SDK\r\n SDK Version = 8.3.1.GA\r\n Target Platform = android", "comment": { "comments": [ { "id": "454047", "author": { "name": "topener", "key": "topener", "displayName": "Rene Pot", "active": true, "timeZone": "Europe/Berlin" }, "body": "Thanks for raising this bug! Is this only occurring on Android? I will raise this ticket internally.\r\n\r\nHow are you closing the related window in this case? I only see the opening of a window, no close method.\r\n\r\nSeparate 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. ", "updateAuthor": { "name": "topener", "key": "topener", "displayName": "Rene Pot", "active": true, "timeZone": "Europe/Berlin" }, "created": "2020-02-05T08:10:50.000+0000", "updated": "2020-02-05T08:12:24.000+0000" }, { "id": "454075", "author": { "name": "luke_lu", "key": "luke_lu", "displayName": "Luke Lu", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Thanks, Rene\r\nYeah, memory leak seems to be only on android, although slow no leaks on ios side.\r\nFor 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.\r\n\r\nIn our app, we are using a listview along with a search bar. As mentioned earlier its fine till 1k but starts getting slower. \r\nRegarding 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.\r\n", "updateAuthor": { "name": "luke_lu", "key": "luke_lu", "displayName": "Luke Lu", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2020-02-05T23:53:47.000+0000", "updated": "2020-02-05T23:53:47.000+0000" }, { "id": "454189", "author": { "name": "jquick", "key": "jquick", "displayName": "Joshua Quick", "active": true, "timeZone": "America/Los_Angeles" }, "body": "This does not sound like a memory leak.\r\nThis sounds like a \"memory fragmentation\" issue.\r\n\r\nHaving 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 an {{OutOfMemoryException}}, 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.\r\n\r\nI 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.\r\n\r\nAnyways, that's my hot take on it.", "updateAuthor": { "name": "jquick", "key": "jquick", "displayName": "Joshua Quick", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2020-02-12T03:28:10.000+0000", "updated": "2020-02-12T03:28:10.000+0000" } ], "maxResults": 5, "total": 5, "startAt": 0 } } }