أسرار تطوير تطبيقات الهاتف المحمول. ما هو "التطبيق الأصلي"؟ تطوير التطبيقات الأصلية على نظام Android

يبلغ عمر سوق تطبيقات الهاتف المحمول أكثر من عشر سنوات، لكنه لا يزال يتطور بسرعة. يتزايد الطلب من الشركات باستمرار ولا يزال يفوق العرض بشكل كبير، مما يؤدي إلى زيادة مستمرة في تكلفة التطوير. أحد الحلول لتقليل تكلفة هذه العملية هو التطوير عبر الأنظمة الأساسية، عندما يتم استخدام نفس الكود على كافة الأنظمة الأساسية.

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

دعونا أولا نتناول المصطلحات مرة أخرى.

محلي

إذا استخدم المطورون، أثناء كتابة تطبيق ما، لغة البرمجة المعتمدة لمنصة معينة، سواء كانت Objective-C وSwift لنظام التشغيل iOS أو، فسيتم تسمية هذا التطبيق أصليًا (من اللغة الإنجليزية الأصلية - أصلي، طبيعي).

مزايا التطبيقات الأصلية:

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

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

وليس الأقارب

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

الأول هو أنه في مرحلة إعداد التطبيق للنشر، يتم تحويله إلى نسخة أصلية لمنصة معينة باستخدام أداة التحويل. في الواقع، يتم "ترجمة" إحدى لغات البرمجة عبر الأنظمة الأساسية إلى لغة أخرى.

والثاني هو إضافة غلاف معين إلى الكود الناتج، والذي يعمل بالفعل على الجهاز، ويترجم المكالمات من الكود غير الأصلي إلى وظائف النظام الأصلية بسرعة.

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

مزايا:

• التكلفة وسرعة التطوير. نظرًا لأن الحاجة إلى كتابة تعليمات برمجية أقل بكثير، يتم تقليل تكلفة العمل؛
• القدرة على استخدام الموارد الداخلية للشركة. كما سنبين لاحقًا، غالبًا ما يتم تطوير تطبيقات الهاتف المحمول عبر الأنظمة الأساسية بواسطة المبرمجين الحاليين لديك.

عيوب:

• واجهة غير أصلية أو، على الأقل، الحاجة إلى العمل مع واجهة كل منصة على حدة. كل نظام له متطلباته الخاصة لتصميم العناصر وفي بعض الأحيان تكون متعارضة. ويجب أن يؤخذ هذا في الاعتبار أثناء التطوير؛
• مشاكل في تنفيذ الوظائف المعقدة أو مشاكل محتملة في العمل حتى مع الإجراءات البسيطة بسبب أخطاء في أطر التطوير نفسها. تقوم البيئة عبر الأنظمة الأساسية فقط بترجمة الطلبات إلى استدعاءات النظام والواجهات إلى تنسيق يفهمه النظام، وبالتالي في هذه المرحلة قد تحدث صعوبات في الفهم وأخطاء داخل الإطار نفسه؛
• سرعة العمل. نظرًا لأن البيئة عبر الأنظمة الأساسية عبارة عن "بنية فوقية" فوق الكود (ليس دائمًا، ولكن في مواقف معينة)، فإن لها تأخيرات وتوقفات مؤقتة خاصة بها في معالجة إجراءات المستخدم وعرض النتائج. وكان هذا ملحوظًا بشكل خاص قبل بضع سنوات على الهواتف الذكية التي كانت ذات طاقة أقل مقارنة بأجهزة اليوم، ولكن الآن، مع زيادة أداء الأجهزة المحمولة، أصبح من الممكن بالفعل إهمال هذا الأمر.

كما ترون، فإن هاتين الطريقتين هما عمليًا صورة طبق الأصل لبعضهما البعض - مزايا التطوير الأصلي، وعيوب التطوير عبر الأنظمة الأساسية، والعكس صحيح.

منصات وأدوات شعبية للتطوير عبر الأنظمة الأساسية

كما كتبنا أعلاه، هناك طريقتان - تحويل الكود إلى أصلي في مرحلة التجميع أو إضافة غلاف معين يترجم المكالمات من وإلى النظام.

تعد Cordova وPWA أداتين تعملان بدقة في أيديولوجية الغلاف.

كوردوفا وHTML5

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

يتم التعبير عن جميع العيوب والمزايا هنا بشكل أكثر وضوحًا من أي مكان آخر. يمكنك استخدام مطوري الويب (HTML وCSS وJavaScript كتقنيات أساسية) وإنشاء الإصدار الأول من التطبيق في شهر أو حتى أسبوعين مقابل القليل من المال نسبيًا. نعم، سيكون بطيئًا في التشغيل، وقد لا يتمتع بموقع جغرافي دقيق تمامًا، ولكنه سيعمل على جميع الأجهزة وسيسمح لك، على الأقل، باختبار طلب العملاء على الأجهزة المحمولة.

تم إنشاء عدد كبير من الأطر لهذا النهج، لكنها جميعها تفعل الشيء نفسه بشكل أساسي. الفرق بينهما هو أن Cordova (PhoneGap) لا تضع قيودًا وقوالب على المنطق وواجهة المستخدم لمشروع HTML5 الخاص بك، وتعمل الأطر مع عناصر واجهة المستخدم الجاهزة الخاصة بها والتي تحاكي منصات الهاتف المحمول ومنطق التطوير الخاص بها. مثال على هذا النهج هو: الإطار الأيوني - المجمع؛ Framework7، Mobile Angular UI، Sencha Touch، Kendo UI - أطر الواجهة.

PWA

