تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
هناك بعض الأمور التي يجب مراعاتها لتحديد ما إذا كانت سلاسل عمليات معالجة لعبتك قد تم استخدامها وجدولتها بشكل مناسب لتحقيق أفضل أداء.
مستوى سرعة عرض اللقطة
تعدد سلاسل المحادثات وموازاة السلاسل
وحدة المعالجة المركزية ذات الاهتمامات المشتركة
تعدد سلاسل المحادثات
تستخدم العديد من الألعاب ومحركات الألعاب سلاسل المحادثات المتعددة لتقسيم عمل وحدة المعالجة المركزية إلى مهام منطقية يمكن تشغيلها بشكل مستقل إلى حد ما. ومن بين الإعدادات النموذجية هي سلسلة محادثات لعبة للإدخال ومنطق اللعبة، وسلسلة عرض لإعداد وإرسال الكائنات التي سيتم رسمها، وسلاسل محادثات العمال للمهام الفرعية الأخرى مثل الرسوم المتحركة أو الصوت.
ننصحك باستخدام سلاسل المحادثات بشكل موازٍ للاستفادة من مزايا سلاسل المحادثات المتعددة في الأداء. ومن الأمثلة على ذلك سيناريو يتم فيه تشغيل سلاسل محادثات اللعبة وعرض
سلاسل البيانات بشكل متزامن جزئيًا أو كليًا على نوى مختلفة. لن يكون ذلك ممكنًا دائمًا، كما هو الحال في الحالات التي تعتمد فيها البيانات التي تتم مشاركتها، ومع ذلك، قد يؤدي ذلك كلما أمكن ذلك إلى انخفاض أوقات استخدام وحدة المعالجة المركزية (CPU)، ما قد يؤدي إلى ارتفاع عدد اللقطات في الثانية.
الشكل 1. لعبة تتضمّن سلسلة محادثات رئيسية وعرضية متوازية، بالإضافة إلى سلسلة تعليمات وسلسلة محادثات صوتية
وحدة المعالجة المركزية ذات الاهتمامات المشتركة
أحد العوامل التي تؤثر بشكل كبير في أداء أعباء عمل وحدة المعالجة المركزية (CPU) هي طريقة جدولتها على النواة. يمكن تقسيم ذلك إلى عنصرين:
ما إذا كانت سلاسل محادثات لعبتك تعمل على النواة الأكثر ملاءمةً لأعباء العمل
تحدِّد هذه السياسة ما إذا كانت سلاسل محادثات لعبتك يتم التبديل بين النواة بشكل متكرر.
تستخدم الأجهزة الحديثة بنية تسمى الحوسبة غير المتجانسة، حيث يكون للنواة مستويات أداء مختلفة:
يوفّر نواة واحدة أو أكثر من النواة أداءً مثاليًا في الأداء، ولكنه يستهلك المزيد من الطاقة. تسمى هذه أحيانًا أنوية "كبيرة".
تحقّق النوى الأخرى أعلى مستوى من الأداء، ولكنها أكثر توفيرًا للطاقة. وتسمى هذه أحيانًا أنوية "صغيرة".
اختياريًا، يوفّر واحد أو أكثر من النواة التوازن بين الأداء والقوة. وتُسمى هذه أحيانًا النوى "المتوسطة".
يمكنك التحقق من سلوك سلسلة وحدة المعالجة المركزية (CPU) ضمن استخدام وحدة المعالجة المركزية (CPU) من خلال تفعيل وحدة المعالجة المركزية (CPU) في إعدادات الملف الشخصي عند تتبُّع عملية التتبُّع. ويمكنك عرض العمليات الفردية التي تعمل على نوى وحدة المعالجة المركزية (CPU) لجهازك، وذلك عن طريق تكبير قسم من آثار الأنشطة أقل من 200 ملي ثانية. تتوافق عادةً النوى الأصغر مع فهارس أصغر (على سبيل المثال، وحدات المعالجة المركزية (CPU) من 0 إلى 3)،
بينما تتوافق النوى الأكبر مع فهارس أعلى (على سبيل المثال، وحدات المعالجة المركزية (CPU) من "6 إلى 7")
وتشغل النوى الوسطى في حال توفّرها فهارس (على سبيل المثال، وحدات المعالجة المركزية (CPU) من "5 إلى 6").
يكون ذلك وفقًا للاعتراف الشائع، ولكنه ليس ضمانًا.
إذا وجدت أنه تتم جدولة بعض سلاسل المحادثات على وحدات معالجة مركزية (CPU) لا تفي باحتياجاتها من حيث الأداء أو الطاقة،
يمكنك ضبط تقارب وحدة المعالجة المركزية (CPU) لهذه السلاسل يدويًا.
الشكل 2. لعبة تتضمّن سلسلة التعليمات الرئيسية والقابلة للعرض وتعمل بشكل أساسي على نوى كبيرة (وحدة معالجة مركزية من 6 إلى 7) وتظهر باللون الأزرق الفاتح
يمكنك أيضًا ملاحظة ما إذا كانت سلاسل المحادثات تبدِّل بين النوى.
وتتحمل مفاتيح التبديل الأساسية هذه بعض النفقات العامة بسبب تبديل السياق وفقدان الحالة في ذاكرة التخزين المؤقت/التسجيلات الخاصة بالنواة.
الشكل 3. لعبة تتضمّن سلسلة التعليمات الرئيسية (Thread-7) وسلسلة محادثات (Thread-8) تبدِّل بين النوى، وتظهر باللون الأرجواني
إنّ ضبط تقارب وحدة المعالجة المركزية (CPU) لسلسلة محادثات يوجِّه النظام إلى جدولته على النواة المحدّدة أثناء تشغيل لعبتك في المقدّمة.
هناك عدة عوامل يجب مراعاتها عند إجراء ذلك:
لا يمكن لبرنامج النظام الأساسي ضبط موضع المهمة ديناميكيًا لعوامل وقت التشغيل
مثل التحميل والتقييد الحراري.
قد يؤدي اختبار الأداء على أجهزة مختلفة إلى تقديم خصائص أداء مختلفة جدًا، خاصةً إذا كانت الأجهزة تختلف اختلافًا كبيرًا حسب نقطة السعر أو تاريخ الإصدار.
قد يشغِّل جهاز أحدث أو أكثر تكلفة عبء عمل معيّنًا بشكلٍ مريح على وحدة أساسية صغيرة، ولكن قد يحتاج جهاز أقدم أو أكثر تكلفة إلى نواة أكبر للوفاء بالمواعيد النهائية لحمل العمل نفسه.
وقد يؤدي فرض التقارب على النوى الكبيرة إلى زيادة استنزاف البطارية والحمل الحراري بدون داعٍ.
ولهذه الأسباب، يُفضل عمومًا تجنب ضبط التقاربات باستخدام وحدة المعالجة المركزية (CPU) يدويًا.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Analyze thread scheduling\n\nThere are a few things to consider in order to determine if your game process threads are appropriately utilized and scheduled for the best performance.\n\n- Frame pacing\n- Multithreading and thread parallelization\n- CPU core affinity\n\nMultithreading\n--------------\n\nMany games and game engines use multithreading to divide CPU work into logical tasks, which may be run somewhat independently. One typical configuration is a game thread for input and game logic, a render thread for preparing and submitting objects to be drawn, and worker threads for other subtasks such as animations or audio.\n\nWe recommend parallelizing threads to take advantage of performance gains of\nmultithreading. An example of this is a scenario where the game and render\nthreads are running partially or fully concurrently on different cores. This\nwon't always be possible, such as in cases with shared data dependencies;\nhowever, when possible, this may result in lower CPU times and thus potentially\nhigher frame rates.\n**Figure 1.**Game with a well-parallelized main and render thread, as well as a worker thread and audio thread\n\nCPU core affinity\n-----------------\n\n| **Important:** CPU core affinity has been superseded by the [Performance Hint API](/games/optimize/adpf/performance-hint-api). Use this API when your app is on a device running Android 12 and later.\n\nOne factor that significantly affects the performance of your CPU workloads is how they are scheduled on the cores. This may be split into two components:\n\n- Whether your game threads are running on the most suitable core for their workload.\n- Whether your game threads switch between cores frequently.\n\nModern devices often use an architecture called *heterogeneous computing*, where the cores have different levels of performance:\n\n- One or a few cores offer top peak performance, but consume more power. These are sometimes called \"big\" cores.\n- Other cores have lower peak performance, but are more power-efficient. These are sometimes called \"little\" cores.\n- Optionally: one or more cores offer a balance between performance and power. These are sometimes called \"mid\" cores.\n\nYou may investigate CPU thread behavior under **CPU Usage** by enabling the\n**CPU** in the profile config when taking a trace. By zooming into a section of\nyour trace \\\u003c200 ms, you can view the individual processes running on your device's CPU cores. Typically, smaller cores correspond to smaller indexes (for example, CPUs '0'-'3')\nwhereas larger cores correspond to higher indexes (for example, CPUs '6'-'7')\nand middle cores if present will occupy indexes in between (for example, CPUs '5'-'6').\nThis is by common convention, but it's not a guarantee.\n\nIf you find that certain threads are being scheduled on CPUs that don't meet their needs for performance or power,\nconsider manually setting the CPU affinity for those threads.\n**Figure 2.**Game with main and render thread primarily running on the large cores (CPU 6-7), shown in light blue\n\nYou may also observe whether your threads switch between cores.\nSuch core switches incur some overhead from the context switch and the loss of state with a core's cache/registers.\n**Figure 3.**Game with main (Thread-7) and render thread (Thread-8) that switch between cores, shown in purple\n\nSetting CPU affinity for a thread instructs the system to schedule it on the given core when your game is in the foreground.\nThere are several factors to consider when doing this:\n\n- The platform software can't dynamically adjust task placement for runtime factors such as load and thermal throttling.\n- Performance testing on different devices may yield very different\n performance characteristics, especially if the devices vary considerably by\n price point or by release date.\n\n A newer or more expensive device might run a given workload comfortably on\n a little core, but an older or more affordable device might require a\n bigger core to meet deadlines for that same workload.\n- By forcing affinities to big cores, you may unnecessarily increase battery\n drain and thermal load.\n\nFor these reasons, it's generally best to avoid manually setting CPU affinities."]]
