بيونيك (برنامج)

بايونيك هي تطبيق لمكتبة لغة C القياسية ، طورتها جوجل لنظام التشغيل أندرويد . وهي تختلف عن مكتبة GNU C (glibc) في كونها مصممة للأجهزة ذات الذاكرة وقدرة المعالجة الأقل من نظام لينكس النموذجي . وهي مزيج من شفرة برمجية جديدة وشفرة من أنظمة FreeBSD و NetBSD و OpenBSD ، مُرخصة بموجب رخصة BSD ، على عكس glibc التي تستخدم رخصة GNU العامة الصغرى . كان هذا الاختلاف مهمًا في بدايات أندرويد، عندما كان الربط الثابت شائعًا، ولأن بايونيك لها واجهة ثنائية خاصة بها ، فلا يمكن استبدالها بمكتبة libc أخرى دون تعطيل جميع التطبيقات الموجودة.

Bionic هي مكتبة C تُستخدم مع نواة لينكس ، وتوفر مكتبات libc و libdl و libm ( وظائف libpthread جزء من libc ، وليست مكتبة منفصلة كما هو الحال في بعض الأنظمة الأخرى). وهذا يختلف عن مكتبات BSD C التي تتشارك Bionic معها في الشيفرة، لأنها تتطلب نواة BSD .

كانت الأهداف المعلنة علنًا لمشروع بايونيك كما يلي: ^{[ 1 ] [ 2 ]}

• مرخصة بموجب ترخيص BSD : أرادت جوجل عزل تطبيقات أندرويد عن تأثير تراخيص حقوق النشر لإنشاء مساحة مستخدم خاصة ونظام بيئي للتطبيقات، ^{[ 3 ]} ولكن:
  • يعتمد نظام أندرويد على نواة لينكس، والتي تخضع لرخصة جنو العمومية العامة (GPL) الإصدار 2.
  • مكتبة GNU C (glibc) هي المكتبة القياسية الأكثر انتشارًا للغة C في نواة لينكس، وهي تخضع لرخصة GNU العامة الصغرى (LGPL)، وهي أيضًا رخصة حقوق نسخ مفتوحة. على عكس رخصة GPL، تسمح رخصة LGPL صراحةً بالربط الديناميكي، لكنها لا تسمح بالربط الثابت للبرامج الاحتكارية دون توفير شفرة المصدر أو ملفات الكائنات القابلة للربط.
  • رخصة BSD المتساهلة هي رخصة غير خاضعة لقانون حقوق النشر ، وهي متوافقة في كلا الاتجاهين. يمكن لبديل مكتبة glibc المرخص بموجب رخصة BSD أن يعمل كطبقة عازلة بين النواة (kernel) الخاضعة لقانون حقوق النشر والتطبيقات غير الخاضعة له، ولذلك اختارته جوجل لنظامها Bionic كبديل لمكتبة glibc. ^{[ 4 ]}
• الحجم الصغير: كان بايونيك أصغر بكثير من مكتبة GNU C؛ والأهم من ذلك أن متطلبات الذاكرة الخاصة به كانت (ولا تزال) أقل بكثير.
• السرعة: تم تصميم معالج Bionic لوحدات المعالجة المركزية ذات ترددات الساعة المنخفضة نسبيًا.

يدعم نظام Bionic نواة لينكس فقط، ولكنه يدعم حاليًا معمارية arm و arm64 و riscv64 و x86 و x86-64 . كانت المنصة تتطلب معمارية armv7 مع معالج Neon منذ إصدار Marshmallow ، ^{[ 5 ]} على الرغم من أن حزمة تطوير Android الأصلية (NDK) استمرت في دعم معمارية armv5 (التي كانت تُسمى armeabi) حتى الإصدار NDK r16. لا تزال NDK تدعم معمارية armv7، إلا أن الإصدار NDK r24 أسقط دعم معمارية غير Neon. تاريخيًا، كان هناك دعم جزئي لمعمارية SH-4 في المنصة، ولكن لم يتم شحن أي أجهزة منها، وتم إزالة هذا الدعم لاحقًا. لم تدعم NDK معمارية SH-4 أبدًا، وتمت إزالة دعم معماريتي MIPS و MIPS64 من NDK في الإصدار r17.

