Эффективный источник okio, поддержанный уже выделенным ByteString? - PullRequest
Новая
       37

Эффективный источник okio, поддержанный уже выделенным ByteString?

0 голосов
/ 05 февраля 2019

При использовании веб-сокета OkHttp слушатель использует ByteString для предоставления двоичной полезной нагрузки приложению.Я хочу передать эти байты в некоторый код, который принимает okio.Source (в данном конкретном случае, GzipSource), но я не могу найти какой-либо хороший способ сделать это эффективно.

Мое текущее решение выглядит следующим образом: 

        @Override
        public void onMessage(WebSocket webSocket, ByteString bytes) {
            Buffer gzipBuffer = new Buffer();
            gzipBuffer.write(bytes);

            GzipSource gzipSource = new GzipSource(gzipBuffer);
            ....
        }

Недостатком этого Buffer.write является то, что он создает дополнительные байтовые копии (а в случае буфера сегментированные, даже если они объединены в пул)это дополнительные накладные расходы).И в этом случае Websocket, байтовый массив был просто выделен для самой ByteString (при передаче из WebSocketReader impl).

Мой вопрос: есть ли какой-либо другой предпочтительный способ чтения из ByteString через Source?Поскольку ByteString должен быть неизменным, а Source будет просто содержать некоторую информацию о положении чтения, я думаю, что это должно быть вполне выполнимо (но не из внешнего кода, поскольку я не могу получить доступ к byte[]) ..Так что мне кажется, что я упускаю очевидное решение здесь ..:)

Спасибо за любые подсказки или указатели!

1 Ответ

0 голосов
/ 06 февраля 2019

То, как вы написали, почти оптимально.

Okio оптимизирован для перемещения данных между слоями преобразования: сжатие, кадрирование, создание потоков и т. Д. Хотя перемещение данных между слоями происходит очень быстро (нет копий)) первоначальные затраты на получение данных в систему изначально.Обычно это все, что вам нужно сделать: загрузка файла или отправка пакета.Но в этом случае вам нужно скопировать, чтобы получить байты в первый буфер.Это кажется неэффективным, но положительным моментом является то, что ваш следующий вызов Source.read () будет быстрым, поэтому общий результат будет отличным.

...