กำหนดค่า System Tracing

คุณสามารถกำหนดค่าการติดตามระบบเพื่อจับภาพ โปรไฟล์ CPU และโปรไฟล์เทรดของแอปในช่วงระยะเวลาสั้นๆ จากนั้น คุณสามารถใช้รายงานเอาต์พุตจากการติดตามระบบเพื่อปรับปรุง ด้านประสิทธิภาพ

ตั้งค่าการติดตามระบบจากเกม

เครื่องมือ Systrace มี 2 วิธีดังนี้

• บรรทัดคำสั่ง โปรแกรม
• ในอุปกรณ์ บริการ

Systrace เป็นเครื่องมือระดับต่ำที่มีคุณสมบัติดังนี้

• ให้ข้อมูลที่ได้จากการสังเกตการณ์ Systrace จะบันทึกเอาต์พุตโดยตรงจากเคอร์เนล ดังนั้น เมตริกที่บันทึกได้จะเกือบจะเหมือนกับชุดของ ระบบจะรายงานการเรียกระบบ
• ใช้ทรัพยากรน้อย Systrace มีโอเวอร์เฮดต่ำมาก โดยปกติจะน้อยกว่า 1% เนื่องจากมีการสตรีมข้อมูลไปยังบัฟเฟอร์ในหน่วยความจำ

การตั้งค่าที่เหมาะสมที่สุด

ควรให้เครื่องมือมีชุดอาร์กิวเมนต์ที่สมเหตุสมผล ดังนี้

• หมวดหมู่: ชุดหมวดหมู่ที่ดีที่สุดสำหรับระบบเกม การติดตาม ได้แก่ {sched, freq, idle, am, wm, gfx, view, sync, binder_driver, hal, dalvik}

• ขนาดบัฟเฟอร์: กฎทั่วไปคือขนาดบัฟเฟอร์ 10 MB ต่อแกน CPU ทำให้ติดตามได้ยาวประมาณ 20 วินาที เช่น ถ้าอุปกรณ์มี CPU แบบ Quad-core 2 แกน (ทั้งหมด 8 แกน) ค่าที่เหมาะสมในการส่งผ่าน โปรแกรม systrace มีขนาด 80,000 KB (80 MB)

  หากเกมของคุณมีการสลับ บริบทเป็นจำนวนมาก เพิ่มบัฟเฟอร์เป็น 15 MB ต่อแกน CPU

• เหตุการณ์ที่กำหนดเอง: หากคุณกำหนดเหตุการณ์ที่กำหนดเอง กิจกรรมที่จะบันทึกในเกม เปิดใช้ Flag -a ซึ่งทำให้ Systrace รวมเหตุการณ์ที่กำหนดเองเหล่านี้ใน รายงานเอาต์พุต

หากคุณใช้บรรทัดคำสั่ง systrace ให้ใช้คำสั่งต่อไปนี้ เพื่อบันทึกการติดตามของระบบที่ใช้แนวทางปฏิบัติแนะนำสำหรับชุดหมวดหมู่ การบัฟเฟอร์ ขนาดและเหตุการณ์ที่กำหนดเอง ได้แก่

python systrace.py -a com.example.myapp -b 80000 -o my_systrace_report.html \
  sched freq idle am wm gfx view sync binder_driver hal dalvik

หากคุณใช้แอประบบ Systrace ในแอป โปรดทำตามขั้นตอนต่อไปนี้เพื่อ บันทึกการติดตามของระบบที่ใช้แนวทางปฏิบัติแนะนำสำหรับชุดหมวดหมู่และบัฟเฟอร์ ขนาดและเหตุการณ์ที่กำหนดเอง ได้แก่

1. เปิดใช้ตัวเลือกติดตามแอปพลิเคชันที่แก้ไขข้อบกพร่องได้

   ถึง ใช้การตั้งค่านี้ อุปกรณ์ต้องมีขนาด 256 MB หรือ 512 MB (ขึ้นอยู่กับ ว่า CPU มี 4 หรือ 8 แกน) และหน่วยความจำขนาด 64 MB แต่ละชิ้นจะต้อง ที่ใช้ได้ต่อเนื่องกัน

