Каковы преимущества и недостатки использования configChanges = «ориентация» для устройств Android?

Question

Я хочу использовать android:configChanges="orientation|keyboardHidden" для нескольких своих действий, чтобы мой onCreate не вызывался снова, но я думал, что посмотрю, имел ли кто-нибудь список плюсов и минусов, потому что this link говорит, что он должен будет использоваться в качестве крайней меры.

Answer 1

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

Небольшой недостаток заключается в том, что использование конкретных ресурсов (для пейзажной или портретной ориентации) не применяется автоматически.

В моем (возможно, небольшом) опыте, я думаю, что это не стоит того, чтобы делать всю сантехнику.

«Правильная» обработка этих изменений конфигурации требует большого количества сантехники с вашей стороны, и все становится еще более драматичным, если вам нужно поддерживать диалоги прогресса во время изменений ориентации экрана.

Хотя большинство людей предпочтут быстрое исправление, изменив манифест и настроив свою деятельность на android: configChanges = "keyboardHidden | orientation", я думаю, важно понять, что есть альтернативы этому.

Это требует большего количества кода, но это дает вам более полное представление о том, как работает общая система.

Answer 2

Это странно, что Google на самом деле не говорить больше о рассуждении позади него, но на самом деле есть три основные причины, я могу думать о том, чтобы избежать использования этого подхода:

• По моему опыту, некоторые типы показов (особенно WebViews и MapViews на Android 2.1 или ниже) могут вести себя довольно странно после изменения ориентации, если они не были воссозданы (например, кнопки масштабирования, например, неправильно настроены).
• Это не позволяет использовать ориентировочные макеты (см., Например, ландшафтный вид нового приложения Market).
• Это может помешать вам обнаружить ошибочное поведение вашего приложения, связанное с другими причинами, по которым ваша деятельность может быть уничтожена и воссоздана (например, с низкой памятью или с другими нормальными убивающими в фоновом режиме). То есть, если ваша деятельность может изящно обрабатывать перезапуск из-за вращения, возможно, он может перезапустить из-за фонового убийства. Если вы пропустите обработку вращения, вы можете не столкнуться с перезагрузкой из-за фонового убийства при обычном тестировании, пока пользователь с более старым телефоном с низкой памятью не запишет сообщение об ошибке.

Последняя причина - большая; особенно с более старыми телефонами с низким ОЗУ и с предположительно более агрессивными режимами аутокинирования в Gingerbread, ваши действия должны знать, как быстро воссоздаваться после уничтожения, сохраняя свое состояние независимо от ориентации. И как только ваша деятельность может справиться с такими видами разрушения/отдыха, вы, вероятно, все настроены на то, чтобы сменить вращение в любом случае. Вы можете получить некоторую скорость, поглощая событие вращения (так как вам не нужно возвращаться через инфляцию компоновки и все такое), но это примерно все, в этот момент.

Если вы решите проглотить вращения, я настоятельно рекомендую всегда использовать эмулятор или устройство с опцией «Незамедлительно уничтожить действия» , а затем убедиться, что переключение приложений или резервное копирование в стеке задач по-прежнему работают правильно.

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