مع الزيادة السريعة للبرامج الصغيرة على المنصات الرئيسية ، واجه المطورون المزيد والمزيد من مشاكل التكيف مع النظام الأساسي. تختلف طرق تحسين أداء التطبيقات على الأنظمة الأساسية المختلفة أيضًا ، كيف يجب أن نستجيب؟ شارك DCloud CTO Cui Hongbao "الاتجاه المستقبلي للبرامج الصغيرة" في مؤتمر GMTC Shenzhen 2019 (مؤتمر التكنولوجيا الأمامية الكبيرة العالمية) ، وقدم البنية التقنية للبرنامج الصغير ، ونقاط بطاقة الأداء وحلول التحسين لكل نظام أساسي. وفيما يتعلق بالتغيرات التكنولوجية المستقبلية للبرامج الصغيرة ، اقترح اتجاه التطوير المحتمل للبرامج الصغيرة في المستقبل. هذه المقالة مرتبة حسب محتوى الخطاب.

أعرض نفسي لفترة وجيزة ، مزارع في منتصف العمر ، مخضرم في التنمية عبر المنصات. في العصر الذي كان فيه هاتف موتورولا الصدفي متقدمًا وعصريًا ، بدأت في المشاركة في إدارة R & D عبر الأنظمة الأساسية "windows mobile / j2me / symbain" وأنظمة أخرى. ربما لم يشاهد العديد من الطلاب هذه الهواتف المحمولة. في الحقبة الأخيرة من الإنترنت عبر الهاتف النقال والعصر الحالي للبرامج الصغيرة ، شاركت أيضًا بعمق في إخراج محرك "التطبيق الهجين" ومكتبة واجهة المستخدم الأمامية (mui) وإطار التطوير الشامل للبرامج الصغيرة (uni-app). يشغل حاليًا منصب CTO في DCloud وأيضًا بصفته الشخص المسؤول عن منتج "uni-app".

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

1. تاريخ التطبيقات الصغيرة

تم إنشاء HTML5 في W3C في 2007 وتم إصداره في نفس العام مثل iPhone.

توقع جوبز أن يساعد HTML5 iPhone على بناء نظام بيئي للتطبيق. ومع ذلك ، فإن سرعة تطوير HTML5 ليست كما هو متوقع ، على الرغم من أنها نجحت في كسر احتكار IE + Flash ، إلا أنها لم تصل إلى نقطة استضافة تجربة إنترنت ممتازة للجوال.

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

يعلم الجميع أن جانب الهاتف المحمول هو بشكل رئيسي iOS و Android. في الواقع ، كانت هناك ثلاث مسابقات نظام رئيسية في الأيام الأولى. وأخرى هي نظام MeeGo من Nokia. تعتمد MeeGo الاستراتيجية البيئية للتطبيق ثنائي الوضع C + HTML5. ومع ذلك ، كان تطوير C صعبًا للغاية ، ولم تكن تجربة HTML5 جيدة ، لذلك تم ترك MeeGo في الخلف ؛ في المقابل ، يعتمد Android على بيئة تقنية Java للتميز عن المنافسة.

لذلك في الأيام الأولى من الإنترنت عبر الهاتف النقال ، تم تعيين بيئة التطبيق على تطوير النغمة الأصلية.

هناك عدد من الشركات المصنعة للمتصفحات في الصين تحاول تحسين HTML5. على سبيل المثال ، أصدرت Baidu تطبيقًا خفيفًا في Baidu World Congress في عام 2013. من خلال توسيع القدرات الأصلية لـ WebView وتكملة JS API ، يمكن لتطبيقات HTML5 تحقيق المزيد من الوظائف.

إن قمة هذا النوع من تطوير الأعمال هي WeChat JS SDK الذي أصدرته WeChat في أوائل عام 2015. وباعتباره أكبر متصفح محمول في الصين ، فقد وسع WeChat عددًا كبيرًا من واجهات برمجة تطبيقات JS الأساسية للمتصفح ، مما سمح للمطورين باستخدام WeChat للدفع مقابل WeChat وشفرة المسح الضوئي والعديد من الميزات الأخرى التي لا يمكن لـ HTML5.

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

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

