إذا نفذت الصفحة حلقة JavaScript طويلة على الخيط الرئيسي، فقد يتأخر زر الإلغاء أو يتجمد مؤشر التقدم حتى تنتهي الحلقة. مشروع تخرج في علوم الحاسوب يمكن أن يبني مختبراً يعالج قائمة كبيرة من السجلات، ويقارن التنفيذ دفعة واحدة بتقسيم تعاوني يستدعي scheduler.yield() بين أجزاء العمل. السؤال ليس «كيف أجعل الموقع أسرع؟» بشكل عام، بل كيف يتبادل العمل المجدول وقت الخيط الرئيسي مع مهام التفاعل، وما الكلفة التي تظهر في زمن إنهاء المعالجة؟

تصلح الفكرة لمشاريع تخرج علوم الحاسوب التي تقارن عدالة الجدولة واستجابة التفاعل بقياسات قابلة للتكرار.

عرّف المشكلة على الخيط الرئيسي

الرسم والتفاعل وتشغيل JavaScript في الصفحة تتنافس على وقت التنفيذ. إذا لم يكتمل عمل طويل، قد لا يعالج المتصفح ضغط زر أو يرسم تحديث التقدم فوراً. تشرح MDN واجهة جدولة المهام ذات الأولويات أدوات تنظيم المهام، ومنها scheduler.yield() الذي يتيح للشيفرة التنازل مؤقتاً عن التنفيذ. وتعرض مسودة WICG لواجهات الجدولة نموذج المهام ذات الأولويات وآلية التنازل التعاوني؛ وتظل الإتاحة الفعلية مرتبطة بدعم المتصفح. صمم المختبر حول مهمة قابلة للتكرار، مثل حساب مجموع أو تصنيف عناصر اصطناعية، لا حول تحميل موارد الشبكة؛ ذلك سؤال مستقل.

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

قارن استراتيجيات الجدولة بحذر

أنشئ ثلاثة أوضاع: تنفيذ كامل متصل، تقسيم العمل إلى دفعات مع آلية إفساح مدعومة، ووضع بديل عندما لا تتوفر الواجهة. يتطلب استخدام scheduler.yield() فحص وجود الواجهة؛ لا تفترض أنها متاحة في كل متصفح أو سياق. توضح صفحة MDN للطريقة أنها تعيد Promise وتسمح للمتصفح بإتاحة فرصة للمهام الأخرى قبل متابعة الجزء التالي. لا تجعل تنفيذ البديل مطابقاً افتراضياً؛ سجّل آليته كي تكون المقارنة مفهومة.

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

اجمع قياساً قابلاً للتفسير

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

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

مثال تصميم تجربة

أنشئ مصفوفة اصطناعية من 200 ألف رقم، واجمع الأرقام التي تتجاوز عتبة ثابتة. قارن وضع الحلقة المتصلة بوضع دفعات من 2,000 عنصر يتبعها await scheduler.yield(). أثناء المعالجة اضغط زر إيقاف بعد ثانية. النتيجة المتوقعة أن أحد الأوضاع قد يسمح بمعالجة الضغط قبل اكتمال الحساب، بينما قد يزيد وقت النهاية بسبب التنازل المتكرر. الرقم والحجم مثال لتخطيط التجربة وليس توصية أو نتيجة قياس فعلية.

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

اختبر حالات الفشل والبديل

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

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

مخرجات مشاريع التخرج وحدودها

يسلم الفريق مصدر البيانات الاصطناعية، كود الاستراتيجيات الثلاث، سجل القياسات، وشرحاً لطريقة الضغط والإلغاء. ترتبط الفكرة بـمشاريع التخرج وتطوير تطبيقات الويب. يمكن قراءة مدقق HTTP 103 للمقارنة بين مرحلتين مختلفتين: ذلك الموضوع يتابع طلب مورد قبل HTML، وهذا يقيس جدولة تنفيذ JavaScript بعد تحميل الصفحة. لا تجمع مؤشريهما في تقرير واحد بعنوان «تحسين الأداء» من دون تعريف كل سبب.

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

المصادر

مراجعة المصادر: .

اختبار المثال وحدوده

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

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

الخدمة المرتبطة: تطوير المواقع والتطبيقات والأنظمة المخصصة.

أرسل متطلبات مشروعك