2. เลือกหมวดหมู่ จากนั้นเปิดใช้หมวดหมู่ในรายการต่อไปนี้

   • am: เครื่องมือจัดการกิจกรรม
   • binder_driver: ไดรเวอร์ Kernel ของ Binder
   • dalvik: Dalvik VM
   • freq: ความถี่ของ CPU
   • gfx: กราฟิก
   • hal: โมดูลฮาร์ดแวร์
   • idle: ไม่ได้ใช้งาน CPU
   • sched: การกำหนดเวลา CPU
   • sync: การซิงค์
   • view: ดูระบบ
   • wm: ผู้จัดการหน้าต่าง

3. เปิดใช้ Record Tracing

4. โหลดเกมของคุณ

5. ทำการโต้ตอบในเกมโดยสอดคล้องกับเกมเพลย์ ประสิทธิภาพอุปกรณ์ที่คุณต้องการวัด

6. หลังจากที่คุณพบพฤติกรรมที่ไม่เป็นที่ต้องการในเกมไม่นาน ให้พลิกระบบ การติดตามตัวเอง

คุณได้บันทึกสถิติประสิทธิภาพแล้ว ที่จำเป็นต่อการวิเคราะห์ปัญหาเพิ่มเติม

ระบบในอุปกรณ์จะติดตามบันทึกไฟล์ในการติดตามที่บีบอัดเพื่อประหยัดพื้นที่ในดิสก์ รูปแบบ (*.ctrace) หากต้องการยกเลิกการบีบอัดไฟล์นี้เมื่อสร้างรายงาน ให้ใช้ บรรทัดคำสั่งได้ รวมถึงมีตัวเลือก --from-file ดังนี้

python systrace.py --from-file=/data/local/traces/my_game_trace.ctrace \
  -o my_systrace_report.html

ปรับปรุงประสิทธิภาพในด้านใดด้านหนึ่ง

ส่วนนี้จะเน้นย้ำถึงข้อกังวลต่างๆ เกี่ยวกับประสิทธิภาพที่พบได้บ่อยในเกมบนอุปกรณ์เคลื่อนที่และ อธิบายวิธีระบุและปรับปรุงด้านเหล่านี้ของเกม

ความเร็วในการโหลด

ผู้เล่นต้องการเห็นการทำงานของเกมให้เร็วที่สุดเท่าที่จะทำได้ ในการปรับปรุงเวลาในการโหลดเกมให้ได้มากที่สุด ดังต่อไปนี้ โดยปกติการวัดผลจะช่วย เวลาในการโหลดได้

• ดำเนินการโหลดแบบ Lazy Loading หากคุณใช้ชิ้นงานเดียวกันติดต่อกัน ฉากหรือระดับในเกมของคุณ ให้โหลดเนื้อหาเหล่านี้เพียงครั้งเดียว
• ลดขนาดชิ้นงาน ด้วยวิธีนี้ คุณสามารถรวมกลุ่ม ที่ไม่ได้บีบอัดไว้ ของเนื้อหาดังกล่าวด้วย APK ของเกมคุณ
• ใช้วิธีบีบอัดดิสก์อย่างมีประสิทธิภาพ ตัวอย่างของวิธีการดังกล่าว ได้แก่ zlib
• ใช้ IL2CPP แทนที่จะเป็นโมโน (ใช้ได้เฉพาะเมื่อคุณใช้ Unity) IL2CPP ให้ผลที่ดีกว่า ประสิทธิภาพของสคริปต์ C# ของคุณ
• ทำให้เกมเป็นแบบมัลติเทรด ดูรายละเอียดเพิ่มเติมได้ที่อัตราเฟรม ความสอดคล้อง

ความสม่ำเสมอของอัตราเฟรม

หนึ่งในองค์ประกอบที่สำคัญที่สุดของประสบการณ์เกมเพลย์คือการมี อัตราเฟรมที่สม่ำเสมอ เพื่อให้บรรลุเป้าหมายนี้ได้ง่ายขึ้น โปรดทำตาม เทคนิคการเพิ่มประสิทธิภาพที่กล่าวถึงในส่วนนี้

มัลติเทรด