بعض أجزاء مصدر libc، مثل stdio ، مأخوذة من أنظمة BSD (وخاصة OpenBSD )، بينما تمت كتابة أجزاء أخرى، مثل تطبيق pthread ، من الصفر.

تطورت آلية تخصيص الذاكرة الديناميكية بمرور الوقت. قبل إصدار لولي بوب، كان هناك مُخصِّص ذاكرة أصلي واحد، وهو dlmalloc من تطوير دوغ ليا . أما في إصداري لولي بوب ومارشملو، فكان هناك تطبيقان: dlmalloc و jemalloc . يُوفر jemalloc أداءً أعلى بكثير من dlmalloc، ولكنه يتطلب ذاكرة إضافية لإدارة العمليات. استخدمت معظم الأجهزة jemalloc، بينما استمرت الأجهزة ذات الذاكرة المنخفضة في استخدام dlmalloc. من إصدار نوجا وحتى أندرويد 10 ، تستخدم جميع الأجهزة jemalloc. تستخدم الأجهزة ذات الذاكرة المنخفضة إعدادًا مُبسَّطًا لـ jemalloc يُعطِّل ذاكرة التخزين المؤقت tcache ليُقارب استهلاك الذاكرة الأقل لـ dlmalloc مع الحفاظ على معظم سرعة jemalloc. في أندرويد 11 ، تم تغيير مُخصِّص الذاكرة لمعظم الأجهزة إلىيُضحي Scudo ببعض الأداء العالي لـ jemalloc مقابل ميزات إضافية لتعزيز الأمان. ^{[ 6 ]} ومع ذلك، لا يزال يُسمح للأجهزة ذات الذاكرة المنخفضة باستخدام jemalloc. ^{[ 7 ]}

تُعتبر بعض الأجهزة ذات معالجات 64 بت ، مثل جهاز Nexus  9 ، أجهزة ذات ذاكرة منخفضة فعليًا نظرًا لمتطلبات المساحة الإضافية اللازمة لمؤشرات 64 بت واستضافة وحدتي Zygote. ( وحدة Zygote هي خدمة نظام أندرويد تُعتبر الأصل لجميع عمليات تطبيقات أندرويد. ^{[ 8 ]} )

مصدر مكتبة libm هو في الغالب مصدر FreeBSD ، ولكن مع مُجمِّع مُحسَّن ساهم به مختلف موردي SoC .

تمت كتابة الرابط الديناميكي (و libdl) من الصفر.

لا يتضمن نظام التشغيل بايونيك مكتبة libthread_db (المستخدمة من قِبل gdbserver )، بينما كان يتضمنها NDK. تضمنت منصة أندرويد مكتبة gdbserver مرتبطة بشكل ثابت، مما يسمح للمطورين باستخدام أحدث إصدار من gdb حتى على الأجهزة القديمة. وبما أن أندرويد قد تخلت عن دعم gdb واستبدلته بـ lldb، فإن هذا لم يعد ذا صلة.

لا توجد مكتبات libpthread أو libresolv أو librt منفصلة على نظام أندرويد ، فجميع وظائفها موجودة في مكتبة libc. بالنسبة لمكتبة libpthread، لا توجد محاولة لتحسين الأداء في حالة المعالجة أحادية الخيوط، لأن التطبيقات تعمل في بيئة متعددة الخيوط حتى قبل تنفيذ أول تعليمة من تعليمات برمجية خارجية. 

