فهم بنية وحدة المعالجة المركزية لنظام Android (ABI): لماذا أهمية Arm64-v8a وarmeabi-v7a وx86

إذا سبق لك أن قمت بدمج مجموعة من ملفات APK المقسمة وشاهدت هاتفك يتراجع "التطبيق غير مثبت"، أو ما هو أسوأ من ذلك، شاهدته يتم تثبيته بشكل جيد فقط ليتعطل في اللحظة التي قمت فيها بالنقر على الرمز، فهناك احتمال كبير أن المشكلة الحقيقية لا علاقة لها بالتنزيل التالف. كان من المؤكد تقريبًا أن الأمر يتعلق بالهندسة المعمارية: عدم التطابق بين وحدة المعالجة المركزية التي يعمل عليها هاتفك ووحدة المعالجة المركزية التي تم تجميع الكود الأصلي للتطبيق من أجلها. لا يتعين على معظم مستخدمي Android أبدًا التفكير في هذا الأمر، حتى اللحظة التي يكسر فيها شيئًا ما بهدوء، وبعد ذلك يصبح الأمر ذا صلة بسرعة. إليك ما تعنيه بنية وحدة المعالجة المركزية لملف APK، ولماذا يتم شحن تطبيق واحد على متجر Play سرًا كإصدارات مختلفة متعددة، وكيفية التحقق من التوافق قبل تثبيت أي شيء.

ما هو ABI

ABI لتقف علي واجهة التطبيق الثنائية. من الناحية العملية، إنها مجموعة التعليمات التي تفهمها الشريحة - تنسيق كود الجهاز الخام الذي يمكن للمعالج تنفيذه مباشرة. يتم تجميع معظم تطبيقات Android، والأجزاء المكتوبة بلغة Java أو Kotlin، في كود ثانوي يتم تشغيله داخل Android Runtime (ART)، ولا يهتم ART بشكل خاص بالشريحة التي يتواجد عليها. هذه الطبقة لا تعتمد على الهندسة المعمارية من حيث التصميم، وهو جزء كبير من سبب "عمل تطبيقات Android" بشكل عام عبر مجموعة واسعة من الأجهزة.

الكود الأصلي قصة مختلفة. تقوم الكثير من التطبيقات، وخاصة الألعاب وتطبيقات الكاميرا وأدوات التعلم الآلي وأي شيء يقوم بمعالجة الصوت أو الفيديو بكثافة، بشحن المكتبات الأصلية المكتوبة بلغة C أو C++ من خلال Android NDK. يتم تجميع هذه المكتبات مسبقًا في كود الآلة لمجموعة تعليمات محددة، ولا يمكن للرقاقة المصممة لمجموعة تعليمات واحدة بشكل عام تنفيذ كود الآلة المكتوب لمجموعة مختلفة. هذا هو السبب الكامل وراء وجود واجهات برمجة التطبيقات (ABIs) كشيء يستحق الفهم: في اللحظة التي يتضمن فيها التطبيق مكتبة .so أصلية واحدة، يصبح توافقه مرتبطًا بالبنيات التي تم إنشاء المكتبة من أجلها.

البنى التي ستواجهها

كان هناك تنوع أكبر في هذا المجال (تذكر armeabi أو MIPS؟)، ولكن بحلول عام 2026، تقلص المجال إلى أربع واجهات ABI تستحق المعرفة:

إذا كنت تحمل هاتفًا اشتريته في أي وقت خلال السنوات الخمس أو الست الماضية، فمن المؤكد تقريبًا أنه Arm64-v8a. الاستثناءات التي تستحق التذكر هي المحاكيات وأجهزة Chromebook، والتي تعمل بشكل متكرر على x86_64 بدلاً من ذلك، نظرًا لأن ذلك يتطابق مع وحدة المعالجة المركزية للكمبيوتر المحمول أو سطح المكتب الأساسي.

لماذا تهتم التطبيقات بشحن إصدارات متعددة على الإطلاق

