قد تكون على دراية بـ Flutter، وهي مجموعة تطوير برامج مفتوحة المصدر لواجهة المستخدم من Google، وهي مفيدة لتطوير تطبيقات الهاتف المحمول عبر الأنظمة الأساسية من قاعدة تعليمات برمجية واحدة لأي متصفح ويب. تم إصداره في مايو 2017، ونحن نستخدمه لتطوير العديد من الشاشات في تطبيق الهاتف المحمول الخاص بنا. على الرغم من أن هذا الحل كان يعمل بشكل جيد في ذلك الوقت، إلا أن مستخدمي اليوم يتوقعون المزيد – المزيد من إمكانية الوصول، والمزيد من الأداء، والمزيد من الميزات، والمزيد من الرسوم المتحركة، والمزيد من الابتكار.
ولتحقيق هذه الغاية، قررنا منذ عامين تقريبًا الاستثمار بكثافة في نهج الهاتف المحمول أولاً لزيادة نمو تطبيق الهاتف المحمول الخاص بنا واعتماده. عندما بدأنا البحث وحددنا المشكلة التي يجب حلها، سألنا أنفسنا: ما هي التقنية المناسبة التي ستساعدنا على تحقيق رؤيتنا بأن نكون الهاتف المحمول أولاً مع توفير تجربة محلية عالية الأداء؟ كيف نضمن أن الحل يمكن أن يتطور مع تغير النظام البيئي لنظام التشغيل وتمييز عروضنا عن المنتجات الأخرى المتاحة؟
لقد وزننا الإيجابيات والسلبيات …
تُعد Flutter تقنية ممتازة لبناء حلول أصلية متعددة المنصات وفعالة من حيث التكلفة:
- يمكن أن يكون لديك قاعدة تعليمات برمجية واحدة تعمل على كلا النظامين الأساسيين، مما يوفر الوقت والموارد.
- ونظرًا لأنه يستخدم نفس واجهة المستخدم ومنطق الأعمال على كلا النظامين الأساسيين، فإنه يساعد في الحفاظ على الاتساق في النظام البيئي.
- نظرًا لأنه مفتوح المصدر، فإنه متاح لمجموعة واسعة من المطورين والشركات لمواصلة تحسينه.
ومع ذلك، فإن دعم كل من Flutter والإصدارات الأصلية في تطبيقات iOS وAndroid كان يؤثر على التطوير ودعم الإنتاج والجودة وحالة قاعدة التعليمات البرمجية:
- تعمل الاستفادة من Flutter بشكل أفضل عندما يكون التطبيق مبنيًا على Flutter فقط. في حالتنا، نظرًا لأنه كان علينا إدارة Flutter وNative في نفس قاعدة التعليمات البرمجية، فقد أضاف ذلك حملًا إضافيًا، وهو ما سنصفه بعد ذلك.
- كان الاختبار أكثر تحديًا واستهلاكًا للوقت نظرًا لعدم طرح Flutter بنسبة 100%؛ كنا بحاجة إلى اختبار كلا الإصدارين (Flutter وnon-Flutter) باستخدام عدة أجهزة، مما أدى إلى تكرار الكثير من العمل.
- يتطلب التبديل بين Flutter وNative وقت تطوير إضافيًا بنسبة 20% تقريبًا لمهندسينا.
- نظرًا لأن إصدار Flutter الخاص بنا كان قديمًا، فقد كان تصحيح أخطاء ميزات Flutter على نظام التشغيل iOS أمرًا صعبًا. هناك غياب لأدوات IDE، التي تسمح بالتعمق في تصحيح الأخطاء اللازمة لضمان تجربة مستخدم سلسة.
- كان تصحيح الأخطاء أكثر صعوبة لأننا نفتقر إلى أدوات قوية في IDE لتصحيح الأخطاء في الوقت الفعلي أو فحص التعليمات البرمجية في وقت التشغيل لتحليل مشكلات السبب الجذري وإصلاحها.
- نظرًا لإصدار إضافات جديدة إلى نظام التشغيل كل عام في النظام البيئي، فقد تأخر الوصول إلى هذه الوظيفة أو الإمكانات لأننا كنا بحاجة إلى انتظار تحديثات Flutter SDK التي مكنت هذه الوظيفة.
- لم نتمكن من الاستفادة من XCode 14.3 على نظام التشغيل iOS والاستمرار في اعتماد الإصدارات المستقبلية عند إصدارها. (يوفر XCode 14.3 إمكانات مبتكرة مثل الرموز التعبيرية الجديدة وإشعارات تطبيقات الويب وعزل الصوت للمكالمات الخلوية ودعم VoiceOver المحسّن و أكثر.)
كانت هناك العديد من المزايا للتحول إلى النهج الأصلي الكامل:
- قدم التطوير الأصلي أداءً واستجابة فائقين بسبب التحسين لنظام تشغيل وأجهزة معينة.
- كانت تجربة المستخدم سلسة لأن المطورين يمكنهم الالتزام بإرشادات التصميم الخاصة بالنظام الأساسي والاستفادة من عناصر واجهة المستخدم الأصلية.
- كان للمطورين إمكانية الوصول المباشر إلى ميزات الجهاز لإنشاء تطبيقات غنية بالميزات.
- تميل التطبيقات الأصلية إلى احتلال مرتبة أعلى في متاجر التطبيقات، مما يؤدي إلى تحسين الرؤية وإمكانية الاكتشاف. يمكنهم العمل دون اتصال بالإنترنت أو باتصال محدود واعتماد تحديثات نظام التشغيل الجديدة بسرعة للحصول على تجربة مستخدم سلسة.
- تستفيد التنمية الأصلية من مجموعة قوية من أدوات التطوير والمكتبات ودعم المجتمع.
ومع ذلك، كانت هناك عيوب لهذا النهج أيضًا:
- يتطلب التطوير الأصلي قواعد تعليمات برمجية منفصلة لمنصات مختلفة، مما قد يؤدي إلى زيادة وقت التطوير والتكلفة.
- هناك احتمال حدوث تباين في السلوك وواجهة المستخدم مع وجود قاعدتين برمجيتين ومنطق عمل مختلف.
وبعد دراسة جميع الإيجابيات والسلبيات، قرر الفريق أن المضي قدمًا بنهج محلي كامل هو أفضل طريقة للمضي قدمًا.
يوفر النهج الأصلي أداءً فائق السرعة
لقد كان التحول إلى النهج الأصلي بالكامل بمثابة جهد هائل استغرق عامًا ونصف لإكماله، ولكن يمكننا أن نقول بثقة أنه كان القرار الصحيح. يوفر النهج الأصلي إمكانية الوصول الكامل إلى القدرات الأصلية والنظام البيئي الأصلي، مما يمكننا من تقديم تجارب مستخدم استثنائية.
تشديد قاعدة التعليمات البرمجية لتحسين إمكانية القراءة وتسهيل الصيانة. يوجد الآن خطر أقل لتسلل مشكلات الانحدار إلى قاعدة التعليمات البرمجية وتقليل حمل التهيئة من أجل انتقالات أسرع للشاشة.
أدى استخدام التطبيق الأصلي إلى تقليل وقت تشغيل التطبيق بنسبة 40%، من ثانيتين إلى 1.2 ثانية فقط. أصبح حجم حزمة التطبيق أصغر بنسبة 30% تقريبًا (280 ميجابايت بدلاً من 398 ميجابايت)، وتقلصت بصمة ذاكرة التطبيق بحوالي 65% (من 450 إلى 200 ميجابايت). وفي نهاية المطاف، تتيح هذه التغييرات تجربة مستخدم متميزة من خلال تطبيقنا للهاتف المحمول.
“إن إزالة Flutter من قاعدة التعليمات البرمجية الخاصة بنا والانتقال من قاعدة تعليمات برمجية هجينة إلى قاعدة تعليمات أصلية بالكامل قد أدى إلى تمكن الفريق الهندسي من بناء الميزات التي تبدو و يشعر أفضل،” يقول تومدرويد أندرسون، مهندس برمجيات الموظفين – الهاتف المحمول.
توفير الوقت للمطورين
المستخدمون ليسوا الوحيدين الذين يستفيدون من التحول إلى اللغة الأصلية. يتمتع مطورو الأجهزة المحمولة لدينا بتوفير الوقت والتكلفة والقدرة على الاستفادة من أحدث الميزات والقدرات المتوفرة في نظامي التشغيل Android وiOS لتعزيز وإثراء مشاريعهم.
يقول Jing Zhu، مهندس البرمجيات الذي عمل أيضًا في المشروع، إن التصميم الجديد أسهل في تصحيح الأخطاء ويوفر للفريق الكثير من وقت التطوير نظرًا لأنهم لا يحتاجون إلى إنشاء أطر عمل Flutter ومكتبات متعلقة بـ Flutter. ويبين الجدول أدناه توفير الوقت المحقق:
| قبل أن تصبح أصلية | بعد أن أصبح مواطنًا | توفير الوقت (%) | |
| اختبارات الوحدة | 20 دقيقة و46 ثانية | 12 دقيقة و38 ثانية | 64% |
| بناء محاكي iOS | 24 دقيقة و32 ثانية | 8 دقائق و32 ثانية | 188% |
| إصدار البناء | 30 دقيقة، 41 ثانية | 22 دقيقة و 29 ثانية | 36% |
| بناء المؤسسة | 29 دقيقة، 3 ثواني | 20 دقيقة، 25 ثانية | 42% |
بالإضافة إلى ذلك، أصبحت دورات التطوير أقصر، وذلك بفضل تحسين أوقات XCode. يوضح الجدول أدناه كيف أدى التحول إلى التطوير الأصلي إلى تسريع أوقات التطوير:
| قبل أن تصبح أصلية | بعد أن أصبح مواطنًا | توفير الوقت (%) | |
| بناء نظيف | 2 دقيقة و16 ثانية | 1 دقيقة و6 ثواني | 106% |
| إعادة بناء | 29 ثانية | 2.5 ثانية | 1060% |
| بناء اختبار الوحدة | 42 دقيقة | 5 دقائق و6 ثواني | 650% |
يقول فرناندو جينزينجي، كبير مهندسي البرمجيات للهواتف المحمولة: “تساعدنا إزالة Flutter من قاعدة التعليمات البرمجية في التركيز على ما يوفره كل نظام تشغيل محليًا”. “لقد زادت إنتاجيتنا بشكل ملحوظ دون قيود Flutter، وأصبح من الأسهل على مهندسينا الحفاظ على قاعدة التعليمات البرمجية.”
بالإضافة إلى ذلك، التصميم الجديد أكثر حداثة. ويضيف جينغ: “لدينا الآن ألوان سمات متسقة عبر الشاشات، مما يجعل تطبيقنا يبدو أنظف وأكثر أناقة بالتأكيد”. “نظرًا لأن المزيد والمزيد من جيل الألفية يشترون المنازل، فإن التصميم الجديد يمكن أن يجذب المزيد من المستخدمين إلى تطبيقنا للهاتف المحمول.”
بناء أفضل لصالح الجميع
كان تحويل تطبيق الهاتف المحمول الخاص بنا من Flutter إلى تطبيق أصلي بالكامل يستحق الوقت والجهد المستثمرين. الآن، يمكن للمطورين لدينا الاستفادة من أحدث ميزات وإمكانيات Apple وGoogle لتحسين تجربة المستخدم. كما أنها توفر قدرًا كبيرًا من الوقت والموارد والميزانية التي يمكن إعادة تخصيصها لإنشاء ميزات مبتكرة تُسعد المستهلكين لدينا وتجعل تجربتهم عبر الهاتف المحمول مع Realtor.com جذابة ومفيدة ومؤثرة.
يقول تومدرويد: “لم يعد علينا أن نشعر بمستوى معين من القلق بشأن النهج الهجين الذي قد يعيقنا”. “يمكننا الآن التركيز على جهود التحديث وتمكين فريقنا من إنشاء ميزات جديدة رائعة.”
Realtor.com® هو سوق عقاري مفتوح مصمم للجميع. نحن نقود التغيير الهادف بينما نعمل على منصة رائدة في الصناعة في طليعة تكنولوجيا العقارات. يتعلم أكثر عن مشاريعنا و الابتكار معنا أثناء اتخاذ الخطوة التالية في حياتك المهنية التقنية.