وضع Multi-WebView ، والاستيلاء على الرسوم المتحركة الانتقالية ، والتحديث المنسدل ، وترحيل علامات التبويب ، و WebView الذي تم تحميله مسبقًا ... تستمر تقنيات التحسين المختلفة في التكرار ، وتتيح أخيرًا للتطبيق المختلط تحقيق اختراق في تجربة الأداء.

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

يحتاج تطبيق C / S فقط إلى الحصول على بيانات JSON عبر الإنترنت في كل مرة يتم فيها تحميل الصفحة ؛ بينما يحتاج تطبيق B / S إلى تحميل صفحة DOM والنمط ورمز المنطق من الخادم في كل مرة بالإضافة إلى بيانات JSON ، لذا فإن تطبيق B / S يتم تحميل الصفحة ببطء وتكون التجربة ضعيفة.

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

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

تمامًا مثل بث الوسائط أثناء التشغيل ، يمكن أيضًا استخدام التطبيقات أثناء التشغيل.

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

التالي هو برنامج WeChat الصغير. كان الاسم الأصلي في الواقع رقم تطبيق WeChat ، والذي أعيدت تسميته لاحقًا إلى التطبيق الصغير. تم اختباره داخليًا في سبتمبر 2016 وتم إصداره رسميًا في يناير 2017. بعد ذلك ، Alibaba ، تحالف الشركة المصنعة للهواتف المحمولة ، Baidu ، و Toutiao ، أطلقت منصة البرامج الصغيرة الخاصة بها ، وعصر البرامج الصغيرة يتدحرج.

في سبتمبر 2018 ، أطلق WeChat تطوير السحابة ، والذي نعتقد أنه عقدة مهمة في تاريخ تطوير البرامج الصغيرة. فهو يسمح لمهندسي الواجهة الأمامية بتنفيذ جميع الحلقات التجارية المغلقة من الأمام إلى الخلف ، مما يقلل من تكاليف الاتصالات وتكاليف العمالة وتشغيل وصيانة الأطراف الأمامية والخلفية. التكلفة هي ترقية رئيسية لنموذج التطوير. مقارنة بزملاء الدراسة السابقين ، يمكن كتابة واجهة المستخدم الأمامية من خلال JS / CSS ويمكن كتابة الأعمال الخلفية من خلال "Node.js". وبالمقارنة مع ما يسمى بنموذج التطوير الكامل المكدس ، فإن تطوير السحابة له مزايا أفضل لأن زملاء الصف الأمامي لا يزال هناك نقص في الخبرة في تحسين DB ، والتوسع المرن ، والحماية من الهجوم ، ومعالجة التعافي من الكوارث ، وما إلى ذلك ، ولكن تطوير السحابة يلف هذه ، ويركز حقًا فقط على تنفيذ الأعمال ، ويعهد آخرون بخدمات السحابة.

الثانية ، بنية البرنامج الصغيرة

تعد هذه بنية تصميم عام نسبيًا نسبيًا. في الوقت الحالي ، يتشابه تصميم العديد من معماريات التطبيق الصغير تقريبًا (الفرق بين التطبيقات السريعة هو أن طبقة العرض لها عرض محلي فقط).

يعلم الجميع أن التطبيق الصغير هو بنية عرض منطقية منفصلة للطبقة.

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

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

يتم تشغيل الطبقة المنطقية أخيرًا في بيئة JS CORE أو V8 ؛ JS CORE ليست بيئة DOM أو بيئة عقدة. لا يمكنك استخدام كائنات DOM أو BOM في JS. كل ما يمكنك الاتصال به هو المواصفات القياسية ECMAScript. طرق.

ماذا لو كنت تريد إرسال طلب شبكة؟ window.XMLHttpRequest غير متاح (بالطبع ، حتى إذا كان من الممكن تسميته ، فهناك قيود أكثر صرامة عبر النطاقات في WKWebView لنظام التشغيل iOS ، والتي ستسبب مشاكل). في الوقت الحالي ، يجب إرسال طلب الشبكة من خلال وحدة الشبكة الأصلية. بين JS CORE والأصل ، يلزم JS Bridge هذا للتواصل.

ثالثا ، حفر الأداء التي تسببها الهندسة المعمارية

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