เมื่อพัฒนาสำหรับหลายแพลตฟอร์ม จะเป็นเรื่องปกติที่จะวางกิจกรรมทั้งหมด ภายในเกมให้อยู่ในชุดข้อความเดียว แม้ว่าวิธีดำเนินการนี้จะเรียบง่าย สำหรับใช้งานในเครื่องมือสร้างเกมหลายๆ ระบบ การใช้บน Android ไม่ใช่วิธีที่เหมาะสม อุปกรณ์ ดังนั้น เกมแบบแยกชุดข้อความเดี่ยวมักจะโหลดได้ช้าและขาด อัตราเฟรมที่สม่ำเสมอ

Systrace ที่แสดงในรูปที่ 1 แสดงพฤติกรรมที่ปกติของเกม ทำงานโดยใช้ CPU ครั้งละ 1 เครื่องเท่านั้น:

หากต้องการปรับปรุงประสิทธิภาพของเกม ให้สร้างเกมแบบหลายชุดข้อความ โดยทั่วไป รูปแบบที่ดีที่สุดคือควรมี 2 เทรด ดังนี้

• ชุดข้อความเกมซึ่งมีโมดูลหลักของเกมและส่งการแสดงภาพ คำสั่ง
• เทรดการแสดงผล ซึ่งรับคำสั่งการแสดงผลและแปลงเป็น คำสั่งกราฟิกที่ GPU ของอุปกรณ์สามารถใช้เพื่อแสดงฉาก

Vulkan API ขยายมาจากโมเดลนี้ เนื่องจากมีความสามารถในการพุช แบบขนานกัน ด้วยคุณสมบัตินี้ คุณจะสามารถเผยแพร่การแสดงภาพหลายภาพได้ เทรดใน CPU หลายตัวเพื่อช่วยเพิ่มประสิทธิภาพเวลาในการแสดงผลของฉาก

คุณยังทำการเปลี่ยนแปลงเฉพาะเครื่องมือ เพื่อเพิ่มประสิทธิภาพให้เกม ประสิทธิภาพของชุดข้อความหลายรายการ:

• หากคุณกำลังพัฒนาเกมโดยใช้เครื่องมือเกมของ Unity ให้เปิดใช้ การแสดงผลแบบมัลติเธรดและ GPU Skinning
• ถ้าคุณกำลังใช้เครื่องมือการแสดงผลที่กำหนดเอง ตรวจสอบให้แน่ใจว่าคำสั่งการแสดงผล ไปป์ไลน์คำสั่งของไปป์ไลน์และกราฟิกอยู่ในแนวที่ถูกต้อง หากไม่เป็นเช่นนั้น คุณ อาจทำให้เกิดความล่าช้าในการแสดงฉากของเกม

หลังจากนำการเปลี่ยนแปลงเหล่านี้ไปใช้ คุณควรเห็นว่าเกมใช้ CPU อย่างน้อย 2 ตัว พร้อมกันดังแสดงในรูปที่ 2:

กำลังโหลดองค์ประกอบ UI

เมื่อสร้างเกมที่มีฟีเจอร์มากมาย คุณก็จะต้องอยากแสดงตัวเลือกต่างๆ มากมาย และการทำงานต่างๆ กับโปรแกรมเล่นได้ในเวลาเดียวกัน หากต้องการรักษาอัตราเฟรมให้สม่ำเสมอ แต่สิ่งสำคัญคือ หน้าจออุปกรณ์เคลื่อนที่ที่มีขนาดเล็ก และทำให้ UI เรียบง่ายที่สุดเท่าที่จะทำได้

รายงาน Systrace ที่แสดงในรูปที่ 3 เป็นตัวอย่างของเฟรม UI ที่ พยายามแสดงผลองค์ประกอบจำนวนมากเกินไปเมื่อเทียบกับ ความสามารถ

เป้าหมายที่ดีคือลดเวลาการอัปเดต UI ลงเหลือ 2-3 มิลลิวินาที คุณสามารถ การอัปเดตที่รวดเร็วเหล่านั้นได้โดยการดำเนินการเพิ่มประสิทธิภาพในลักษณะต่อไปนี้

