سؤال

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

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

هل كانت مفيدة؟

المحلول

تحتوي معظم لغات البرمجة على وظيفة "نوم" يمكنك الاتصال بها لجعل البرنامج يتوقف عن فعل الأشياء.

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

قد يكون من الأفضل إعداد بعض الوظائف المتكررة. لا أعرف كيفية القيام بذلك ، لكنني أظن أن هناك طريقة مع مضيف البرمجة النصية Windows لبدء تطبيقك فقط على أي جدول تريده.

نصائح أخرى

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

بدلاً من ذلك ، يمكنك إنشاء مهمة مجدولة تعمل بشكل دوري للقيام بذلك.

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

لذا اكتب حدث المؤقت الخاص بك مثل هذا:

OnMyTimer...
begin
  MyTimer.Enabled := false;
  try
    DoSomethingForALongTime;  // Usually runs in 45 seconds, but sometimes takes 45 minutes!
  finally
    MyTimer.Enabled := true;  // and (SomeAbortRequest = False) and (SomeHorribleErrorCount = 0);  
  end;
end;

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

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

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

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

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

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

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

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

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

تجنب العائد ()/switchTothRead () وحفظ الوقت الخاص بك (باستخدام الآن () على سبيل المثال) لأن ذلك يعني أن الكثير من تبديل مؤشرات الترابط يحدث ، على فعل .... لا شيء!

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top