تطبيقات تتعطّل عند الاستئناف من السكون ── كيف تعمل أحداث الطاقة وكيف تبني تطبيقات أعمال تصمد أمام الاستئناف

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

بعض تطبيقات الأعمال التقليديّة كُتبت على افتراض أنّ «الحاسوب يبقى شغّالاً». الآن وقد صارت الحواسيب المحمولة مركز العمل اليومي، لا يمكن تجاهل بيئة تنام خلال دقائق إن تُركت. فوق ذلك، الأجهزة التي تدعم Modern Standby تنام بآليّة تختلف عن التقليديّة.

المقال موجَّه إلى المطوِّرين الذين يبنون تطبيقات أعمال وبرمجيّات التحكّم بالأجهزة على Windows. يعرض، من المصادر الأوّليّة، الإشعارات التي يسلِّمها نظام التشغيل، وما ينكسر بعد الاستئناف، وكيف تصمِّم التعافي، وكيف تحقِّق في الميدان، بهذا الترتيب.

1. الخلاصة أوّلاً

مركز التصميم ليس «نظِّف دائماً قبل السكون» بل «كن قادراً على التعافي بعد الاستئناف مهما توقّف الجهاز». ثلاث نقاط للبقاء في الذهن.

• الإشعار المسبق ليس ضماناً أنّك تستطيع الإنهاء. لا يمكن رفض السكون، وفترة السماح لـ PBT_APMSUSPEND نحو ثانيتين. عند تعليق طارئ لا يصل الإشعار أصلاً. وحتّى تحت Modern Standby، لا تفترض أنّ تطبيق سطح مكتب يظلّ يعمل أثناء السكون.¹²³
• صمِّم على افتراض أنّ الاتّصالات والمقابض واستمراريّة الزمن لا تُحفَظ عبر الاستئناف. وجِّه أخطاء الاتّصال، لا إشعار الاستئناف وحده، إلى منطق إعادة الاتّصال نفسه، وراجع أيضاً جداول المؤقِّتات وفروق الزمن المنقضي.
• كبح السكون والاستعداد للاستئناف إجراءان منفصلان. استخدم SetThreadExecutionState أو طلب طاقة لفترات العمل التي تحتاجه، وأزلِه دائماً بعدها. غير أنّه لا يمنع فعل سكون صريح من المستخدم، لذا ليس سبباً لتجاوز منطق التعافي.⁴⁵

يمكنك أيضاً البدء من الفصل الذي يطابق هدفك.

2. ماذا يحدث حول السكون ── تدفّق أحداث الطاقة

يُشعر نظام التشغيل التطبيقات بتغيّرات حالة الطاقة عبر رسالة WM_POWERBROADCAST.² أوّلاً، الأحداث الثلاثة المستخدمة حول انتقال التعليق. كيف يختلف الخمول منخفض الطاقة في Modern Standby مشمول في الفصل 3.

sequenceDiagram
    accTitle: تدفّق إشعارات السكون والاستئناف
    accDescr: يصل PBT_APMSUSPEND قبيل السكون مع نحو ثانيتين سماح؛ وعند الاستئناف يصل PBT_APMRESUMEAUTOMATIC دائماً، ويتبع PBT_APMRESUMESUSPEND فقط لاستئناف بدأه المستخدم
    participant OS as نظام التشغيل
    participant A as التطبيق
    OS->>A: PBT_APMSUSPEND (نحو ثانيتين سماح)
    A->>A: حفظ الحالة وإغلاق الاتّصالات
    Note over OS: السكون (الشيفرة لا تعمل)
    OS->>A: PBT_APMRESUMEAUTOMATIC (يصل عند الاستئناف)
    A->>A: إعادة الاتّصال وإعادة بناء الحالة
    OS->>A: PBT_APMRESUMESUSPEND (استئناف بدأه المستخدم فقط)
    A->>A: تحديثات الشاشة وعمل آخر مواجه للمستخدم