التكنولوجيا العصرية من Google هي نفس تطبيقات الويب، ولكن من خلال استخدام تقنيات معينة (في المقام الأول ما يسمى عامل الخدمة - البرامج النصية التي تعمل في الخلفية، وبيان تطبيق الويب - وصف لتطبيق الويب في شكل مفهوم للجوال system ) يمكنهم العمل كأنظمة أصلية بدون غلاف PhoneGap. يمكن تثبيتها على الشاشة الرئيسية، وتجاوز متجر التطبيقات، والعمل دون اتصال بالإنترنت، والعمل مع إشعارات الدفع، ومع الوظائف الأصلية.

المشكلة هي أنه حتى الآن لا تدعم جميع المنصات هذه "التقنيات المعينة". يتعلق هذا في المقام الأول بشركة Apple، التي يبدو أنها لا تحب حقًا القدرة على توزيع التطبيقات عبر متجر التطبيقات.

مع الأخذ في الاعتبار جميع أوجه القصور في حلول HTML5، أنشأت العديد من الشركات أدوات تسمح لك بكتابة التعليمات البرمجية بلغة واحدة غير أصلية، ثم يتم ترجمتها بعد ذلك إلى اللغة الأصلية. وهذا يقتل عصفورين بحجر واحد: هناك قاعدة تعليمات برمجية واحدة فقط، والتطبيقات أقرب ما تكون إلى الأصلية قدر الإمكان.

زامارين

منصة مايكروسوفت. لغة البرمجة القياسية لتطوير المؤسسات هي C#، وبيئة التطوير عبر الأنظمة الأساسية هي Visual Studio. الإخراج هو تطبيقات أصلية لأنظمة iOS وAndroid وWindows. صحيح أنها كبيرة الحجم نسبيًا.

رد الفعل الأصلي

النظام الأساسي من - تتم كتابة التطبيقات بلغة JavaScript وباستخدام أنماط تشبه CSS. وتبين أن الواجهة أصلية، ويتم تفسير التعليمات البرمجية على النظام الأساسي، مما يمنحها المرونة اللازمة.

نظرًا لكونها منصة حديثة نسبيًا، لا تزال React Native تعاني بشكل واضح (وإن لم يكن كارثيًا) من نقص أدوات التطوير والوثائق.

رفرفة

بطبيعة الحال، لا يمكن لشركة عملاقة مثل Google أن تتجاهل موضوع التطوير عبر الأنظمة الأساسية لتطبيقات Android وiOS. Flutter، على الرغم من أنه في مرحلة تجريبية حاليًا، يتخذ نهجًا مختلفًا عن React Native وXamarin. فهو لا يحول الكود المصدري إلى كود أصلي، والذي يتم تنفيذه بواسطة النظام الأساسي، ولكنه في الواقع يرسم نافذة على شاشة الهاتف الذكي ويعرض جميع العناصر بنفسه. اللغة المستخدمة هي لغة Dart "الملكية"، والتي أنشأتها Google كنسخة محسنة من JavaScript.

وهذا له مزايا (على سبيل المثال، واجهات متطابقة خارجيًا) وعيوب (على سبيل المثال، تتطلب إعادة رسم الواجهة قدرًا معينًا من الذاكرة ووقت وحدة المعالجة المركزية).

تتطور المنصة بسرعة وتستثمر Google الكثير من الجهد والمال فيها. ولكن بالمقارنة مع Flutter، حتى React Native يبدو وكأنه نظام بيئي راسخ ومثير للإعجاب.

ماذا تختار

ربما يكون رأسك يدور بالفعل، لكن لا يزال ليس لديك أي فكرة عما تختاره. دعنا نقدم قائمة بسيطة من الأسئلة لمساعدتك:

• هل ينبغي أن تعمل بطريقة أو بأخرى على أي جهاز؟ يختار لغة البرمجةكأساس؛
• هل لديك ما يكفي من الأموال، ولست في عجلة من أمرك وترغب في الحصول على أعلى مستوى من الجودة في التطبيق؟ لديك طريق مباشر ل التنمية المحلية;
• هل لديك مطور ويب "مدمج" أم أنك تريد فقط تجربة تطبيق الهاتف المحمول أثناء العمل بسرعة وسهولة؟ هنا يمكننا أن نوصي كوردوفا/HTML أو PWA;
• هل لديك نظام CRM خاص بك ومطور C# يدعمه؟ خذها زامارين;
• هل "تريد المحاولة"، لكنك بحاجة إلى جعل كل شيء جميلًا وعصريًا؟ انظر بعيدا رد الفعل الأصلي أو الرفرفة.

يمكنك أيضًا الذهاب من الجانب الآخر. انظر إلى الوظيفة التي ستحتاجها في تطبيقك وانتقل من هناك:

• تطبيق بطاقة عمل بسيط؟ يأخذ رد الفعل الأصلي أو HTML5وستحصل على منصتين بسعر أقل؛
• هل لديك موقع ويب يتمتع بحركة مرور عالية وتحتاج إلى اختبار تواجدك في مساحة الهاتف المحمول؟ HTML5;
• التطبيقات المعقدة مع إمكانية الوصول إلى وظائف الجهاز المطلوبة؟ التطوير الأصلي، Xamarin، React Native.

التطوير عبر الأنظمة الأساسية ليس حلاً سحريًا

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

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

تستمر الهواتف الذكية في اكتساب المزيد والمزيد من المساحة تحت الشمس، ليس فقط كأداة لالتقاط صور القطط ومقاطع الفيديو XXX، ولكن أيضًا كأداة عمل. ولذلك، فإن الطلب على تطوير الهاتف المحمول آخذ في الازدياد. من المقبول عمومًا أن العمل والهدوء هما Objective-C/Swift لنظام iOS وJava/Kotlin لنظام Android. لا شك أن هذا عمل شاق ورائع، ولكن هناك عددًا كبيرًا من السيناريوهات الحقيقية التي يكون فيها استخدام أطر العمل عبر الأنظمة الأساسية أكثر تفضيلاً مقارنة بالأدوات الأصلية.

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

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

