حفظ أوقات مزامنة IDE في الخليج منظور تاريخي
قبل عشر سنوات في مؤتمر Google I / O 2013، كشف المدير الهندسي Tor Norbye عن Android Studio، وهو بيئة تطوير متكاملة حديثة (IDE) لبناء واختبار وشحن التطبيقات. من خلال إظهار قدرات هذه الأداة الجديدة، أظهر Tor كيف أنها ستجعل المطورين أكثر إنتاجية وكفاءة. يعتمد Android Studio على منصة IntelliJ الشهيرة من JetBrains ، والتي سمحت لشركة Google بإطلاق محرر كامل الميزات من بوابة البداية.
كان أحد القرارات الرئيسية كجزء من الإصدار 1.0 هو التكامل مع أداة أتمتة بناء Gradle، وهو مشروع مفتوح المصدر تم إصداره في البداية بواسطة Hans Dockter و Adam Murdoch في عام 2008. كان الهدف من هذا التكامل هو توفير طريقة للبناء ليس فقط من سطر الأوامر ولكن أيضًا في بيئات التكامل المستمر (CI) وداخل IDE. لكي يعمل هذا، يحتاج نظام إنشاء Gradle وIDE إلى تقديم تجربة متسقة، لذا فإن أي تغييرات في Gradle ستنعكس بشكل صحيح في Android Studio. لإنجاز هذا العمل الفذ، تضمن عملية المزامنة، المعروفة أيضًا باسم “المزامنة”، أن نظام البناء وIDE يعملان في وئام.
بالنسبة لقاعدة الشفرات الكبيرة لـ Square ، حيث زاد عدد مشاريع Gradle الفرعية من 1800 إلى 4400 على مدار العامين الماضيين، ظهرت أوقات مزامنة IDE كواحدة من أهم الشكاوى من مطوري Android لدينا. كانت عملية المزامنة هذه ووقت الفهرسة اللاحق، والذي سيستغرق ما يصل إلى 20-25 دقيقة، ضروريين لـ IDE للتنقل بطريقة سحرية عبر قاعدة التعليمات البرمجية، أو تقديم اقتراحات الإكمال التلقائي، أو ببساطة عرض تلميحات أو اقتراحات سياق ذات مغزى. بدونها، لا يمكن استخدام أي من هذه الميزات المهمة في Android Studio.
كان أحد التحديات هو محاولة عزل المشكلة. هل كان مرتبطًا بحقيقة أن Android Studio غالبًا ما تأخر عن إصدارات IntelliJ لمدة عام على الأقل، وربما تم إصلاح المشكلة بالفعل؟ هل كانت مرتبطة بأحد ملحقات IntellIJ المختلفة؟ أم أن المشكلة تعيش في نظام بناء Gradle؟ كان تحديد مكان وجود هذه الأنواع من المشكلات أحد أكبر التحديات، على غرار مهندسي موثوقية الموقع الذين يحاولون التأكد من عنق الزجاجة من خلال مراقبة التفاعلات بين الأنظمة المختلفة.
نظرًا لأن تراجع الأداء في جزء واحد من النظام أحدث تقلبات كبيرة في تجربة IDE، فقد حاولنا فهم هذه المشكلات بشكل أفضل. على سبيل المثال، اكتشف مهندس سكوير ستيفان نيكولا عدم الكفاءة في المكون الإضافي IntelliJ Kotlin، حلل تبعياته مما أدى إلى تقليل وقت المزامنة بمقدار 3 دقائق لـ Android Studio v4.1. في محاولة لتشخيص سبب تحول التجميد إلى مشكلة شائعة، اكتشف بابلو باكستر كيف يمكننا إرفاق نقاط التوقف بعملية تشغيل Android Studio مقابل أحدث كود مصدر لمكوِّن Android IntelliJ الإضافي من Google. عندما بدأنا نفهم أن أوقات المزامنة قد تأثرت سلبًا بإستراتيجيتنا المعيارية، مدفوعة بشكل أساسي بنمو مشروع Gradle الفرعي في قاعدة الأكواد الكبيرة الخاصة بنا، سارع توني Robalik في اجتياز الرسم البياني للبناء بنسبة 400٪ بناءً على التطبيق الذي تم إنشاؤه في monorepo الخاص بنا.
لقد جربنا أيضًا مناهج أخرى لم تنجح تمامًا. على سبيل المثال، عند تجربة IDEs السحابية، وجدنا أن وقت المزامنة لم يتحسن بغض النظر عن مقدار وحدة المعالجة المركزية والذاكرة التي قدمناها لـ Android Studio. استندت غزتنا في استخدام Bazel ، وهو إصدار مفتوح المصدر من نظام البناء الداخلي لـ Google، جزئيًا على افتراض أن تجربة IDE ستكون أفضل، خاصة وأن المكوّن الإضافي Bazel IntelliJ عرض خيار مزامنة جزئي. في نهاية المطاف، أصبحت مشكلات Android Studio ذات أولوية أعلى، وكشفت محاولات تحويلنا إلى Bazel عن الكثير من الديون التقنية في منطق البناء الذي دفعنا للعمل على رعي الأفيال وختمها، في إشارة إلى شعار شركة Gradle.
بشكل أساسي، كانت مشكلة مزامنة IDE بحاجة إلى حل مع ميزة الاستيراد الموازي، والتي هبطت في إصدار Android Studio Electric Eel في يناير. استغرق حدوث ذلك عامين بسبب التغييرات المختلفة التي يجب إجراؤها واختبارها على نطاق واسع. أولاً، كانت هناك حاجة إلى تطوير نماذج بيانات جديدة بواسطة Google ، والتي بدأت في الظهور في Android Studio v4.2. ثانيًا، احتاج Gradle إلى إضافة دعم للتوازي في Tooling API الخاصة بهم، والتي توفر طبقة تجريد للإصدارات المتطورة. أخيرًا، كانت البيانات من Gradle بحاجة إلى أن تُترجم إلى نماذج IntelliJ بالتوازي، وبشكل أساسي المشاريع، والأوجه، ومعلومات المكتبة لاستخدامها في IDE.
لا يزال هناك مجال للتحسين، لا سيما أجزاء من النماذج أثناء المزامنة التي لا تزال متبادلة بالتتابع. بدأت JetBrains و Google و Gradle أيضًا في الاستفادة من التمثيل المعقم لهيكل مشروعنا الذي تم إنشاؤه بواسطة أداة النسخ المتماثل مفتوحة المصدر من Google ، والتي نأمل أن تتيح التكرارات الأسرع للتحقق من التحسينات. بالإضافة إلى ذلك، يواصل Gradle التركيز على Project Isolation، والذي من شأنه أن يساعد بشكل أكبر في تسريع أداء مزامنة IDE.
بغض النظر، كانت ميزة الاستيراد الموازي بمثابة تغيير لقواعد اللعبة بالنسبة لنا. وقد أدى إلى تحسين السرعة بنسبة 60٪ وتوفير ما يقدر بنحو 1600 ساعة للمطورين سنويًا. بينما لا يزال هناك مجال للتحسين، كانت الميزة الجديدة بالفعل تناقضًا صارخًا في تجربة IDE لـ Android Studio. لخص غرانت بارك، مطور Android الذي عانى مع العديد من هذه المشكلات، الأمر بشكل أفضل: “لا أصدق عيني … يبدو أن كل مشكلة قد اختفت بطريقة سحرية. إذا استمر هذا الأمر، أعتقد أن حياتي هنا كمطور قد تحسن 100 مرة. “
ما زلت أتذكر عندما تم إصدار الإصدار 0.2 من Android Studio لأول مرة قبل عشر سنوات. في إصدار المعاينة المبكر هذا، لم تتم إضافة التكامل بين Gradle و Android Studio بعد، لذا فإن إضافة تبعية إلى Gradle لا تزال تتطلب إجراء تغييرات من خلال واجهة مستخدم IDE. لم تعد هناك حاجة إلى هذه الخطوة الإضافية، وقد وصلنا إلى دائرة كاملة في جعل عملية المزامنة أسرع وأكثر أداءً للقواعد البرمجية الكبيرة مثل قواعدنا. شكرًا لشركائنا في الصناعة على دعمهم في تحسين Android Studio خلال العقد الماضي!
المصدر: developer
قد يهمك:
