Стоит ли использовать parcelable для передачи данных между действиями?

Я хочу улучшить производительность моего приложения. Одна вещь, которая приходит мне на ум,-это заменить все сериализуемые параметры пакета намерений на parcelable.

Я нашел этот поток: преимущество использования Parcelable вместо сериализации объекта

Там кто-то утверждает Из книги, что parcelable предназначен только для межпроцессной коммуникации? Это, наверное, уже не актуально, верно? Потому что это, по крайней мере технически, возможно.

Тогда есть также утверждение, что parcelable не надежен, потому что реализация варьируется в разных устройствах, это, конечно, было бы убийственной характеристикой, так как я хочу, чтобы он работал всегда, все устройства и API, начиная с API 7.

И я также прочитал несколько советов об использовании Externalizable или реализации пользовательского протокола... но я не понимаю, почему Parcelable не надежен, почему разработчики Android делают такой шум вокруг чего-то, что не будет работать на всех устройствах? Или это комментарий не соответствует действительности?

Стоит ли реализовывать Parcelable? Придерживаюсь ли я Сериализуемого? Или пользовательская сериализация / экстернализация-это правильный подход?

Пожалуйста, не говорите мне "просто попробуйте", у меня нет времени на это, особенно чтобы проверить, надежен ли Parcelable (а также недостаточно устройств)... спрашивается опыт...

Спасибо.

P.S. Также не говорите мне "сериализуемый будет приемлемым для большинства случаев" я знаю, что это действительно приемлемо, но у меня есть время и было бы нравится использовать его с Parcelable (или что-то еще), если это улучшает пользовательский опыт.

2 5
android performance parcelable serialization

2 ответа:

Parcelable работает всегда, все время, на всех устройствах. Если бы это было не так, ничего не сработало бы. Внутренние устройства Android очень сильно зависят от Parcelable.

Parcelable будет немного эффективнее, чем Serializable, но я серьезно сомневаюсь, что это сильно повлияет на ваш "пользовательский опыт" (если, конечно, вы не используете его повсюду и не сериализуете очень большие и сложные объекты).

Если вы думаете, что у вас проблемы с производительностью, то я бы потратил свое свободное время на профилирование применение и сбор эмпирических данных о том, где он проводит свое время. IMHO замена Serializable на Parcelable является относительно низкоуровневой оптимизацией реализации, которая, вероятно, даст вам близкое к нулю ощутимое улучшение производительности.

5

Там кто-то утверждает Из книги, что parcelable предназначен только для межпроцессной коммуникации? Это, наверное, уже не актуально, верно? Потому что это, по крайней мере технически, возможно.

Если Parcelable не предназначался для передачи между действиями, почему методputExtra (String name, Parcelable value) Intent существует начиная с уровня API 1?

Тогда есть также утверждение, что parcelable не является надежным, потому что реализация варьируется в разных устройствах, это было бы, конечно, убийственной характеристикой, так как я хочу, чтобы он работал всегда, все устройства и API, начиная с API 7.

Позвольте мне процитировать посылку документация:

Parcel не является механизмом сериализации общего назначения. Этот класс (и соответствующий Parcelable API для размещения произвольных объектов в посылке) спроектирован каквысокопроизводительный IPC-транспорт . Как таковой, он не подходит для поместите любые данные участка в постоянное хранилище : изменения в базовой реализации любых данных в участке могут сделать старые данные нечитаемыми.

Здесь я могу прочитать только совет о том, чтобы не хранить данные о посылках в постоянном хранилище. По моему личному опыту, Parcelable никогда не был проблемой для передачи данных между действиями. Я активно использую его и поддерживаю API 8 к текущему API.

Относительно производительности и скорости установлено, что использование Parcelable лучше, так как это специфичный для Android высокопроизводительный механизм сериализации IPC transport. Хотя, чтобы действительно увидеть улучшение, оно должно зависеть от того, насколько вы его используете.

4