لماذا نحتاج إلى أدوات مشتركة بين المنصات؟

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

الأدوات الأصلية = مقدمة من مالك النظام البيئي.

جميع العلامات الأخرى لـ "الأصلية" هي علامات ثانوية - واجهة السلوك والتطبيق، والوصول إلى إمكانيات نظام التشغيل، والأداء، وما إلى ذلك.

بالإضافة إلى ذلك، اتضح دائما أن الأدوات الأصلية غير متوافقة مع بعضها البعض ليس فقط على مستوى لغات التطوير والاتفاقيات والبنيات المقبولة، ولكن أيضا على مستوى آليات العمل مع نظام التشغيل والمكتبات. ونتيجة لذلك، لتنفيذ نفس الخوارزميات والواجهات، كان من الضروري كتابة تطبيق لعدة بيئات بلغات برمجة مختلفة، ومن ثم دعمه على أساس "أمر واحد لكل منصة". وفي الوقت نفسه، تكون إمكانيات ومظهر التطبيقات على منصات مختلفة دائمًا متطابقة بنسبة 90٪ تقريبًا. من أجل المتعة فقط، قم بمقارنة تنفيذ برامجك المفضلة لنظامي التشغيل iOS وAndroid.

النقطة الثانية المهمة هي وجود المعرفة والخبرة اللازمة داخل الفريق: إذا لم يكن هناك، فسوف يستغرق الأمر بعض الوقت للتعلم.

من أجل حل هاتين المشكلتين، ظهرت في السوق منذ فترة طويلة أدوات التطوير عبر الأنظمة الأساسية (وليس فقط الأجهزة المحمولة)، والتي تقدم:

• تعظيم قاعدة التعليمات البرمجية المشتركة في لغة برمجة واحدة بحيث يكون تطوير المنتج وصيانته أسهل؛
• استخدام الكفاءات والمتخصصين الحاليين لتنفيذ التطبيقات على منصات جديدة.

نظرًا لوجود الكثير من لغات البرمجة (وبيئات البرمجة) الآن (والمتخصصين الذين يتحدثون هذه اللغات)، فهناك عدد لا بأس به من الأدوات للتطوير عبر الأنظمة الأساسية. على سبيل المثال، سوف نركز على تلك الشعبية في منطقتنا PhoneGap وXamarin وReact Native وQt.

الآن يمكننا أن نتحدث عن الأساطير.

الأسطورة 1. السحر

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

المبدأ الرئيسي الذي تقوم عليه الحلول عبر الأنظمة الأساسية هو تقسيم الكود إلى قسمين:

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

من أجل ربط العالم "الأصلي" والعالم "عبر الأنظمة الأساسية"، من الضروري استخدام خاص كوبريفهو الذي يحدد قدرات وقيود الأطر عبر الأنظمة الأساسية.

عند استخدام الجسر، ينخفض ​​الأداء دائمًا بسبب تحويل البيانات بين "العوالم"، بالإضافة إلى تحويل استدعاءات واجهة برمجة التطبيقات (API) والمكتبات.

لذلك، يجب أن تحتوي جميع التطبيقات عبر الأنظمة الأساسية على جزء أصلي، وإلا فإن نظام التشغيل ببساطة لن يتمكن من تشغيلها. لذلك دعونا نلقي نظرة فاحصة على واجهات برمجة التطبيقات والآليات الخاصة بالنظام التي توفرها أنظمة التشغيل iOS وAndroid وWindows نفسها. دعنا ننتقل إلى الأسطورة التالية.

الأسطورة 2. ليس مواطنا!

لذلك، لدينا جزء متعدد المنصات من التطبيق، يعيش في بيئة افتراضية ويتفاعل مع نظام التشغيل من خلال البنية التحتية لإطار العمل والجسر.

توفر جميع أنظمة التشغيل: iOS وAndroid وWindows UWP إمكانية الوصول إلى الأنظمة الفرعية التالية (مجموعات واجهات برمجة تطبيقات النظام):

• يتم استخدام WebView (متصفح ويب داخل التطبيق) في عمليات المزج المستندة إلى PhoneGap ويعمل بشكل أساسي كبيئة تشغيل لموقع الويب المحلي؛
• تُستخدم محركات JavaScript في React Native ونظائرها للتنفيذ السريع لتعليمات JS البرمجية وتبادل البيانات بين Native وJS؛
• يتم استخدام OpenGL ES (أو DirectX) في محركات الألعاب والتطبيقات المعتمدة على Qt/QML أو نظائرها لعرض الواجهة؛
• يعد نظام واجهة المستخدم الفرعي مسؤولاً عن واجهة المستخدم الأصلية للتطبيق، وهي ذات صلة بـ React Native وXamarin.

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

عرض ويب- التطبيق موجود في متصفح الويب الخاص به، على غرار موقع الويب المكون من صفحة واحدة. لا يمكن الوصول إلى عناصر التحكم الأصلية (الأزرار، والقوائم، وما إلى ذلك)، فكل شيء يعتمد على HTML/CSS/JavaScript. من ناحية أخرى، سيشعر مطور الويب وكأنه سمكة خارج الماء.

محركات جافا سكريبتأصبحت شائعة مؤخرًا نسبيًا، حيث تمت إضافة آلية مماثلة إلى نظام التشغيل iOS فقط في الإصدار 7.0. إحدى الميزات الجديرة بالاعتبار هي الحاجة إلى إجراء تسلسل لهياكل البيانات المعقدة المنقولة بين بيئة JavaScript والبيئات الأصلية في JSON. لوصف هذه الفئة من الحلول بإيجاز، يتم تنفيذ كود JS الذي يتحكم في التطبيق الأصلي في بيئة JavaScript.

