Статические фрагменты против динамических фрагментов

существует большая разница в использовании фрагментов через XML или динамически через java-код, в зависимости от того, какой вы выбрали основное отличие будет от того, как пользователь испытывает поток приложения.

TLDR: приведенные ниже характеристики разделяются как фрагментами, созданными через XML, так и динамически с помощью кода java (через FragmentManager API), но код Java позволяет изменять, добавлять, удалять каждый фрагмент во время выполнения, позволяя гибкость это было бы невозможно иначе.

но чтобы ответить на ваш вопрос:

1-ремонтопригодность-примерно то же самое, вы используете атрибут android:name для определения fragment класс, который вы хотите использовать против использования:

// get fragment manager
FragmentManager fm = getFragmentManager();

// add fragment
FragmentTransaction ft = fm.beginTransaction();
ft.add(R.id.your_placehodler, new YourFragment());
// alternatively add it with a tag
// trx.add(R.id.your_placehodler, new YourFragment(), "detail");
ft.commit();

в случае только одной транзакции в любом случае едва ли есть какие-либо усилия.

2 - совместимость с: об этом как часто используются разработчиками везде

3 - производительность, одноразовый процесс инфляции может быть немного быстрее, но они по сути, даже.

4-UX: здесь в зависимости от ваших потребностей может быть без разницы или огромный.

так в чем же эта большая разница между XML или "динамическими фрагментами"?

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

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

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

// replace
FragmentTransaction ft = fm.beginTransaction();
ft.replace(R.id.your_placehodler, new YourFragment());
ft.commit();

// remove
Fragment fragment = fm.findFragmentById(R.id.your_placehodler);
FragmentTransaction ft = fm.beginTransaction();
ft.remove(fragment);
ft.commit(); 

" Итак, почему у нас есть XML-экземпляры фрагментов? Мы должны запретить их прямо сейчас!"

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

еще один важно случай использования может быть просто готов к использованию другого устройства Configuration например размер экрана, или разные ориентация экрана (как при использовании приложения как на планшетов и телефонов portrait / landscape), XML-это простое решение для предоставления другого макета для каждого из этих (и других) устройств настойки.

источники: ссылке

ссылке

ссылке

ссылке