ประสิทธิภาพที่ดีขึ้นผ่านการแยกชุดข้อความ

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

เทรดหลัก

เมื่อผู้ใช้เปิดแอปของคุณ Android จะสร้าง Linux ใหม่ ประมวลผลพร้อมด้วยเทรดการดำเนินการ ชุดข้อความหลักนี้ หรือที่เรียกว่าเทรด UI จะรับผิดชอบต่อทุกอย่างที่เกิดขึ้น บนหน้าจอ การเข้าใจวิธีการทำงานสามารถช่วยให้คุณออกแบบแอปโดยใช้ เทรดหลักเพื่อประสิทธิภาพที่ดีที่สุด

ภายใน

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

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

ขณะที่มีภาพเคลื่อนไหวหรือการอัปเดตหน้าจอเกิดขึ้น ระบบจะพยายามเรียกใช้ บล็อกการทำงาน (ซึ่งรับผิดชอบการวาดหน้าจอ) ทุกๆ 16 มิลลิวินาทีโดยประมาณ เพื่อให้แสดงผลได้อย่างราบรื่นที่ 60 เฟรมต่อวินาที ระบบต้องใช้ลำดับชั้น UI/มุมมอง เพื่อให้ระบบบรรลุเป้าหมายนี้ ต้องอัปเดตในเทรดหลัก อย่างไรก็ตาม เมื่อคิวข้อความของชุดข้อความหลัก มีงานที่ยาวเกินไปหรือยาวเกินไปสำหรับเทรดหลัก ทำให้การอัปเดตเสร็จสมบูรณ์เร็วพอ แอปพลิเคชันควรย้ายงานนี้ให้ผู้ปฏิบัติงาน ชุดข้อความ หากเทรดหลักดำเนินการบล็อกงานเสร็จภายใน 16 มิลลิวินาทีไม่ได้ ผู้ใช้อาจสังเกตเห็นว่ามีการค้าง กระตุก หรือขาดการตอบสนองของ UI ต่อการป้อนข้อมูล ถ้าเทรดหลักบล็อกเป็นเวลาประมาณ 5 วินาที ระบบจะแสดง แอปพลิเคชัน กล่องโต้ตอบ "ไม่ตอบสนอง" (ANR) ที่ให้ผู้ใช้ปิดแอปได้โดยตรง

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

ชุดข้อความและการอ้างอิงออบเจ็กต์ UI

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

ปัญหาเกี่ยวกับข้อมูลอ้างอิงจัดอยู่ในหมวดหมู่ที่แตกต่างกัน 2 หมวดหมู่ ได้แก่ ข้อมูลอ้างอิงที่ชัดแจ้ง และการอ้างอิงโดยนัย

การอ้างอิงที่โจ่งแจ้ง

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

ตัวอย่างเช่น ลองพิจารณาแอปที่มีการอ้างอิงโดยตรงไปยังออบเจ็กต์ UI ใน เทรดผู้ปฏิบัติงาน ออบเจ็กต์ในเทรดผู้ปฏิบัติงานอาจมีการอ้างอิงไปยัง View; แต่ก่อนที่งานจะเสร็จสมบูรณ์ View ออกจากลำดับชั้นการแสดงผลแล้ว เมื่อการทำงาน 2 อย่างนี้เกิดขึ้นพร้อมกัน การอ้างอิงจะเก็บออบเจ็กต์ View ไว้ในหน่วยความจำและตั้งค่าพร็อพเพอร์ตี้ไว้ แต่ผู้ใช้จะไม่ วัตถุนี้และแอปจะลบวัตถุเมื่อการอ้างอิงวัตถุหายไป

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

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

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

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

การอ้างอิงโดยนัย

ข้อบกพร่องในการออกแบบโค้ดที่พบบ่อยกับออบเจ็กต์แบบแยกชุดข้อความสามารถดูได้ในข้อมูลโค้ด ด้านล่างนี้

Kotlin

class MainActivity : Activity() {
    // ...
    inner class MyAsyncTask : AsyncTask<Unit, Unit, String>() {
        override fun doInBackground(vararg params: Unit): String {...}
        override fun onPostExecute(result: String) {...}
    }
}

Java

public class MainActivity extends Activity {
  // ...
  public class MyAsyncTask extends AsyncTask<Void, Void, String>   {
    @Override protected String doInBackground(Void... params) {...}
    @Override protected void onPostExecute(String result) {...}
  }
}

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

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