برنامج OpenGL ES وDirectXهي أنظمة فرعية منخفضة المستوى وتستخدم لعرض واجهة المستخدم في الألعاب، على سبيل المثال، Qt/QML. أي أنه عند استخدام OpenGL/DirectX، يقوم المطورون بأنفسهم برسم عناصر التحكم والرسوم المتحركة، والتي يمكن أن تكون مشابهة فقط لتلك الأصلية. من ناحية أخرى، فهو نظام فرعي منخفض المستوى ذو أداء عالٍ جدًا، ولهذا السبب يتم استخدامه أيضًا في محركات الألعاب عبر الأنظمة الأساسية.

تحتوي جميع التطبيقات عبر الأنظمة الأساسية على جزء أصلي، وبالتالي من المحتمل أن يكون لها نفس الوصول الكامل إلى واجهات برمجة تطبيقات النظام مثل تلك الأصلية. بالإضافة إلى ذلك، يتم إنشاء التطبيقات عبر الأنظمة الأساسية وتعبئتها بأدوات أصلية في حزم التثبيت الأصلية. السؤال الرئيسي هو كيفية تنظيم التفاعل بين الجزء المشترك بين الأنظمة الأساسية والجزء الأصلي. على سبيل المثال، داخل WebView أو باستخدام Open GL ES / DirectX، لا توجد طريقة لإنشاء واجهة مستخدم ذات مظهر أصلي تمامًا، ولكن في نفس الوقت هناك وصول كامل إلى نظام تحديد المواقع العالمي (GPS) وإشعارات الدفع والوظائف الأخرى. ويمكن للتعليمات البرمجية في JavaScript أو C# التحكم بحرية تامة في التطبيق الأصلي وسلوكه، مما يوفر مظهرًا أصليًا تمامًا.

للتلخيص، نعم، إنها "غير أصلية" من حيث أدوات التطوير المستخدمة (ليست من Apple أو Google). ولكن يمكن أن يكون التطبيق أصليًا تمامًا من حيث الوصول إلى واجهات برمجة التطبيقات (APIs) الخاصة بالنظام ويوفر مظهرًا ومظهرًا أصليين تمامًا. ونحن ننتقل إلى الأسطورة التالية.

الأسطورة 3. عكاز على عكاز

من المفيد هنا أن نفهم أن واجهات برمجة التطبيقات الأصلية لا تعتبر عكازات بشكل افتراضي (على الرغم من وجود آراء مختلفة هنا)، لذلك يتم توجيه كل السخط إلى الجزء عبر الأنظمة الأساسية. من الواضح أن بيئة التنفيذ (على سبيل المثال، WebView أو محرك JavaScript أو Mono) من الصعب أيضًا أن نطلق عليها عكازًا - حلول ناضجة ذات تاريخ طويل.

يبدو أن العكاز هو كيفية تكامل الجزء المشترك بين الأنظمة الأساسية مع الجزء الأصلي. لفهم كيفية عمل أطر العمل المختلفة بشكل أفضل، باستخدام مثال PhoneGap وXamarin وQt وReact Native، سنلقي نظرة على آليات نظام التشغيل المستخدمة لربط الأجزاء المشتركة بين الأنظمة الأساسية والأجزاء "الأصلية".

سنبدأ مع PhoneGap. يوجد أدناه بنية المستوى الأعلى لتطبيق يعتمد على هذا الإطار.

أحد التطبيقات الموجودة على PhoneGap هو في الواقع تطبيق أصلي يعرض WebView باعتباره عنصر التحكم الوحيد في واجهة المستخدم. ومن خلاله يحدث التفاعل مع الجزء الأصلي. تدعم جميع عروض WebView القياسية في أنظمة التشغيل iOS وAndroid وWindows UWP القدرة على إضافة المعالجات الأصلية الخاصة بك لخصائص وأساليب JS. في الوقت نفسه، يعيش كود JS في بيئته المعزولة ولا يعرف شيئًا عن الجزء الأصلي - فهو ببساطة يسحب أساليب JS الضرورية أو يغير خصائص JS الضرورية. كل شيء موجود داخل Web DOM القياسي، والذي تتم إضافة عناصر جديدة مرتبطة بالتنفيذ الأصلي إليه ببساطة.

عند إنشاء تطبيقات في React Native، سيحتاج المطور دائمًا تقريبًا إلى تنفيذ الجزء الأصلي في Objective-C أو Java أو C#، وستأتي إدارة التطبيق الأصلي نفسه من JavaScript. في الواقع، محرك JavaScript هو عنصر WebView متوفر بشكل منفصل. يحدث التفاعل من خلال نفس جسر JS كما في حالة PhoneGap. ومع ذلك، في React Native، لا يتحكم كود JS في شجرة DOM على الويب، بل في التطبيق الأصلي.

يرجى ملاحظة أنه بسبب قيود نظام التشغيل iOS (لا توجد طريقة لتنفيذ JIT)، يتم تفسير كود JavaScript بسرعة، بدلاً من تجميعه. بشكل عام، ليس لهذا تأثير كبير على الأداء في التطبيقات الحقيقية، لكن الأمر يستحق الأخذ في الاعتبار.

الآن دعونا نلقي نظرة على Xamarin.iOS وXamarin.Android الكلاسيكيين، نظرًا لأن Xamarin.Forms (الذي يدعم Windows UWP) عبارة عن مجموعة شاملة فوقهما.

