How can I transfer the binary data obtained by the web end via socket.io to the Android native layer?

[sakura-Joker]

I have checked the source code, and it is necessary to transmit strings to the native layer. However, this will affect my efficiency. For the binary stream pushed by socket.io at 30fps, I have to convert it to base64 for transmission, and then convert it back from base64 in the native layer. As a result, from the time-consuming statistics log, I found that the round-trip conversion time for the binary data of each frame fails to meet the expected requirement.

[MILLERMARRU]

I checked MessageHandler.java (the actual Android bridge implementation):

webView.addJavascriptInterface(this, "androidBridge");
// ...
@JavascriptInterface
public void postMessage(String jsonStr) { /* ... */ }

The entire JS-to-native channel for plugin calls is a single @JavascriptInterface method that only accepts a String. There's no binary channel in the Capacitor bridge itself, by design, every plugin call payload gets JSON-stringified on the JS side and JSON-parsed on the native side (same story on iOS with WKScriptMessageHandler, which also only carries JSON-serializable messages). That's a hard architectural constraint, not something you can configure around with plugin options, so the base64 round trip you're doing on every socket.io frame is exactly what the bridge forces you into.

For 30fps binary streaming this is the wrong path entirely. The approach that actually gets you real throughput is bypassing the Capacitor plugin bridge for this hot path: terminate the socket.io connection natively (there's a mature Java/Kotlin socket.io client) inside a custom plugin, and hand frames to your native processing/rendering code directly without ever marshalling them back through postMessage/PluginCall.resolve(). If you still need the bytes visible to JS (e.g. to feed a <canvas>), you can register your own WebView.addJavascriptInterface class directly on bridge.getWebView() from your plugin's load(), separate from Capacitor's own bridge interface, since a custom JS interface method can hand back a typed value without you having to build your own base64 layer on top, though you'll still cross the JSON boundary the moment you route anything through a standard plugin call. If the end goal is just displaying the stream, it's worth checking whether you can decode natively and render into a native SurfaceView layered over the WebView instead, that sidesteps the bridge for the frame data entirely.