#android #arraylist #android-6.0-marshmallow
#Android #список массивов #android-6.0-marshmallow
Вопрос:
Есть приложение, которое генерирует список массивов данных, собранных из вызова rest. Список массивов используется в адаптере, поддерживающем ListView. Был случай, когда список массивов достигал размера 999 записей.
Приложение передает список массивов через putExtra для намерения. Список массивов используется для заполнения списка. При вызове startActivity происходит сбой приложения без создания трассировки стека, записанной в stacktrace.
Существует ли ограничение на размер, который может иметь список массивов? В запущенном действии установлена точка останова отладки, и сбой происходит сразу после вызова метода super onCreate.
Идеи о том, как это отладить? Удалось передать список массивов с 390 записями без сбоев.
Комментарии:
1. «При вызове startActivity происходит сбой приложения без создания трассировки стека, записанной в stacktrace» — тогда откуда вы знаете, что ваше приложение разбилось? «Существует ли ограничение на размер, который может иметь список массивов?» — весь
Intentдолжен быть значительно меньше 1 МБ. Передача большогоArrayListчерезIntentдополнительные функции — не очень хороший план. «Установлена точка останова отладки в запущенном действии, и сбой происходит сразу после вызова метода super onCreate» — попробуйте запустить приложение вне отладчика, чтобы трассировка стека дошла до LogCat.2. Спасибо. Я знаю, что приложение разбилось, потому что его представление в графическом интерфейсе исчезло. Запустили приложение в режиме, отличном от отладки, и все равно не получили трассировку стека. Проверит возможность превышения лимита в 1 МБ.
3. «потому что это представление графического интерфейса исчезает» — обычно это не является признаком сбоя, хотя это немного зависит от того, как написано ваше приложение. Если вы используете Android Studio, переключитесь на «Без фильтров» в LogCat (вместо фильтрации на основе приложения) и найдите трассировку стека.
4. Приложение написано так, чтобы графический интерфейс оставался на переднем плане до тех пор, пока пользователь не уволит его. Будет сброшен logcat без поиска имени приложения.
5. Недавно я столкнулся с этой проблемой, вы должны получить сообщение типа «ОШИБКА ТРАНЗАКЦИИ СВЯЗУЮЩЕГО» или что-то подобное, что означает, что в процессе сортировки / демарширования произошел сбой — общая транзакция слишком большая. РАЗУМНЫМ решением было бы разбить список массивов на части и маршалировать / dwmarshal их. На принимающей стороне продолжайте добавлять новый список массивов, пока он не будет завершен. Вы можете добавить уникальную информацию, сколько частей пакета, чтобы вы знали, когда ArrayList завершен, и идентификатор пакета. Это сработало для меня, если вы действительно не хотите, чтобы механизм постоянного хранения мог быть жизнеспособным.
Ответ №1:
КАК сказал @CommonsWare, существует ограничение <1 МБ, но на практике это намного меньше, как только вам нужно передать больше данных, чем пара сотен КБ, вам нужно использовать другие процедуры для передачи данных.
Наиболее распространенным было бы сохранить его в локальной базе данных или другом хранилище, а затем в другом запросе активности для данных (с намерением вы передаете только данные, необходимые для последующего запроса списка), и вместо того, чтобы загружать их все сразу, вы используете CursorLoaderтак что вы загружаете только те данные, которые вам нужны.
Другой быстрый и грязный способ — добавить статическое поле для передачи данных в другое действие, а затем при загрузке прочитать значение и удалить его, проблема, с которой вы столкнетесь, заключается в том, что это не является потокобезопасным и не решит вопрос о том, что делать с данными на другомдействие при выполнении onSavedInstanceState, потому что вы столкнетесь с той же проблемой размером 1 МБ. [ПРЕДУПРЕЖДЕНИЕ: это худшее решение, которое вы могли придумать, поэтому, пожалуйста, попробуйте что-нибудь еще, прежде чем попробовать это, вот почему я сначала дал вам очень хороший подход и оставил этот в конце]
[ОБНОВЛЕНИЕ:]
Кстати, первый подход заключается в том, как мы устранили эту проблему в приложении Microsoft Band, потому что у нас было так много данных, поступающих в рамках очень длительного прогона (точки GPS и другие отслеживаемые данные).). Просто убедитесь, что данные недостаточно велики, чтобы создать узкое место где-то в другом месте. Раньше мы кэшировали их только в памяти и никогда не отправляли на диск, чтобы избежать процесса сериализации или времени, необходимого для сохранения и извлечения из хранилища.
Комментарии:
1. Ценю это, но считаю использование статики очень плохим выбором дизайна. Рассмотрим другие подходы.
2. OP уже борется с тем, как разработано его приложение, с точки зрения кодирования. Возможно, отбросьте часть использования статического списка массивов, поскольку это в долгосрочной перспективе вызовет больше проблем, чем решит.
3. @T.Barrett как я уже сказал в ответе, это очень быстрый и грязный подход, и я просто добавляю его сюда, потому что я помню, как женщина из Google предлагала эту альтернативу для передачи больших изображений от действия к действию. Но я также думаю, что этого следует избегать любой ценой.
4. @MarkKeen Я знаю, и я это понимаю, но, отвечая Баррету, я просто добавляю это, потому что в прошлом люди Google давали решение для передачи больших изображений по действиям. Но вы правы, этого следует избегать любой ценой, поэтому мое обновление фокусируется на первом как на более жизнеспособном решении.