الشكل 1: الإشعارات تعادل «كلمة قبيل ذلك، وكلمة أو اثنتين بعد الاستئناف». معالجة جانب الاستئناف هي ما يقود التعافي.

إشعار ما قبل السكون فرصة «للاستعداد إن وُجد وقت»

PBT_APMSUSPEND الإشعار المسلَّم قبيل دخول السكون. يتيح إغلاق الملفّات وحفظ الحالة، لكنّه يأتي بالقيدين التاليين.

إذن تصميم «يُنهي الحفظ دائماً بعد تلقّي هذا الإشعار» لا يصمد. استخدم الإشعار المسبق للاستعداد بما يلحق في الوقت، وضع جوهر التعافي في جانب الاستئناف.

flowchart TB
    accTitle: الفرق بين السكون العادي والتعليق الطارئ
    accDescr: السكون العادي يسلِّم PBT_APMSUSPEND قبيل ذلك مع نحو ثانيتين للاستعداد، أمّا تعليقاً طارئاً تسبّبه بطاريّة حرجة وما شابه فيتوقّف بلا إشعار مسبق، لذا تصميم يعتمد على الإشعار المسبق لا يصمد
    n2["سكون عادي"] --> pre["PBT_APMSUSPEND (نحو ثانيتين سماح)"]
    pre --> s1["استعد ثمّ توقّف"]
    e2["تعليق طارئ (بطاريّة شبه نافدة)"] --> s2["توقّف بلا إشعار مسبق"]
    s2 -.-> l2["تصميم يفترض أنّ الإشعار سيأتي لا يصمد"]

الشكل 2: التعليق الطارئ يأتي بلا إنذار. لذا الاستعداد «مكافأة إن لحق في الوقت»، والجوهر يذهب إلى جانب الاستئناف.

إشعارات الاستئناف تفصل التعافي الآلي عن العمل المواجه للمستخدم

عند الاستئناف من التعليق، يصل PBT_APMRESUMEAUTOMATIC أوّلاً. إن استأنف الجهاز بسبب زر الطاقة أو ضغطة مفتاح، أو كُشف حضور مستخدم بعد الاستئناف، يتبع PBT_APMRESUMESUSPEND.⁶⁷

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

flowchart TB
    accTitle: تقسيم العمل عبر مرحلتَي الاستئناف
    accDescr: ضع التعافي الآلي كإعادة الاتّصال على PBT_APMRESUMEAUTOMATIC الذي يصل عند الاستئناف؛ وضع العمل المواجه للمستخدم كتحديثات الشاشة أو مطالبة إعادة تسجيل الدخول على PBT_APMRESUMESUSPEND الذي يصل فقط عند استئناف بدأه المستخدم
    ra["PBT_APMRESUMEAUTOMATIC (عند الاستئناف)"] --> m["تعافٍ آلي"]
    rs["PBT_APMRESUMESUSPEND (استئناف بدأه المستخدم)"] --> u["عمل مواجه للمستخدم"]
    m -.-> m1["إعادة الاتّصال وإعادة فتح المقابض"]
    u -.-> u1["تحديثات الشاشة ومطالبة إعادة تسجيل الدخول"]

الشكل 3: الثاني لا يصل عند استئناف بلا مراقبة، لذا وضع التعافي المطلوب على الثاني سيُفوِّته.

التطبيقات بلا نافذة تستطيع تلقّي الإشعارات أيضاً

الخدمات والتطبيقات الطرفيّة بلا نافذة تستطيع استخدام RegisterSuspendResumeNotification مع DEVICE_NOTIFY_CALLBACK وتلقّي الإشعارات نفسها عبر ردّ نداء.⁸

كذلك، لا تستطيع WM_POWERBROADCAST إخبارك هل كانت حالة الطاقة المنخفضة سكوناً أم إسباتاً.⁷ ينبغي للتطبيق تصميم تعافيه حول الحدث المشترك «توقّف، ثمّ عاد».