1. طبقة المنطق / عرض حجب طبقة الاتصال

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

إذا كنت ترغب في تحقيق انزلاق سلس على هيكل البرنامج الصغير ، فمن الصعب جدًا ، لماذا؟

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

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

لكنها جلبت أيضًا عيوبًا واضحة:

لا يمكن تشغيل JS في طبقة العرض (WebView) ، ولا يمكن لـ JS في الطبقة المنطقية تعديل صفحة DOM مباشرة. يمكن أن يعتمد تحديث البيانات ونظام الأحداث فقط على الاتصال بين سلاسل المحادثات ، ولكن تكلفة الاتصال عبر سلاسل المحادثات عالية للغاية ، خاصة في السيناريوهات التي تتطلب اتصالًا متكررًا.

استنادًا إلى هذا التصميم المعماري ، نعود إلى "swipeaction" ونحلل عملية اللمس ، وهي عملية الاستجابة الداخلية للبرنامج الصغير:

(1) عندما يسحب المستخدم عنصر القائمة ، يتم تشغيل حدث touchmove بواسطة طبقة العرض ، ويتم نقل الطبقة المنطقية عبر الطبقة الأصلية (لا يتم توصيل الطبقة المنطقية وطبقة العرض مباشرة ، ويكون النقل الأصلي مطلوبًا) ، أي الخطوتين و في الشكل أدناه ؛

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

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

لحل مشكلة ازدحام الاتصالات هذه ، تقدم العديد من التطبيقات الصغيرة تدريجيًا حلولاً مقابلة ، مثل WeChat WXS و Alipay SJS و Baidu Filter ، ولكن كل برنامج صغير يدعم مواقف مختلفة. راجع الجدول أدناه للحصول على التفاصيل.

بالإضافة إلى ذلك ، فإن "الرسوم المتحركة ذات الإطارات الرئيسية" لـ WeChat و Lottie الرسوم المتحركة "عرض الرسوم المتحركة" لـ Baidu هي أيضًا طريقة لتقليل الاتصال المتكرر.

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

كما نعلم جميعًا ، فإن JS-Native Bridge المستخدم في الجزء السفلي من "Weex" ، يجعل هذا الجسر الاتصال بين JS و Native لديه خسارة ثابتة في الأداء.

مع الاستمرار في أخذ "swipeaction" أعلاه كمثال ، لتحقيق انزلاق قائمة عناصر القائمة ، اتبع تقريبًا العملية التالية:

(1) ربط أحداث اللمس (أو أحداث التدوير) بطريقة عرض واجهة المستخدم ؛

(2) عندما يتم تشغيل الإيماءة ، تمرر طبقة واجهة المستخدم الأصلية حدث الإيماءة إلى طبقة منطق JS عبر الجسر ، مما ينتج اتصالًا من واجهة المستخدم الأصلية إلى منطق JS ، أي الخطوتين و في الشكل أدناه ؛

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

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

تقدم "ويكس" حل "BindingX" لحجب الاتصالات ، وهي آلية تسمى "Expression Binding".

(1) العرض الذي يستقبل حدث الإيماءة ، ويمثل الإزاحة أثناء الحركة متغيرين "x، y" ؛

(2) وجهة النظر التي من المتوقع أن تتغير (تتبع الحركة) ، وخصائص التغيير هي "translateX" و "translateY" ، ويتم التعبير عن الإزاحة المقابلة للتغيير بواسطة التعبير "f (x)، f (y)"

(3) وصف "سلوك التفاعل" في شكل تعبيرات وتعيينها مسبقًا على طبقة واجهة المستخدم الأصلية مسبقًا ؛

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

مقتطفات من رمز زائف من موقع ويكس الرسمي

رمز النسخ

