Zrozumienie architektury procesorów Androida (ABI): dlaczego arm64-v8a, armeabi-v7a i x86 mają znaczenie

Jeśli kiedykolwiek scaliłeś zestaw podzielonych plików APK i zaobserwowałeś, jak telefon wyświetla komunikat „Aplikacja niezainstalowana” lub, co gorsza, jak instalował się prawidłowo, a po dotknięciu ikony ulegał awarii, istnieje spora szansa, że ​​prawdziwy problem nie miał nic wspólnego z uszkodzonym pobranym plikiem. Prawie na pewno chodziło o architekturę: niedopasowanie procesora, na którym działa telefon, i procesora, dla którego skompilowano natywny kod aplikacji. Większość użytkowników Androida nigdy nie musi o tym myśleć, aż do momentu, gdy po cichu coś zepsuje, a potem szybko staje się to istotne. Oto, co architektura procesora oznacza dla pliku APK, dlaczego pojedyncza aplikacja w Sklepie Play jest potajemnie dostarczana w postaci kilku różnych wersji siebie i jak sprawdzić zgodność przed zainstalowaniem czegokolwiek.

Co to jest ABI

ABI oznacza interfejs binarny aplikacji. W praktyce jest to zestaw instrukcji zrozumiały dla chipa — format surowego kodu maszynowego, który procesor może bezpośrednio wykonać. Większość aplikacji na Androida, części napisane w Javie lub Kotlinie, jest kompilowana do kodu bajtowego działającego w środowisku wykonawczym Androida (ART), a ART nie przejmuje się szczególnie tym, na którym chipie się znajduje. Warstwa ta z założenia jest niezależna od architektury, co w dużej mierze wyjaśnia, dlaczego aplikacje na Androida „po prostu działają” na tak szerokiej gamie sprzętu.

Kod natywny to inna historia. Wiele aplikacji, zwłaszcza gier, aplikacji do aparatu, narzędzi do uczenia maszynowego i wszystkiego, co wymaga intensywnego przetwarzania dźwięku lub wideo, dostarcza natywne biblioteki napisane w C lub C++ za pośrednictwem Android NDK. Biblioteki te są kompilowane z wyprzedzeniem w kod maszynowy dla jednego konkretnego zestawu instrukcji, a chip zbudowany dla jednego zestawu instrukcji zazwyczaj nie może wykonać kodu maszynowego napisanego dla innego. To jest cały powód, dla którego ABI istnieją jako coś wartego zrozumienia: w momencie, gdy aplikacja zawiera choćby jedną natywną bibliotekę .so, jej zgodność zostaje powiązana z architekturami, dla których biblioteka została zbudowana.

Architektury, na które natkniesz się

Kiedyś w tej przestrzeni panowała większa różnorodność (pamiętasz zwykły armeabi lub MIPS?), ale do 2026 roku pole zawęziło się do czterech wartych poznania ABI:

Jeśli trzymasz telefon kupiony w ciągu ostatnich pięciu lub sześciu lat, prawie na pewno jest to arm64-v8a. Wyjątkami, o których warto pamiętać, są emulatory i Chromebooki, które często działają na platformie x86_64, ponieważ jest ona zgodna z procesorem laptopa lub komputera stacjonarnego.

Dlaczego aplikacje w ogóle zawracają sobie głowę dostarczaniem wielu kompilacji

Oczywistym pytaniem jest, dlaczego programiści nie upchają natywnych bibliotek każdej architektury w jednym pliku APK i nie skończą z tym. Niektóre aplikacje tak właśnie robią i nazywa się to uniwersalnym lub „grubym” plikiem APK. Minusem jest rozmiar. Gra z natywnymi bibliotekami dla arm64-v8a, armeabi-v7a, x86 i x86_64, wszystkie zebrane razem, może z łatwością podwoić lub potroić swój rozmiar w porównaniu z kompilacją zawierającą tylko jedną architekturę, której potrzebuje Twoje urządzenie. Pomnóż to przez miliony instalacji, a otrzymasz naprawdę znaczną ilość zmarnowanej przepustowości i miejsca na kod, który nigdy nie będzie działał na tym urządzeniu.

Aby uniknąć marnotrawstwa, Google Play i format Android App Bundle dzielą aplikację na mały podstawowy plik APK oraz szereg plików APK konfiguracyjnych, z których jeden jest poświęcony architekturze. Gdy telefon zażąda aplikacji, Sklep Play dostarcza podstawowy plik APK wraz z podziałem architektury pasującym do Twojego układu, a także z dopasowaną gęstością ekranu i podziałami językowymi. Kończy się instalacją, która zachowuje się jak pojedyncza aplikacja, ale składa się z kilku specjalnie zaprojektowanych elementów za kulisami.

Jak korzystają z tego podzielone pliki APK i pakiety aplikacji

Jeśli kiedykolwiek otworzyłeś pakiet .apks lub .xapk i zauważyłeś nazwy plików takie jak split_config.arm64_v8a.apk, split_config.armeabi_v7a.apk, split_config.xxhdpi.apk i split_config.en.apk znajdujące się obok base.apk, to jest to dokładnie ten system w akcji, po prostu wyeksportowany jako zestaw plików, a nie dostarczony po cichu przez Sklep Play. Podziały gęstości i języków są zwykle bezpieczne w przypadku instalacji bez rozróżnienia, ponieważ telefon po prostu zignoruje zasoby, których nie potrzebuje. Podział architektury jest inny: zainstaluj niewłaściwy lub nie zainstaluj pasującego, a będziesz miał poważne kłopoty.