3. Modern Standby ── معنى «السكون» تغيّر

تشغيل النظام وقدرة التطبيق على التشغيل شيئان مختلفان

سكون S3 التقليدي نموذج يوقف النظام كلّه. Modern Standby، بالمقابل، نموذج شبيه بالهاتف الذكي يظلّ فيه النظام يعمل على فترات بعد انطفاء الشاشة.

غير أنّ ذلك لا يعني أنّ تطبيقات سطح المكتب العاديّة تظلّ تعمل. في المرحلة الأولى من دخول السكون تُوقَف بـ Desktop Activity Moderator (DAM).³

المكوِّنات التي تستفيد من النشاط المتقطّع هي المبنيّة لهذه الآليّة. لتصميم تطبيق أعمال، الخلاصة واحدة في الحالتين: «شيفرتك أنت لا تعمل أثناء السكون».³

flowchart TB
    accTitle: الفرق بين السكون التقليدي وModern Standby
    accDescr: سكون S3 التقليدي يوقف النظام كلّه، بينما تحت Modern Standby يظلّ النظام يعمل على فترات بعد انطفاء الشاشة. غير أنّ تطبيقات سطح المكتب تُوقَف بـ DAM، لذا شيفرة التطبيق لا تعمل في الحالتين
    s3["سكون S3 التقليدي: يتوقّف النظام كلّه"] --> conc["شيفرة التطبيق لا تعمل"]
    ms["Modern Standby: النظام يعمل على فترات"] --> dam["تطبيقات سطح المكتب تُوقَف بـ DAM"]
    dam --> conc

الشكل 4: تغيّر النموذج، لكن لتطبيق سطح مكتب الخلاصة واحدة: «لا تستطيع العمل أثناء السكون».

لا تجعل إشعار الاستئناف المحفِّز الوحيد للتعافي

دخول خمول Modern Standby منخفض الطاقة والخروج منه لا يتطابقان دائماً مع انتقال التعليق التقليدي. قد يكون اتّصال مكسوراً أصلاً دون وصول أيّ إشعار. عامل إشعار الاستئناف عوناً يسرِّع التعافي، وضع في المركز مساراً يعيد الاتّصال عند كشف خطأ اتّصال. البنية الملموسة مشروحة في الفصل 5.

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

4. ما الذي ينكسر ── أعراض كلاسيكيّة

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

اتّصال TCP لا يلاحظ الانقطاع حتّى ترسل أو تستقبل

أثناء السكون يعامل الطرف المقابل وأجهزة NAT وجدران النار صمتك مهلة ويلغي الاتّصال. مقبسُك لا يعلم شيئاً عن ذلك، لذا يفشل فقط عندما ترسل أو تستقبل بعد الاستئناف.

أحياناً لا يُخطئ استقبال معلَّق أصلاً. لذلك تحتاج keepalive للتحقّق ممّا إذا كان الاتّصال حيّاً. اتّصالات قواعد البيانات وWebSockets تتبع النمط نفسه.

المنافذ التسلسليّة وأجهزة USB تحتاج إعادة فتح مقابضها

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

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

راجع العمل الدوري والزمن المنقضي والعمل المجدول كلّاً على حدة

مشكلات الزمن تقع في الأنواع الثلاثة التالية.

العمل الدوري خصوصاً قد يُطلَق مرّة فوراً بعد الاستئناف للنبضة المتأخّرة، أو قد لا يحدث شيء حتّى الفترة التالية. لا تترك معالجة التشغيلات الفائتة للسلوك الضمني للمؤقِّت.

