How to trace memory usage by Tabris.js app using Chrome DevTools.
Since Tabris.js Android uses Google V8 as its JavaScript engine, this benefits developers to use Chrome DevTools features to debug source code, profile CPU, and memory usage of the JavaScript VM.
Enable debugging on Tabris.js Android app and make sure you’ve an installed Google Chrome browser on your computer. Once you see that screen on your Android device:
open your Google Chrome browser on your computer and enter this URL:
|
1 |
devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=[IP]:[port] |
Replace IP and port from the popup displayed on your Android device. If everything went right, you will see this window on your Google Chrome browser:
There is an example Tabris.js app to create a memory leak in the app (you can access the example here). It creates a new PdfView widget on each button click:
|
1 2 3 4 5 6 7 8 9 10 11 |
function createPdfView(blob) { contentView.append( new PdfView({ top: '#button 20', bottom: 0, layoutData: 'stretchX', pageElevation: 4, src: blob }) ); } |
As you can see from the code snippet, it creates a new PdfView widget, but previously created PdfView widgets are not garbage collected because they are still in the UI tree!
The UI looks as follows on an Android device:
You can click Memory panel in Chrome to switch to the memory profiler:
We will use Allocation instrumentation on timeline profiler type because this kind of profiler lets us stop the profiler at any time we want. Then start the profiler by clicking the “Start” button. During the recording, do some interactions in the app, such as clicking the “Show PDF” button multiple times. After some time, stop the profiler by pressing stop the record button:
Once the profiler stops, it will show the object allocation as follows:
Refer to this website to learn more about the complete memory terminology in Chrome.
As seen in the window in the screenshot above, you can see details about all available objects in the JavaScript VM, which is very helpful to trace memory usage by objects and finding the memory leak. For our example, there are currently 11 PdfView objects available (PdfView x11) in the VM, which is definitely a memory leak in the app, but we traced and found it!
Let us know about your thoughts and if you’re interested in such topics!
Feedback is welcome!
Want to join the discussion?Feel free to contribute!