{مرساة: foo_view.ref // ---- >  هذه إشارة إلى الدعائم "العرض الذي يولد الإيماءة": }

يعاني "React Native" أيضًا من مشاكل متشابهة ، ولتجنب التواصل المتكرر ، فإن النظام البيئي "React Native" له أيضًا حلول مقابلة ، مثل مكونات "Animated" ودعم Lottie للرسوم المتحركة. خذ المكون "Animated" كمثال ، من أجل تحقيق تأثير الرسوم المتحركة على نحو سلس ، يستخدم المكون واجهة برمجة تطبيقات تعريفية ، ويحدد فقط المدخلات والمخرجات وسلوك التحويل المحدد على جانب JS ، والرسوم المتحركة الحقيقية هي من خلال Native Driver في الطبقة الأصلية التنفيذ ، وذلك لتجنب التواصل المتكرر. ومع ذلك ، يمكن أن يحدد النهج التصريحي سلوكًا محدودًا وليس مؤهلاً للسيناريوهات التفاعلية.

يواجه تطبيق "Uni-app" أيضًا مشكلة حظر الاتصالات على جانب التطبيق. الحل الحالي هو استخدام آلية مشابهة لـ WeChat WXS (تسمى داخليًا "Jovjs ") ، ولكنه يخفف من القيود التي تمنع WXS من الحصول على عناصر DOM للصفحة ، مثل ما يلي الرسوم المتحركة القماشية لكرات صغيرة متعددة تتحرك في الصورة في نفس الوقت ، تنفيذ "uni-app" على جانب التطبيق هو:

(1) الحصول على كائن قماش في تصيير ؛

(2) الرسوم المتحركة للرسم على القماش على الويب ، بدلاً من الرسم على القماش الأصلي.

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

يلخص الجدول التالي حلول الإطار الشامل فيما يتعلق بحظر الاتصالات:

2. تحديث فرق البيانات / المكون

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

تحسين أداء تطوير التطبيق الصغير ، جوهر هو استدعاء "setData" ، يمكنك القيام بأمرين فقط:

• استدعاء "setData" بأقل قدر ممكن ؛
• في كل مرة يتم استدعاء "setData" ، يتم تمرير أصغر كمية من البيانات ، أي يتم تحديث فرق البيانات.

(1) تقليل عدد مكالمات setData

لنفترض أننا نحتاج إلى تغيير قيمة المتغيرات المتعددة ، المثال على النحو التالي:

التغيير: الوظيفة () { this.setData ({a: 1}) ؛ ... // منطق الأعمال الأخرى this.setData ({b: 2}) ؛ ... // منطق الأعمال الأخرى this.setData ({c: 3}) ؛ ... // منطق الأعمال الأخرى this.setData ({d: 4}) ؛ }}

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

تحتوي بعض الأطر ثلاثية الأطراف للبرامج الصغيرة على إمكانيات دمج بيانات مضمنة. على سبيل المثال ، يتم تخصيص "uni-app" بعمق في وقت تشغيل Vue. لا يحتاج المطورون إلى الانتباه إلى تكلفة الاتصال لـ "setData". يمكنهم كتابة الرمز التالي بأمان:

التغيير: الوظيفة () { this.a = 1 ؛ ... // منطق الأعمال الأخرى this.b = 2 ؛ ... // منطق الأعمال الأخرى this.c = 3 ؛ ... // منطق الأعمال الأخرى this.d = 4 ؛ }}

كما هو الحال في المهام الأربعة المذكورة أعلاه ، سيتم دمج تطبيق uni-app تلقائيًا في سجل "{" a ": 1،" b ": 2،" c ": 3،" d ": 4}" عند الاستدعاء ، واستدعاء "setData" مرة واحدة لإكمال تقلل جميع عمليات نقل البيانات بشكل كبير من تكرار مكالمات setData ، والنتائج هي كما يلي:

لتقليل عدد مكالمات "setData" ، هناك نقطة أخرى: يجب أن تتجنب صفحات الخلفية (الصفحات غير المرئية للمستخدمين) استدعاء "setData".

(2) تحديث فرق البيانات

لنفترض أن لدينا سيناريو "صفحة قائمة + تحميل سحب للأعلى" ، فإن عنصر القائمة الأولي هو "item1 ~ item4" ، بعد أن يسحب المستخدم لإضافة 4 سجلات جديدة "item5 ~ item8" إلى القائمة ، يكون رمز البرنامج الصغير كما يلي:

الصفحة ({ البيانات: { قائمة: } ، التغيير: الوظيفة () { السماح newData = ؛ this.data.list.push (... newData)؛ // رقم قياسي جديد لعنصر القائمة this.setData ({ قائمة: this.data.list }) }} })

كما هو موضح في الكود أعلاه ، عند تنفيذ طريقة التغيير ، سيتم إرسال جميع عناصر البند "item1 ~ item8" في القائمة من خلال "setData" ، لكن بيانات التغيير الفعلية هي فقط "item5 ~ item8".

في هذا السيناريو ، يجب على المطورين حساب الفرق وتمرير البيانات التي تم تغييرها فقط من خلال "setData". وفيما يلي عينة من التعليمات البرمجية:

الصفحة ({ البيانات: { قائمة: } ، التغيير: الوظيفة () { // الحصول على فهرس العرض التالي حسب الطول let index = this.data.list.length؛ السماح newData = ؛ السماح newDataObj = {}؛ // البيانات المتغيرة newData.forEach ((item) = >  { newDataObj = item؛ // التحكم بدقة في محتوى التغيير من خلال القائمة الثانوية }) ؛ this.setData (newDataObj) // تعيين بيانات الاختلاف }} })

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

هنا ، يوصى بأن يختار المطورون أطر عمل تطبيقات خارجية ناضجة ، والتي قامت تلقائيًا بتجميع حسابات البيانات التفاضلية وأكثر ملاءمة للمطورين. على سبيل المثال ، تعتمد "uni-app" على مكتبة "westore JSON Diff". قبل استدعاء setData ، ستقارن البيانات التاريخية أولاً بحساب بيانات الاختلافات مع التغييرات بدقة وكفاءة ، ثم استدعاء setData لنقل البيانات التي تم تغييرها فقط. هذا يقلل من كمية البيانات المنقولة ويحسن أداء الاتصالات. التالي رمز عينة:

تصدير الافتراضي { البيانات () { إرجاع { قائمة: }} } ، طرق: { التغيير: الوظيفة () { السماح newData = ؛ this.list.push (... newData) // التعيين المباشر ، يقوم الإطار تلقائيًا بحساب بيانات الاختلاف }} }} }}

تلميحات: عند تنفيذ طريقة التغيير أعلاه ، سيتم إرسال عناصر القائمة الأربعة المضافة حديثًا "item5 ~ item8" في القائمة في الماضي ، مما يحقق إرسالًا مبسطًا للغاية لمجموعة البيانات.

(3) تحديث فرق المكون

الصورة التالية هي لقطة شاشة لقائمة Weibo:

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

كيفية تحقيق أداء أعلى يحب ويبو؟ هذا في الواقع سيناريو نموذجي لتحديثات المكونات.

يجب أن تكون الطريقة المناسبة هي تغليف كل Weibo في مكون. بعد أن يحبه المستخدم ، احسب فقط بيانات الاختلاف ضمن نطاق المكون الحالي (يمكن فهمه على أنه يتم تقليل نطاق Diff إلى 1/200 من الأصل) ، بحيث تكون الكفاءة أطول.

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

3. التقديم الهجين

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

تنقسم المكونات الأصلية في التطبيقات بشكل أساسي إلى ثلاث فئات من حيث الاستخدام:

• تم إنشاؤها من خلال عناصر التكوين: علامات التبويب وشريط التنقل والتحديث المنسدل.
• تم إنشاؤها بواسطة اسم المكون ، مثل: الكاميرا ، لوحة الرسم ، الإدخال ، المشغل المباشر ، الدافع المباشر ، الخريطة ، منطقة النص ، الفيديو ؛
• تم إنشاؤها من خلال واجهة API ، مثل: showModal ، showActionSheet ، إلخ.

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

(1) لماذا تقديم التقديم الهجين

السؤال التالي ، لماذا يجب أن نقدم التقديم الأصلي؟ ولماذا يتم توفير التحسينات الأصلية فقط لهذه المكونات القليلة؟ لماذا لم يتم تنفيذ المكونات الأخرى أصلاً؟

يتطلب هذا منا تحليل كل مكون على حدة والتفكير فيه بشكل منفصل. وإليك بعض الأمثلة:

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

عندما يتعلق الأمر بتوطين عنصر تحكم "الإدخال" ، يمكنك التباعد قليلاً.

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

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

(2) المشاكل الناجمة عن العرض المختلط

على الرغم من أن المكونات الأصلية تجلب ميزات أكثر ثراءً وأداءً أفضل ، إلا أنها تطرح أيضًا بعض المشكلات الجديدة ، مثل:

• مشاكل التسلسل الهرمي: الأصلي دائمًا في أعلى مستوى ، لا يمكنك تعيين مستوى العناصر المختلفة من خلال "z-index" ، ولا يمكنك تغطية بعضها البعض بمكونات مدمجة مثل العرض والصورة ، ولا تدعم "عرض منتقي" "عرض التمرير" "swiper" تستخدم في المكونات ؛

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

بالطبع ، لا تواجه جميع البرامج الصغيرة هذه المشكلة. بعض البرامج الصغيرة تنفذ WebView عن طريق تعديل نواة WebView المضمنة. يمكنك أيضًا استخدام خطوط السمة rom ، مثل WeChat و QQ و Alipay ؛ برامج صغيرة أخرى (Baidu ، Toutiao) ، لا يزال لا يمكن تقديم WebView كخط تحت عنوان rom.

(3) خطة تحسين العرض الهجين

الآن بعد أن أصبح العرض الهجين لهذه المشاكل ، ستكون هناك حلول لها. الحلول الحالية هي كما يلي.

• برنامج : إنشاء مكونات عالية المستوى

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

باستثناء ارتداد البايت ، دعمت العديد من البرامج الصغيرة الأخرى "صورة الغلاف / صورة الغلاف".

يخفف view-view / cover-image مشكلة التغطية ذات الطبقات إلى حد معين ، ولكن له أيضًا بعض القيود ، مثل ترتيب التعشيش الصارم.

• برنامج : يزيل الطبقات ويعرض في نفس الطبقة

نظرًا لوجود مشكلة في الطبقات ، قم بإزالة الطبقات والتغيير من الطبقة 2 إلى الطبقة 1. جميع المكونات في طبقة واحدة. أليس "فهرس z" فعالًا؟

من السهل قول هذا الهدف الصغير ، لكن التنفيذ الفعلي لا يزال معقدًا للغاية.

4. تقديم نفس الطبقة

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

الوضع الحالي للبرامج الصغيرة السائدة مع تقديم الويب كمكون رئيسي والعرض الثانوي كمكمل ، كيف يمكن تحقيق تقديم الطبقة نفسها؟

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

(1) منصة iOS

يستخدم التطبيق الصغير WKWebView للعرض على جانب iOS. يستخدم WKWebView العرض الطبقي داخليًا بشكل عام ، يتم دمج عدة عقد DOM في طبقة واحدة للعرض. لذلك ، لا توجد مراسلات بين عقد و طبقات DOM. ومع ذلك ، بمجرد تعيين خاصية CSS لعقدة DOM على "تجاوز السعة: التمرير" ، سيقوم WKWebView بإنشاء WKChildScrollView لذلك ، وقد عالجت نواة WebKit العلاقة الهرمية بين WKChildScrollView وعقد DOM الأخرى. هناك مراسلات فردية مع الطبقة.

يمكن أن تستند نفس الطبقة التي يتم تقديمها على جانب iOS من التطبيق الصغير إلى WKChildScrollView ، وتكون العملية الرئيسية كما يلي:

• قم بإنشاء عقدة DOM وقم بتعيين خاصية CSS الخاصة بها لتجاوز: التمرير ؛
• إعلام الطبقة الأصلية للعثور على مكون WKChildScrollView الأصلي المقابل لعقدة DOM ؛
• قم بتثبيت المكون الأصلي على عقدة WKChildScrollView كعرض فرعي.

(2) منصة أندرويد

يستخدم التطبيق الصغير Chromium كطبقة عرض WebView على جانب Android. بخلاف WKWebView لنظام التشغيل iOS ، يتم تقديمه بشكل موحد ولن يتم وضعه في طبقات. لكن Chromium يدعم آلية WebPlugin. WebPlugin هو آلية مكون إضافي في نواة المتصفح يمكن استخدامها للتحليل " <  تضمين > ". يمكن أن تعتمد نفس طبقة العرض على جانب Android على" <  تضمين > "إضافة ملحق نواة Chromium لتحقيق العملية العامة كما يلي:

• تقوم الطبقة الأصلية بإنشاء مكون أصلي (مثل الفيديو) ؛
• ينشئ WebView " <  تضمين > "العقدة وتحديد نوعها كفيديو.
• تعمل نواة Chromium على إنشاء مثيل WebPlugin * وإنشاء RenderLayer ؛
• ترسم الطبقة الأصلية صورة المكون الأصلي على SurfaceTexture المرتبط بـ RenderLayer ؛
• يجعل Chromium طبقة RenderLayer.

تعادل هذه العملية إضافة مكون إضافي خارجي إلى WebView و " <  تضمين > "العقدة هي عقدة DOM حقيقية ، ويمكن تطبيق المزيد من الأنماط على العقدة.

الرابع ، قد المستقبل

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

1. تجربة مستخدم أفضل

دعني أتحدث عن مشكلة تجربة المستخدم ، بشكل رئيسي في جانبين:

• حل حفر الأداء الحالية ، مثل العناصر التي تم تحليلها أعلاه ، وازدحام الاتصالات ، وقيود الطبقات ، وما إلى ذلك ، والتي لن تتكرر هنا ؛
• دعم المزيد من تجربة التطبيق ، تكوين أكثر حرية ومرونة ، على سبيل المثال ، Gaussian blur.

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

تم إصدار تطبيق uni-app إلى جانب التطبيق ، وهو في الواقع محرك برنامج صغير كامل. سيفتح DCloud المحرك بالكامل في المستقبل القريب. مرحبًا ببناء منصة التطبيق الخاصة بك على أساس التطبيق الصغير appi appk.

يتميز التطبيق الصغير أحادي التطبيق SDK بالخصائص التالية:

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

2. كفاءة التطوير

يجب تحليل كفاءة التطوير من بعدين: عبر السحاب وعبر السحابة.

(1) التنمية الشاملة

تتميز البرامج المصغرة الحالية بسمات مصنّعة واضحة ، ويختلف كل مصنع عن الآخر. على سبيل المثال ، لدى علي مجموعات متعددة من البرامج الصغيرة (Alipay و Taobao و Nail وما إلى ذلك) ، ولكن لحسن الحظ ، تم توحيد Ali بشكل أساسي. ومع ذلك ، تحت نظام Tencent ، لا تزال تطبيقات WeChat و QQ فريقين ومجموعتين من المواصفات.

كان التطبيق الصغير سابقًا على الهاتف المحمول. في عام 2019 ، تم إصدار التطبيق الصغير للكمبيوتر الشخصي في 360.

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

كل شيء ممكن.

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

في مواجهة العديد من منصات البرامج الصغيرة وحركة مرورها الضخمة الواردة ، كيف يستجيب المطورون؟

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

(2) التنمية عبر السحابة

بمساعدة "uni-app" أو غيرها من أطر العمل الشاملة ، يمكن للمطورين تطوير جميع التطبيقات الأمامية. لكنها لا تزال بحاجة إلى توظيف مطورين خلفيين مثل PHP أو Java ، والتي لديها كل من تكلفة الموظفين الخلفيين وتكلفة الاتصالات الأمامية / الخلفية.

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

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

خامسا - ملخص

استنادًا إلى الحالة الحالية للبرامج الصغيرة ، قد نتمكن من تلخيص الاتجاهات المحتملة لتقنية التطبيق الصغير:

تسمح الفجوة بين البرامج الصغيرة الأخرى و WeChat للمطورين بتقديم خدمات تطبيقات عالية الأداء ؛

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

يجعل الإطار الشامل + Serverless المطورين أسهل والشركات أكثر كفاءة.

نبذة عن الكاتب: قام Cui Hongbao ، DCloud CTO ، رئيس فريق Uni-App ، بتطوير مشروعين رائجين بعشرات الآلاف من Github Star. مع أكثر من 10 سنوات من الخبرة في إدارة البحث والتطوير ، لديه خبرة عملية واسعة في المحركات عبر الأنظمة الأساسية وواجهة المستخدم الأمامية وتحسين أداء البرنامج الصغير.