flowchart TB
    accTitle: ثلاثة أشكال ينكسر فيها استمرار الزمن
    accDescr: العمل الدوري يتوقّف أثناء السكون ويختلف الإطلاق بعد الاستئناف حسب الواجهة، لذا أعد بناء الجدول عند الاستئناف؛ وفرق الختم الزمني السابق ينفجر بعد الاستئناف فاحمه؛ والعمل المجدول لا يعمل إن كان الجهاز نائماً فانظر في إيقاظ جدولة المهام
    t1["عمل دوري: يتوقّف أثناء السكون"] -.-> g1["أعد بناء الجدول عند الاستئناف"]
    t2["فرق الزمن المنقضي: ينفجر"] -.-> g2["احمِ من الفروق غير الطبيعيّة"]
    t3["عمل مجدول: نائم، لم يعمل قط"] -.-> g3["أيقظ الجهاز بإعداد إيقاظ"]

الشكل 5: اكتب معالجة المؤقِّت والساعة على افتراض أنّ «الزمن يقفز». لكلّ من الأشكال الثلاثة نوع إجراء مضاد خاصّ.

flowchart TB
    accTitle: ثلاثة أشياء تنكسر عبر السكون
    accDescr: عبر السكون يُلغى اتّصال TCP بمهلة في الجانب المقابل، ويُبطَل مقبض جهاز USB كأنّه أُعيد توصيله، ويلاحظ العمل القائم على الزمن المنقضي قفزة زمنيّة هائلة. تعافَ من كلّ منها بإعادة اتّصال وإعادة فتح وحماية فرق
    sleep["فترة السكون"] --> tcp["اتّصال TCP: ألغاه الطرف المقابل"]
    sleep --> usb["جهاز USB: بُطِل المقبض"]
    sleep --> time["الزمن المنقضي: قفزة هائلة"]
    tcp -.-> r1["اكشف الخطأ وأعد الاتّصال"]
    usb -.-> r2["أعد فتح الجهاز"]
    time -.-> r3["احمِ من الفروق غير الطبيعيّة"]

الشكل 6: ما ينكسر يقع في ثلاث أسر، «اتّصالات» و«مقابض» و«استمراريّة الزمن»، ولكلّ منها نوع تعافٍ مستقر.

محرّكات الشبكة وVPN لها فترة انتظار فور الاستئناف

محرّكات الشبكة وVPN تحتاج أحياناً إعادة مصادقة وإعادة إقامة بعد الاستئناف. نتيجة لذلك، ثمّة نافذة من ثوانٍ قليلة إلى عشرات الثواني فور الاستئناف يفشل فيها الوصول.

بدل إعادة محاولة كلّ شيء دفعة واحدة لحظة استئناف الجهاز، صمِّم التطبيق ينتظر قليلاً ويعيد المحاولة على مراحل.

5. بناء تطبيقات تصمد أمام الاستئناف

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

اجمع إشعار الاستئناف وأخطاء الاتّصال في منطق إعادة الاتّصال نفسه

عندما تتلقّى نافذة المستوى الأعلى WM_POWERBROADCAST بـ PBT_APMRESUMEAUTOMATIC، ألغِ الاتّصالات التي تمسكها وأعد بناءها. غير أنّه لا تعتمد على إشعار الاستئناف وحده. يمكن تفويت الإشعارات، ويمكن أن يحدث اتّصال قبل وصول الإشعار.

وفِّر دائماً مساراً «يعيد الاتّصال عند كشف خطأ اتّصال»، وعامل إشعار الاستئناف محفِّزاً يبدأ ذلك العمل أبكر. مثال C# التالي هو الجزء الذي يطلب إعادة اتّصال من إشعار الاستئناف. جانب خطأ الاتّصال ينصبّ في منطق إعادة الاتّصال نفسه.

// C#: اجمع إشعار الاستئناف وأخطاء الاتّصال في منطق إعادة الاتّصال نفسه
protected override void WndProc(ref Message m)
{
    const int WM_POWERBROADCAST = 0x0218;
    const int PBT_APMRESUMEAUTOMATIC = 0x0012;
    if (m.Msg == WM_POWERBROADCAST && (int)m.WParam == PBT_APMRESUMEAUTOMATIC)
    {
        _connectionManager.RequestReconnect();   // طلب إعادة اتّصال idempotent
    }
    base.WndProc(ref m);
}