• อัปเดตเฉพาะองค์ประกอบบนหน้าจอที่เคลื่อนไหว
• จำกัดจำนวนพื้นผิวและเลเยอร์ของ UI ลองรวมการเรียกใช้กราฟิกเข้าด้วยกัน เช่น เฉดสีและพื้นผิว ซึ่งใช้วัสดุเดียวกัน
• เลื่อนการดำเนินการภาพเคลื่อนไหวขององค์ประกอบไปยัง GPU
• กำจัดการอุดตันรุนแรงมากขึ้น
• หากเป็นไปได้ ให้ดำเนินการวาดโดยใช้ Vulkan API สุ่มเลือก ค่าใช้จ่ายในการดำเนินการน้อยกว่าใน Vulkan

การใช้พลังงาน

แม้หลังจากทำการเพิ่มประสิทธิภาพที่กล่าวถึงในส่วนก่อนหน้านี้แล้ว คุณอาจ พบว่าอัตราเฟรมของเกมแย่ลงภายใน 45-50 นาทีแรก ได้อย่างมีประสิทธิภาพ นอกจากนี้ อุปกรณ์อาจเริ่มร้อนและใช้พลังงานมากขึ้น แบตเตอรี่เมื่อเวลาผ่านไป

ในหลายกรณี ชุดของความร้อนและการใช้พลังงานที่ไม่พึงประสงค์นี้เกี่ยวข้องกับ กับวิธีกระจายภาระงานของเกมไปยัง CPU ของอุปกรณ์ เพื่อเพิ่ม ประสิทธิภาพการใช้พลังงานของเกม ให้นำแนวทางปฏิบัติแนะนำที่แสดงใน ส่วนต่างๆ ต่อไปนี้

เก็บเทรดที่ใช้หน่วยความจำมากอยู่บน CPU 1 เครื่อง

ในอุปกรณ์เคลื่อนที่จำนวนมาก แคช L1 จะอยู่ใน CPU ที่เจาะจงและแคช L2 จะอยู่ในชุด CPU ที่ใช้นาฬิการ่วมกัน ในการเพิ่ม Hit ของแคช L1 ให้สูงสุด โดยทั่วไปควรเก็บชุดข้อความหลักของเกมไว้ พร้อมกับแท็กอื่นๆ เทรดที่ใช้หน่วยความจำมาก ซึ่งทำงานบน CPU เดี่ยว

เลื่อนการทำงานเป็นระยะเวลาสั้นๆ ให้กับ CPU ที่ใช้พลังงานต่ำ

เครื่องมือเกมส่วนใหญ่ รวมถึง Unity ทราบว่าต้องเลื่อนการดำเนินการของเธรดผู้ปฏิบัติงานไปยัง CPU ตัวอื่นที่สัมพันธ์กับเทรดหลักของเกม แต่เครื่องยนต์จะไม่ ทราบถึงสถาปัตยกรรมเฉพาะของอุปกรณ์และไม่สามารถคาดการณ์ ภาระงานมากเท่าที่จะทำได้

อุปกรณ์แบบออนชิปโดยส่วนใหญ่จะมีนาฬิกาที่ใช้ร่วมกันอย่างน้อย 2 นาฬิกา นาฬิกาหนึ่งสำหรับ CPU ความเร็วสูงของอุปกรณ์และอีก 1 หน่วยสำหรับ CPU ที่ช้าของอุปกรณ์ ผลที่ตามมาจากการดำเนินการนี้ นั่นคือ ถ้า CPU ที่รวดเร็ว 1 ตัวต้องทำงานด้วยความเร็วสูงสุด CPU ความเร็วอื่นๆ ก็ทำงานที่ความเร็วสูงสุดเช่นกัน

รายงานตัวอย่างที่แสดงในรูปที่ 4 แสดงเกมที่ใช้ประโยชน์จาก CPU อย่างไรก็ตาม ระดับการทำกิจกรรมในระดับสูงนี้จะให้พลังงานและความร้อนสูงมาก อย่างรวดเร็ว

หากต้องการลดการใช้พลังงานโดยรวม วิธีที่ดีที่สุดคือการให้ข้อมูลกับเครื่องจัดตารางเวลา งานที่สั้นลง เช่น การโหลดเสียง การเรียกใช้ชุดข้อความของผู้ปฏิบัติงาน และ ผู้ออกแบบท่าเต้นจะยึดตามชุด CPU ที่ช้าในอุปกรณ์ โอนงานนี้ไปยัง CPU ที่ช้าให้ได้มากที่สุดโดยที่ยังคงรักษา อัตราเฟรมที่ต้องการ

