Zespół ChromeOS dokłada wszelkich starań, aby ulepszać narzędzia i platformy dla deweloperów, które umożliwiają deweloperom aplikacji na Androida bezproblemową optymalizację aplikacji pod kątem Chromebooków. W tym celu musimy stale szukać sposobów na udostępnianie deweloperom skutecznych zestawów narzędzi, które ułatwią tworzenie aplikacji na duże ekrany i ChromeOS.
ChromeOS rozwijał się przez lata, gdy pojawiały się nowe wyzwania. Jednym z tych wyzwań jest wczesne i częste informowanie inżynierów o krytycznych problemach. Reguły Lint są kluczowe dla jakości, ponieważ dostarczają deweloperom sygnały ostrzegawcze o problemach, które wystąpią, jeśli nie zostaną rozwiązane. Zaktualizowane reguły lint zapewniają deweloperom większą widoczność działania aplikacji w ChromeOS, pokazując problemy, zarówno te związane z oprogramowaniem, jak i sprzętem, które niewątpliwie spowodują problemy z aplikacjami na Androida uruchamianymi na dowolnym urządzeniu z ChromeOS.
Więcej informacji o tych regułach lintowania i ich znaczeniu znajdziesz w naszym poście na blogu.
Gdzie znajdują się te reguły lint?
Prace nad tym narzędziem trwają już od kilku miesięcy. Zgodnie z harmonogramem wydań Android Studio niektóre reguły lint są wprowadzane w wersjach Canary Electric Eel. Niektóre z tych reguł lint są teraz dostępne w wersjach Canary Flamingo. W najbliższych miesiącach będziemy pracować nad tym, aby te funkcje były dostępne w stabilnych wersjach Android Studio.
Warto też pamiętać, że w nowszych wersjach Android Studio te reguły będą domyślnie włączone. Chcemy w ten sposób zapewnić bardziej zdecydowane wskazówki dotyczące tego, jak w przyszłości pomagać inżynierom w tworzeniu aplikacji na ChromeOS i większe ekrany.
Nowe reguły lint (zaktualizowane w Flamingo Canary 3)
Obsługa ABI x86/x86_64
Większość Chromebooków działa na architekturze Intel, co czyni je platformą opartą głównie na architekturze x86. Aby ChromeOS był prawidłowo obsługiwany, gdy kod NDK jest częścią pliku binarnego, architektura x86 zwiększa wydajność, ponieważ eliminuje konieczność tłumaczenia z bibliotek ARM. Dlatego zdecydowanie zalecamy, aby zespół deweloperów dodał obsługę architektury x86 lub najlepiej x86_64, ponieważ zwiększy to wydajność każdego kodu natywnego w ChromeOS lub na dowolnym urządzeniu z procesorem Intel.
Środek zaradczy
Jeśli to możliwe, dodaj x86 i x86_64 w abiSplits w build.gradle. Upewnij się też, że dodajesz kod do odpowiednich folderów, aby obsługiwać te interfejsy ABI. Więcej informacji znajdziesz w dokumentacji interfejsów ABI Androida i w prezentacji ABI Support from ADS.
Uwaga: upewnij się, że wszystkie używane biblioteki zewnętrzne mają też pliki binarne x86 i x86_64.
Ograniczenia sprzętowe ChromeOS
Większość urządzeń z ChromeOS ma mniejszy zestaw czujników sprzętowych i innych funkcji niż telefon z Androidem. Celem tej reguły jest poinformowanie deweloperów, że jeśli używają flagi <uses-feature> z parametrem android:required=true, ich aplikacja nie będzie dostępna w Sklepie Google Play w ChromeOS. Aby zapewnić dostępność aplikacji na jak największej liczbie urządzeń, zalecamy, aby funkcja sprzętowa nie była wymagana domyślnie. Zamiast tego możesz dodać kod zabezpieczający, który będzie sprawdzać konkretny sprzęt w czasie działania. Przykładem może być
<uses-feature android:name="android.hardware.camera" android:required="true">
Środek zaradczy
Upewnij się, że funkcje w aplikacji są rzeczywiście wymagane. Jeśli nie, zmień parametr android:required na false i dodaj programowanie defensywne, gdy wymagane są wywołania interfejsu API. Więcej informacji znajdziesz w dokumentacji dotyczącej funkcji zadeklarowanych jawnie.
Aktywności, których rozmiaru nie można zmienić
Domyślnie środowisko wykonawcze Androida w ChromeOS, które działa na Chromebookach z Androidem R lub nowszym, uruchamia aplikację na Androida w wersji na telefon lub tablet w zależności od domyślnego stanu interfejsu. Jest jednak trzecia opcja, która zapewnia użytkownikom ChromeOS większy komfort – tryb z możliwością zmiany rozmiaru. Jeśli w ramach aktywności włączysz ten flagę, użytkownicy, którzy mogą korzystać z aplikacji w dowolnym środowisku z wieloma oknami, będą mogli zmieniać jej rozmiar. Te zmiany pozwolą użytkownikom skalować interfejs zgodnie z własnymi potrzebami. Po wprowadzeniu tych zmian w pliku manifestu przetestuj aplikację w emulatorze na komputery, o którym mowa poniżej.
Środek zaradczy
Dodaj atrybut resizableActivity="true" do działania w pliku AndroidManifest.xml. Więcej informacji znajdziesz w dokumentacji dotyczącej ograniczeń na dużych ekranach.
Zmiany konfiguracji
Ważną kwestią związaną z ekranami o zmiennej wielkości jest to, że za każdym razem, gdy użytkownik zmieni rozmiar aplikacji, wywoływana jest funkcja onConfigurationChanged(). Jeśli aplikacja wykonuje pełne ponowne rysowanie w ramach tej metody, będzie to miało wpływ na wydajność. Obecnie sprawdzamy, czy funkcja finish() nie jest wywoływana w ramach funkcji onConfigurationChanged, ponieważ stan savedInstanceState powinien być obsługiwany z większą szczegółowością niż pełne ponowne rysowanie. Będziemy nadal znajdować przypadki, w których nastąpi spadek wydajności, i odpowiednio aktualizować tę regułę.
Środek zaradczy
Sprawdź, czy w interfejsie onConfigurationChanged() API w aktywnościach i fragmentach nie jest wywoływana funkcja finish(). Więcej informacji znajdziesz w dokumentacji dotyczącej obsługi zmian konfiguracji.
Obsługa klawiatury i myszy
Wraz z rosnącą popularnością Jetpack Compose chcieliśmy mieć pewność, że korzystanie z tych bibliotek będzie w przyszłości obejmować też obsługę myszy i klawiatury. Z czasem będziemy zwiększać możliwości korzystania z myszy, klawiatury, trackpada i innych urządzeń peryferyjnych. Aby uzyskać podstawowe funkcje, musisz zaktualizować zależności Gradle do minimalnych wymaganych wersji.
Środek zaradczy
Zaktualizuj urządzenie androidx.compose.foundation:foundation do wersji co najmniej 1.2. Więcej informacji znajdziesz w informacjach o wersji Compose.
Wskazówka: 90% użytkowników korzysta z aplikacji na Chromebookach za pomocą klawiatury i myszy. (Źródło: wewnętrzne dane Google z 2022 r.*)
Prześlij opinię
Zespół stale pracuje nad ulepszaniem tych narzędzi i dokumentacji dotyczącej optymalizacji pod kątem dużych ekranów. Kluczowym krokiem w tym procesie jest przekazywanie nam opinii na temat dokładności i przydatności reguł lint wdrożonych w Android Studio. Możesz to zrobić, przesyłając opinię na temat reguły. Gdy reguła lint pojawi się w Android Studio, kliknij „Provide feedback on this warning” (Prześlij opinię o tym ostrzeżeniu). Powinno się wyświetlić okno dialogowe podobne do tego poniżej. Im dokładniejsze i bardziej szczegółowe będą podane informacje, tym szybciej będziemy mogli wprowadzić odpowiednie zmiany.