إعادة الاتّصال تجمع «idempotence وbackoff وkeepalive»

يحتاج منطق إعادة الاتّصال العناصر الثلاثة التالية معاً.

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

flowchart TB
    accTitle: تصميم إعادة اتّصال يصمد أمام الاستئناف
    accDescr: إشعار الاستئناف وخطأ الاتّصال وفشل keepalive تصبّ كلّها في منطق إعادة اتّصال idempotent واحد، يعيد المحاولة بـ backoff أسيّ عند الفشل
    e1["إشعار الاستئناف (PBT_APMRESUMEAUTOMATIC)"] --> r["منطق إعادة اتّصال idempotent"]
    e2["كشف خطأ اتّصال"] --> r
    e3["فشل keepalive"] --> r
    r --> ok{"نجح؟"}
    ok -->|"نعم"| run["عودة إلى التشغيل العادي"]
    ok -->|"لا"| back["إعادة محاولة بعد backoff أسيّ"]
    back --> r

الشكل 7: اجمع إعادة الاتّصال في مسار idempotent واحد، وادخل الطريق نفسه من إشعار الاستئناف أو كشف الخطأ أو الـ keepalive.

لا تخلط فترة قفز فيها الزمن في حساباتك

في عمل يستخدم «الزمن المنقضي منذ المرّة السابقة»، أضف حماية تُبطل الفترة عندما تكشف فرقاً كبيراً بصورة غير طبيعيّة. النقطة ألّا تطويه في متوسّط وألّا تعاملَه مهلة عاديّة.

عند قياس الزمن عبر الاستئناف، ميِّز الساعة التي تظلّ تتقدّم أثناء السكون (زمن الجدار) عن الزمن المصروف فعليّاً على العمل. إعادة بناء جدول العمل الدوري ومعالجة العمل المجدول الذي لم يعمل ينبغي أيضاً مراجعتهما بفئات الفصل 4.

اكبح السكون صراحة للعمل الذي يجب ألّا يُقاطَع

بينما عمل يجب ألّا يُنام خلاله جارٍ، كترحيل بيانات أو اتّصال مستمر بجهاز، استخدم SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED). إن أردت أيضاً إبقاء الشاشة مشتعلة، أضف ES_DISPLAY_REQUIRED.⁷⁴

الوسيلة الأخرى طلب طاقة عبر PowerCreateRequest وPowerSetRequest. لأنّك تستطيع إرفاق سلسلة سبب، يعرض powercfg /requests «من يمنع السكون، ولماذا». هذا ألطف من حيث أنّ طاقم التشغيل يستطيع قراءة السبب.⁵

غير أنّ ضبط الكبح لا يمنع كلّ نوع مقاطعة. افحص القيود التالية منفصلة عن منطق التعافي.

flowchart TB
    accTitle: وسيلتان لكبح السكون
    accDescr: سواء استخدمت SetThreadExecutionState المريح أو واجهة طلب الطاقة التي تستطيع إرفاق سلسلة سبب وتظهر لمسؤول عبر powercfg، أزلِه دائماً عندما ينتهي العمل
    need["فترة عمل يجب ألّا يُنام خلالها"] --> a["SetThreadExecutionState"]
    need --> b["طلب طاقة (PowerSetRequest)"]
    a -.-> a1["مريح، أعلام فقط"]
    b -.-> b1["مع سبب، ظاهر في powercfg"]
    a --> off["أزلِه دائماً عندما ينتهي العمل"]
    b --> off

الشكل 8: بأيّ وسيلة، «أزلِه عندما تنتهي» شرط مطلق. طلب طاقة يستطيع إظهار السبب ألطف للتشغيل.