อุปกรณ์ส่วนใหญ่แสดง CPU ที่ช้าไว้ก่อน CPU ที่เร็ว แต่คุณไม่สามารถคาดเดาเองได้ว่า SOC ของอุปกรณ์จะใช้คำสั่งซื้อนี้ หากต้องการตรวจสอบ ให้เรียกใช้คำสั่งที่คล้ายกับคำสั่ง ที่แสดงในการค้นพบโทโพโลยีของ CPU โค้ด ใน GitHub

หลังจากที่ทราบว่า CPU ใดเป็น CPU ในอุปกรณ์แล้ว ให้ประกาศ กลุ่มความสนใจสำหรับชุดข้อความระยะสั้นของคุณ ซึ่งเครื่องจัดตารางเวลาของอุปกรณ์ ติดตาม โดยเพิ่มโค้ดต่อไปนี้ในแต่ละชุดข้อความ

#include <sched.h>
#include <sys/types.h>
#include <unistd.h>

pid_t my_pid; // PID of the process containing your thread.

// Assumes that cpu0, cpu1, cpu2, and cpu3 are the "slow CPUs".
cpu_set_t my_cpu_set;
CPU_ZERO(&my_cpu_set);
CPU_SET(0, &my_cpu_set);
CPU_SET(1, &my_cpu_set);
CPU_SET(2, &my_cpu_set);
CPU_SET(3, &my_cpu_set);
sched_setaffinity(my_pid, sizeof(cpu_set_t), &my_cpu_set);

ความเค้นจากความร้อน

เมื่ออุปกรณ์ร้อนเกินไป อุปกรณ์อาจควบคุม CPU และ/หรือ GPU ซึ่งอาจทำให้เกิด ส่งผลต่อเกมในลักษณะที่ไม่คาดคิด เกมที่มีกราฟิกซับซ้อนและมีรายละเอียดเยอะ การประมวลผลข้อมูล หรือกิจกรรมเครือข่ายที่ยั่งยืนมีแนวโน้มที่จะพบปัญหามากกว่า

ใช้ Thermal API เพื่อตรวจสอบการเปลี่ยนแปลงของอุณหภูมิในอุปกรณ์และดำเนินการเพื่อ จะรักษาการใช้พลังงานให้ต่ำลงและอุณหภูมิอุปกรณ์เย็นลง เมื่ออุปกรณ์รายงานว่า ความเค้นจากความร้อน ลดกิจกรรมต่อเนื่องเพื่อลด การใช้พลังงาน เช่น ลดอัตราเฟรมหรือการขายพื้นที่โฆษณาของรูปหลายเหลี่ยม

ขั้นแรก ให้ประกาศออบเจ็กต์ PowerManager และ เริ่มต้นในเมธอด onCreate() เพิ่ม Listener สถานะความร้อนลงในวัตถุ

class MainActivity : AppCompatActivity() {
    lateinit var powerManager: PowerManager

    override fun onCreate(savedInstanceState: Bundle?) {
        powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
        powerManager.addThermalStatusListener(thermalListener)
    }
}

public class MainActivity extends AppCompatActivity {
    PowerManager powerManager;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE);
        powerManager.addThermalStatusListener(thermalListener);
    }
}

กำหนดการดำเนินการที่จะทำเมื่อผู้ฟังตรวจพบสถานะ เปลี่ยน หากเกมของคุณใช้ C/C++ ให้เพิ่มโค้ดให้กับระดับสถานะความร้อนใน onThermalStatusChanged() เพื่อเรียกใช้โค้ดเกมของระบบโดยใช้ JNI หรือใช้ Thermal API แบบดั้งเดิม