أحد الأسئلة الواضحة هو لماذا لا يقوم المطورون بحشر المكتبات الأصلية لكل بنية في ملف APK واحد والانتهاء منها. تقوم بعض التطبيقات بذلك بالضبط، ويطلق عليها APK العالمي أو "الدهون". الجانب السلبي هو الحجم. يمكن للعبة التي تحتوي على مكتبات أصلية لـarm64-v8a وarmeabi-v7a وx86 وx86_64 المجمعة معًا أن تتضاعف بسهولة أو تضاعف حجمها ثلاث مرات مقارنة بالإصدار الذي يحتوي فقط على البنية الوحيدة التي يحتاجها جهازك. قم بضرب ذلك عبر الملايين من عمليات التثبيت، وستجد قدرًا كبيرًا حقًا من النطاق الترددي والتخزين الضائعين، للتعليمات البرمجية التي لن تعمل أبدًا على هذا الجهاز.

لتجنب هذا الهدر، قام Google Play وتنسيق Android App Bundle بتقسيم التطبيق إلى ملف APK أساسي صغير بالإضافة إلى سلسلة من ملفات APK للتكوين، أحدها مخصص للهندسة المعمارية. عندما يطلب هاتفك التطبيق، يقدم Play Store ملف APK الأساسي مع تقسيم البنية الذي يطابق الشريحة الخاصة بك فقط، إلى جانب كثافة الشاشة وتقسيمات اللغة المتطابقة. ينتهي بك الأمر إلى تثبيت يعمل كتطبيق واحد، ولكن يتم تجميعه من عدة أجزاء مخصصة لهذا الغرض خلف الكواليس.

كيف تستخدم ملفات APK وحزم التطبيقات المنقسمة هذا

إذا سبق لك أن فتحت حزمة .apks أو .xapk ولاحظت وجود أسماء ملفات مثل split_config.arm64_v8a.apk وsplit_config.armeabi_v7a.apk وsplit_config.xxhdpi.apk وsplit_config.en.apk بجوار base.apk، فهذا هو بالضبط هذا النظام قيد التنفيذ، حيث تم تصديره كمجموعة من الملفات بدلاً من تسليمها بصمت بواسطة متجر Play. عادةً ما تكون تقسيمات الكثافة واللغة آمنة للتثبيت بشكل عشوائي نظرًا لأن الهاتف سيتجاهل ببساطة الموارد التي لا يحتاج إليها. يختلف تقسيم البنية: قم بتثبيت الإصدار الخاطئ، أو تفشل في تثبيت الإصدار المطابق، وستواجه مشكلة حقيقية.

عندما تستخدم محولًا لدمج حزمة مقسمة مرة أخرى في ملف APK واحد قابل للتثبيت، يجب أن تختار عملية الدمج تقسيمات البنية المراد طيها. يحتفظ المحول الجيد بكل تقسيم معماري مفيد حقًا، أو يتيح لك الاختيار، بدلاً من الاحتفاظ بواحدة فقط في صمت على أمل أن تتطابق مع جهازك.

ماذا يحدث عندما لا تتطابق الهندسة المعمارية

هناك وضعان مختلفان للفشل يستحقان التعرف عليهما، لأنهما يبدوان مختلفين عن المستخدم العادي.

الأول هو فشل التثبيت التام. إذا تم إنشاء التطبيق بشكل كامل تقريبًا حول تعليمات برمجية أصلية دون أي تراجع ذي معنى، فسيرفض مدير حزم Android تثبيته على الإطلاق، وعادةً ما يظهر خطأ مثل INSTALL_FAILED_NO_MATCHING_ABIS. لن تتمكن أبدًا من فتح التطبيق؛ يوقفك المثبت عند الباب.

أما النتيجة الثانية الأكثر إحباطا فهي النجاح الجزئي الصامت. إذا كان التطبيق يحتوي على نقطة إدخال Java أو Kotlin يتم تحميلها بشكل جيد من تلقاء نفسه، ولكنه يحاول بعد ذلك الاتصال بمكتبة أصلية غير موجودة في بنيتك، فسيكتمل التثبيت بشكل طبيعي. يبدو كل شيء على ما يرام حتى تنقر على الأيقونة، وعند هذه النقطة يتعطل التطبيق على الفور تقريبًا، غالبًا مع وجود UnsatisfiedLinkError مدفونًا في السجلات. هذه هي القصة الكلاسيكية "لقد قمت بتحويله، وتم تثبيته، ثم يتم إغلاقه على الفور"، وهي دائمًا مشكلة في الهندسة المعمارية وليست ملفًا تالفًا.