إن كان التشغيل المستمر متطلّبة، راجع الموضع والتشغيل

الخدمات والتطبيقات بلا نافذة تستطيع أيضاً تلقّي الإشعارات عبر DEVICE_NOTIFY_CALLBACK مع RegisterSuspendResumeNotification.⁸

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

6. التحقيق ── powercfg وسجلّ الأحداث

لتذكرة دعم، أكِّد أوّلاً هل كان الحاسوب نائماً قبيل الخطأ. اسأل هل أُغلق الغطاء وكم دقيقة تُرك الجهاز خاملاً، ثمّ استخدم الأداة التي تناسب العَرَض.

مطابقة سجلّ الأحداث مع سجلّ التطبيق تتيح تأكيد هل كان ثمّة استئناف قبيل الخطأ بموضوعيّة. لا تتوقّف عند الاشتباه في السكون؛ صفّ الأختام الزمنيّة واعزل السبب.

flowchart TB
    accTitle: ربط أعراض مشاكل الطاقة بأوامر التحقيق
    accDescr: لعَرَض لا ينام، اعثر من يمسك طلب طاقة بـ powercfg /requests؛ ولعَرَض يستيقظ من تلقاء نفسه، اعثر سبب الإيقاظ بـ /lastwake و/waketimers؛ وللخطّ الزمني استخدم Kernel-Power في سجلّ الأحداث
    s1["لا ينام"] --> c1["powercfg /requests"]
    s2["يستيقظ من تلقاء نفسه"] --> c2["powercfg /lastwake و/waketimers"]
    s3["تريد فحص الخطّ الزمني"] --> c3["Kernel-Power في سجلّ الأحداث"]
    c1 -.-> note["كبح سكون لم يُزَل يظهر أيضاً"]

الشكل 9: الأعراض ترتبط بأوامر التحقيق في ثلاث أسر. أكِّد أوّلاً «هل نام قبيل ذلك»، ثمّ اختر الأداة.

7. الخلاصة

معالجة السكون لا تنتهي بمجرّد تلقّي الإشعارات. اسمح بأن لا يكتمل الاستعداد في الوقت وبألّا يصل إشعار الاستئناف، وقسِّم الأدوار كالتالي.

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

مقالات ذات صلة

• مطبّات تطبيقات الاتّصال التسلسلي - عبر إعادة الاتّصال وتصميم السجلّ
• إغلاق Windows كما يراه تطبيقك ── النجاة من إشعارات الخروج وإعادة التشغيل وفقدان الطاقة بشكل صحيح
• ما وضع الكفاءة في Windows؟ - أيقونة الورقة الخضراء وكيف تعطِّله
• لماذا ينبغي تفضيل انتظار الأحداث على Sleep(1) في Windows
• ما الذي يعنيه «لا يستجيب» حقّاً ── كيف يقرِّر Windows أنّ تطبيقاً قد تجمّد، وكيف تصمِّم تطبيقات لا تتجمّد

مجالات الاستشارة ذات الصلة

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

• تحقيق الأعطال وتحليل الأسباب
• تطوير تطبيقات Windows
• الاستشارة التقنيّة ومراجعة التصميم
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

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

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل يستطيع التطبيق أن يعلم مسبقاً أنّ الجهاز على وشك السكون وأن يرفضه؟

على Windows الحالي يمكن للتطبيق تلقّي الإشعار لكن لا يمكنه الرفض. قبيل السكون تصل رسالة WM_POWERBROADCAST بحدث PBT_APMSUSPEND، فيستطيع التطبيق الاستعداد بإغلاق الملفّات وحفظ الحالة، لكن الوقت المسموح للمعالجة نحو ثانيتين لكلّ تطبيق؛ وبعد ذلك يتقدّم النظام دون انتظار التطبيق. عند تعليق طارئ، كبطارية شبه نافدة، لا يصل إشعار مسبق أصلاً. إذن تصميم «يجب أن يكتمل قبل السكون» لا يصمد؛ يجب أن يكون التصميم «قادراً على التعافي عند الاستئناف مهما قُطع». لقطعة عمل يجب ألّا يُنام خلالها حقّاً، اكبح السكون صراحة بـ SetThreadExecutionState أو طلب طاقة (PowerSetRequest).