تستخدم منصة أندرويد مكتبة libc++ القياسية للغة C++ (استخدمت الإصدارات حتى لولي بوب مكتبة stlport). وقد وفرت حزمة تطوير البرامج الأصلية (NDK) سابقًا مكتبتي stlport وGNU libstdc++، ولكن تم حذفهما بدءًا من الإصدار 18 من NDK. ^{[ 9 ]} تجدر الإشارة إلى أنه إذا كان أي كود أصلي في تطبيق أندرويد يستخدم لغة C++، فيجب أن تستخدم جميع أكواد C++ نفس مكتبة STL . لا يوفر نظام تشغيل أندرويد مكتبة STL، ويجب تضمينها مع كل تطبيق.

على الرغم من أن نظام بايونيك يهدف إلى تطبيق جميع وظائف C11 و POSIX ، إلا أنه لا يزال هناك (حتى إصدار أندرويد 15) حوالي 11 وظيفة من وظائف POSIX مفقودة من مكتبة libc ^{[ 10 ]} . كما توجد وظائف POSIX أخرى، مثل عائلة endpwent/getpwent/setpwent، غير قابلة للتطبيق على نظام أندرويد لافتقاره إلى قاعدة بيانات passwd . أما مكتبة libm، فقد اكتملت مع إصدار أوريو .

بعض الدوال لا تتوافق عمداً مع معايير POSIX أو C لأسباب أمنية، مثل دالة printf التي لا تدعم %nسلسلة التنسيق. ^{[ 11 ]}

تم تنفيذ العديد من ملحقات GNU الأكثر استخدامًا في Bionic، وكذلك العديد من ملحقات BSD.

يستخدم كود النظام الأساسي Bionic مباشرةً، بينما يستخدم مطورو الطرف الثالث حزمة تطوير البرامج الأصلية لنظام Android (NDK). ولا يزال العديد من مطوري الطرف الثالث يستهدفون إصدارات نظام التشغيل القديمة، مما يُسهم في الاعتقاد السائد بأن Bionic يفتقر إلى العديد من الميزات. وقد صدّر نظام Gingerbread 803 وظائف من مكتبة libc، بينما صدّر نظام Oreo 1278 وظيفة (بزيادة قدرها 1.6 ضعف). ^{[ 10 ]}

تاريخياً، اختلف كل من NDK والمنصة، لكن NDK r11 والإصدارات اللاحقة استبدلت نسخ NDK المتفرعة بنظائرها الحالية على المنصة. ركز هذا العمل في البداية على مُجمّعي GCC و Clang .

قبل إصدار NDK r14، عندما تم توفير ملفات الرأس "الموحدة" لأول مرة بشكل اختياري، كان لدى NDK نسخ متفرعة من ملفات رأس النظام الأساسي لمستويات واجهة برمجة التطبيقات المختلفة. هذا يعني أن إصلاحات ملفات الرأس فقط (إصلاحات تعريفات الثوابت أو البنى، على سبيل المثال) لم تكن متاحة لمعظم مستخدمي NDK لأنهم كانوا يستهدفون مستوى واجهة برمجة تطبيقات أقدم، بينما كانت إصلاحات النظام الأساسي تُضاف فقط إلى ملفات رأس النظام الأساسي الحالية. خلال فترة تطوير أوريو، تم تزويد ملفات رأس النظام الأساسي بمعلومات مستوى واجهة برمجة التطبيقات بحيث يمكن استخدام نفس مجموعة ملفات الرأس لجميع مستويات واجهة برمجة التطبيقات، مع ظهور الوظائف المتاحة فقط في مستوى واجهة برمجة التطبيقات الذي يستهدفه المطور. هذه هي ما يُسمى بملفات الرأس "الموحدة"، وهي الوضع الافتراضي منذ إصدار NDK r15.

قبل الإصدار NDK r16، كان NDK يربط مكتبةً تُسمى libandroid_support.a بشفرةٍ تستخدم libc++ لتوفير وظائف مطلوبة من libc++ لم تكن موجودة في إصدارات نظام التشغيل القديمة. لم تكن هذه الشفرة هي نفسها المستخدمة من قِبل النظام الأساسي، وقد تسببت في العديد من الأخطاء (مثل تعطيل الوسائط الموضعية لعائلة printf في أي شفرة تستخدم libc++). من NDK r16 إلى r25، ظلت libandroid_support.a موجودة، ولكن تم بناؤها مباشرةً من مصدر النظام الأساسي المُستخدم آنذاك عند بناء كل إصدار من NDK. بدءًا من NDK r26، اختفت libandroid_support.a، لأن جميع إصدارات نظام التشغيل التي لا يزال NDK يدعمها تحتوي على كل ما تحتاجه libc++.

