Nativescript-ui-feedback: Memory leak in RadListView

Created on 25 Jul 2018  路  8Comments  路  Source: ProgressNS/nativescript-ui-feedback

Did you verify this is a real problem by searching the Forum: No, GitHub: yes

This is somewhat related to https://github.com/NativeScript/NativeScript/issues/6111 but this effects RLV instead of the normal LV, and it effects the RLV differently.

Tell us about the problem

RadListView will leak all template created controls. This is especially prevalent in a NAN app; but can be duplicated with a much simpler test case in a PAN app. I have both a NAN and PAN app that exhibit this issue; I'll attach the PAN app to this bug report. (If you need the NAN app, ask).

Which platform(s) does your issue occur on?

Only tested on Android.

Please provide the following version numbers that your issue occurs with:

Component nativescript has 4.1.2 version and is up to date.
Component tns-core-modules has 4.1.1 version and is up to date.
Component tns-android has 4.1.3 version and is up to date.
"nativescript-ui-listview": "3.5.10",

Please tell us how to recreate the issue in as much detail as possible.

  1. Start the application.
  2. Pull to refresh (each time you pull to refresh, you will see more leakage)

Is there code involved? If so, please share the minimal amount of code needed to recreate the problem.

First thing is that you need to do the same thing as I describe in NativeScript#6111 - You need to add some tracking code to the UI/Label/Label.android.js file.

var _counter = 0, _disposed = 0;
Label.prototype.createNativeView = function () {
        _counter++;
        console.log("Label: create", _counter, ", disposed:", _disposed, "Left:", _counter-_disposed);
        if (!TextView) {
            TextView = android.widget.TextView;
        }
        return new TextView(this._context);
    };
Label.prototype.disposeNativeView = function () {
        _disposed++;
        console.log("Label: Disposing Labels left:", _counter-_disposed);
        _super.prototype.disposeNativeView.call(this);
};

The idea behind this code is it will track how many Labels have been created and how many have been disposed of. This information is confirmed by doing a actual JS heap dump; which is what put me onto this issue in the first place; in my real app I was leaking ~150 labels each navigation.goBack from the details screen to the listview screen.

I've also added this tracking code to images; and the same issue occurs; so the issue is NOT the actual Label or Image; it is the RLV Template , anything in all the RLV template will be retained and/or more created on a refresh call.

testlist.zip

backlog bug listview high

Most helpful comment

Hi @NathanaelA @NickIliev ,

Thank you for bringing this to our attention. We have pinpointed an possible cause of this issue in the RadListView and we are in the process of addressing it. We will do our best to have a fix available and published by early next week.

All 8 comments

@NickIliev - Do we have any chance an ETA on a fix for this bug; this is effecting a real client app that is already deployed; and the NS app slows down to unacceptable levels after about 5-10 minutes of usage because of this leak. ~150 Labels and ~20 images really saps memory quickly.

@NathanaelA the plugin's team is currently investigating the issue and they will post any related information (including ETA) immediately after they have more insights of the depths and the roots of the problem.

Hi @NathanaelA @NickIliev ,

Thank you for bringing this to our attention. We have pinpointed an possible cause of this issue in the RadListView and we are in the process of addressing it. We will do our best to have a fix available and published by early next week.

Hi @NickIliev @VladimirAmiorkov
Thank you for your prompt action guys. Have you released the new version of listview?

Hi @nmongiya ,

It turned out that this memory leak was caused by multiple leak places both in _nativescript-ui-listview_ and _tns-core-modules-widgets_. We have resolved all related issues and we are in the process of testing and finally releasing new versions so stay tuned. You can follow this PR with the related memory leak caused by the widgets on Android.

Hi @VladimirAmiorkov I have updated nativescript-ui-listview to ^3.6.0 & "tns-core-modules": "^4.2.0", but now it is showing me the below error.
node_modules/tns-core-modules/ui/styling/gradient.d.ts(7,25): error TS6143: Module '../../css/parser' was resolved to 'C:/Trunk/FreshTracker/Mobile/node_modules/tns-core-modules/css/parser.js', but '--allowJs' is not set.

Just to everyone is aware; https://github.com/NativeScript/tns-core-modules-widgets/pull/131 is related to this issue; until they actually accept that PR into the master/release this issue won't be fixed. So despite this issue being closed; part of the root cause has NOT been accepted into the widgits; so this issue is not fully fixed until that is accepted and in the release branch.

@nmongiya Hmm this should not be caused by anything that nativescript-ui-listview is related to. Did you try to clean the node_modules and platforms before updating your versions in the package.json? Also make sure if working with Angular and nativescript-dev-webpack to follow their migration/update steps.

@NathanaelA Yes this is the current state of this issue. We are in the process of merging it and releasing a hot fix of the midgets as soon as possible.

Was this page helpful?
0 / 5 - 0 ratings