يستخدم Xamarin مكتبة Mono للتفاعل مع نظام التشغيل المستهدف، مما يسمح لك باستدعاء التعليمات البرمجية الأصلية باستخدام آلية P/Invoc. كما يتم استخدامه للتواصل مع واجهات برمجة التطبيقات الأصلية في iOS/Android. وهذا يعني أنه بالنسبة لجميع أساليب واجهة برمجة التطبيقات الأصلية العامة، يتم إنشاء الأغلفة في لغة C#، والتي بدورها تستدعي واجهات برمجة تطبيقات النظام. بهذه الطريقة، يمكنك الوصول إلى جميع واجهات برمجة تطبيقات النظام من تطبيق Xamarin الخاص بك.

وأخيرا، دعونا نلقي نظرة على Qt، حيث أن هناك الكثير من الأسئلة حول هذا الموضوع من المطورين ذوي الخبرة.

كيو تي هي "شيء في حد ذاته"، ولها مزايا وقيود. تتصل مكتبات Qt ببساطة بواجهات برمجة تطبيقات نظام C++ الموجودة في جميع أنظمة التشغيل. لعرض واجهة المستخدم، يتم استخدام آليات منخفضة المستوى، ولكن محرك الرسومات الخاص به يدعم التصميم الأصلي. في هذه الحالة، على Android، يتعين عليك الوصول إلى Java API من خلال جسر خاص (جسر JNI)، وبالنسبة لنظام التشغيل Windows UWP، استخدم محول الاتصال Open GL ES إلى DirectX، نظرًا لأن Open GL غير متاح لـ UWP.

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

الأسطورة 4. بطيئة

إن البطاقة الرابحة المهمة التي يحب الأشخاص استخدامها في النزاعات حول أطر العمل عبر الأنظمة الأساسية هي الأداء المنخفض. مرة أخرى، يعتمد الأمر على ما يجب مقارنته وما هي الببغاوات التي يجب حسابها.

دعونا نتذكر أن خصوصية التطبيقات عبر الأنظمة الأساسية هي الوجود الموازي لعالمين متصلين بجسر:

• PhoneGap: HTML/JS وJava / Objective-C / C# الأصلي؛
• React Native: JS وNative Java / Objective-C / C#؛
• Xamarin: Mono وJava/Objective-C الأصلي؛
• كيو تي: C++ وجافا الأصلية/الهدف-C.

وبالتالي، عند مقارنة الأداء، من الضروري أن تأخذ في الاعتبار سرعة التشغيل:

• جزء عبر منصة.
• الجزء الأصلي؛
• كوبري.

إذا كتبت في محرك بحث، على سبيل المثال، وتفاعلت مع الأداء الأصلي مقابل الأداء السريع، فيمكنك الاطلاع على العديد من الاختبارات المختلفة، ويلاحظ الكثير منها أن الأداء ينخفض ​​بشكل حاد مع الاستخدام النشط للجسر، بما في ذلك المعالجة النشطة لواجهة المستخدم من خلال رمز المنصة. بالنسبة لـ Xamarin، يبدو الوضع هو نفسه - الجزء عبر الأنظمة الأساسية سريع جدًا ويمكن مقارنته بالجزء الأصلي في معالجة البيانات، ولكن عند استخدام الجسر، قد ينخفض ​​الأداء. تعمل Qt بشكل عام على مستوى C++، وهو سريع بحد ذاته. إذا نظرنا إلى الحلول المستندة إلى PhoneGap، فسيعتمد الأداء بشكل كبير على WebView، ولكن لا يزال يتعين عليك عدم تغيير واجهة المستخدم بشكل نشط في كود JavaScript أو إجراء حسابات علمية.

ببطء؟ نعم، من الممكن حدوث انخفاض في الأداء بسبب التفاعل غير الكفؤ مع نظام التشغيل عبر الجسر. ومع ذلك، فإن العوالم متعددة المنصات نفسها هي بنفس سرعة العوالم الأصلية.

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

سنتحدث اليوم عن التطبيقات المحلية والهجينة مع دينيس ألتوخوف، مطور Android في شركة Anadea.

مرحبًا دينيس!
مرحبًا!

أخبرني كمحترف: ما الفرق بين التطبيقات الأصلية والتطبيقات الهجينة؟
حسنًا، انظر: تم إنشاء الأنظمة الأصلية لمنصة معينة، سواء كانت Android أو iOS أو Windows. وهي مكتوبة باللغات الأصلية - Java في حالة Android وObjective C في حالة iOS. تم تنزيله حصريًا من المتاجر الرسمية.

مثل بلاي ماركت؟
نعم، بالنسبة لنا هو PlayMarket وAppStore لـ Apple. ويتم التثبيت والتوزيع من خلال هذه المتاجر. يتم فتحه كتطبيق منفصل وله نوافذ خاصة به. غير الأصلي، المكتوب بلغة JavaScript، هو في الأساس تطبيق يتم فتحه في المتصفح وله نوع من تخطيط الهاتف المحمول.

هل هو في الأساس تطبيق ويب؟
نعم. وميزته هي أنه متعدد المنصات - حيث يمكنك الكتابة لجميع الأنظمة الأساسية في وقت واحد، Windows وAndroid وiPhone أو أي نظام آخر سيفتحها. ولكن هنا يتم فرض مثل هذا القيد بحيث لن تتمكن من الوصول إلى العديد من الوظائف الفنية التي يطلبها العميل. على سبيل المثال، يريد العمل النشط مع الكاميرا - لا يمكنك القيام بذلك بغير اللغة الأصلية. لا يمكنك إنشاء تصميم باستخدام الأدلة المتوفرة لنظامي التشغيل iOS وAndroid.

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

