Android 2.2: лучший способ чтения небольших блоков двоичных данных из больших файлов? - PullRequest
1 голос
/ 15 декабря 2011

Я разрабатываю для Android 2.2.

Вещи, помещенные в res и ресурсы, по умолчанию сжимаются в APK, если только их расширение не указывает, что они уже сжаты (mp3, png).Более того, до Android 2.3 в ресурсы можно было помещать несжатые файлы размером менее 1 МБ.

Вопрос 1:

, если я помещаю 1,5 МБ двоичного файла в res / raw,и моя программа ссылается на него со стандартным идентификатором Android (R.raw .....), тогда система вытянет весь файл в память ?Поскольку 1,5 МБ хранятся в сжатом виде, я полагаю, что это необходимо.Это неприятно, поскольку возможно, что программе требуется только 1 КБ данных для загрузки из заданного смещения файла.Это может серьезно повлиять на производительность / скорость приложения.

Я вижу два решения:

  1. (взломать) Использование расширений mp3 или png;но я не уверен, что это все-таки позволяет эффективный доступ к памяти (например, inputtream.skipbytes и т. д.)
  2. После установки, при первом запуске приложения, приложение будет копировать файлы в свою собственную записьрабочая папка (на SD-карте).С этого момента он всегда будет обращаться к файлам оттуда, а не к R.raw ....Следовательно, последовательное чтение будет работать точно, т. Е. Использование памяти будет не больше, чем фактические данные, считанные из указанного смещения файла (кроме временных буферов чтения, используемых реализацией inputtream.seek, которые хорошо оптимизированы, то есть, полагаю, небольшие).).

Вопрос 2:

Каков наилучший способ эффективного чтения двоичных данных из больших файлов?Я не хочу разбивать мои большие файлы на множество маленьких, если только это не единственный способ.

Ответы [ 2 ]

1 голос
/ 15 декабря 2011

Я также хотел бы выбрать решение № 2, но вместо использования файла произвольного доступа я бы использовал java.nio.MappedByteBuffer - таким образом, вы получите быстрый произвольный доступ с семантическим байтовым буфером.

1 голос
/ 15 декабря 2011

Я бы выбрал решение # 2, а затем использовал бы RandomAccessFile, чтобы избежать линейного доступа.

...