Android(Unity)のBluetooth SPP通信でリアルタイムにJavaのInputStream.read()を動かすと重い・ブロックされる

Question

前提・実現したいこと

UnityにAndroidのJavaプラグインを導入し，マイコンとAndroid間でBluetooth SPP通信を用いて高速にバイト配列の送受信をするシステムを作成しています．

Android側から送信する際は問題ないのですが，Android側が受信する際にJavaのInputStream.read(byte[] b)を実行すると，1回の呼び出しで10ms程度固まってしまいます．
10ms固まるのはマイコン側が6バイト送信し，それをJavaが6バイトで受け取る設定にしている時なのですが，これをマイコン側の設定を7バイト以上に設定すると，スムーズに呼び出しができます．ただしこれでは毎回受け取る際に配列がずれていってしまうので意味がありません．
なお，CPU負荷の測定にはUnityのProfilerを用いています．

発生している問題・エラーメッセージ

画像の一番下の階層のAndroidJNI.CallStaticObjectMethod()が，実際にJavaに実装したメソッドが実行され，戻り値がC#側に返ってくるまでかかった時間です．

・マイコン側(6バイト)，Java側(6バイト)設定時

2020/09/15 23:04:39.639 22994 23036 Info ContentValues [0] = 65, [1] = 66, [2] = 67, [3] = 68, [4] = 69, [5] = 70
2020/09/15 23:04:39.650 22994 23036 Info ContentValues [0] = 65, [1] = 66, [2] = 67, [3] = 68, [4] = 69, [5] = 70
2020/09/15 23:04:39.661 22994 23036 Info ContentValues [0] = 65, [1] = 66, [2] = 67, [3] = 68, [4] = 69, [5] = 70
2020/09/15 23:04:39.670 22994 23036 Info ContentValues [0] = 65, [1] = 66, [2] = 67, [3] = 68, [4] = 69, [5] = 70
2020/09/15 23:04:39.681 22994 23036 Info ContentValues [0] = 65, [1] = 66, [2] = 67, [3] = 68, [4] = 69, [5] = 70
2020/09/15 23:04:39.709 22994 23036 Info ContentValues [0] = 65, [1] = 66, [2] = 67, [3] = 68, [4] = 69, [5] = 70
2020/09/15 23:04:39.718 22994 23036 Info ContentValues [0] = 65, [1] = 66, [2] = 67, [3] = 68, [4] = 69, [5] = 70

・マイコン側(7バイト)，Java側(6バイト)設定時

2020/09/15 22:57:43.209 21682 21825 Info ContentValues [0] = 65, [1] = 66, [2] = 67, [3] = 68, [4] = 69, [5] = 70
2020/09/15 22:57:43.225 21682 21825 Info ContentValues [0] = 71, [1] = 65, [2] = 66, [3] = 67, [4] = 68, [5] = 69
2020/09/15 22:57:43.242 21682 21825 Info ContentValues [0] = 70, [1] = 71, [2] = 65, [3] = 66, [4] = 67, [5] = 68
2020/09/15 22:57:43.259 21682 21825 Info ContentValues [0] = 69, [1] = 70, [2] = 71, [3] = 65, [4] = 66, [5] = 67
2020/09/15 22:57:43.275 21682 21825 Info ContentValues [0] = 68, [1] = 69, [2] = 70, [3] = 71, [4] = 65, [5] = 66
2020/09/15 22:57:43.292 21682 21825 Info ContentValues [0] = 67, [1] = 68, [2] = 69, [3] = 70, [4] = 71, [5] = 65
2020/09/15 22:57:43.309 21682 21825 Info ContentValues [0] = 66, [1] = 67, [2] = 68, [3] = 69, [4] = 70, [5] = 71

該当のソースコード

受信側のコードのみを抽出して記述しています．

static public byte[] BluetoothReceive() {
        int readLen = -1;
        byte[] buffer = new byte[6];

        // もしモジュールと接続できていれば
        if (connectFlg) {
            try
            {
                readLen = mInputStream.read(buffer);
                Log.i(TAG, "[0] = " + buffer[0] + ", "
                        + "[1] = " + buffer[1] + ", "
                        + "[2] = " + buffer[2] + ", "
                        + "[3] = " + buffer[3] + ", "
                        + "[4] = " + buffer[4] + ", "
                        + "[5] = " + buffer[5]
                );
            } catch (IOException e) {
                e.printStackTrace();
            } catch (NullPointerException ee){
                ee.printStackTrace();
            }
        }
        return buffer;
    }

private SByte[] receiveBuffer = new SByte[6];

