06 نوفمبر 2025·8 دقيقة
عقلية الأداء لدى جون كارماك في رسومات الزمن الحقيقي
دليل عملي لعقلية الأداء على طريقة جون كارماك: القياس، ميزانيات زمن الإطار، المقايضات، وشحن أنظمة زمن-حقيقي معقدة.
دليل عملي لعقلية الأداء على طريقة جون كارماك: القياس، ميزانيات زمن الإطار، المقايضات، وشحن أنظمة زمن-حقيقي معقدة.
غالبًا ما يُعامل جون كارماك كأسطورة محركات الألعاب، لكن الجزء المفيد ليس الأسطورة—بل العادات القابلة للتكرار. المسألة ليست نسخ أسلوب شخص أو افتراض "حركة عبقرية". إنها مبادئ عملية تؤدي بانتظام إلى برامج أسرع وأكثر سلاسة، خاصة عندما تتراكم المهل الزمنية والتعقيد.
هندسة الأداء تعني جعل البرنامج يحقق هدف سرعة على عتاد حقيقي، وفي ظروف حقيقية—دون كسر الصحة الوظيفية. ليست "جعلها سريعة بأي ثمن". إنها حلقة منضبطة:
تظهر هذه العقلية مرارًا في عمل كارماك: ناقش بالأرقام، اجعل التغييرات قابلة للشرح، وفضّل النهج التي يمكنك صيانتها.
الرسومات الزمن الحقيقي لا ترحم لأنها تملك مهلة في كل إطار. إذا فشلت في الالتزام بها، يشعر المستخدم فورًا بتلعثم، تأخر في الإدخال، أو حركة غير متسقة. برامج أخرى يمكن أن تخفي الكفاءة المتدنية خلف قوائم انتظار أو شاشات تحميل أو عمل في الخلفية. المُصيّر لا يمكنه التفاوض: إما تنتهي في الوقت، أو لا.
لهذا السبب تتعمم الدروس خارج الألعاب. أي نظام بمتطلبات زمن استجابة مشددة—واجهات المستخدم، الصوت، AR/VR، التداول، الروبوتات—يستفيد من التفكير بالميزانيات، فهم الاختناقات، وتجنب القفزات المفاجئة.
ستحصل على قوائم تحقق، قواعد تقريبية، وأنماط قرار يمكن تطبيقها على عملك: كيفية تحديد ميزانيات زمن الإطار (أو الكمون)، كيفية القياس قبل التحسين، كيف تختار "الشيء الواحد" لإصلاحه، وكيف تمنع التراجعات حتى يصبح الأداء روتينًا—وليس ذعرًا في المراحل الأخيرة.
تفكير الأداء على طريقة كارماك يبدأ بتبديل بسيط: توقف عن الكلام عن "FPS" كوحدة أساسية وابدأ الكلام عن زمن الإطار.
FPS هو مقلوب ("60 FPS" يبدو جيدًا، "55 FPS" يبدو قريبًا)، لكن تجربة المستخدم تحكمها مدة كل إطار—وكذلك، وبنفس الأهمية، مدى اتساق هذه الأوقات. قفزة من 16.6 ms إلى 33.3 ms مرئية فورًا حتى لو بدا متوسط FPS مقبولًا.
المنتج الزمني الحقيقي يملك ميزانيات متعددة، وليس فقط "الرندر أسرع":
هذه الميزانيات تتفاعل. توفير زمن GPU عن طريق إضافة تجميع شديد على CPU قد يجلّب آثارًا عكسية، وتقليص الذاكرة قد يزيد تكاليف البث أو فك الضغط.
إذا كان هدفك 60 FPS، فميزانيتك الكلية 16.6 ms لكل إطار. تقسيم تقريبي قد يبدو:
إذا تجاوز أي من CPU أو GPU الميزانية، ستفشل في الإطار. لهذا تتحدث الفرق عن كونها "محدودة CPU" أو "محدودة GPU"—ليس كوسمات، بل كطريقة لتقرير من أين سيأتي المللي ثانية التالية عمليًا.
المغزى ليس مطاردة مؤشر مزيف مثل "أعلى FPS على جهاز متقدم". الأمر هو تحديد ما الذي يُعتبر سريعًا بما فيه الكفاية لجمهورك—أهداف العتاد، الدقة، عمر البطارية، الحرارية، واستجابة الإدخال—ثم معاملة الأداء كميزانيات صريحة يمكنك إدارتها والدفاع عنها.
التحرك الافتراضي لدى كارماك ليس "نحسّن"، بل "تحقّق". مشاكل الأداء في الزمن الحقيقي مليئة بقصص محتملة—إيقافات GC، "الشادر البطيء"، "نداءات رسم كثيرة"—وأغلبها خاطئ في بنيتك على عتادك. التحليل الزمني هو كيف تستبدل الحدس بالأدلة.
عامل التحليل كميزة من الدرجة الأولى، لا كأداة إنقاذ في اللحظة الأخيرة. التقط زمن الإطارات، خطوط زمنية للـ CPU والـ GPU، والعدادات التي تشرحها (مثلثات، نداءات الرسم، تغييرات الحالة، التخصيصات، إخفاقات الكاش إن أمكن). الهدف: الإجابة على سؤال واحد: أين يذهب الوقت فعليًا؟
نموذج مفيد: في كل إطار بطيء، هناك شيء واحد هو العامل المحدد. قد يكون GPU متأخرًا على تمريرة ثقيلة، أو CPU عالقًا في تحديث التحريك، أو الخيط الرئيسي متوقفًا على تزامن. اعثر على هذا القيد أولًا؛ الباقي ضوضاء.
حلقة مُنضبطة تمنع التشتت:
إذا لم يكن التحسّن واضحًا، افترض أنه لم يساعد—لأنه على الأرجح لن يصمد مع وصول محتوى جديد.
عمل الأداء معرض بشكل خاص للخداع الذاتي:
القياس أولًا يبقي جهودك مركزة، وتنازلاتك مبررة، وتغييراتك أسهل للدفاع عنها في المراجعة.
مشاكل الأداء في الزمن الحقيقي تبدو فوضوية لأن كل شيء يحدث معًا: اللعب، الرندر، البث، التحريك، الواجهة، الفيزياء. غريزة كارماك هي تقطيح الضوضاء وتحديد المحدد المسيطر—الشيء الوحيد الذي يحدد زمن الإطار حاليًا.
معظم البطء يقع في عدة سِلال:
المغزى ليس تصنيف التقرير—بل اختيار الرافعة المناسبة.
بعض التجارب السريعة يمكن أن تخبرك ما الذي يسيطر:
نادراً ما تفوز بشحذ 1% من عشر أنظمة. اعثر على التكلفة الأكبر التي تتكرر كل إطار وهاجمها أولًا. إزالة مُسبب وحيد بقيمة 4 ms تتفوق على أسابيع من التحسينات الدقيقة.
بعد إصلاح الصخرة الكبيرة، تظهر الصخرة التالية. هذا طبيعي. عامل عمل الأداء كلوب: قس → غيّر → أعد القياس → أعد الترتيب. الهدف ليس ملف تعريف مثالي؛ إنه تقدم ثابت نحو زمن إطار متوقع.
قد يبدو متوسط زمن الإطار جيدًا بينما التجربة سيئة. تُقيَّم الرسومات الزمن الحقيقي بـ أسوأ اللحظات: الإطار المفقود أثناء انفجار كبير، التلعثم عند دخول غرفة جديدة، التوقف المفاجئ عند فتح قائمة. هذا هو ذيل الكمون—إطارات نادرة ولكن ليست نادرة بما يكفي يشعر بها المستخدم.
لعبة تعمل عند 16.6 ms معظم الوقت (60 FPS) لكنها تقفز إلى 60–120 ms كل بضع ثوانٍ ستشعر "معطلة"، حتى لو ظل المتوسط مطبوعًا عند 20 ms. البشر حساسون للإيقاع. إطار طويل واحد يكسر توقعية الإدخال، حركة الكاميرا، ومزامنة الصوت/الصورة.
القفزات عادة تأتي من عمل غير موزّع بالتساوي:
الهدف جعل العمل المكلف متوقعًا:
لا ترسم فقط خط FPS متوسط. سجّل توقيتات كل إطار ووضّح:
إذا لم تستطع تفسير أسوأ 1% من الإطارات، فأنت لم تفسر الأداء حقًا.
عمل الأداء يصبح أسهل لحظة تتوقف فيها عن التظاهر بأنك تستطيع الحصول على كل شيء مرة واحدة. أسلوب كارماك يدفع الفرق لتسمية المقايضة بصوت عالٍ: ماذا نشتري، ماذا ندفع، ومن سيشعر بالفرق؟
معظم القرارات تقع على عدد من المحاور:
إذا حسّن تغيير محورًا لكن كلف به سراً ثلاثة محاور أخرى، وثّقه. "هذا يضيف 0.4 ms GPU و80 MB VRAM ليمنح ظلالًا أنعم" عبارة قابلة للاستخدام. "يبدو أفضل" ليست كذلك.
الرسومات الزمن الحقيقي ليست عن الكمال؛ إنها عن الوصول إلى هدف باستمرار. اتفق على حدود مثل:
بمجرد أن يتفق الفريق أن، مثلاً، 16.6 ms عند 1080p على GPU المرجعي هو الهدف، تصبح الحجج ملموسة: هل تحافظ هذه الميزة على الميزانية، أم تجبر على تخفيض مكان آخر؟
عندما تكون غير متأكد، اختر خيارات يمكنك التراجع عنها:
القابلية للعكس تحمي الجدول. يمكنك شحن المسار الآمن وإبقاء الطموح خلف مفتاح.
تجنب الإفراط في هندسة مكاسب غير مرئية. تحسّن 1% في المتوسط نادرًا ما يبرر شهرًا من التعقيد—ما لم يزيل تلعثمًا، يصحح زمن إدخال، أو يمنع انهيار ذاكرة صعب. أعطِ الأولوية للتغييرات التي يلاحظها اللاعبون فورًا، واترك الباقي لاحقًا.
عمل الأداء يصبح أسهل كثيرًا عندما يكون البرنامج صحيحًا. قدر كبير من وقت "التحسين" يُقضى فعليًا في مطاردة أخطاء صحة تبدو كقضايا أداء: حلقة O(N²) غير مقصودة نتيجة عمل مكرر، مرور عرضي على تمرير رسم مرتين لأن علمًا لم يُعدّ، تسريب ذاكرة يزيد زمن الإطار ببطء، أو حالة سباق تتحول إلى تلعثم عشوائي.
محرك ثابت ومتوقَّع يمنحك قياسات نظيفة. إذا تغير السلوك بين التشغيلين، لا يمكنك الوثوق في الملفات التعريفية، وستنتهي بتحسين الضوضاء.
ممارسات هندسية منضبطة تساعد الأداء:
العديد من قفزات زمن الإطار هي "هيزنبرج": تختفي عندما تضيف تسجيلًا أو تتبعًا. العلاج هو إعادة الإنتاج الحتمية.
ابنِ حزمة اختبار صغيرة ومتحكم بها:
عندما يظهر التلعثم، تريد زرًا يعيد تشغيله 100 مرة—ليس تقريرًا غامضًا أنه "أحيانًا يحدث بعد 10 دقائق".
عمل السرعة يستفيد من تغييرات صغيرة قابلة للمراجعة. عمليات إعادة الهيكلة الكبيرة تخلق أوضاع فشل متعددة دفعة واحدة: تراجعات، تخصيصات جديدة، وعمل خفي إضافي. الفرق الضيقة تجعل من السهل الإجابة على السؤال الوحيد المهم: ما الذي تغيّر في زمن الإطار، ولماذا؟
الانضباط ليس بيروقراطية هنا—إنه ما يحافظ على موثوقية القياسات حتى يصبح التحسين مباشرًا بدلًا من خرافي.
أداء الزمن الحقيقي ليس فقط عن "كود أسرع". إنه عن ترتيب العمل بحيث يستطيع CPU وGPU فعلهما بكفاءة. كرّر كارماك حقيقة بسيطة: الآلة حرفية. تحب البيانات المتوقعة وتكره النفقات القابلة للتجنب.
المعالجات الحديثة سريعة جدًا—حتى تبدأ بالانتظار على الذاكرة. إذا كانت بياناتك متناثرة عبر كائنات صغيرة كثيرة، يقضي CPU وقته في مطاردة مؤشرات بدلًا من الحساب.
نموذج ذهني مفيد: لا تذهب لعشرة محلات لشراء عشرة عناصر. ضعهم في عربة واحدة وامشِ الممرات مرة واحدة. في الكود، يعني ذلك إبقاء القيم المستخدمة كثيرًا قريبة (غالبًا في مصفوفات أو هياكل مضغوطة) حتى يجلب كل سطر كاش بيانات ستستخدمها فعليًا.
التخصيصات المتكررة تخلق تكاليف مخفية: نفقات المخصص، التجزؤ، وتوقفات غير متوقعة عندما يضطر النظام للتنظيف. حتى لو كان كل تخصيص "صغيرًا"، يمكن لسيل مستمر أن يصبح ضريبة تدفعها كل إطار.
الإصلاحات الشائعة مملة عن قصد: أعد استخدام البافرات، استخدم تجمعات للكائنات، وفضّل التخصيصات طويلة العمر في المسارات الساخنة. الهدف ليس الذكاء—إنه الاتساق.
قد يختفي قدر كبير من زمن الإطار في الأعمال الإدارية: تغييرات الحالة، نداءات الرسم، عمل السائق، استدعاءات النظام، وتنسيق الخيوط.
التجميع هو نسخة "العربة الكبيرة" من الرندر والمحاكاة. بدلًا من إصدار العديد من العمليات الصغيرة، جمّع العمل المتشابه حتى تعبر الحدود المكلفة أقل مرات. غالبًا ما يتفوق قطع النفقات على تحسين شادر أو حلقة داخلية—لأن الآلة تقضي وقتًا أقل في التجهيز وأكثر في العمل الفعلي.
عمل الأداء ليس فقط عن كود أسرع—بل عن كود أقل. للتعقيد تكلفة تدفعها يوميًا: الأخطاء تستغرق وقتًا أطول لعزلها، الإصلاحات تحتاج اختبارًا أكثر، التكرار يتباطأ لأن كل تغيير يمس أجزاء أكثر، والتراجعات تتسرب عبر مسارات نادرة الاستخدام. هذا التعقيد لا يهدر وقت المطور فقط؛ غالبًا ما يضيف نفقات وقت تشغيل (فروع زائدة، تخصيصات، فقدان الكاش، تزامن) يصعب رؤيتها حتى يفوت الأوان.
نظام "ذكي" قد يبدو أنيقًا حتى تكون على موعد نهائي ويظهر قفزة إطار على خريطة واحدة، GPU واحد، أو مجموعة إعدادات واحدة. كل علم ميزة إضافية، مسار تراجع، وحالة خاصة يضاعف عدد السلوكيات التي تحتاج لفهمها وقياسها. ذلك التعقيد لا يهدر وقت المطور فقط؛ غالبًا ما يضيف عبء تشغيل يصعب رصده حتى يتأخر الأثر.
قاعدة جيدة: إن لم تستطع شرح نموذج الأداء لزميل في بضعة جمل، فمن المحتمل أنك لا تستطيع تحسينه بثقة.
للحلول البسيطة ميزتان:
أحيانًا أسرع مسار هو إزالة ميزة، قطع خيار، أو دمج عدة متغيرات في واحد. ميزات أقل تعني مسارات كود أقل، مجموعات حالة أقل، وأماكن أقل يمكن أن يتدهور فيها الأداء.
حذف الكود أيضًا حركة جودة: أفضل خطأ هو الذي تزيله بحذف الوحدة التي قد تخلقه.
صحّح (قطة علاج) عندما:
أعد الهيكلة عندما:
البساطة ليست "أقل طموحًا". إنها اختيار تصاميم تبقى مفهومة تحت الضغط—حين يهم الأداء أكثر.
أعمال الأداء تظل فقط إذا استطعت أن تعرف متى تتدهور. هذا ما تفعله اختبارات تراجع الأداء: طريقة قابلة للتكرار لاكتشاف متى يضيف تغيير جديد بطءًا، يقلل السلاسة، أو يزيد الذاكرة.
على عكس الاختبارات الوظيفية (التي تجيب "هل تعمل؟"), اختبارات التراجع تجيب "هل لا تزال السرعة نفسها؟". البناء قد يكون صحيحًا 100% ومع ذلك إصدارًا سيئًا إذا أضاف 4 ms زمن إطار أو ضاعف أزمنة التحميل.
لا تحتاج مختبرًا لتبدأ—بل اتساقًا.
اختر مجموعة صغيرة من المشاهد الأساسية التي تمثل الاستخدام الحقيقي: منظر ثقيـل GPU، منظر ثقيـل CPU، ومنظر "أسوأ حالة". اجعلها ثابتة ومُسَجّلة حتى تكون مسارات الكاميرا والمدخلات متطابقة تشغيلًا بعد تشغيل.
شغّل الاختبارات على عتاد ثابت (كمبيوتر/كونسول/مجموعة تطوير معروفة). إذا غيرت تعريفات التشغيل، السائق، أو الإعدادات، سجّل ذلك. عامل مجموعة العتاد/البرمجيات كجزء من جهاز الاختبار.
خزن النتائج في تاريخ مُؤرَّخ: هاش الكوميت، تكوين البناء، هوية الجهاز، والقياسات المقيّدة. الهدف ليس رقمًا مثاليًا—بل خط اتجاه موثوق.
فضل المقاييس التي يصعب الجدل عليها:
حدد حدودًا بسيطة (مثلاً: p95 لا يتراجع أكثر من 5%).
عامل التراجعات كبقع أخطاء مع مالك ومهلة.
أولًا، قسّم التاريخ (bisect) للعثور على التغيير الذي أدخله. إذا كان التراجع يعيق الإصدار، ارجع سريعًا وأعد إدخال التغيير مع تصحيح.
عند إصلاحه، أضف حواجز: احتفظ بالاختبار، أضف ملاحظة في الكود، ووثّق الميزانية المتوقعة. العادة هي الفوز—يصبح الأداء شيئًا تحافظ عليه، لا شيئًا "تفعله لاحقًا".
"الشحن" ليس حدثًا زمنيًا—إنه متطلب هندسي. نظام يعمل جيدًا فقط في المختبر، أو يصل لزمن الإطار بعد أسبوع من التعديلات اليدوية، ليس جاهزًا. منهجية كارماك تعامل قيود العالم الحقيقي (تنوع العتاد، محتوى فوضوي، سلوك لاعب غير متوقع) كجزء من المواصفات منذ اليوم الأول.
عندما تقترب من الإصدار، الكمال أقل قيمة من التوقعية. عرّف غير القابل للتفاوض بعبارات واضحة: هدف FPS، قفزات زمن الإطار الأسوأ، حدود الذاكرة، وأزمنة التحميل. ثم عامل أي شيء ينتهكها كبقعة، لا كـ "تجميل". هذا يعيد تأطير عمل الأداء من تحسين اختياري إلى عمل موثوقية.
ليست كل البطء لها نفس الأهمية. أصلح المشاكل الأكثر وضوحًا للمستخدم أولًا:
انضباط التحليل يدفع العائد هنا: أنت لا تخمن أي قضية "كبيرة"، بل تختار بناءً على الأثر المقاس.
عمل الأداء في مراحل متأخرة مخاطرة لأن "الإصلاحات" قد تضيف تكاليف جديدة. استخدم طرحًا تدريجيًا: نزّل القياس أولًا، ثم ضع التغيير خلف علم، ثم وسّع التعرض. فضّل الإعدادات الآمنة افتراضيًا—إعدادات تحمي زمن الإطار حتى لو خفّضت الجودة البصرية قليلًا—خصوصًا للاكتشاف التلقائي للتكوينات.
إذا تشحن على منصات أو درجات مختلفة، عامل الإعدادات الافتراضية كقرار منتج: أفضل أن تبدو أقل بريقًا قليلًا من أن تكون غير مستقرة.
حوّل المقايضات إلى نتائج: "هذه التأثير يكلف 2 ms كل إطار على GPUs المتوسطة، ما يهدد السقوط تحت 60 FPS أثناء المعارك." قدم خيارات، لا محاضرات: خفض الدقة، تبسيط الشادر، حد معدل الظهور، أو قبول هدف أقل. تصبح القيود أسهل قبولًا إذا رُسمت كخيارات ملموسة بتأثير مستخدم واضح.
لا تحتاج محركًا جديدًا أو إعادة كتابة لتتبنى تفكير كارماك حول الأداء. تحتاج حلقة قابلة للتكرار تجعل الأداء مرئيًا، قابلاً للاختبار، وصعبًا أن ينكسر بالخطأ.
قِس: التقط خط أساس (المتوسط، p95، أسوأ قفزة) لزمن الإطار والأنظمة الرئيسة.
ميزانية: ضع ميزانية لكل إطار للـ CPU والـ GPU (والذاكرة إن كنت ضيقًا). اكتب الميزانية بجانب هدف الميزة.
عزل: أعِد إنتاج التكلفة في مشهد اختباري صغير. إن لم تستطع تكرارها، فلا يمكنك إصلاحها بثقة.
حسّن: غيّر شيئًا واحدًا في المرة. فضّل التغييرات التي تقلل العمل، لا فقط "تجعله أسرع".
تحقق: أعد القياس، قارن الفروق، وتحقق من تراجعات الجودة وقضايا الصحة الوظيفية.
وثّق: سجّل ما الذي تغيّر، لماذا ساعد، وماذا تراقب في المستقبل.
إذا أردت تشغيل هذه العادات عبر فريق، المفتاح خفض الاحتكاك: تجارب سريعة، حزم اختبار قابلة للتكرار، وسحبات سهلة للتراجع.
Koder.ai يمكن أن يساعد هنا عندما تبني الأدوات المحيطة—ليس المحرك نفسه. لأنه منصة تولّد كودًا حقيقيًا وقابلًا للتصدير (تطبيقات ويب في React؛ باك-إند في Go مع PostgreSQL؛ موبايل في Flutter)، يمكنك بسرعة إنشاء لوحات داخلية لنتائج نسب زمن الإطار، تاريخ التراجع، وقوائم مراجعة "أداء"، ثم التكرار عبر الدردشة بينما تتطور المتطلبات. اللقطات وخيارات التراجع تناسب حلقة "غيّر شيئًا واحدًا → أعد القياس" عمليًا.
إذا رغبت بإرشاد عملي أكثر، تصفح /blog أو اطلع كيف الفرق تفعيل ذلك على /pricing.
زمن الإطار هو الزمن لكل إطار بالمللي ثانية (ms)، ويرتبط مباشرة بكمية العمل التي نفذها المعالج/معالج الرسوم.
اختر هدفًا (مثلاً 60 FPS) وحوّله إلى مهلة صارمة (16.6 ms). ثم قسّم تلك المهلة إلى ميزانيات صريحة.
مثال كنقطة بداية:
عامل هذه الأرقام كمتطلبات منتج، واضبطها وفقًا للمنصة والدقة والحرارة وأهداف زمن الاستجابة للإدخال.
ابدأ بجعل اختباراتك قابلة للتكرار، ثم قِس قبل أي تغيير.
فقط بعدما تعرف أين يذهب الوقت يمكنك أن تقرر ما الذي يجب تحسينه.
جرِّب تجارب سريعة ومُوجَّهة لعزل المحدّد:
تجنب إعادة كتابة الأنظمة حتى تستطيع تسمية التكلفة المسيطرة بالمللي ثانية.
لأن المستخدمين يشعرون بأسوأ الإطارات، لا بالمتوسط.
تتبَّع:
بناء يوفّر متوسط 16.6 ms لكنه يقفز إلى 80 ms سيبدو معطلاً.
اجعل العمل المكلف متوقعًا ومجدولًا:
سجل القفزات حتى تتمكن من إعادة إنتاجها وإصلاحها، لا الاعتماد على الأمل.
اجعل المقايضة صريحة بالأرقام وتأثير المستخدم.
استخدم عبارات مثل:
ثم قرر بناءً على حدود متفق عليها:
لأن عدم الاستقرار في الصحة الوظيفية يجعل بيانات الأداء غير موثوقة.
خطوات عملية:
إذا تغيّر السلوك بين تشغيل وآخر فلن تقوم بتحسين الاختناق؛ ستجري على ضوضاء.
معظم عمل "الكود السريع" هو في الواقع عمل على الذاكرة والنفقات العامة.
ركّز على:
غالبًا ما يمنح تقليل النفقات العامة مكاسب أكبر من تحسين رياضيات حلقة داخلية.
اجعل الأداء قابلًا للقياس، القابلية للتكرار، وصعبًا أن يتلف دون قصد.
إن لم تكن متأكدًا، فضّل القرارات القابلة للتراجع (إيقاف الميزة، مستويات جودة قابلة للتدرج).
عند ظهور تراجع: قسّم التاريخ (bisect)، عيّن صاحبًا، وتراجع سريعًا إذا كان يعيق الإصدار.