Search code examples
javascriptangularjsmobileionic-frameworksafari-web-inspector

Using Safari web inspector to debug memory leak?

FYI, we are debugging our mobile hybrid app which was develop using angularJS 1.4.2 and ionic framework 1.2.4 with WKWebView.

The multiple snapshots below is to show the events before and after. Based on webkit memory debugging article, the snapshot will show the live JavaScript objects which has not yet been GC.
Snapshot of series of action taken

Snapshot 2 showing the default state of page A and controller A. snapshot2

Snapshot 5 is still in the same page but after doing some calculation and generated a base64 string pdf from PDFTron to view it on UIWebview. snapshot5

Snapshot 10 showing after exit page A and navigate to page C with controller C. snapshot10

Comparison of snapshot 2 and snapshot 10, all the base64 string still remain there. Comparison of snapshot2 and 10

Questions:

  1. Is it normal when the size of snapShot keep increasing without reduce, is it consider memory leak?
  2. The snapshot size is representing all the live javascript objects only or it will show all the object that we visited whether it is live or not, just like some history objects in the app?
  3. What is the different of snapshot size and snapshot live size?
  4. AngularJS will help to destroy the scope when navigate to next controller, we also disable cache on ionic. So is these base64 string consider memory leak item also?
Solution

  • Update

    There was a new article released on the memory debugging. This article include a more detail steps and the procedure.

    New memory debugging article

    Answers

    After going through few months of memory debugging on the apps, we have some addition finding on debugging the memory leaks.

    1. The size of the snapshot will keep increasing as there may have some static object or variables when navigate between pages.
    2. Like above, the snapshot size is represent the current active memory usage of the apps including the static objects, UI elements and other components that was active in this controller.
    3. Instead of checking the snapshot size and snapshot live size, retained size and self size will have more information on the memory usage. Self size is the size of the current element while retained size is how much memory will be release after the current self element is destroyed.
    4. The base64 string is consider memory leak item. Although proper scope destroy and variable clear is done in the controller side, but there are some leak because some addition services still referencing to this string. After cleaning up all the remaining referencing issue, the base64 string leak is gone now.

    Memory debugging steps

    Some suggestion here for those who might also want to use the memory debugging in the future. Current steps for memory debugging:

    1. Navigate from page A - page B, then from page B back to page A.
    2. Do a snapshot.
    3. Repeat step 1 and do another snapshot.
    4. Compare the first snapshot with the second snapshot.
    5. Repeat step 1 to step 4 if want to do another snapshot comparison.

    *Remember always take the latest snapshot. Eg. use snapshot 5 and 6 instead of 1 and 2 because the earlier snapshot might have the chance to be GC and the result will not be accurate.

    With this steps, it was better to find out and pin point the memory leaks section. Normally we will track the object, function and array count. If there were memory leaks, the number of count will be increase when comparing the snapshot. Some other memory leaks item will be the $$ inside the object count. This kind of object might cause memory leaks as the object is not in use anymore but is still reference by other parts of the application.