كيف أكشف أنّ الجهاز قد استأنف؟

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

هل يمكن إبقاء التطبيق يعمل أثناء السكون؟

كقاعدة، لا. أثناء السكون يتوقّف تنفيذ المعالج نفسه (على جهاز Modern Standby تُوقَف تطبيقات سطح المكتب بـ Desktop Activity Moderator)، وشيفرة التطبيق لا تعمل. ثمّة خياران. الأوّل كبح السكون فقط أثناء العمل. تحديد ES_SYSTEM_REQUIRED مع SetThreadExecutionState، أو إصدار طلب طاقة بـ PowerCreateRequest/PowerSetRequest، يكبح السكون التلقائي عند الخمول لتلك الفترة (يمكنك التأكيد بـ powercfg /requests). هذا ما يزال لا يوقف فعل سكون صريح كإغلاق المستخدم للغطاء، لذا تحتاج الاستعداد للاستئناف حتّى أثناء الكبح. الثاني قبول السكون وتصميم التطبيق «ليلحق بعد الاستئناف». للعمل المجدول كدفعة ليليّة، يمكنك أيضاً إيقاظ الحاسوب بميزة «إيقاظ الحاسوب لتشغيل هذه المهمّة» في جدولة المهام. العمل الذي يجب أن يعمل باستمرار حقّاً مكانه خادم أو خدمة مضبوطة بلا سكون.

لماذا تتوقّف اتّصالات TCP والمنافذ التسلسليّة بعد الاستئناف؟

لأن محوِّلات الشبكة وأجهزة USB تسقط أيضاً في حالة طاقة منخفضة أثناء السكون. يكون اتّصال TCP قد أُلغي أصلاً من الطرف المقابل أو بمهلة NAT أو جدار نار، لذا يفشل الإرسال والاستقبال بعد الاستئناف (غالباً لا تلاحظ حتّى يفشلا). محوِّل USB إلى تسلسلي وما شابه يُعامَل أحياناً عند الاستئناف كأنّه نزع جهاز وإعادة إدخاله، فيصير المقبض الذي كان مفتوحاً غير صالح. في الحالتين الجواب الصحيح افتراض أنّ «المقابض والاتّصالات لا تبقى عبر الاستئناف» وتنفيذ منطق إعادة اتّصال يعيد بناء الاتّصال عند إشعار استئناف أو خطأ اتّصال. النمط المستقر يجمع keepalive دوريّاً مع إعادة محاولة بـ backoff أسيّ عند الفشل.

كيف أحقِّق في جهاز ينام من تلقاء نفسه أو يستيقظ من تلقاء نفسه؟

أمر powercfg الأداة الأولى. في اتجاه «لا ينام»، يعرض powercfg /requests أيّ العمليّات وبرامج التشغيل أصدرت طلبات طاقة تمنع السكون. في اتجاه «يستيقظ من تلقاء نفسه»، يعرض powercfg /lastwake أحدث سبب إيقاظ، وpowercfg /waketimers المؤقِّتات المجدولة حالياً لإيقاظ الجهاز. على جهاز Modern Standby يُنتج powercfg /sleepstudy تقريراً لاستهلاك الطاقة والنشاط أثناء السكون. يُسجَّل تاريخ السكون والاستئناف أيضاً في سجلّ الأحداث (مصدر Kernel-Power في سجلّ النظام)، فتؤكِّد على خطّ زمني متى نام الجهاز ومتى ولماذا استيقظ.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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