Kiedy używasz konwertera do scalania podzielonego pakietu z powrotem w jeden instalowalny plik APK, proces scalania musi wybrać, która architektura ma zostać złożona. Dobry konwerter utrzymuje każdy podział architektury, który jest naprawdę przydatny, lub pozwala ci wybrać, zamiast po cichu trzymać tylko jeden i mieć nadzieję, że będzie pasował do twojego urządzenia.

Co się dzieje, gdy architektura nie pasuje

Istnieją dwa różne tryby awarii, które warto rozróżnić, ponieważ wyglądają i działają inaczej niż zwykły użytkownik.

Pierwszym z nich jest całkowity błąd instalacji. Jeśli aplikacja jest zbudowana prawie wyłącznie w oparciu o kod natywny i nie ma znaczących rozwiązań zastępczych, menedżer pakietów Androida w ogóle odmówi jej zainstalowania, zwykle wyświetlając błąd taki jak INSTALL_FAILED_NO_MATCHING_ABIS. Nigdy nawet nie będziesz mógł otworzyć aplikacji; instalator zatrzymuje Cię przy drzwiach.

Drugi, bardziej frustrujący wynik to cichy częściowy sukces. Jeśli aplikacja ma punkt wejścia Java lub Kotlin, który sam się ładuje, ale następnie próbuje wywołać bibliotekę natywną, która po prostu nie jest dostępna dla Twojej architektury, instalacja zakończy się normalnie. Wszystko wygląda dobrze, dopóki nie dotkniesz ikony, kiedy to aplikacja ulega awarii niemal natychmiast, często z plikiem UnsatisfiedLinkError ukrytym w dziennikach. To klasyczna historia „Przekonwertowałem, zainstalowałem, a potem po prostu natychmiast się zamyka” i prawie zawsze jest to problem z architekturą, a nie uszkodzony plik.

Jak sprawdzić architekturę własnego telefonu

Dla zdecydowanej większości użytkowników sprawa jest prosta: jeśli masz telefon z 2019 roku lub nowszy, wybierz architekturę arm64-v8a. Jeśli jednak chcesz mieć stuprocentową pewność lub korzystasz ze starszego bądź nietypowego urządzenia, oto kilka praktycznych sposobów:

• Sprawdź dokładny model chipsetu swojego telefonu (widoczny na pudełku, w instrukcji lub na stronie takiej jak GSMArena) i sprawdź, czy ten chipset jest 32-bitowy, czy 64-bitowy ARM.
• Zainstaluj lekką aplikację informującą o systemie, która bezpośrednio raportuje architekturę procesora. Istnieje kilka bezpłatnych aplikacji specjalnie do tego celu.
• Sprawdź, czy telefon został dostarczony z oryginalną wersją systemu operacyjnego Android 9 lub nowszą; Wymagania Google dotyczące wersji 64-bitowej z mniej więcej tamtej epoki sprawiają, że arm64-v8a jest w zasadzie gwarantowany we wszystkim, co się kwalifikuje.

Jak sprawdzić, jakie architektury obsługuje plik APK

Przed zainstalowaniem pliku spoza Sklepu Play warto raczej sprawdzić, co się w nim znajduje, niż zgadywać. Natywne biblioteki pakietu APK znajdują się w folderach nazwanych na cześć ich architektury w katalogu lib/, takich jak lib/arm64-v8a/ lub lib/armeabi-v7a/. Każde narzędzie, które może sprawdzić wewnętrzną strukturę pliku APK, może dokładnie określić, które z tych folderów są obecne, a co za tym idzie, na jakich urządzeniach plik będzie uruchamiany.

Uniwersalny plik APK vs pojedynczy plik ABI: którego należy użyć?

Typowe błędy popełniane przez ludzi przy dzielonych pakietach

• Zakładając, że każdy podział jest opcjonalny. Podział gęstości i języka zwykle tak, ale podział architektury nie; nigdy nie pomijaj go podczas scalania.
• Chwytanie tylko jednej architektury wydzielonej z witryny lustrzanej. Jeśli pobranie innej firmy oferuje tylko, powiedzmy, fragment armeabi-v7a, może po prostu nie działać na urządzeniu, które zamiast tego potrzebuje arm64-v8a, nawet jeśli sama aplikacja jest legalna.
• Zapominając, że tablety i Chromebooki nie zawsze są ARM. Wiele Chromebooków z aplikacjami na Androida i niektóre starsze tablety mają procesory x86 lub x86_64, a nie ARM.
• Testowanie pakietu APK obsługującego tylko ARM w emulatorze x86. Niektóre starsze kompilacje emulatorów działają na platformie x86, a pakiet APK zawierający tylko natywne biblioteki ARM po prostu nie uruchomi się w nich, niezależnie od tego, jak pakiet APK został spakowany.
• Mylenie „uniwersalnego” z „pojedynczym ABI”. Uniwersalny plik APK jest celowo większy, ponieważ zawiera wszystko; plik APK z jednym ABI jest mały i celowo ograniczony do jednej rodziny chipów.

Często Zadawane Pytania (FAQ)

Nie musisz tego wszystkiego zapamiętywać. Krótka wersja: nowoczesne telefony prawie zawsze są wyposażone w arm64-v8a, aplikacje są dzielone według architektury, aby zaoszczędzić miejsce, a jeśli coś odmawia instalacji lub ulega awarii zaraz po otwarciu, niedopasowanie architektury jest jedną z pierwszych rzeczy, które warto wykluczyć przed założeniem, że sam plik jest uszkodzony.