جميع التطبيقات الكبيرة هي في الغالب أصلية. لماذا؟
غياب أي قيود هو السبب الرئيسي. يمكنك الوصول إلى أي وظيفة يوفرها لك نظام التشغيل. يعد هذا التطبيق أكثر مرونة ويتمتع بعمر بطارية أفضل بكثير بفضل بنية اللغة الأصلية الصحيحة. ينظر نظام التشغيل نفسه إلى تطبيقك ويرتب العمل الصحيح مع البطارية والشاشة وما إلى ذلك. سيكون تنفيذ نفس العمل مع الخرائط في تطبيق مختلط دون استخدام الأدوات الأصلية من Google وApple أكثر صعوبة.

هل واجهت تطبيقات هجينة في ممارستك؟
نعم. على سبيل المثال، قبل عام، ظهر مشروع يعمل بالخرائط - لقد تم كتابته بلغة JavaScript، وكان من الصعب إطلاقه في استوديو خاص، وكان المشروع نفسه معطلاً. لقد تمكنت بطريقة ما من تشغيله فقط على محاكي iPhone!

يا إلهي!
وهذا من أجل رؤية شيء ما على الأقل! وكان من الصعب جدًا فهم ما كان يحدث هناك. في النهاية، توصل العميل إلى استنتاج مفاده أنه بدلاً من تطبيق هجين واحد، طلب تطبيقين أصليين - لنظامي التشغيل iOS وAndroid.

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

هل هذا هو السبب في أن التطبيقات غير الأصلية غالبًا ما تكون ذات جودة رديئة؟
نعم - "تتعطل" أو لا تعمل بشكل صحيح لأن شخصًا ما جاء من الخارج. الجانب الإشكالي الآخر لـ "الهجينة" هو تنظيم الإخطارات. ربما تعمل هذه الخدمات بطريقة ما هناك، ولكن، على سبيل المثال، نعمل الآن على تطبيق اجتماعي لمشاركة الصور، ويتم إنشاء الإشعارات هناك على نظامي iOS وAndroid بشكل مختلف تمامًا. وهنا فرق كبير بالنسبة لك. كيف ستبدو الإشعارات في تطبيق الويب على المنصات الثلاث المعلنة (iOS، Android، Windows)، حيث يتمتع كل منها بخصائصه الفردية... ولكن من يدري؟

ماذا عن السلامة؟
الهجينة تخسر هنا أيضًا. يمكنك تنزيل ملف APK من مكان واحد فقط - من المتجر. بالإضافة إلى ذلك، قبل نشر التطبيق باستخدام الأدوات القياسية، لديك الفرصة لتشفير كل شيء، وإخفاء التنفيذ، وما إلى ذلك. بالإضافة إلى التشفير، يتم استخدام شيء آخر يسمى proguard - فهو يكسر الروابط ويمسح الأسماء. لا يوجد شيء من هذا في لغة غير أصلية، مما يعني أنه يمكن لأي شخص تفكيكه وسرقة الكود الخاص بك وتنزيله من بعض الأماكن الأخرى.

أي أن التطبيقات الهجينة لا تزال بعيدة جدًا عن التطبيقات الأصلية؟
بالطبع. إنها منطقية إذا كنت تقوم بتطوير شيء بسيط جدًا، ومعمم، وإذا كانت الميزانية منخفضة والمواعيد النهائية ضيقة. شيء لا يتطلب كل قوة الجهاز ولا يرتبط بالأجهزة. إذا كانت جميع الوظائف مطلوبة، فإن أنظمة التشغيل الأصلية لـ Google وApple لديها بالفعل جبل كامل من الأساليب وطرق العمل مع الكاميرا والخرائط والبلوتوث والمزيد. وبالطبع ستكون أفضل وذات جودة أعلى من الدراجة المعاد اختراعها من قبل بعض مطوري الطرف الثالث.

وأنا أتفق تماما معك. شكرا لأخذ الوقت للدردشة!
على الرحب والسعة.

دعونا نلخص محادثتنا مع دينيس:

• إذا كنت تحتاج إلى سرعة عالية وسيستخدم تطبيقك الأجهزة مباشرة (الكاميرا، ذاكرة الوصول العشوائي، شريحة الفيديو، البلوتوث، شبكة Wi-Fi، الشاشة، وما إلى ذلك) - قم بتطوير تطبيق أصلي؛
• إذا كنت مهتمًا بمستوى عالٍ من الأمان، فقم بتطوير تطبيق أصلي؛
• إذا كنت تعمل على مشروع كبير حقًا، فقم بتطوير تطبيق أصلي؛
• إذا كنت بحاجة إلى شيء بسيط جدًا ومشروعك لا يحتاج إلى النقاط المذكورة أعلاه، فيمكنك القيام بذلك باستخدام تطبيق مختلط.

التنمية الهجينة والمحلية: قابلة للمقارنة؟

تطبيقات هجينة أم أصلية (من اللغة الإنجليزية الأصلية - اللغة الأصلية)؟ يعد هذا أحد أهم الأسئلة التي تطرح على عاتق عميل البرنامج عندما يحتاج إلى إصدار تطبيق جديد لاستخدام المستهلك.

لنبدأ بتعريف كل واحد منهم. يجمع التطبيق المختلط، كما يبدو، بين عناصر من التطبيقات الأصلية (يعمل التطبيق دون أي دعم خارجي) والويب (يتم تشغيل التطبيق باستخدام متصفح ويتم كتابته عادةً بتنسيق HTML5). يستعير التطبيق تقنيات الويب المتوافقة مثل HTML5 وCSS وJavascript ويستخدم بعضًا من التعليمات البرمجية الخاصة به ليكون أكثر استجابة لجهاز المستخدم. يتم وضع التطبيقات الهجينة داخل التطبيق الخاص بها حيث يوجد WebView الخاص بمنصة الهاتف المحمول (المتصفح مضمن داخل تطبيق الهاتف المحمول، إذا جاز التعبير). ببساطة، التطبيق المختلط هو موقع ويب يتم تعبئته في غلاف أصلي. من أمثلة العلامات التجارية التي تستخدم عمليات المزج: Amazon App Store، وGmail، وYelp.

