Search code examples
javascriptperformancememory-leakssamsung-smart-tv

Samsung Smart TV App is very slow after exiting and starting again

We have developed a Samsung Smart TV app for the 2011 & 2012 platforms. The app is HTML/JavaScript based. Normally the app is performing well, but after exiting the app becomes very slow, by a factor of six. The measured JS execution times are only slightly slower, but the HTML elements are rendered much slower to the screen. This behavior happens on all devices (TV and Blu-Ray Player devices with Smart TV Platform).

The exit is realized by executing the JS command

var widgetAPI = new Common.API.Widget();
widgetAPI.sendExitEvent();

The app behaves the same (i.e. becomes slower after starting again) when using the command

widgetAPI.sendReturnEvent();

(which returns the user to the Smart Hub instead of exiting completely). Through trial and error I discovered that making the app crash on purpose solves the problem - this results in an identical behaviour to the user as calling the sendExitEvent method. However, it is not a very clean method, and furthermore I would prefer to use the sendReturnEvent command.

How can I return the user to the Smart Hub programatically so that the app does not get slower when starting it again?

I hope somebody has some first-person experience and advice regarding this. I have tried to eliminate possible JS memory leak sources (using JS programming best practices and advice from Samsung), but that has not remedied the problem.

Solution

  • I solved the problem using two actions:

    • Instead of simply calling widgetAPI.sendReturnEvent() I redirect the user to a new page exit.html (using window.location.href), which is almost empty, except for an onload handler, which calls the following commands (which are equivalent to widgetApi.sendReadyEvent() and widgetApi.sendReturnEvent() but without needing to include the Widget.js file)
       curWidget.setPreference("ready","true");
   curWidget.setPreference("return","true");
    • Commenting out all alert commands. Apparently calling alert leaks memory when used several times so that the accumulated garbage is not collected from the memory when exiting the app, causing it to be slower after restart

    Only applying the both methods seemed to fix the issue. Presumably the app accumulates memory leaks causing the app being slow after restart

    1) on the document level (despite our efforts to follow all guidelines to prevent them), which are then purged after loading another HTML file.

    2) on a global level, caused by calling alert