Metoda nr 1:
Aby uzyskać całkowicie przezroczysty pasek stanu, musisz użyć statusBarColor
, który jest dostępny tylko w API 21 i nowszych. windowTranslucentStatus
jest dostępny w API 19 i nowszych, ale dodaje przyciemnione tło do paska stanu. Jednak ustawienie windowTranslucentStatus
daje jedną rzecz, statusBarColor
której nie daje zmiana na przezroczystą: ustawia flagi SYSTEM_UI_FLAG_LAYOUT_STABLE
i SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
. Najłatwiejszym sposobem na uzyskanie tego samego efektu jest ręczne ustawienie tych flag, co skutecznie wyłącza wstawki narzucone przez system układu Androida i pozostawia samemu sobie.
W swojej onCreate
metodzie nazywasz tę linię :
getWindow().getDecorView().setSystemUiVisibility(
View.SYSTEM_UI_FLAG_LAYOUT_STABLE
| View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN);
Pamiętaj, aby ustawić przezroczystość w /res/values-v21/styles.xml:
<item name="android:statusBarColor">@android:color/transparent</item>
Lub ustaw przezroczystość programowo:
getWindow().setStatusBarColor(Color.TRANSPARENT);
Dobrą stroną tego podejścia jest to, że te same układy i projekty mogą być również używane w API 19, zamieniając przezroczysty pasek stanu na przyciemniany półprzezroczysty pasek stanu.
<item name="android:windowTranslucentStatus">true</item>
Metoda nr 2:
Jeśli potrzebujesz tylko pomalować obraz tła pod paskiem stanu, zamiast umieszczać widok za nim, możesz to zrobić, ustawiając tło motywu działania na żądany obraz i ustawiając przezroczystość paska stanu, jak pokazano w metodzie # 1. To była metoda, której użyłem do stworzenia zrzutów ekranu do artykułu Android Police z kilku miesięcy temu.
Metoda nr 3:
Jeśli musisz zignorować standardowe wstawki systemowe dla niektórych układów, zachowując je w innych, jedynym realnym sposobem na to jest praca z często połączoną ScrimInsetsFrameLayout
klasą. Oczywiście niektóre rzeczy wykonane na tych zajęciach nie są konieczne we wszystkich scenariuszach. Na przykład, jeśli nie planujesz używać syntetycznej nakładki paska stanu, po prostu init()
zakomentuj wszystko w metodzie i nie przejmuj się dodawaniem niczego do pliku attrs.xml. Widziałem, jak to podejście działa, ale myślę, że przekonasz się, że ma ono inne implikacje, których obejście może wymagać dużo pracy.
Zauważyłem też, że sprzeciwiasz się owijaniu wielu układów. W przypadku zawijania jednego układu wewnątrz drugiego, gdzie oba mają match_parent
wysokość i szerokość, wpływ na wydajność jest zbyt trywialny, aby się nim martwić. Niezależnie od tego możesz całkowicie uniknąć tej sytuacji, zmieniając klasę, z której się ona rozciąga, FrameLayout
na dowolną inną klasę układu, którą lubisz. Będzie działać dobrze.
android:fitsSystemWindows="true"