private void FixedUpdate()
    {
        if (connectFlag)
        {
            try
            {
                receiveBuffer = bluetoothPlugin.CallStatic<SByte[]>("BluetoothReceive");
            }
            catch (Exception e)
            {
                Debug.LogWarning("[Server] " + e);
            }
        }

    }

const uint8_t ReplyBuffer[] = {65, 66, 67, 68, 69, 70};
void setup()
{
    SerialBT.begin("ESP32test");
}

void loop()
{
　　if (SerialBT.available())
    {
        SerialBT.write(ReplyBuffer, sizeof(ReplyBuffer) / sizeof(uint8_t));
    }
}

試したこと

Javaの公式リファレンスを見るとInputStream.read()は
「入力データが読み込めるようになるか、ファイルの終わりが検出されるか、あるいは例外がスローされるまでブロックします。」
と書かれていたため，readの戻り値が-1の時と，6以外の時でログを仕込んでみましたが，そもそもそのログにすら到達していませんでした．

非常にマニアックな質問となってしまい申し訳ありませんが，おそらくJava特有の問題かと思われるので，JavaのI/O周りにお詳しい方がいらっしゃいましたらご回答よろしくお願いします．

補足情報（FW/ツールのバージョンなど）

Android Studio 4.0.1
Unity 2019.4.6f1
ESP32 Arduino Core 1.0.4

追記(2020/9/16)

Arduino(ESP32)側でflushしてみましたが変化はありませんでした．
ArduinoのSerial.flushは送信シリアルデータの送信が完了するのを待つという仕様になっているようです.ESP32のBluetoothSerial.flush()の実装を見ると，

void BluetoothSerial::flush()
{
while(read() >= 0){}
}

となっており，こちらはread()が-1を返す(バッファの読み込みが終わる)まで待機するような実装になっていました．
JavaのOutputStream.flush()の様な強制的に書き込むようなメソッドがあればよかったのですが…

追記です．
ESP32側で以下のように送ったバイト数と送信にかかった時間を計測しました．

unsigned long Start = micros();
size_t hoge = SerialBT.write(ReplyBuffer2, sizeof(ReplyBuffer2) / sizeof(uint8_t));
unsigned long Stop = micros();
Serial.print(" sendTime: ");
Serial.print(Stop - Start);
Serial.println(F("µs"));
Serial.print((int)hoge);
Serial.println("bytes sent");

sendTime: 93µs
6bytes sent

送信に約0.1ms程度しかかかっていないため，ESP32側の送信は即座に行われているように見えます．

Answer 1

ある程度の遅延を受け入れることにより，とりあえずUnityアプリのFPSが落ちることは避けることができました．
BufferedInputStreamにラップして，available()を用いることにより，ストリームに溜まっているバッファのバイト数を取得しました．

BufferedInputStream mBufferedInputStream = new BufferedInputStream(mInputStream);
int bytesAvailable = mBufferedInputStream.available();
if (bytesAvailable > 0)
{
    mBufferedInputStream.read(buffer, 0, buffer.length);
}

ただし，bytesAvailableを見ると，UnityのFixed Timestepが0.016s(=60Hz)時で100byte程度溜まっていたので，およそ300ms程度の遅延が見受けられました．
Bluetooth SPP通信ではこの程度の遅延は普通なのでしょうか．

Answer 2

mInputStream.read(buffer)は6バイト読み込むまで処理をブロックするのでArduinoがバッファリングして即座に6バイトを送信していない気がします。なのでwriteの後にflushで強制的にバッファを吐き出すとどうでしょうか？

SerialBT.flush();

Comments

[Harris-1227]

Arduino(ESP32)側でflushしてみましたが変化はありませんでした．
ArduinoのSerial.flushは送信シリアルデータの送信が完了するのを待つという仕様になっているようです.ESP32のBluetoothSerial.flush()の実装を見ると，

```
void BluetoothSerial::flush()
{
while(read() >= 0){}
}
```
となっており，こちらはread()が-1を返す(バッファの読み込みが終わる)まで待機するような実装になっていました．
JavaのOutputStream.flush()の様な強制的に書き込むようなメソッドがあればよかったのですが…

[Harris-1227]

追記です．
ESP32側で以下のように送ったバイト数と送信にかかった時間を計測しました．
```Arduino
unsigned long Start = micros();
size_t hoge = SerialBT.write(ReplyBuffer2, sizeof(ReplyBuffer2) / sizeof(uint8_t));
unsigned long Stop = micros();
Serial.print(" sendTime: ");
Serial.print(Stop - Start);
Serial.println(F("µs"));
Serial.print((int)hoge);
Serial.println("bytes sent");
```

```SerialMonitor
sendTime: 93µs
6bytes sent
```
送信に約0.1ms程度しかかかっていないため，ESP32側の送信は即座に行われているように見えます．