كيفية التحقق من بنية هاتفك الخاص

بالنسبة للغالبية العظمى من الأشخاص، يعد هذا أمرًا بسيطًا: إذا كان هاتفك من عام 2019 أو أحدث، فافترض أن Arm64-v8a وانتقل إلى الأمام. إذا كنت تريد التأكد، أو كنت تتعامل مع جهاز قديم أو غير عادي، فهناك بعض الخيارات العملية:

• ابحث عن طراز مجموعة الشرائح الدقيقة لهاتفك (المرئي على العلبة أو في الدليل أو على موقع مثل GSMArena) وابحث عما إذا كانت مجموعة الشرائح هذه هي 32 بت أو 64 بت ARM.
• قم بتثبيت تطبيق معلومات النظام خفيف الوزن الذي يقوم بالإبلاغ عن بنية وحدة المعالجة المركزية مباشرةً، ويوجد العديد منها مجانًا خصيصًا لهذا الغرض.
• التحقق مما إذا كان الهاتف مشحونًا بنظام التشغيل Android 9 أو إصدار أحدث كإصدار نظام التشغيل الأصلي الخاص به؛ إن متطلبات Google 64 بت في تلك الحقبة تجعل من الذراع 64-v8a مضمونًا بشكل أساسي لأي شيء مؤهل.

كيفية التحقق من البنيات التي يدعمها APK

قبل تثبيت ملف من خارج متجر Play، من المفيد التأكد مما بداخله بدلاً من التخمين. توجد مكتبات APK الأصلية في مجلدات تحمل اسم بنيتها داخل دليل lib/، مثل lib/arm64-v8a/ أو lib/armeabi-v7a/. يمكن لأي أداة يمكنها فحص البنية الداخلية لـ APK أن تخبرك بالضبط عن أي من هذه المجلدات موجودة، مما يخبرك بالضبط عن الأجهزة التي سيتم تشغيل الملف عليها.

Universal APK مقابل Single-ABI APK: ما الذي يجب أن تستخدمه؟

الأخطاء الشائعة التي يرتكبها الأشخاص مع الحزم المقسمة

• على افتراض أن كل تقسيم هو اختياري. عادةً ما تكون انقسامات الكثافة واللغة كذلك، لكن تقسيم البنية ليس كذلك؛ لا تتخطاها أبدًا أثناء الدمج.
• الاستيلاء على بنية واحدة فقط منقسمة من موقع مرآة. إذا كان التنزيل من جهة خارجية يقدم فقط، على سبيل المثال، شريحة Armeabi-v7a، فقد يفشل ببساطة على جهاز يحتاج إلى Arm64-v8a بدلاً من ذلك، على الرغم من أن التطبيق نفسه شرعي.
• ننسى أن الأجهزة اللوحية وأجهزة Chromebook ليست دائمًا تعمل بنظام ARM. تعمل الكثير من أجهزة Chromebook التي تعمل بتطبيقات Android، وبعض الأجهزة اللوحية القديمة، على إصدار x86 أو x86_64 بدلاً من ARM.
• اختبار APK الخاص بـ ARM فقط داخل محاكي x86. تعمل بعض إصدارات المحاكي القديمة على الإصدار x86، ولن يتم تشغيل ملف APK الذي يشحن مكتبات ARM الأصلية فقط بداخلها، بغض النظر عن كيفية تعبئة ملف APK.
• الخلط بين "عالمي" و"ABI فردي". ملف APK العالمي أكبر حجمًا عن عمد لأنه يتضمن كل شيء؛ يعد ملف APK لـ ABI واحدًا صغيرًا ويقتصر عمدًا على عائلة شرائح واحدة.

الأسئلة الشائعة (FAQ)

لا تحتاج إلى حفظ أي من هذا. النسخة المختصرة: الهواتف الحديثة تكون دائمًا تقريبًا Arm64-v8a، ويتم تقسيم التطبيقات حسب البنية لتوفير المساحة، وإذا رفض شيء ما التثبيت أو تعطل مباشرة بعد الفتح، فإن عدم تطابق البنية هو أحد الأشياء الأولى التي تستحق الاستبعاد قبل افتراض أن الملف نفسه معطل.