تم تطوير تطبيق أصلي لنظام تشغيل محمول محدد (Objective-C /Swift لنظام iOS أو Java لنظام Android) وتم تحسينه لتحقيق الاستفادة الكاملة من جميع إمكانات النظام الأساسي (الكاميرا، وقائمة جهات الاتصال، ونظام تحديد المواقع العالمي (GPS)، وما إلى ذلك). بشكل أساسي، يتم تنفيذ التطبيق الأصلي باستخدام الأدوات الخاصة بالمنصة. ومن أمثلة هذه التطبيقات ستاربوك، وهوم ديبوت، وفيسبوك (على الرغم من أن البعض يختلف مع الأخير).

دعونا نلقي نظرة على بعض الاعتبارات المهمة التي ستساعدك على الاختيار بين التطبيق الأصلي أو المختلط.

تكلفة التطوير

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

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

وقت

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

إذا لم يكن الوقت أولوية، فقد يكون التطوير الأصلي مناسبًا لك. خلاف ذلك، سيكون من الأفضل الهجين.

التحديثات

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

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

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

المستخدمين

من خلال التطبيق الأصلي، يمكنك بسهولة استخدام الوظائف الواسعة لجهازك المحمول: الكاميرا والميكروفون ونظام تحديد المواقع العالمي (GPS) وغير ذلك الكثير. ومع ذلك، فإن منحنى تعلم المستخدم صغير.

يتم أيضًا تطوير التطبيقات الأصلية عادةً للاستخدام في حالة عدم توفر شبكة Wi-Fi أو القدرة على تلقي البيانات من الخارج. يمكن أن يعمل الهجين أيضًا في الوضع المستقل، وسيكون لديك خيارات أقل قليلاً.

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

أمان

قد يشير النقاد المختلطون إلى عمليات حقن جافا سكريبت أو ثغرات أمنية في طبقة المقابس الآمنة (SSL)، ولكن إذا قمت بتأمين موقعك، فهذا ليس مصدر قلقك. ومع ذلك، تحتوي التطبيقات المختلطة على المزيد من المعلومات المعرفية المتاحة للعامة، مما يزيد من احتمالية إجراء عملية الهندسة العكسية. كما أنها تعتمد أيضًا على المكونات الإضافية، التي تشكل طبقة إضافية من التعليمات البرمجية حيث يمكن العثور على ثغرة أمنية.

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

التوافق عبر الأنظمة الأساسية

الأمر بسيط هنا - هذا هو المكان الذي تفوز فيه التطبيقات المختلطة: التطبيق الأصلي الذي تم تطويره لجهاز iPhone لن يعمل على نظام Android، والعكس صحيح.

خاتمة

هل تبحث عن إجابة محددة؟ الشيء الوحيد الذي يمكنني أن أخبرك به هو أن أفضل شكل من أشكال تطوير التطبيقات هو الذي يناسب احتياجاتك الفريدة. سيعتمد هذا على مواردك واحتياجات المستخدم النهائي. اسمحوا لي أن أذكرك أنه يمكنك دائمًا الاتصال بي لتطوير البرنامج؛ يمكنني إنشاء تطبيق بلغة Java أو C#. لدي أيضًا خبرة في تطوير J2ME وAndroid.

في هذه المقالة، سنقوم بمقارنة 6 حلول تطوير عبر الأنظمة الأساسية كانت شائعة في عام 2016 ونحاول العثور على الحل الأفضل.

أطر العمل عبر الأنظمة الأساسية PhoneGap وXamarin وUnity وQt وAppcelerator Titanium وTelerik Platform تشغل حاليًا 80% من سوق التطوير عبر الأنظمة الأساسية للأجهزة المحمولة.

ويبين الجدول أدناه الخصائص الرئيسية لكل إطار:

PhoneGap

يسمح لك PhoneGap Build بإنشاء إصدارات لنظام التشغيل iOS وAndroid وWindows Phone في وقت واحد، دون الحاجة إلى تثبيت أي أدوات SDK (بالطبع، هناك بعض المكر في هذا - عند التطوير، لا يزال من الأفضل البناء محليًا، على الأقل على Android قبل إرساله للاختبار). ولكن الأهم من ذلك هو أن هذه الخدمة تتيح لك إنشاء نظام iOS في السحابة دون الحاجة إلى امتلاك جهاز Mac.

يتطلب تثبيت PhoneGap مجهودًا لا يصدق، لذا أنصحك بتخصيص نصف يوم مجانًا... مجرد مزاح. استغرق تثبيت XCode حوالي 3 دقائق - وكان يتألف من تنزيل الأرشيف وتفريغه وتثبيته. هذا كل شئ.

يوفر PhoneGap الفرصة لاستخدام الوظائف الأصلية لجهاز محمول للعمل مع:

• مقياس التسارع,
• آلة تصوير،
• بوصلة،
• جهات الاتصال،
• ملف التخزين،
• تحديد الموقع الجغرافي,
• قاعدة البيانات
• الأحداث والإخطارات،
• وسائل الإعلام، الخ.

مزايا:

• يحتوي PhoneGap على واجهة برمجة تطبيقات بسيطة تجعل من السهل البدء في التطوير لأولئك الذين واجهوا HTML وCSS وJavaScript.
• القدرة على استخدام أي مكتبات JavaScript موجودة (JQuery، Prototype، Sencha Touch)
• يدعم جميع منصات المحمول

