Android - повторяющиеся фрагменты транзакций и ресурсов телефона (сложный) - PullRequest
2 голосов
/ 25 марта 2012

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

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

(приложение является портом для Android существующего приложения для iPhone, и хотя люди, на которых я работаю, с готовностью понимают необходимость сделать Android-приложение как можно более родным для Android, они хотят, чтобы базовый пользовательский интерфейс и управление остаются прежними, так что если пользователь iPhone купит телефон Android и купит другую копию своего приложения, принципиальной разницы не будет)

Однако основная вкладка отличается - она ​​сама себя перезагружает. Приложение по сути является учебным пособием; представьте, что каждый вид представляет собой карточку, представляющую информацию, и пользователя, если листать карточки.

Это достигается с помощью запроса фрагмента 'card', чтобы менеджер фрагментов отсоединился, а затем снова присоединился. Это достигается путем вызова метода в FragmentActivity, который выполняет следующее (упрощенное из фактического кода):

FragmentTransaction ft = .... .beginTransaction();

ft.setCustomAnimations(int out,int in)
ft.detach(relevantFragment);
ft.attach(relevantFragment);

ft.commit();
.... .executePendingTransaction();

где 'out' - fromXDelta = "0", toXDelta = "- 100%"

и 'in' - fromXDelta = "100%", toXDelta = "0"

Следовательно, старый вид сдвигается влево, в то время как новый вид скользит справа.

Это работает просто отлично, на самом деле, с точки зрения пользовательского опыта, это именно то, что я хочу. Однако фрагмент, который мы перезагружаем, имеет сложную иерархию представлений чрезвычайно , и я понимаю, что фрагменты будут собираться и повторно создаваться для каждого перехода при каждом переходе, который пользователь может легко вызвать большое количество раз (100+) при использовании приложения для обучения.

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

.

АКТУАЛЬНЫЙ ВОПРОС: Есть ли какой-либо способ эмулировать такое поведение, которое не заставляет телефон полностью разрушать и заново создавать представление каждые секунды просмотра, когда пользователь щелкает по нему?

Вещи, которые я рассмотрел:

  1. Устраните транзакции / анимации и просто заставьте фрагмент загружать новую информацию. Это было бы легко, конечно, но это не то, чего хотят мои работодатели.

  2. Создайте две идентичные копии иерархии представления в XML и переключайте их назад и вперед из View.VISIBLE и View.GONE, используя собственную ScaleAnimation для попытки эмулировать это поведение. Я не уверен, сработает ли это, но на первый взгляд это выглядит довольно ... неряшливо.

  3. Это ненужная и / или глупая оптимизация, о которой мне не стоит беспокоиться из-за того, как работает телефон и / или система Android, и я просто не понимаю, что теряю время.

Любые советы, предложения или разъяснения о том, как работает операционная система, высоко ценятся.

Ответы [ 2 ]

3 голосов
/ 25 марта 2012

мое понимание фрагментов таково, что все это будет собирать мусор и пересматриваться при каждом переходе

Если вы посмотрите на свой код, это невозможно, по крайней мере, на уровне фрагментов. Вы не отпускаете объект Fragment и не предоставляете средства для Android для создания совершенно нового идентичного фрагмента. Следовательно, Fragment не будет собираться мусором.

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

Почти все, что я прочитал, указывает на то, что я должен избегать создания / сбора тяжелых объектов, так как это приведет к тому, что мое приложение пожирает батарею пользователя

Совершено миллионы раз, определенно. Сделано "100+" раз, это не будет "пожирать" батарею. Клев, возможно.

Вещи, которые я рассмотрел:

Я бы сосредоточился на # 3. Самое большее, определите, действительно ли воссоздается иерархия представления фрагмента в форме множественных вызовов onCreateView(). Если это так, используйте Traceview, чтобы точно определить, сколько времени занимает эта операция.

0 голосов
/ 26 марта 2012

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

CommonWare верен в своем первоначальном ответе (в основном).Fragment.onCreateView () IS вызывается каждый раз, когда фрагмент прикреплен, но продуктивного способа оптимизации рендеринга представления нет.Ничего не поделаешь, не о чем беспокоиться.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...