درک معماری CPU Android (ABI): چرا arm64-v8a، armeabi-v7a و x86 مهم هستند
اگر تا به حال مجموعه‌ای از فایلهای APK تقسیم‌شده را ادغام کرده‌اید و تماشا کرده‌اید که تلفنتان «برنامه نصب نشده» را پس می‌زند، یا بدتر از آن، مشاهده کرده‌اید که به خوبی نصب میشود تا لحظه‌ای که روی نماد ضربه می‌زنید خراب شود، به احتمال زیاد مشکل واقعی ربطی به دانلود خراب ندارد. تقریباً مطمئناً در مورد معماری بود: عدم تطابق بین CPU که تلفن شما روی آن کار می کند و CPU کد اصلی برنامه برای آن کامپایل شده است. اکثر کاربران Android هرگز مجبور نیستند به این موضوع فکر کنند، درست تا لحظه ای که به آرامی چیزی را می شکند و سپس به سرعت مرتبط می شود. در اینجا به معنای معماری CPU برای یک APK، اینکه چرا یک برنامه واحد در Play Store به صورت مخفیانه به عنوان چندین ساخت مختلف از خودش ارسال می شود، و نحوه بررسی سازگاری قبل از نصب هر چیزی است.
ABI چیست
ABI مخفف Application Binary Interface است. از نظر عملی، این مجموعه دستورالعملی است که یک تراشه درک می کند - قالب کد خام ماشینی که یک پردازنده می تواند مستقیماً اجرا کند. اکثر برنامههای Android، قسمت‌هایی که به زبان جاوا یا کاتلین نوشته شده‌اند، در بایت کدی که در داخل Android Runtime (ART) اجرا میشود، کامپایل می‌شوند و ART به‌خصوص اهمیتی نمی‌دهد که روی کدام تراشه قرار دارد. این لایه از نظر طراحی دارای معماری ناشناس است، که بخش بزرگی از این است که چرا برنامههای Androidی معمولاً در طیف وسیعی از سخت‌افزار «فقط کار می‌کنند».
کد بومی داستان متفاوتی است. بسیاری از برنامه‌ها، به‌ویژه بازی‌ها، برنامههای دوربین، ابزارهای یادگیری ماشینی و هر چیزی که پردازش صوتی یا تصویری سنگین انجام میدهد، کتابخانه‌های بومی نوشته شده به زبان C یا C++ را از طریق Android NDK ارسال میکند. این کتابخانه ها زودتر از موعد در کد ماشین برای یک مجموعه دستورالعمل خاص کامپایل می شوند و تراشه ای که برای یک مجموعه دستورالعمل ساخته شده است معمولاً نمی تواند کد ماشین نوشته شده برای یک مجموعه دیگر را اجرا کند. به همین دلیل است که ABI ها به عنوان چیزی ارزش درک وجود دارند: لحظه ای که یک برنامه حتی یک کتابخانه بومی .so را شامل می شود، سازگاری آن با معماری هایی که کتابخانه برای آن ساخته شده است گره می خورد.
معماری هایی که با آنها برخورد خواهید کرد
قبلاً تنوع بیشتری در این فضا وجود داشت (armeabi ساده یا MIPS را به خاطر دارید؟)، اما تا سال 2026 این زمینه به چهار ABI کاهش یافت که ارزش دانستن دارد:
| ABI | عرض بیت | دستگاه های معمولی | یادداشت ها |
|---|---|---|---|
| arm64-v8a | ARM 64 بیتی | تقریباً از سال 2019 تقریباً هر تلفن فروخته شده است | هدف پیش فرض برای برنامه های جدید؛ چندین سال است که گوگل برای ارسال های جدید فروشگاه Play به پشتیبانی 64 بیتی نیاز دارد. |
| armeabi-v7a | ARM 32 بیتی | دستگاه های قدیمی یا ارزان قیمت، برخی از تلفن های ارزان قیمت هنوز در بازارهای در حال ظهور فروخته می شوند | هنوز هم توسط بسیاری از برنامه‌ها برای سازگاری به عقب ارسال میشود، حتی اگر بیشتر دستگاه‌های فعال دیگر به آن نیازی ندارند. |
| x86 | اینتل 32 بیتی | تبلت های قدیمی مبتنی بر اینتل، شبیه سازهای قدیمی | عمدتا منسوخ شده؛ امروز به ندرت با یک گوشی 32 بیتی x86 واقعی روبرو خواهید شد. |
| x86_64 | اینتل 64 بیتی | برخی از کروم بوک ها، شبیه سازهای دسکتاپ Android، چند تبلت x86 | اگر برنامه‌ها را در یک شبیه‌ساز آزمایش کنید، مانند یک Android Studio AVD مبتنی بر x86 یا ساخت‌های BlueStacks، مهم است. |
اگر تلفنی در دست دارید که در پنج یا شش سال گذشته خریده اید، تقریباً مطمئناً گوشی arm64-v8a است. استثناهایی که ارزش به خاطر سپردن دارند شبیه سازها و کروم بوک ها هستند که به جای آن اغلب روی x86_64 اجرا می شوند، زیرا با پردازنده اصلی لپ تاپ یا دسکتاپ مطابقت دارد.
چرا برنامه ها اصلاً حمل و نقل چند ساختمان را آزار می دهند؟
یک سوال واضح این است که چرا توسعه دهندگان کتابخانه های بومی هر معماری را در یک APK جمع نمی کنند و با آن کار نمی کنند. برخی از برنامه ها دقیقاً این کار را انجام می دهند و به آن APK جهانی یا "چاق" می گویند. نکته منفی اندازه است. یک بازی با کتابخانه‌های بومی برای arm64-v8a، armeabi-v7a، x86، و x86_64 که همگی با هم جمع‌بندی شده‌اند، میتوانند به راحتی در مقایسه با ساختی که فقط دارای معماری مورد نیاز دستگاه شما باشد، اندازه آن دو یا سه برابر شود. آن را در میلیون‌ها نصب ضرب کنید و به دنبال مقدار قابل توجهی از پهنای باند و فضای ذخیره‌سازی هدر رفته هستید، برای کدهایی که هرگز روی آن دستگاه اجرا نمی‌شوند.
برای جلوگیری از این اتلاف، Google Play و قالب Android App Bundle یک برنامه را به یک APK پایه کوچک به اضافه یک سری APK پیکربندی تقسیم می‌کنند که یکی از آنها به معماری اختصاص دارد. وقتی تلفن شما برنامه را درخواست میکند، فروشگاه Play APK پایه را همراه با تنها تقسیم معماری که با تراشه شما مطابقت دارد، همراه با تراکم صفحه نمایش و تقسیم زبان ارائه میدهد. در نهایت با نصبی مواجه می‌شوید که مانند یک برنامه واحد عمل میکند، اما از چندین قطعه ساخته‌شده در پشت صحنه جمع‌آوری شده است.
نحوه استفاده از APK و بسته نرم افزاری Split از این
اگر تا به حال یک بسته .apks یا .xapk را باز کرده اید و متوجه نام فایل هایی مانند split_config.arm64_v8a.apk، split_config.armeabi_v7a.apk، split_config.xxhdpi.apk، و split_config.en.apk شده اید که در کنار یک base.apk قرار گرفته اند، این دقیقاً این سیستم در عمل است که به جای اینکه به صورت مجموعه ای از فایل ها توسط Playsil تحویل داده شود، به عنوان مجموعه ای از فایل ها صادر می شود. تراکم و تقسیم زبان معمولاً برای نصب بی رویه بی خطر هستند زیرا تلفن به سادگی منابعی را که به آن نیاز ندارد نادیده می گیرد. تقسیم معماری متفاوت است: یکی را اشتباه نصب کنید یا مشابه را نصب نکنید، و واقعاً با مشکل مواجه خواهید شد.
هنگامی که از یک مبدل برای ادغام یک بسته تقسیم‌شده به یک APK قابل نصب استفاده می‌کنید، فرآیند ادغام باید انتخاب کند که کدام معماری تقسیم میشود تا در آن قرار گیرد. یک مبدل خوب هر تقسیم‌بندی معماری را که واقعاً مفید است حفظ میکند، یا به شما اجازه میدهد انتخاب کنید، نه اینکه بی‌صدا فقط یکی را نگه دارید و امیدوار باشید که با دستگاه شما مطابقت داشته باشد.
وقتی معماری مطابقت ندارد چه اتفاقی میافتد
دو حالت شکست متمایز وجود دارد که ارزش دانستن از همدیگر را دارند، زیرا ظاهر و احساس آنها برای یک کاربر معمولی متفاوت است.
اولین مورد، عدم موفقیت در نصب است. اگر یک برنامه تقریباً به طور کامل بر اساس کدهای اصلی و بدون بازگشت معنی‌دار ساخته شده باشد، مدیر بسته Android به هیچ وجه از نصب آن خودداری میکند و معمولاً با خطایی مانند INSTALL_FAILED_NO_MATCHING_ABIS مواجه میشود. شما هرگز حتی نمی توانید برنامه را باز کنید. نصاب شما را جلوی در متوقف می کند.
دومین نتیجه ناامیدکننده تر، موفقیت جزئی خاموش است. اگر یک برنامه دارای یک نقطه ورودی جاوا یا کاتلین باشد که به خودی خود به خوبی بارگیری می شود، اما سپس سعی می کند به یک کتابخانه بومی که به سادگی برای معماری شما موجود نیست فراخوانی کند، نصب به طور معمول کامل می شود. همه چیز خوب به نظر می رسد تا زمانی که روی نماد ضربه بزنید، در این مرحله برنامه تقریباً بلافاصله خراب می شود، اغلب با یک UnsatisfiedLinkError مدفون در گزارش ها. این داستان کلاسیک "من آن را تبدیل کردم، نصب کرد، سپس فوراً بسته می شود" است، و تقریبا همیشه یک مشکل معماری است تا یک فایل خراب.
چگونه معماری گوشی خود را بررسی کنیم
برای اکثریت قریب به اتفاق مردم این ساده است: اگر تلفن شما متعلق به سال 2019 یا بالاتر است، arm64-v8a را فرض کنید و ادامه دهید. اگر می‌خواهید مطمئن باشید، یا با یک دستگاه قدیمی یا غیرعادی سر و کار دارید، چند گزینه کاربردی وجود دارد:
- مدل دقیق چیپست گوشی خود را جستجو کنید (روی جعبه، دفترچه راهنما یا سایتی مانند GSMArena قابل مشاهده است) و جستجو کنید که آیا آن چیپست ARM 32 بیتی است یا 64 بیتی.
- یک برنامه اطلاعات سیستمی سبک وزن را نصب کنید که به طور مستقیم معماری CPU را گزارش می دهد، چندین برنامه رایگان به طور خاص برای این منظور وجود دارد.
- بررسی کنید که آیا گوشی با Android 9 یا جدیدتر به عنوان نسخه اصلی سیستم عامل خود ارسال شده است یا خیر. الزامات 64 بیتی گوگل در آن دوره، arm64-v8a را اساساً در مورد هر چیزی که واجد شرایط باشد تضمین می کند.
چگونه بررسی کنیم که یک APK از چه معماری هایی پشتیبانی می کند
قبل از نصب یک فایل از خارج از فروشگاه Play، به جای حدس زدن، ارزش آن را دارد که آنچه در داخل آن وجود دارد تأیید کنید. کتابخانه‌های بومی APK در پوشه‌هایی با نام معماری آنها در فهرست lib/، مانند lib/arm64-v8a/ یا lib/armeabi-v7a/، زندگی می‌کنند. هر ابزاری که بتواند ساختار داخلی یک APK را بررسی کند، می‌تواند دقیقاً به شما بگوید کدام یک از این پوشه‌ها وجود دارد، که به شما می‌گوید دقیقاً فایل روی چه دستگاه‌هایی اجرا میشود.
قبل از نصب بررسی کنید
ابزار اطلاعات APK ما پوشه داخلی lib/ یک APK را می خواند و هر معماری را که برای آن ساخته شده است فهرست می کند، بنابراین می توانید قبل از بارگذاری جانبی، سازگاری را تأیید کنید. هنگامی که شما یک بسته تقسیم را با تبدیل XAPK به APK خود تبدیل می کنید، ما نیز پس از هر تبدیل، آن را به طور خودکار ظاهر می کنیم، معماری های موجود در فایل ادغام شده را فهرست می کنیم و زمانی که به نظر می رسد یک بیلد فاقد قطعه ای است که دستگاه های معمولی به آن نیاز دارند، آن را علامت گذاری می کنیم.
APK جهانی در مقابل APK Single-ABI: کدام را باید استفاده کنید؟
| معیار | APK جهانی / چربی | Single-ABI APK |
|---|---|---|
| اندازه فایل | بزرگتر، گاهی اوقات 2-4 برابر | کوچک، فقط شامل مواردی است که دستگاه شما نیاز دارد |
| سازگاری | تقریباً روی هر دستگاهی کار می کند | فقط روی یک معماری منطبق کار می کند |
| بهترین برای | به اشتراک گذاری یک فایل که باید در همه جا کار کند، گیرندگان مطمئن نیستند | دستگاه خودتان، زمانی که از قبل معماری آن را می دانید |
| ریسک | خطر بسیار کم عدم تطابق ABI | اگر اشتباه انتخاب کنید، شکست می خورد یا خراب می شود |
اشتباهات رایجی که افراد با بسته های تقسیم شده مرتکب می شوند
- با فرض اینکه هر تقسیم اختیاری است. تراکم و تقسیم زبان معمولا وجود دارد، اما تقسیم معماری نیست. هرگز در طول ادغام آن را نادیده نگیرید.
- گرفتن تنها یک معماری جدا از یک سایت آینه. اگر یک دانلود شخص ثالث فقط بخش armeabi-v7a را ارائه دهد، ممکن است به سادگی در دستگاهی که به arm64-v8a نیاز دارد، شکست بخورد، حتی اگر خود برنامه قانونی باشد.
- فراموش نکنید که تبلت ها و کروم بوک ها همیشه ARM نیستند. بسیاری از کرومبوکهای دارای برنامههای Android و برخی تبلتهای قدیمیتر، x86 یا x86_64 هستند تا ARM.
- آزمایش یک APK فقط ARM در یک شبیه ساز x86. برخی از ساخت‌های شبیه‌ساز قدیمیتر روی x86 اجرا می‌شوند و APK که فقط کتابخانه‌های بومی ARM را ارسال میکند، صرف‌نظر از نحوه بسته‌بندی APK، به سادگی در داخل آنها راه‌اندازی نمی‌شود.
- اشتباه گرفتن "جهانی" با "single-ABI". یک APK جهانی عمدا بزرگتر است زیرا شامل همه چیز می شود. APK تک ABI کوچک است و عمداً به یک خانواده تراشه محدود می شود.
خوراکی های کلیدی
- ABI مجموعه دستورالعملی است که یک تراشه درک می کند. فقط برای برنامه هایی که شامل کد بومی (C/C++) هستند اهمیت دارد.
- arm64-v8a تقریباً هر تلفن مدرن را پوشش می دهد. armeabi-v7a برای دستگاه های قدیمی تر است. x86/x86_64 بیشتر در شبیه سازها و کروم بوک ها نمایش داده می شود.
- برنامه ها معمولاً بر اساس معماری تقسیم می شوند تا از ارسال کدهای غیر ضروری به هر دستگاهی جلوگیری شود.
- یک معماری ناهماهنگ یا نصب را به طور کامل مسدود می کند یا باعث خرابی فوری پس از یک نصب به ظاهر موفق می شود.
- می‌توانید قبل از نصب هر چیزی، معماری دستگاه خود و معماری‌های پشتیبانی‌شده APK را بررسی کنید، و از حدس و گمان کاملاً اجتناب کنید.
سوالات متداول (FAQ)
آیا برای نصب اپلیکیشن پلی استور معمولی باید معماری گوشی خود را بدانم؟
خیر. فروشگاه Play بهطور خودکار دستگاه شما را شناسایی میکند و فقط ساختار منطبق را ارائه میدهد، بنابراین این موضوع تنها زمانی مرتبط میشود که فایلهای APK را از خارج از فروشگاه Play بارگذاری کنید.
آیا یک APK می تواند چندین معماری را همزمان پشتیبانی کند؟
بله یک APK جهانی یا چرب، کتابخانه های بومی را برای هر معماری پشتیبانی شده در یک فایل جمع می کند. این بزرگتر است اما بر روی هر دستگاه سازگار بدون در نظر گرفتن تراشه نصب می شود.
چرا APK تبدیل شده من نصب شد اما بلافاصله خراب شد؟
این معمولاً زمانی اتفاق میافتد که برنامه دارای مقدار کمی کد جاوا باشد که به خوبی نصب میشود، اما سپس سعی میکند یک کتابخانه بومی را که برای معماری دستگاه شما گنجانده نشده است بارگیری کند و در زمان اجرا یک UnsatisfiedLinkError ایجاد میکند.
آیا arm64-v8a backward با برنامه های armeabi-v7a سازگار است؟
به طور کلی بله. اکثر تراشههای arm64-v8a میتوانند دستورالعملهای ARM 32 بیتی را نیز اجرا کنند، بنابراین یک APK فقط armeabi-v7a معمولاً همچنان بر روی تلفن مدرن arm64 اجرا میشود، نه برعکس.
آیا دستگاه های Android x86 هنوز در سال 2026 در دسترس هستند؟
امروزه در گوشیها نادر هستند، اما هنوز هم x86 یا x86_64 را در برخی از تبلتهای قدیمیتر مبتنی بر اینتل، تعداد انگشت شماری از کرومبوکهای دارای برنامههای Android و اکثر شبیهسازهای Android دسکتاپ میبینید.
شما نیازی به حفظ هیچ یک از این موارد ندارید. نسخه کوتاه: تلفن‌های مدرن تقریباً همیشه arm64-v8a هستند، برنامه‌ها برای صرفه‌جویی در فضا بر اساس معماری تقسیم می‌شوند، و اگر چیزی از نصب امتناع کرد یا بلافاصله پس از باز کردن خراب شد، عدم تطابق معماری یکی از اولین مواردی است که قبل از اینکه فرض کنیم خود فایل شکسته شده است، ارزش حذف را دارد.