val thermalListener = object : PowerManager.OnThermalStatusChangedListener() {
    override fun onThermalStatusChanged(status: Int) {
        when (status) {
            PowerManager.THERMAL_STATUS_NONE -> {
                // No thermal status, so no action necessary
            }

            PowerManager.THERMAL_STATUS_LIGHT -> {
                // Add code to handle light thermal increase
            }

            PowerManager.THERMAL_STATUS_MODERATE -> {
                // Add code to handle moderate thermal increase
            }

            PowerManager.THERMAL_STATUS_SEVERE -> {
                // Add code to handle severe thermal increase
            }

            PowerManager.THERMAL_STATUS_CRITICAL -> {
                // Add code to handle critical thermal increase
            }

            PowerManager.THERMAL_STATUS_EMERGENCY -> {
                // Add code to handle emergency thermal increase
            }

            PowerManager.THERMAL_STATUS_SHUTDOWN -> {
                // Add code to handle immediate shutdown
            }
        }
    }
}

PowerManager.OnThermalStatusChangedListener thermalListener =
    new PowerManager.OnThermalStatusChangedListener () {

    @Override
    public void onThermalStatusChanged(int status) {

        switch (status)
        {
            case PowerManager.THERMAL_STATUS_NONE:
                // No thermal status, so no action necessary
                break;

            case PowerManager.THERMAL_STATUS_LIGHT:
                // Add code to handle light thermal increase
                break;

            case PowerManager.THERMAL_STATUS_MODERATE:
                // Add code to handle moderate thermal increase
                break;

            case PowerManager.THERMAL_STATUS_SEVERE:
                // Add code to handle severe thermal increase
                break;

            case PowerManager.THERMAL_STATUS_CRITICAL:
                // Add code to handle critical thermal increase
                break;

            case PowerManager.THERMAL_STATUS_EMERGENCY:
                // Add code to handle emergency thermal increase
                break;

            case PowerManager.THERMAL_STATUS_SHUTDOWN:
                // Add code to handle immediate shutdown
                break;
        }
    }
};

เวลาในการตอบสนองของการแตะเพื่อแสดง

เกมที่แสดงเฟรมเร็วที่สุด จะสร้างสถานการณ์ที่เชื่อมโยงกับ GPU ที่เฟรมบัฟเฟอร์จะยัดเยียดมากเกินไป CPU ต้องรอ GPU ซึ่งทำให้เกิดความล่าช้าที่เห็นได้ชัดเจนระหว่างอินพุตของโปรแกรมเล่นกับอินพุต เอฟเฟกต์บนหน้าจอ

หากต้องการทราบว่าคุณสามารถปรับปรุงการกำหนดอัตราเฟรมของเกมให้ดีขึ้นได้หรือไม่ ให้ทำดังนี้ ขั้นตอนต่อไปนี้

1. สร้างรายงาน Systrace ที่มีหมวดหมู่ gfx และ input หมวดหมู่เหล่านี้มีการวัดผลที่เป็นประโยชน์อย่างยิ่งสำหรับการพิจารณา เวลาในการตอบสนองของหน้าจอสัมผัส

2. ตรวจสอบส่วน SurfaceView ของรายงาน Systrace บัฟเฟอร์มากเกินไป ทำให้จำนวนการดึงบัฟเฟอร์ที่รอดำเนินการอยู่อยู่ระหว่าง 1 ถึง 2 ดังที่แสดง ในรูปที่ 5:

   

หากต้องการลดความไม่สอดคล้องกันนี้ของการกำหนดอัตราการแสดงโฆษณาเฟรม ให้ทำตามขั้นตอนที่อธิบายไว้ให้เสร็จสมบูรณ์ ในส่วนต่อไปนี้

ผสานรวม Android Frame Pacing API ในเกม

Android Frame Pacing API ช่วยให้คุณ ทำการสลับเฟรมและกำหนดช่วงการสับเปลี่ยนเพื่อให้เกมของคุณรักษา อัตราเฟรมที่สม่ำเสมอยิ่งขึ้น

ลดความละเอียดของเนื้อหาที่ไม่ใช่ UI ของเกม

การแสดงผลบนอุปกรณ์เคลื่อนที่รุ่นใหม่มีพิกเซลจำนวนมากเกินกว่าที่โปรแกรมเล่นจะสามารถทำได้ ดังนั้น คุณสามารถลดตัวอย่างให้มีขนาด 5 หรือแม้แต่ 10 พิกเซลได้ มีสีเดียว จากโครงสร้างของแคชดิสเพลย์ส่วนใหญ่ ลดความละเอียดลงได้ด้านเดียวเท่านั้น

