Czyli rozumiem, że jeśli robię przykładowo menu z sklepem i zmienia mi się tylko środek, czyli zawartość sklepu (Jak wybiorę daną kategorię) a ekran po boku nie zmienia się, to najlepiej użyć fragmentu w tym ,,środku", który się zmienia, a boki zostawić nie zmienne tak?
A to już zależy jak to konkretnie zaimplementowałeś. W takim wypadku, przykładowo, jeśli robisz dla smartfona menu wysuwane, a dla tabletu w poziomej orientacji menu umieszczne na stałe. To można to zrobić np tak:
Dla smartfonu - activity korzystające DrawerLayout i w nim:
- fragment z menu
- jakiś layout jako "container" któy będziesz podmieniał fragmentami z zawartością sklepu
Dla tabletu - activity zawierający zwykły relative layout a w nim:
- po lewej fragment z menu, dokładnie ten sam co w wersji smartfon
- po prawej tak jak w smartfonie - layout który będziesz podmieniał na potrzebne fragmenty
Dzięki temu menu piszesz raz, masz jedną klasę, jeden layout, całość obsługi menu w osobnym fragmencie niezależnym od platformy, fragmenty z zawartością sklepu masz niezależne od platformy i w nich nie musisz się przejmować w ogóle tym w jakiej aktywności są umieszczone. Jedyne co pozostaje do zakodowania osobno dla tych layoutow, to obsluga drawera dla smartfona. Czyli osobny kod piszesz wyłącznie dla tego elementu który różni oba layouty. Całą resztę piszesz raz, bez przejmowania sie tym w jakim układzie zostanie wyświetlona. Dlatego cała reszta jest podzielona na fragmenty.
To tak przykładowo. Inny przykład - layout główny masz zawsze ten sam, jedno activity, sklep za to na każdej potstronie ma kompletnie inny układ, inne obiekty itd. To wtedy robisz activity z menu na stałe, a "podstrony" robisz jako fragmenty.
Możesz ewentualnie zrobić tyle activity ile masz "podstron" w sklepie i w każdym z nich osadzić menu jako fragment, bo jest identyczne dla wszystkich. Ale to wydaje mi się mało optymalne, bo masz dużo powtarzającego się kodu i przy jakimś późniejszym rozwoju apki i większych zmianach, musisz wprowadzać zmiany w każdym activity.
Generalnie priorytetem jest jak najmniejszy nakład pracy przy późniejszych zmianach w kodzie. Wydajność dopiero na drugim miejscu. Dzięki temu napiszesz więcej, szybciej i ładniej. A jeśli przesadzisz z optymalizacją i w imię wydajności zrobisz kod w którym każdą zmianę trzeba uwzględnić w wielu miejscach kodu, to prędzej czy później narobisz tyle błędów, że i tak z wydajności nic nei zostanie, a user nie będzie zadowolony.