ابتداءً من إصدار Android Jelly Bean MR1 (4.2)، يدعم Bionic وظائف مشابهة لوظائف مكتبة glibc _FORTIFY_SOURCE، ^{[ 12 ]} وهي ميزة تتضمن فيها دوال السلاسل النصية والذاكرة غير الآمنة (مثل strcpy()` string` و`function` strcat()و` function` memcpy()) عمليات فحص لتجاوزات المخزن المؤقت. تُجرى هذه الفحوصات أثناء الترجمة إذا أمكن تحديد أحجام المخزن المؤقت في وقت الترجمة، أو أثناء التشغيل في غير ذلك. ولأن fortify يعتمد على دعم وقت التشغيل من libc، فإن قابليته للتوافق مع إصدارات Android الأقدم محدودة. ^{[ 13 ]} تم بناء النظام الأساسي نفسه مع _FORTIFY_SOURCEتمكين هذه الميزة.

تاريخيًا، تمثلت إحدى عيوب مكتبة fortify في ارتباطها الوثيق بمترجم GCC، مما صعّب دعمها بشكل جيد في مترجمات أخرى، مثل Clang. ونتيجةً لذلك، عندما اعتمد نظام Android مترجم Clang افتراضيًا، ^{[ 14 ]} أصبحت آلية عمل fortify في Bionic أقل فائدة بشكل ملحوظ. في Android Oreo (8.0)، أُعيد تصميم fortify في Bionic ^{[ 15 ]} مع مراعاة Clang، مما أدى إلى توفير تجربة استخدام مماثلة لتجربة fortify على GCC. منذ هذا التحديث، أُضيفت بعض عمليات التحقق الإضافية، تتجاوز تلك الموجودة في مكتبة glibc، لاكتشاف التعليمات البرمجية التي - وإن لم تكن بالضرورة تُسبب سلوكًا غير مُعرّف - إلا أنها غير صحيحة بشكل واضح. ولأن هذا التطبيق الجديد لا يتطلب دعمًا إضافيًا لمكتبة libc مقارنةً بالتطبيق السابق، فإن التحسينات الخاصة بـ Clang متاحة للتطبيقات التي تستهدف إصدارات Android الأقدم من Oreo.

استخدمت جوجل ملفات رأسية لنواة لينكس مرخصة بموجب رخصة جنو العمومية الإصدار الثاني (GPLv2) لإنشاء نظام التشغيل بايونيك . وللتخلص من هذه الرخصة، زعمت جوجل أنها حذفت من الملفات الرأسية أي محتوى قابل لحقوق النشر، محولةً إياها إلى "حقائق" غير قابلة لحقوق النشر. ^{[ 16 ] [ 17 ]} اعتبر لينوس تورفالدز، مبتكر لينكس، سلوك جوجل مقبولاً، ^{[ 17 ]} إلا أن تفسير جوجل لرخصة جنو العمومية قد طُعن فيه، على سبيل المثال من قبل ريموند نيمر، أستاذ القانون في مركز القانون بجامعة هيوستن . ^{[ 18 ]}

• Hybris (المعروف أيضًا باسم libhybris )
• مسلم
• صندوق الألعاب

• مؤتمر جوجل I/O 2008 - تشريح ووظائف جسم الإنسان الآلي (أندرويد) على يوتيوب
• الصفحة الرئيسية للمطورين لنظام Android
• الصفحة الرئيسية لمجموعة أدوات تطوير تطبيقات أندرويد الأصلية (NDK)
• المصادر البيولوجية (المستودع الرسمي)
• ملاحظات بيونيك على موقع eLinux.org