⌛ خلاصة الوقت

تحدثت في مدونتي الأخيرة عن كيفية تقليل حجم تطبيقي من 75 ميجابايت إلى 34 ميجابايت في أسبوعين فقط (عرض!). ولكن هذا ليس كل شيء، لقد قمت أيضًا بتحسين الأداء العام لتطبيقنا بنسبة تصل إلى 80%؟.

دعونا نكتشف كيف !!

؟ المعرفة

بعد جولة بسيطة من التجول، اكتشفت عددًا قليلاً من المشكلات ذات المستوى الأعلى في تطبيقنا والتي تؤدي إلى تجربة مستخدم سيئة وأداء منفرد. يا له من يوم!

• الشرير الرئيسي - تجميد واجهة مستخدم التطبيق بالكامل أثناء إنشاء استجابة في الوقت الفعلي

• الشرير الجانبي - وقت استجابة بطيء ولا توجد معدلات إطارات

• عاشق الشرير - عدد كبير جدًا من مكالمات API

• الجيش الموتى الأحياء - معالجة سيئة للأخطاء والأعطال

• المعاناة - المزيد من استخدامات وحدة المعالجة المركزية وتكاليف الخادم

• المشوه - ME !

ومن هنا تبدأ معركة لا حياة فيها لإعادة خلق الكون بأمل عالم أفضل.

خطة تاهيتي (لكنها ناجحة هذه المرة)

لذلك بدأت بمعالجة المشكلات الأسهل أولاً لأنه من السهل تجاهل الكساد الكبير بدلاً من محاربته في الوقت الحالي.

1. ⚛️ لعنة التفاعل

حكمة وعنة ReactJs هي الحالات. مع تقدمنا ​​في العمر في React، ندرك أن الحالات الأقل تكون أفضل للتطبيق. ومن ثم، كانت هذه القطعة الفنية تحديدًا تستخدم 22 حالة (نعم، 22 حالة استخدام) في شاشة دردشة واحدة حيث كل ما يمكنك فعله هو إرسال رسالة واستلامها.

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

لذلك، إذا كنت تعرف الرياضيات، 100*22 = 2200 إعادة عرض في كل مرة نحصل فيها على رد.

هل يجب أن أشرح أكثر؟ ( لا )

لذلك بدأت في إعادة إنشاء الشاشة بأكملها وقمت بإنزال الرقم إلى 6 حالات الآن. مع وظائف أفضل وسلسة كما كان من قبل.

هذا أكثر أداء بنسبة 72% من السابق !!

2. ❄️ الصحراء المتجمدة

الآن بعد مشاهدة Radahn of React، يمكننا أن نستنتج بسهولة أن التطبيق سوف يتجمد كثيرًا، أليس كذلك؟

الآن حتى مع وجود 6 حالات، تظل المشكلة الرئيسية كما هي وهي 100*6. ما زلنا معلقين ولكن مع عدد أقل من الولايات.

كان السبب الرئيسي هو تحديث React dom في كل قطعة. لذا لمعالجة هذه المشكلة استخدمنا "معالجة الدُفعات وإنشاء معدلات الإطارات.

الجحيم نعم!

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

لقد التقطنا مجموعة محدودة من القطع دفعة واحدة واحتفظنا بالاستجابة حتى يتم تحرير الإطار وكررنا نفس الشيء حتى تتم معالجة جميع القطع.

وبالتالي بدلاً من تحديث DOM 100 مرة، قمنا بتحديث DOM 3-4 مرات فقط.

الآن قم بإجراء العمليات الحسابية واحسب تحسين أداء الواجب المنزلي!

3. ؟ كن مستمعا جيدا!

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

تعد Apis طريقة رائعة ورائعة للحصول على البيانات ولكن استخدامها بحكمة هو مهارة خاصة بك! الآن كان هذا التطبيق يستخدم واجهة برمجة التطبيقات هذه للحصول على حالة المستخدم من الواجهة الخلفية. ولكن الجزء الأفضل هو أنه كان يستخدمه كل 3 ثوانٍ!!

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

أ) الجلب

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

بدلاً من الحصول على 100 طلب من 100 مستخدم، ستحصل الخدمة على 100 طلب من مستخدم واحد. لا يبدو لي قابلاً للتطوير وموثوقًا للغاية.

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

ب) تدفق البيانات

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

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

نقطة للتذكر!

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

ليس فقط للواجهة الخلفية ولكن للواجهة الأمامية أيضًا، فإن إجراء مكالمات إضافية لواجهة برمجة التطبيقات (API) يجعلها تستهلك المزيد من النظام حيث يتعين عليها إجراء المزيد من مصافحات وبروتوكولات HTTP في كل مرة تقوم فيها بإجراء مكالمة.

3. ؟ إنه ليس خطأ إذا لم نعترف به!

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

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

4. ؟ ذكرياتها

Gottacha هومي! إنها لن تعود ولكن تسرب الذاكرة سوف يعود. أحد الأشياء الرئيسية التي ننساها أثناء إرفاق أي مستمع أو استدعاء Api هو إزالة مثيله بعد إغلاق هذا النشاط.

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

التنظيف الصحيح لهذه العناصر يجعل التطبيق أكثر سرعة وأقل تجاوزًا للعنوان.

5. إعلان الأداء

الآن الطريقة الأساسية لاستخدام أي أصل هي استيراده واستخدامه بشكل صحيح؟

ولكن هل تعرف كيف يعمل؟ في كل مرة تقوم فيها باستيراد عنصر بشكل افتراضي، يتم تخصيصه في الذاكرة من خلال التهيئة. لذلك، إذا قمت باستيراد صورة أو مكون والإعلان عنها في 5 ملفات مثل هذا

import Profile from '../../profile'

سيتم إنشاء 5 مثيلات لنفس الشيء!

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

وبالتالي تقليل استخدام الذاكرة إلى 4/5.

✅ الخلاصة -

أنت رجل طيب آرثر! (عذرًا، لقد أكملت للتو RDR2 وكانت لعبة رائعة جدًا).

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

ارتفع تقييم المتجر من 3.5 إلى 4.1 خلال أسبوع واحد فقط من الاستخدام !!!

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

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

؟ قم بإسقاط التعليقات إذا أعجبتك المدونة، أو شاركها مع أصدقائك لتسمح لهم بالاستمتاع بها أيضًا!