Out of memory when doing a lot of request about stetho

[jasta]

I think you've found a bug in Stetho in the same way Stetho's found a bug in your code :)

The issue here is that due to the design of our JSON-RPC/WebSocket implementation, we require that all objects sent over the wire are first constructed as POJOs. The DevTools protocol requires that we read network response bodies as a single, typically base64-encoded, UTF-8 string. This means that in practice if the response body is a very large binary blob, the resulting base64 UTF-8 string will be so large that the VM will be unable to allocate it as a single contiguous char[] buffer*.

I suspect that rather than truly running out of memory, instead Dalvik/ART are refusing to allocate such a large buffer. Somewhere in Logcat output this would be reflected, though it can be hard to spot sometimes.

This can be addressed by us in a couple of ways, but the more important question is: why are you downloading images that are likely much larger than the viewport size of the device? Doing so wastes bandwidth and processing power locally, even with BitmapFactory downsampling the image during decoding.

• - Two important details conspire to inflate the size of this allocation: 1) char is 2 bytes in Java, and 2) base64 encoding typically increases data size by ~25%. So, if your image was 1MB, you should expect an allocation of 2.5MB.

[fourlastor]

You're right, plugged in a Nexus 5 and I managed to find the culprit (with Stetho :) ).
I already proposed something like thumbor to reduce the image size as requested but currently it has low priority.

Just crashing like this isn't very clear tho, maybe something like logging an error if the content lenght is over a certain value (1MB should be good enough), without actually downloading it?

[jasta]

Agreed Stetho has the wrong behaviour. It's supposed to help you debug these kinds of issues, not crash :)

I think we have two decent options:

1. Try to read the string, catch OutOfMemoryException and replace the contents with an error indicating this in some fashion.
2. Build a streaming API for our JSON-RPC encoder so that we can express potentially very large requests and responses (we have a couple other interesting places) in a streaming fashion for efficiency reasons. I do really like this option, but unfortunately we hacked our way through a custom WebSocket and JSON-RPC implementation and neither are exactly well suited for this at the moment.

I'm inclined to post a quick diff for 1, then take a deeper look after 1.1.0 to see if we can rearchitect and improve our underlying protocol implementation.