วิธีแก้ไขอีกอย่างหนึ่งคือ ยกเลิกและล้างข้อมูลงานที่ทำอยู่เบื้องหลังเสมอ Callback ของวงจร Activity รายการ เช่น onDestroy วิธีการนี้สามารถ แต่ก็น่าเบื่อหน่ายและเกิดข้อผิดพลาดได้ง่าย ตามกฎทั่วไป คุณไม่ควรใส่ตรรกะที่ซับซ้อนและไม่ใช้ UI ในกิจกรรมโดยตรง นอกจากนี้ AsyncTask ได้เลิกใช้งานแล้ว ไม่แนะนำสำหรับใช้ในโค้ดใหม่ โปรดดูชุดข้อความใน Android สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับตัวแปรพื้นฐานแบบพร้อมกันที่คุณใช้งานได้

วงจรชีวิตของชุดข้อความและกิจกรรมบนแอป

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

ชุดข้อความที่คงอยู่

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

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

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

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

การจัดการการตอบสนองในวงจรด้วยตนเองสำหรับออบเจ็กต์ชุดข้อความทั้งหมดอาจกลายเป็น มีความซับซ้อนมาก หากคุณไม่ได้จัดการอย่างถูกต้อง แอปของคุณอาจได้รับผลกระทบจาก ปัญหาการช่วงชิงหน่วยความจำและประสิทธิภาพ การรวม ViewModel ด้วย LiveData ช่วยให้คุณทำสิ่งต่อไปนี้ได้ โหลดข้อมูลและรับการแจ้งเตือนเมื่อมีการเปลี่ยนแปลง โดยไม่ต้องกังวลเกี่ยวกับวงจร ออบเจ็กต์ ViewModel รายการ หนึ่งวิธีแก้ปัญหานี้ ViewModels จะได้รับการดูแลในการเปลี่ยนแปลงการกำหนดค่า เป็นวิธีง่ายๆ ในการรักษาข้อมูลมุมมองของคุณไว้ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ ViewModels โปรดดู คู่มือ ViewModel และดูข้อมูลเพิ่มเติมเกี่ยวกับ LiveData โปรดดูคู่มือ LiveData หากคุณ และต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับสถาปัตยกรรมแอปพลิเคชัน โปรดอ่าน คำแนะนำเกี่ยวกับสถาปัตยกรรมแอป

ลำดับความสำคัญของชุดข้อความ

ตามที่อธิบายไว้ในกระบวนการ และวงจรของแอปพลิเคชัน ลำดับความสำคัญที่ชุดข้อความของแอปจะได้รับ ส่วนหนึ่งจะขึ้นอยู่กับว่าแอปอยู่ ณ จุดใดในวงจรของแอป เมื่อคุณสร้างและ จัดการชุดข้อความในแอปพลิเคชันของคุณ คุณจึงต้องกำหนดลำดับความสำคัญ ชุดข้อความที่เหมาะสมจะได้รับลำดับความสำคัญที่เหมาะสมในเวลาที่ใช่ หากตั้งค่าไว้สูงเกินไป เทรดอาจขัดจังหวะเธรด UI และ RenderThread ซึ่งทําให้แอป วางเฟรม หากตั้งค่าต่ำเกินไป คุณอาจทำงานแบบไม่พร้อมกัน (เช่น รูปภาพ ) ช้ากว่าที่ควรจะเป็น

ทุกครั้งที่สร้างชุดข้อความ คุณควรเรียกใช้ setThreadPriority() ชุดข้อความของระบบ เครื่องจัดตารางเวลาจะให้ความสำคัญกับชุดข้อความที่มีลำดับความสำคัญสูง และทำให้ชุดข้อความเหล่านั้นมีความสมดุล ที่จำเป็นสำคัญเพื่อให้งานทั้งหมดสำเร็จลุล่วงในที่สุด โดยทั่วไปชุดข้อความ ในเบื้องหน้า จะได้รับประมาณ 95% ของเวลาการดำเนินการทั้งหมดจากอุปกรณ์ ในขณะที่ จะได้รับประมาณ 5%

นอกจากนี้ระบบยังกำหนดค่าลำดับความสำคัญของตนเองให้กับแต่ละเธรดโดยใช้ Process ชั้นเรียน

โดยค่าเริ่มต้น ระบบจะตั้งค่าลำดับความสำคัญของชุดข้อความเป็นลำดับความสำคัญและกลุ่มเดียวกัน การเป็นสมาชิกเป็นชุดข้อความที่สร้างขึ้น อย่างไรก็ตาม แอปพลิเคชันของคุณสามารถ โปรดปรับลำดับความสำคัญของชุดข้อความโดยใช้ setThreadPriority()

Process ช่วยลดความซับซ้อนในการกำหนดค่าลำดับความสำคัญด้วยการให้ ชุดค่าคงที่ที่แอปของคุณสามารถใช้เพื่อกำหนดลำดับความสำคัญของชุดข้อความ ตัวอย่างเช่น THREAD_PRIORITY_DEFAULT แสดงค่าเริ่มต้นสำหรับชุดข้อความ แอปของคุณควรตั้งค่าลำดับความสำคัญของชุดข้อความเป็น THREAD_PRIORITY_BACKGROUND สำหรับชุดข้อความที่ทำงานไม่เร่งด่วน