• يتم تقديم واجهة المستخدم باستخدام المتصفح المدمج. وهذا يجعل الحصول على تعليقات أكثر صعوبة مقارنةً بالتطبيق الأصلي.
• غالبًا ما يتبين أن المكونات الإضافية الموجودة قديمة، لذلك يتعين عليك أحيانًا كتابة المكونات الإضافية الخاصة بك.

زامارين

من الناحية الوظيفية، تمثل منصة Xamarin عددًا من المنصات الفرعية. تلعب هذه المنصات الفرعية دورًا كبيرًا - فمن خلالها يمكن للتطبيقات توجيه الطلبات إلى واجهات التطبيقات على الأجهزة. تم تعريف الواجهة المرئية، والمنطق مرتبط بـ C#، وكل هذا سيعمل على Android وiOS وWindows Phone. فيديو حول تطوير تطبيق على Xamarin.

مزايا:

• مجتمع كبير ومتنامي.
• يمكن للمطورين استخدام TestCloud لاختبار التطبيقات تلقائيًا.
• إذا كنت معتادًا على لغة C# و.NET، فلن تحتاج إلى قضاء الكثير من الوقت في تعلم العديد من أطر العمل الجديدة.
• يمكنك إعادة استخدام التعليمات البرمجية المكتوبة بالفعل.
• ستبدو التطبيقات تحت أنظمة مختلفة متشابهة جدًا.
• يعد التخطيط الديناميكي لنظام iOS أسهل بكثير من استخدام القيود يدويًا.
• بفضل CustomRenderers، يمكن بسهولة استكمال عناصر التحكم القياسية بخصائص عشوائية (على سبيل المثال، يستغرق إجراء تعبئة متدرجة للأزرار بضع دقائق، على الرغم من أنه لا يعمل خارج الصندوق).

عيوب:

• يصعب تنفيذ بعض أنماط الواجهة على monodroid وصعبة للغاية على monotouch، نظرًا لأن الحلول الافتراضية لهذه الميزة أو تلك تعتمد على عكازات النظام الأساسي، والتي قد لا تعمل ببساطة في Xamarin.
• توجد مشكلات في الأنظمة الأساسية أحادية اللمس و monodroid. يجب أن يلبي طلبك متطلبات الاستقرار المحددة.
• لا يمكن وضع صفحات Android كجزء من نشاط/جزء موجود.
• لا يتم تنفيذ كافة الضوابط.

Telerik AppBuilder

تعد القدرة على إنشاء تطبيقات iOS تعمل على نظام التشغيل Windows أو Linux ميزة أخرى.

مزايا:

• توفر Telerik المكونات الإضافية لـ Visual Studio وSublime Text لـ AppBuilder.
• يقدم AppBuilder طريقة سريعة لاستيراد مكونات Cordova الإضافية.
• IDE كامل عبر الإنترنت.
• سهل الاستخدام والتعلم

عيوب:

• مجتمع صغير

وحدة

مزايا:

• خيار رائع لإنشاء ألعاب محمولة لمجموعة من الأجهزة
• ينتج المحرك ثلاثي الأبعاد نتائج عالية الجودة دون أي تكوينات معقدة
• هناك العديد من الإضافات المجانية الجيدة
• تتيح Unity للمطور إنشاء تظليلات خاصة به وتغيير الطريقة التي تعرض بها Unity اللعبة.

عيوب:

• واجهة المستخدم وصعوبة الاستخدام للمبتدئين
• كود المصدر غير متوفر
• لم يتم تحسين برامج التحويل البرمجي Unity لمعالجات ARM على بعض الأجهزة المحمولة.

• لدى Qt العديد من الأدوات الجيدة للمساعدة في التطوير، على سبيل المثال: IDE QT Creator وQt Designer وملف تعريف التعليمات البرمجية.
• يحتوي على مكتبات تحتوي على واجهات برمجة تطبيقات بديهية لعناصر مثل الشبكات والرسوم المتحركة والمزيد.

عيوب:

• كيو تي صعب للمبتدئين

مسرع التيتانيوم

يمكنك إنشاء تطبيقات حديثة، والأهم من ذلك، أصلية باستخدام أي نظام تشغيل شائع حاليًا: Windows، أو GNU/Linux، أو MacOS X.

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

مزايا:

• تسهل JavaScript تطوير التطبيقات دون استخدام لغات النظام الأساسي.
• يسمح لك Appcelerator بإجراء التحليلات في الوقت الفعلي
• سيؤدي استخدام واجهة برمجة التطبيقات الأصلية إلى توفير أداء أفضل للتطبيقات التي ليست كبيرة جدًا.

عيوب:

• هناك تأخيرات عند تشغيل التطبيق بسبب تحميل المكتبة
• من الصعب إنشاء تطبيقات معقدة لأن استخدام JavaScript له تأثير سلبي على أداء التطبيق.

رد الفعل الأصلي

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

مزايا:

• سير العمل والأدوات الموحدة: لا يهم ما إذا كنت تعمل على إصدار Android أو iOS، فأنت لا تزال تستخدم نفس الأدوات.
• لهذا السبب - سرعة وسهولة التطوير.
• ربط تطبيق قديم بواجهة برمجة تطبيقات JS والتطبيقات الهجينة: لنفترض أن لديك بالفعل تطبيق iOS جاهزًا وتريد التبديل إلى React Native. بعد ذلك يمكنك تغليف المكونات الأصلية بحيث تكون متاحة في React Native. لذلك يمكنك الانتقال تدريجيًا إلى React، والنتيجة هي تطبيق مختلط - نصفه أصلي ونصفه الآخر في React وبعض المكونات القديمة في JS API.