Использование java сериализованных объектов для фиксированных данных - PullRequest
2 голосов
/ 12 января 2020

Есть ли какие-либо негативные последствия или известные ошибки с сохранением данных c (например, хэш-карт, списков, объектов) в Android как Java потоков сериализации ?

По stati c data Я имею в виду данные, которые не изменяются со временем, not , что данные будут находиться в переменной stati c.

Файл сериализации предварительно генерируется и внедряется в приложение в качестве необработанного файлового ресурса (например, app/src/main/res/raw/my_serialized_data.ser), а затем читается с помощью:

InputStream myData = context.getResources().openRawResource(R.raw.my_serialized_data);
ObjectInputStream ois = new ObjectInputStream(charMap);
myTable = (LinkedHashMap<String, String>) ois.readObject();
ois.close();

Помимо проблем с читаемостью человеком, я не вижу никаких недостатки, поскольку чтение сериализованного объекта из файла должно быть быстрее, чем анализ данных из чего-то вроде базы данных CSV или SQLite.

Я обнаружил, что этот подход использовался в некоторых существующих приложениях, и в настоящее время рассматриваю возможность использования этого подхода в своем собственном коде. Мотивация заключается в том, что мои данные имеют размер больше 64 КБ, и для помещения их в хэш-карту потребуется разбить код инициализации на методы размером максимум 64 КБ .

1 Ответ

0 голосов
/ 12 января 2020

Полагаю, у вас есть очень веская причина хранить такой большой объем данных в памяти. Одна важная вещь - медленная загрузка приложения. Как он будет инициализировать все stati c vars. Для этого я предлагаю ленивую технику загрузки. Мне нравится работать с объектами Singleton, которые загружаются только при первом запросе getInstance. Таким образом, нагрузка будет сбалансирована в разных временных интервалах жизненного цикла приложения.

...