แอปของคุณใช้ THREAD_PRIORITY_LESS_FAVORABLE ได้ และ THREAD_PRIORITY_MORE_FAVORABLE เป็นค่าคงที่ที่เพิ่มขึ้นเพื่อกำหนดลำดับความสำคัญที่เกี่ยวข้อง สำหรับรายการ ลำดับความสำคัญของชุดข้อความ โปรดดู ค่าคงที่ THREAD_PRIORITY ใน ชั้นเรียน Process

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ ในการจัดการชุดข้อความ โปรดดูเอกสารอ้างอิงเกี่ยวกับ Thread และ Process ชั้นเรียน

คลาสตัวช่วยสำหรับชุดข้อความ

สำหรับนักพัฒนาซอฟต์แวร์ที่ใช้ Kotlin เป็นภาษาหลัก เราขอแนะนำให้ใช้โครูทีน Coroutines ให้ประโยชน์มากมาย รวมทั้งการเขียนโค้ดแบบอะซิงโครนัสโดยไม่มี Callback และ การเกิดขึ้นพร้อมกันแบบมีโครงสร้างสำหรับการกำหนดขอบเขต การยกเลิก และการจัดการข้อผิดพลาด

เฟรมเวิร์กนี้ยังมีคลาส Java และ Primitive เดียวกันเพื่ออำนวยความสะดวก ชุดข้อความ เช่น Thread, Runnable และ Executors ชั้นเรียน รวมถึงรายการอื่นๆ เช่น HandlerThread ดูข้อมูลเพิ่มเติมได้ที่ชุดข้อความใน Android

คลาส HandlerThread

เทรดของตัวแฮนเดิลคือเทรดระยะยาวอย่างมีประสิทธิภาพที่จะดึงงานจากคิวมาประมวลผล ในนั้น

ลองพิจารณาความท้าทายทั่วไปในการรับเฟรมตัวอย่างจาก ออบเจ็กต์ Camera รายการ เมื่อคุณลงทะเบียนเฟรมตัวอย่างของกล้องถ่ายรูป คุณจะได้รับใน onPreviewFrame() Callback ที่เรียกใช้ในชุดข้อความของเหตุการณ์ หากสิ่งนี้ มีการเรียกใช้ Callback ในเทรด UI ซึ่งเป็นงานในการจัดการกับพิกเซลขนาดใหญ่ อาร์เรย์จะขัดขวางการแสดงผลและการประมวลผลเหตุการณ์

ในตัวอย่างนี้ เมื่อแอปมอบสิทธิ์คำสั่ง Camera.open() ให้กับ บล็อกการทำงานในเธรดของตัวแฮนเดิล วันที่ onPreviewFrame() Callback จะเข้าสู่เทรดของเครื่องจัดการแทนเธรด UI ดังนั้นหากคุณจะทําเป็นระยะเวลานาน ทำงานบนพิกเซล นี่อาจเป็นวิธีแก้ปัญหาที่ดีกว่าสำหรับคุณ

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

คลาส ThreadPoolExecutor

มีงานบางประเภทที่อาจลด ให้ขนานกันมาก งานที่แจกจ่าย ตัวอย่างเช่น งานหนึ่งคือการคำนวณตัวกรอง บล็อกขนาด 8x8 ของรูปภาพ 8 เมกะพิกเซล ด้วยปริมาณของแพ็กเก็ตงานจำนวนมาก HandlerThread ไม่ใช่ชั้นเรียนที่เหมาะสมที่จะใช้

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

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

คุณควรสร้างชุดข้อความกี่รายการ

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

ในทางปฏิบัติ มีตัวแปรจำนวนมากที่ทำให้เกิดเหตุการณ์นี้ เลือกค่า (เช่น 4 สำหรับเงื่อนไขเริ่มต้น) และทดสอบกับ Systrace เท่ากับ สร้างกลยุทธ์ได้เช่นเดียวกับที่อื่นๆ คุณสามารถใช้การลองผิดลองถูกเพื่อค้นหา จำนวนเธรดขั้นต่ำที่คุณสามารถใช้ได้โดยไม่พบปัญหา

อีกปัจจัยหนึ่งในการพิจารณาจำนวนชุดข้อความที่ควรมีคือชุดข้อความ ไม่ฟรี แต่ต้องใช้หน่วยความจำ เทรดแต่ละรายการจะมีหน่วยความจำอย่างน้อย 64K ยอดดังกล่าวจะเพิ่มขึ้นอย่างรวดเร็วในหลายๆ แอปที่ติดตั้งบนอุปกรณ์ โดยเฉพาะอย่างยิ่งใน ที่ Call Stacks เติบโตขึ้นอย่างมาก

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