I'm building an app that contains a WebView that runs some JavaScript code. That JavaScript code is quite allocation heavy and can require a lot of memory.

Sometimes, the amount of required memory exceeds the amount JavaScript can require and crashes the Chromium process of the WebView which crashes my app.

I listen to onMemoryTrim in my application - but it is never called in this scenario on devices with more than 1GB of memory. (Not even with TRIM_MEMORY_RUNNING_LOW).

Is there any way I could detect my WebView is running low on memory and either kill it or let it know (so it can free memory)?

I've tried polling performance.memory but it did not work. The following script crashes the WebView if executed in it:

var a = [];

var kek = () => {
  var b = [];
  for(var i = 0; i < 1024 * 1024 * 2; i++) b.push(Math.random());
  return b;
}

var ival = setInterval(() => {
  let m = performance.memory;
  if(m.jsHeapSizeLimit - m.usedJSHeapSize < 1e5) {
    console.log("Memory limited")
  } else {
    a.push(kek());
  }
});

Is there any way to detect memory is about to run out so I can handle it gracefully without the app crashing?

I'm building an app that contains a WebView that runs some JavaScript code. That JavaScript code is quite allocation heavy and can require a lot of memory.

Sometimes, the amount of required memory exceeds the amount JavaScript can require and crashes the Chromium process of the WebView which crashes my app.

I listen to onMemoryTrim in my application - but it is never called in this scenario on devices with more than 1GB of memory. (Not even with TRIM_MEMORY_RUNNING_LOW).

Is there any way I could detect my WebView is running low on memory and either kill it or let it know (so it can free memory)?

I've tried polling performance.memory but it did not work. The following script crashes the WebView if executed in it:

var a = [];

var kek = () => {
  var b = [];
  for(var i = 0; i < 1024 * 1024 * 2; i++) b.push(Math.random());
  return b;
}

var ival = setInterval(() => {
  let m = performance.memory;
  if(m.jsHeapSizeLimit - m.usedJSHeapSize < 1e5) {
    console.log("Memory limited")
  } else {
    a.push(kek());
  }
});

Is there any way to detect memory is about to run out so I can handle it gracefully without the app crashing?

• javascript
• java
• android
• google-chrome
• android-webview

• onTrimMemory() is called based on overall lifecycle events and the amount of free system RAM. Your problem would appear to be tied to some sort of process limit (e.g., standard app heap limit), and I would not expect onTrimMemory() to be invoked for such scenarios. – CommonsWare Commented Jul 30, 2017 at 13:42
• @CommonsWare thanks, I hadn't realized these were system-wide triggered hooks. It appears that Chrome's JavaScript's limit is the one at fault here. To be pletely frank - this is because Chrome leaks and when it reaches some limit - it crashes (with my app). My X in this XY problem is Chrome not crashing or having a way to catch it in my app and not crash it - although I'm interested in how to measure memory usage from a purely curious PoC as well. – Benjamin Gruenbaum Commented Jul 30, 2017 at 13:56
• @CommonsWare and apparently 8.0 introduces a way to recover from X - developer.android./preview/features/… – Benjamin Gruenbaum Commented Aug 5, 2017 at 15:14
• same here..my heap is getting exhausted..i want to know the js memory allocation..Something of this sought developer.chrome./devtools/docs/heap-profiling – NitZRobotKoder Commented Nov 24, 2017 at 16:17

1 Answer 1

I have discussed this with the Chromium team and the Android team and at the moment (they think and I believe them) that this is impossible.

Sometimes, the amount of required memory exceeds the amount JavaScript can require and crashes the Chromium process of the WebView which crashes my app.

You can however catch out of memory crashes in Android 8.0+ using the new termination handle API. So this works around my problem by not having to check the available memory required in the first place.

By overriding onRenderProcessGone - we get to catch the bug and recreate the WebView.