وقت بدء تشغيل التطبيق

مقدار الوقت المطلوب لبدء التطبيق يمكن أن يختلف بشكل كبير. يصف هذا الموضوع أساليب مختلفة لتقليل وقت البدء الملاحظ و الفعلي لتطبيق Foundation العرض تقديمي لـ Windows "(WPF).

فهم البدء cold و البدء warm

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

يحدث البدء السريع عندما يتم تحميل معظم الصفحات الرئيسية تكون مكونات وقت التشغيل (CLR) الشائعة في اللغة بالفعل في الذاكرة والذي يحفظ وقت وصول القرص الثمين. ولهذا التطبيقات المدارة تبدأ بشكل أسرع عند تشغيلها مرة ثانية.

تنفيذ شاشة البداية

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

يمكنك أيضاً تنفيذ شاشة البداية الخاصة بك باستخدام رسومات Win32 الأصلية. اعرض التطبيق قبل استدعاء أسلوب Run.

تحليل رمز بدء التشغيل

تحديد سبب بدء بطيء هادئ. قد يكون قرص I/O مسؤولاً ولكن ليس دائماً. بشكل عام، يجب تقليل استخدام موارد خارجية، مثل شبكة خدمات ويب أو القرص.

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

ابدأ تشغيل التطبيق الخاص بك فوراً بعد إعادة التمهيد, و تحديد المدة التي تستغرقها للعرض. في حالة بدء تشغيل التطبيق الخاص بك فى كافة المرات اللاحقة (البدء الدافئ) تكون أسرع, مشكلة البدء الهادئ الخاص بك غالباً يكون بسبب I/O.

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

تحسين تحميل الوحدة النمطية

استخدام أدوات مثل المستكشف (Procexp.exe) و Tlist.exe لتحديد الوحدات النمطية التي تقوم بتحميل التطبيق الخاص بك. الأمر Tlist <pid> يُظهر كافة الوحدات النمطية الموجودة المحملة بواسطة عملية ما.

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

إذا كان لديك وحدات نمطية متعددة قم بدمجهم في وحدة نمطية واحدة. تتطلب هذه الطريقة أقل تحميل لتجميع CLR. مركبات أقل تعني أيضًا أن يحتفظ CLR بحالة أقل.

عمليات ما بعد التهيئة

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

كن على علم أنه قد يتم تنفيذ التهيئة داخل مُنشئ فئة و إذا كانت التعليمات التهيئة البرمجية تراجع للفئات الأخرى, قد يؤدي إلى تأثير متتالي على العديد من مُنشئات فئة التى يتم تنفيذها.

تجنب تكوين التطبيق

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

استخدام GAC

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

استخدام Ngen.exe

خذ بعين الاعتبار استخدام "منشئ الصورة الأصلي" (Ngen.exe) على تطبيقك. يعني استخدام Ngen.exe استهلاك CPU التجاري للحصول على مزيد من الوصول إلى القرص لأنه غالباً ما تكون الصورة الأصلية التي تم إنشاؤها بواسطة Ngen.exe أكبر من الصورة MSIL.

لتحسين وقت بدء التشغيل السريع ، يجب دوماً استخدام Ngen.exe في التطبيق، لأن هذا يتجنب تكلفة CPU للتحويل البرمجي JIT من التعليمات البرمجية للتطبيق.

في بعض وحدات السيناريو الهادئ لبدء التشغيل باستخدام Ngen.exe يمكن أن يكون مفيداً. وهذا لأن مترجم JIT (mscorjit.dll) لا يلزم تحميله.

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

منشئ الصورة الأصلية و ClickOnce

الطريقة التي تخطط إلى نشر يمكن للتطبيق الخاص بك أيضا تأكد من وجود اختلاف في وقت تحميل. ClickOnceنشر التطبيقات لا يعتمد منشئ الصورة الأصلية. إذا قررت استخدام التطبيق Ngen.exe ، يجب استخدام تقنية نشر أخرى مثل Windows Installer.

لمزيد من المعلومات، راجع Ngen.exe (مولد النسخة الأصلي).

اعادة التأسيس و تضاربات عنانوين DLL

إذا كنت تستخدم Ngen.exe يجب أن تدرك أن اعادة التأسيس تحدث عندما يتم تحميل الصور الأصلية في الذاكرة. إذا لم يتم تحميل DLL في العنوان الأساسي المفضلة الخاصة به، سيكون بالفعل تم تخصيص عنوان النطاق، سوف يقوم محمّل بتحميله في عنوان آخر يمكن أن تكون عملية وقتاً.

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

للحصول على مزيد من المعلومات حول كيفية تعيين العنوان الأساسي, راجع Ngen.exe (مولد النسخة الأصلي).

أمثلية المصادقة

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

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

بدء تشغيل في .NET Framework 3.5, هناك خيار تكوين يسمح التحقق من صحة رمز المصادقة لكى يمكن التجاوز. للقيام بهذا، أضف الإعداد التالي إلى ملف app.exe.config:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/> 
    </runtime>
</configuration>

لمزيد من المعلومات، راجع <generatepublisherevidence>العنصر.

مقارنة الأداء على Windows Vista

لدى إدارة الذاكرة في نظام التشغيل Windows Vista تقنية تسمى SuperFetch. يحلل superFetch أنماط استخدام الذاكرة بمرور الوقت لتحديد محتوى الذاكرة الأمثل لمستخدم معين. يعمل بشكل مستمر للمحافظة على المحتوى في كافة الأوقات.

يختلف هذا الأسلوب عن تقنية pre-fetch المستخدمة في Windows XP الذي يحمل مسبقاً إلى الذاكرة بدون تحليل أنماط الاستخدام. بمرور الوقت إذا كان يستخدم المستخدم الخاص بك التطبيق بشكل متكرر على نظام التشغيل Windows Vista لتحسين وقت بدء التشغيل الهادئ للتطبيق الخاص بك.

استخدام كفاءة AppDomains

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

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

استخدام سمة NeutralResourcesLanguage

استخدام NeutralResourcesLanguageAttribute لتحديد الثقافة المحايدة للحصول ResourceManager. يتجنب هذا الأسلوب عمليات البحث الغير ناجحة.

استخدم فئة BinaryFormatter لـإنشاء تسلسل

إذا كان من الضروري استخدام إنشاء تسلسل ، استخدام فئة BinaryFormatter بدلاً من XmlSerializer. يتم تطبيق فئة BinaryFormatterفى لقاعدة فئة مكتبة (BCL) في تجميع mscorlib.dll. XmlSerializer يتم تطبيقه في التجميع System.Xml.dll التي قد تكون DLL إضافية للتحميل.

إذا كان من الضروري استخدام فئة XmlSerializer، يمكنك تحقيق أداء أفضل حالة إجراء الإنشاء المسبق لتجميع التسلسل.

تكوين ClickOnce ليتم التحقق من وجود تحديثات بعد بدء التشغيل

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

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

تكوين خدمة PresentationFontCache ليبدأ تلقائياً

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

تعيين ربط البيانات برمجياً

بدلاً من استخدام XAML لتعيين DataContext بشكل إلزامي للإطار الرئيسي، خذ بعين الاعتبار التعيين برمجيًا في أسلوب OnActivated .

راجع أيضًا:

المهام

كيفية القيام بما يلي: إضافة شاشة البداية إلى تطبيق WPF

المرجع

SplashScreen

AppDomain

NeutralResourcesLanguageAttribute

ResourceManager

Ngen.exe (مولد النسخة الأصلي)

<generatepublisherevidence>العنصر