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.
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
Related
Not a specific programming query but more in relation to a javascript app as a whole having a general problem and looking for any possible solutions to debug it.
I'm using React and have a single page app which is receiving streaming data from a websocket about 40 times a second. The user display is updated a similar amount of times each second to show the updates.
The problem I'm having is that after running the page for more than 12 hours not only google chrome, but all of other applications start to freeze momentarily. If I start trying to do too much with the other applications, sometimes all windows on chrome will turn black and it can freeze for up to 30 seconds. The more processing/memory used by other applications and the more versions of the react app I have open, the faster the freezing starts, but in any case only starts after a few hours.
The only fix is currently to restart the whole of windows because even after closing chrome the problem persists.
I've tried using google chrome profiling to inspect the heap type to see a memory leak but the memory size is the same as when I first launched the app.
I've tried reinstalling chrome but this didn't fix the problem either.
I read somewhere online that freezing like this could be due to too much garbage collection? But what would be triggering this to happen in excess? And I don't understand why that would persist after I close google chrome.
A possible solution would be to build in an auto-refresher to refresh the page every hour once the user has been idle for at least 5 minute, but this seems a bit overkill if its a problem which can be solved.
Any tips/advice for debugging this kind of issue or obvious places I should search for a solution? as its very much un-shipable in its current state
The issue was due to one of the two following things on windows 10. I performed both and one of them has caused the freezing to stop:
1) In control Panel -> Power options -> additional power settings -> change plan settings -> change advanced settings-> change the hard-drive sleep option to never or 0
2) Updated chip-set drivers from the motherboard manufacturers website.
I've tried so many profilers for node I've lost count. I've never seen a profiler that gives you this:
This image shows second-by-second usage of CPU (top and center) and memory (bottom). I can click on a single "frame" (a dividend of a second) to see exactly which functions executed on that frame and what memory was allocated and deallocated (GC'd). This is Adobe Scout for Flash/AS3.
I need to find a ghost (a memory leak :), and I've successfully used the above interface hundreds of times to eliminate unwanted allocations and debug why memory doesn't get freed when it should.
How do I find which part of my app is allocating memory on a visual timeline? I need a timeline to see specifically which part of my app is allocating memory and why. Right now everything happens so fast I can't use the "objects currently in memory" panel to do anything useful. And comparing "heap snapshots" is harder than using a timeline. Web-based or app is fine. I use Windows 7.
I use pm2 as a process manager and they have a dashboard service keymetrics. You may have a look to see if match your need. :)
I've created a complex JavaScript web app. It works very well and is fast. But I've noticed that Firefox is continuously using the CPU while the app is open in the browser window but not doing anything. I haven't programmed in any setIntervals, setTimeouts, automatic regular requests to the server - nothing. The only thing it has is the GUI, which is already instantiated and sitting there doing nothing (since the last interaction with the user), and the event handlers which are waiting, attached to various GUI controls. Just to make sure, I used the profiler in Firebug and it confirmed that there was no activity to profile.
I did have 3 FF add-ons running: Avast Online Security, Firebug, and Web Developer. I have disabled these, and it seems to have reduced the CPU useage from say 4-5% to 1-2%. I know this is low, but considering I have only one tab open with my app in it, I would like to know where that 1-2% is being used. The memory consumption is not increasing (it fluctuates, but doesn't increase over time). I have done some quick checks with IE (9) but the CPU usage tends to stay at 0%.
I can't provide any code or solid starting points, but I just thought someone might have some ideas.
The Android WebView widget appears to enter an unrecoverable state if executed JavaScript code is caught in an infinite loop.
For example, this webpage will cause the problem:
<html>
<head>
<title>FAIL</title>
<script type="text/javascript">
function test() {
while (true);
}
</script>
</head>
<body onload="test();">
Failure Test
</body>
As will simply entering the following URL in any Android browser using WebView:
javascript:while(true);
Once such an infinite loop is encountered, one CPU core will be run at its maximum. The WebView appears to never shut down. This will of course rapidly drain the battery and slow the device. Only terminating the containing application appears to resolve this.
The following appear to be ineffective:
Disabling JavaScript: webView.getSettings().setJavaScriptEnabled(false);
Stopping the page from loading: webView.stopLoading();
Pausing all JS Timers: webView.pauseTimers();
Loading an alternate URL: webView.loadUrl("about:blank");
Removing the WebView from the widget hierarchy: parent.removeView(browserView);
Invoking destroy on the WebView: webView.destroy();
Finishing the activity: activity.finish();
Returning false from WebChromeClient.onJsTimeout(); (This method was deprecated in API 17, and appears to never be invoked).
The following is effective:
Killing the VM: System.exit(0); (This is a method that should never be called on Android.)
It's worth noting that the stock Android browser (not Chrome) suffers this problem as well. Though Chrome does not have the issue, it does still appear to occur when using the Chromium-based WebView shipped in Android 4.4.
Once one WebView enters this state, the application will be unable to load any URL into any other WebViews.
If anyone has any suggestions for terminating a WebView, it'd be greatly appreciated. I can't control the content being loaded into the WebView, as it's being used for a general-purpose browser. Otherwise my default solution will be to attempt to detect the scenario and warn the user if it is encountered, providing the option to forcibly terminate the application to prevent battery drain.
Thank you for any ideas!
I don't think you can do too much about that. Because the WebView is single process (this is true for the 4.4 WebView too) and the renderers are running in your app's process a misbehaving web page can lead to your process being OOM killed by allocating tons of memory.
Chrome doesn't suffer from this problem since it runs the renderer in a separate process which can be killed. The WebView could be modified to kill the thread that JavaScript execution is taking place in, however that would lead to memory leaks (since the OS will not clean up for you like it does in the case of a separate process) and like I said above - doing so doesn't really protect you against a malicious web page allocating memory.
I think your solution of displaying a "the page is not responding. kill the app?" popup to the user is the best you can do using the WebView. The alternative is to create your own multi-process browser based on the Chromium code but that will probably take a lot more effort.
I'm trying to build Ext JS application which is using websockets. Application primarily meant to run in chrome, at I have noticed memory footprint goes beyond 200+ MB and chrome starts freezing. I have used chrome://memory to check memory usage and do some profile.
However, Is there any way using which I can programmatic-ally detect this situation and avoid crashing of browser.
Does it freeze as soon as ExtJS loads, or are you actually performing functions for your application when it freezes? It might be that your application is pulling down too much data onto the client, in which case, the culprit is not ExtJS. If you are doing client-size data caching or pagination, make sure you're not loading too much data.