ما هو الاستطلاع الدوري، وكيف يعمل في تطوير التطبيقات؟

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

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

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

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

فكل طلب يوقظ الوحدة اللاسلكية في الجهاز، التي تبقى بعد ذلك في حالة استهلاك مرتفع للطاقة لبعض الوقت، لذا قد يستنزف الاستطلاع المتكرر البطارية بشكل ملحوظ. ولهذا السبب، يقيّد كل من iOS و Android عدد مرات تشغيل التطبيقات في الخلفية: إذ لا يسمح iOS بالاستطلاع المستمر في الخلفية، ولا يعمل العمل الدوري في الخلفية على Android عبر WorkManager إلا مرة كل 15 دقيقة على الأكثر. وقد يكون ذلك مشكلة بشكل خاص للمستخدمين ذوي عمر البطارية المحدود أو باقات البيانات المحدودة، إذ قد يؤدي الاستطلاع المستمر إلى تكاليف غير مرغوب فيها ونفاد أسرع للبطارية.

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

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

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

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

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

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

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

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

وعندما يتلقى العميل الاستجابة، يرسل فورًا طلبًا جديدًا. وهذا يوفر تحديثات أسرع من الاستطلاع الدوري العادي واستجابات فارغة أقل، لأن البيانات تُرسل فور جاهزيتها. غير أن الاستطلاع الطويل يتطلب عددًا أكبر من الاتصالات المفتوحة على الخادم. وغالبًا ما تكون البدائل الحديثة مثل WebSockets و Server-Sent Events أكثر كفاءة للاتصال في الوقت الفعلي.

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

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

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