تحسين الأداء باستخدام مصادر البيانات
في الوحدة السابقة، تعلمت أن مصادر البيانات هي غالباً السبب الرئيسي لبطء أداء تطبيقك. وفي هذه الوحدة، تتعرّف على بعض التقنيات الشائعة التي يمكنك تطبيقها للحد من مشكلات الأداء هذه.
استخدام المجموعات لتخزين البيانات مؤقتاً
في تطبيقك، تجد نفسك تستعلم عن البيانات نفسها بشكل متكرر، كما فِي حالة سحب قوائم الأقسام الخاصة بالقوائم المنسدلة لديك. وفي تلك الحالات، يمكنك الاستعلام عن البيانات مرة واحدة ثم إعادة استخدام تلك البيانات على مدى التطبيق. ويؤدي ذلك إلى تقليل تكرار الاستدعاءات لمصدر البيانات عبر الشبكة. الشكل التالي هو مثال لهذه العملية.
في التطبيق الخاص بك، يتوفر لديك العديد من الشاشات التي تقوم فيها بتوفير قائمة منسدلة لتحديد القسم. ويتم الاحتفاظ بقائمة الأقسام فِي Microsoft Dataverse فِي جدول يسمى DepartmentList. في كل مثيل من القائمة، تَستخدم الصيغة التالية.
Filter(DepartmentList, Status = "Active")
يعمل هذا الإجراء ويتميز بأداء جيد.
عند الانتهاء من التطبيق، تدرك أنك تقوم بالاستعلام فِي جدول DepartmentList عدة مرات على الرغم من أنها معلومات ثابتة. يمكنك تعديل تطبيقك لإنشاء مجموعة بها الخاصية OnStart للتطبيق الذي يخزِّن المعلومات باستخدام الصيغة التالية.
Collect(collectDepartmentList, Filter(DepartmentList, Status = "Active"))
بعد أن قمت الآن بتخزين المعلومات، يمكنك تغيير الخاصية Items لها بعناصر تحكم القائمة المنسدلة لتكون collectDepartmentList بدلاً من Filter(DepartmentList, Status = "Active"). تضيف هذه التغييرات الصغيرة أثراً لزيادة الأداء فِي التطبيق الخاص بك. أيضاً، وحيث تجيد التقنية أكثر، يمكنك إنشاء تطبيقك بهذه الطريقة من البداية، ما يقلل عدد الصيغ التي عليك كتابتها والاحتفاظ بها.
مراقبة التفويض
أحد الأشياء التي يجب وضعها فِي الاعتبار هو أن دالة Collect ليست قابلة للتفويض. ويعني ذلك افتراضياً أن أول 500 عنصر فقط يتم إرجاعها من مصدر البيانات وتخزينها فِي المجموعة. تأكد من التخطيط لهذا القيد أثناء تنفيذك استخدام المجموعات فِي تطبيقك.
ويؤثر التفويض أيضاً على الأداء
عند تعرفك على التفويض، فإنك قد ركزت على إرجاع عدد الصفوف الصحيح لمصدر البيانات. فمن المهم أيضاً تذكر أن التفويض، خصوصاً لتطبيقات الأجهزة المحمولة، يمكن أن يؤثر على الأداء.
عندما يتم تفويض صيغة إلى مصدر البيانات، تتم معالجة جميع العمليات بواسطة مصدر البيانات، ويتم إرجاع الصفوف المطابقة فقط عبر الشبكة إلى التطبيق الذي سيتم عرضه. إذا لم تكن إحدى الدالات قابلة للتفويض، فمن الشائع تغيير حد التفويض إلى 2,000 صف. ويعني هذا أن أول 2000 صف يتم تنزيلها عبر الشبكة ثم معالجتها محلياً. في السيناريوهات التي يكون الاتصال الخليوي فيها لديك بطيء أو يكون الجهاز المحمول منخفض المواصفات، يمكن أن تستغرق هذه المعالجة قدراً زمنياً كبيراً، مما يؤدي إلى مرور المستخدم بتجربة سيئة.
جرِّب استخدام دالات قابلة للتفويض فقط قدر الإمكان. وإذا لم تكن الدالة الخاصة بك قابلة للتفويض، فخطط للأثر على المستخدم النهائي.
استخدام دالة Concurrent لتحميل مصادر بيانات متعددة
لقد سبق أن تعرفت على استخدام المجموعات لتخزين البيانات مؤقتاً فِي تطبيقك. بينما تقوم بتطبيق هذه الدالة فِي تطبيقك، من غير الشائع القيام بتحميل عدة مجموعات عند تشغيل التطبيق. قد تبدو خاصية OnStart على النحو التالي.
Collect(collectDepartmentList, Filter(DepartmentList, Status =
"Active")); Collect(collectCompanyList,
CompanyList);Collect(collectRegions, RegionList)
في هذا المثال، تقوم بإنشاء ثلاث مجموعات، ولكن تتم معالجة المجموعات كلاً على حدة. لذا، إذا استغرقت معالجة كل مجموعة منها 3 ثوان، فيجب أن ينتظر المستخدم 9 ثوانٍ حتى يبدأ تشغيل التطبيق.
تسمح لك دالة Concurrent بمعالجة جميع هذه الاستدعاءات فِي الوقت نفسه. ويمكنك تغيير الكود إلى ما يلي.
Concurrent(
Collect(collectDepartmentList, Filter(DepartmentList, Status = "Active")),
Collect(collectCompanyList, CompanyList),
Collect(collectRegions, RegionList)
)
والآن يتم تشغيل الصيغ الثلاثة فِي الوقت نفسه. تقليل وقت التحميل إلى ثلاث ثوانٍ. دالة Concurrent هي طريقة مثالية لتجنب التأخيرات الطويلة التي تُحدثها الاستدعاءات غير المتزامنة.
ميزات الإصدار الأولي والتجريب
داخل Power Apps، توجد ميزات أخرى ومتقدمة يمكنك تنفيذها فِي تطبيقك. ويمكنك الوصول إليها عن طريق تحديد ملف على شريط القوائم، ثم اختيار إعدادات التطبيق وإعدادات متقدمة. تتغير قائمة الخيارات التي تشاهدها على نحو كبير، ولكن توجد غالباً ميزة أو أكثر ترتبط بالأداء.
ميزات الإصدار الأولى
ميزات الإصدار الأولى هي ميزات تم اختبارها جيداً وتمثل نسخة على وشك الإصدار. وستتوفر لجميع التطبيقات قريباً. يساعدك اختبار هذه الميزات وفهمها فِي الإعداد لحين تصبح قياسية، ومعظمها ممكَّن افتراضياً فِي التطبيقات الجديدة.
وأحد الأمثلة على ميزة الإصدار الأولي الحالية التي تساعد على زيادة الأداء هي حمل "مؤجّل". حيث تعمل هذه الميزة على "تسريع وقت بدء تطبيقك من خلال تعيين استدعاءات تعبيرات الشاشة عند الطلب،" ما يعني أنه لا تتم معالجة الشاشات حتى يصل المستخدم إلى الشاشة، ما يجعل التطبيق يبدأ ويعمل بسرعة أكبر.
الميزات التجريبية
الميزات التجريبية هي ميزات قد تتغير أو تنقطع أو تختفي فِي أي وقت. وهذه الميزات متوقفة عن التشغيل افتراضياً. يمكنك أحياناً العثور على ميزات للأداء ضمن هذه أيضاً؛ لذا فهي تستحق إلقاء نظرة عليها. ولكن، تذكر أنك تخوض مخاطرة بتضمينها فِي تطبيقات الإنتاج؛ إذ يمكن أن تتطور أو تتغير تماماً أو حتى تختفي.
قد ترى فِي بعض الأحيان ميزة تجريبية تتعلق بأداء التطبيق. يمكنك دائمًا تمكينها واختبارها، ثم العودة إلى الإعدادات لتعطيلها.
OnStart مقابل OnVisible
تعد OnStart وOnVisible جزءاً من مجموعة أدواتك لإنشاء تطبيقات رائعة، ولكن من وجهة نظر الأداء، يمكن أن يكون لهما تأثير كبير.
OnStart - هذه خاصية على مستوى التطبيق. يتم تشغيل الصيغ فِي هذه الخاصية مرة واحدة، عند بدء تشغيل التطبيق، ولا يتم تشغيلها بعدئذٍ مطلقاً. يجب معالجة جميع الصيغ قبل فتح التطبيق. ويُستخدم هذا غالباً لتهيئة البيانات التي تحتاجها على مدى التطبيق.
OnVisible - هذه خاصية حسب الشاشة. ويتم تشغيل الصيغ فِي هذه الخاصية فِي كل مرة يتنقل فيها مستخدم إلى الشاشة. ويتم عرض الشاشة قبل انتهاء معالجة الصيغة.
من منظور الأداء، الاعتبار الأساسي هو عند تشغيل الكود. مرة واحدة، أو عند بدء تشغيل التطبيق، أو فِي كل مرة يتم فيها عرض الشاشة. وتعد مجموعة الأقسام السابق ذكرها فِي هذه الوحدة النمطية مثالاً رائعاً. يتم تحميل هذا الكود فِي خاصية OnStart الخاصة بالتطبيق. يعني ذلك أنه يتم تحميله مرة واحدة ثم تكون متوفراً دائماً. إذا قمت بنقل هذا الكود من OnStart إلى OnVisible، فستفقد ميزة المجموعة. إذا كانت الصيغة فِي الخاصية OnVisible، ففي كل مرة ينتقل فيها المستخدم إلى الشاشة، سيتم الاستعلام عن مصدر البيانات. وفي هذه الحالة، سيتم تنفيذه مثل ترك الكود فِي القائمة المنسدلة.
ولا يعني ذلك أنه يجب عدم استخدام OnVisible. تعد OnVisible رائعة للصيغ التي تتعلق بالشاشة الحالية التي عليك تشغيلها. بالإضافة إلى ذلك، فان OnVisible لا تمثل إعاقة. وبذلك لا يضطر المستخدمون إلى الانتظار على الصيغة حتى تنتهي لعرض الشاشة، ما يقلل من الوقت الذي يحتاجه المستخدم لعرض شاشة فارغة.
في معظم التطبيقات، يمكنك استخدام مزيج من OnStart وOnVisible للحصول على أفضل تجربة.
الملخص
كما ترى، يوجد الكثير من الخيارات الخاصة بكيفية إنشاء تطبيقك والتفاعل مع مصادر البيانات. وتعد القائمة التي فِي هذه الوحدة أبعد ما يكون عن الشمول. وتهدف الإرشادات الموجودة هنا إلى إرشادك نحو أداء أفضل، ولكن ربما تختلف النتائج لديك. حين تبدأ تطبيق هذه التقنيات على تطبيقاتك، تتعرّف على أفضل ما يصلح لك ولبيئتك.
في الوحدة التالية، ستتعرّف على تقنيات الاختبار واستكشاف أخطائها وإصلاحها.