แต่อย่าลดความละเอียดขององค์ประกอบ UI ของเกม เป็นสิ่งสำคัญ เพื่อรักษาความหนาของเส้นในองค์ประกอบเหล่านี้เพื่อให้ใหญ่พอ ขนาดเป้าหมายการสัมผัสสําหรับ ผู้เล่นของคุณ

ความลื่นไหลในการแสดงผล

เมื่อ SurfaceFlinger ยึดไว้กับบัฟเฟอร์จอแสดงผลเพื่อแสดงฉากในเกม กิจกรรมของ CPU จะเพิ่มขึ้นชั่วขณะ หากกิจกรรมของ CPU ที่เพิ่มสูงขึ้นอย่างรวดเร็วเหล่านี้ คุณอาจจะเห็นการกระตุกในเกม แผนภาพในรูปที่ 6 จะแสดงสาเหตุดังนี้

หากเฟรมเริ่มวาดช้าเกินไปแม้จะผ่านไป 2-3 มิลลิวินาที เฟรมนั้นอาจพลาดไป หน้าต่างแสดงผลถัดไป เฟรมจะต้องรอจนกว่า Vsync ถัดไปจะถึง (33 มิลลิวินาทีเมื่อเล่นเกมที่ 30 FPS) ซึ่งทำให้ ความล่าช้าที่เห็นได้ชัดจากมุมมองของผู้เล่น

หากต้องการแก้ไขสถานการณ์นี้ ให้ใช้ Android Frame Pacing API ซึ่งจะนำเสนอเฟรมใหม่บน VSync แบบ Wavefront

สถานะหน่วยความจำ

เมื่อใช้งานเกมเป็นระยะเวลานาน อาจเป็นไปได้ว่า อุปกรณ์ของคุณพบข้อผิดพลาดเกี่ยวกับหน่วยความจำไม่พอ

ในกรณีนี้ ให้ตรวจสอบกิจกรรมของ CPU ในรายงาน Systrace และดูความถี่ ระบบกำลังเรียก Daemon kswapd หากมีการโทรจำนวนมาก ระหว่างการดำเนินการของเกม คุณควรสังเกตวิธีที่เกม กำลังจัดการและล้างหน่วยความจำ

ดูข้อมูลเพิ่มเติมได้ที่จัดการหน่วยความจำอย่างมีประสิทธิภาพในเกม

สถานะชุดข้อความ

เมื่อเลื่อนดูองค์ประกอบทั่วไปของรายงาน Systrace คุณสามารถดู ระยะเวลาที่ชุดข้อความนั้นใช้ในชุดข้อความที่เป็นไปได้แต่ละชุด โดยเลือก ชุดข้อความภายในรายงานดังที่แสดงในรูปที่ 7

ดังที่แสดงในรูปที่ 7 คุณอาจพบว่าชุดข้อความของเกมไม่ได้อยู่ใน "การวิ่ง" หรือ "runnable" ได้บ่อยเท่าที่ควร รายการต่อไปนี้ แสดงสาเหตุทั่วไปหลายประการที่ทำให้ชุดข้อความหนึ่งๆ อาจปรากฏขึ้นเป็นระยะๆ การเปลี่ยนไปยังสถานะที่ผิดปกติ:

• หากชุดข้อความอยู่ในโหมดสลีปเป็นเวลานาน เทรดอาจพบปัญหา จากการช่วงชิงล็อก หรือการรอกิจกรรมของ GPU
• หากชุดข้อความถูกบล็อกอย่างต่อเนื่องใน I/O แสดงว่าคุณอ่านข้อมูลมากเกินไป ออกจากดิสก์ได้ หรือเกมของคุณเกิดการขว้าง

แหล่งข้อมูลเพิ่มเติม

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการปรับปรุงประสิทธิภาพของเกม โปรดดูแหล่งข้อมูลต่อไปนี้ แหล่งข้อมูลเพิ่มเติม

วิดีโอ

• งานนำเสนอ Systrace for Games จาก Android Game Developer Summit 2018