แนวทางปฏิบัติแนะนำเกี่ยวกับการจัดการหน่วยความจำ

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

บทนำ

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

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

สิ่งที่ควรทำก่อนติดต่อทีมสนับสนุน

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

ป้องกันหน่วยความจำรั่ว

ทําตามแนวทางปฏิบัติแนะนําเหล่านี้เพื่อช่วยหลีกเลี่ยงสาเหตุที่พบบ่อยที่สุดบางส่วนที่ทําให้เกิด หน่วยความจำรั่วในโค้ดที่ใช้ Google SDK

แนวทางปฏิบัติแนะนำสำหรับแอป Android

ตรวจสอบว่าคุณได้ทำสิ่งต่อไปนี้ทั้งหมดในแอปพลิเคชัน Android แล้ว

1. ปล่อยทรัพยากรที่ไม่ได้ใช้
2. ยกเลิกการลงทะเบียน Listener เมื่อไม่ต้องการใช้แล้ว
3. ยกเลิกงานเมื่อไม่จำเป็น
4. ส่งต่อเมธอดวงจรเพื่อปล่อยทรัพยากร
5. ใช้ SDK เวอร์ชันล่าสุด
6. หลีกเลี่ยงการบล็อกเทรดหลักระหว่างการเริ่มต้นเพื่อป้องกัน ANR

ดูรายละเอียดเฉพาะสำหรับแนวทางปฏิบัติแต่ละข้อได้ที่ส่วนต่อไปนี้

ปล่อยทรัพยากรที่ไม่ได้ใช้

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

ปล่อยการอ้างอิง GoogleMap ที่ไม่มีอัปเดตใน GeoSDK

ข้อผิดพลาดที่พบบ่อยคือ GoogleMap อาจทำให้เกิดหน่วยความจำรั่วไหลหากแคชโดยใช้ NavigationView หรือ MapView GoogleMap มีความสัมพันธ์แบบ 1 ต่อ 1 กับ NavigationView หรือ MapView ที่ดึงข้อมูลมา คุณต้องตรวจสอบว่าไม่มีการแคช GoogleMap หรือปล่อยการอ้างอิงเมื่อมีการเรียก NavigationView#onDestroy หรือ MapView#onDestroy หากใช้ NavigationSupportFragment, MapSupportFragment หรือ Fragment ของคุณเองที่ครอบมุมมองเหล่านี้ คุณต้องปล่อยการอ้างอิงใน Fragment#onDestroyView

class NavFragment : SupportNavigationFragment() {

  var googleMap: GoogleMap?

  override fun onCreateView(
    inflater: LayoutInflater,
    parent: ViewGroup?,
    savedInstanceState: Bundle?,
  ): View  {
    super.onCreateView(inflater,parent,savedInstanceState)
    getMapAsync{map -> googleMap = map}
  }

  override fun onDestroyView() {
    googleMap = null
  }
}

ยกเลิกการลงทะเบียน Listener เมื่อไม่ต้องการใช้แล้ว

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

ตัวอย่างเช่น สมมติว่าแอปพลิเคชันของคุณใช้ Navigation SDK และเรียกใช้ Listener ต่อไปนี้เพื่อรอเหตุการณ์การมาถึง addArrivalListener เพื่อรอเหตุการณ์การมาถึง แอปพลิเคชันควรเรียกใช้ removeArrivalListener เมื่อไม่จําเป็นต้องตรวจสอบเหตุการณ์การมาถึงอีกต่อไป

var arrivalListener: Navigator.ArrivalListener? = null

fun registerNavigationListeners() {
  arrivalListener =
    Navigator.ArrivalListener {
      ...
    }
  navigator.addArrivalListener(arrivalListener)
}

override fun onDestroy() {
  navView.onDestroy()
  if (arrivalListener != null) {
    navigator.removeArrivalListener(arrivalListener)
  }

  ...
  super.onDestroy()
}

ยกเลิกงานเมื่อไม่จำเป็น

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

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

ส่งต่อวิธีการวงจรเพื่อปล่อยทรัพยากร

หากแอปใช้ SDK การนำทางหรือ Maps ให้ตรวจสอบว่าได้เผยแพร่ ทรัพยากรโดยส่งต่อเมธอดวงจรของแอป (แสดงเป็นตัวหนา) ไปยัง navView แล้ว คุณทำได้โดยใช้ NavigationView ใน Navigation SDK หรือ MapView ใน Maps หรือ Navigation SDK นอกจากนี้ คุณยังใช้ SupportNavigationFragment หรือ SupportMapFragment แทนการใช้ NavigationView และ MapView โดยตรงได้ด้วย ตามลำดับ Support Fragments จะจัดการการส่งต่อเมธอดวงจร

หมายเหตุ: NavViewActivity ในโค้ดต่อไปนี้หมายถึงกิจกรรมที่ลูกค้ากำหนด ซึ่งคุณอาจสร้างขึ้น

class NavViewActivity : AppCompatActivity() {

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    ...
    navView = ...
    navView.onCreate(savedInstanceState)
    ...
  }

  override fun onSaveInstanceState(savedInstanceState: Bundle) {
    super.onSaveInstanceState(savedInstanceState)
    navView.onSaveInstanceState(savedInstanceState)
  }

  override fun onTrimMemory(level: Int) {
    super.onTrimMemory(level)
    navView.onTrimMemory(level)
  }

  /* Same with
    override fun onStart()
    override fun onResume()
    override fun onPause()
    override fun onConfigurationChanged(...)
    override fun onStop()
    override fun onDestroy()
  */
}

ใช้ SDK เวอร์ชันล่าสุด

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

หลีกเลี่ยงการบล็อกเทรดหลักระหว่างการเริ่มต้นเพื่อป้องกัน ANR

เมื่อแอปบล็อกเทรดหลักนานเกินไป อาจทำให้เกิดข้อผิดพลาด "แอปพลิเคชันไม่ตอบสนอง" (ANR) เพื่อป้องกันไม่ให้เกิด ANR ให้ใช้วิธีการของวงจร อย่างonCreate() ให้มีน้ำหนักเบาที่สุดเท่าที่จะเป็นไปได้โดยการเลื่อนงานที่ใช้เวลานาน ออกไปหรือเรียกใช้ในเทรดอื่นที่ไม่ใช่เทรดหลัก

หากต้องการหลีกเลี่ยง ANR ที่เกี่ยวข้องกับการเริ่มต้น SDK ให้ทำดังนี้

• สร้างอินสแตนซ์แผนที่ได้ครั้งละ 1 รายการเท่านั้น
• ลดการทำงานในเทรด UI ให้ได้มากที่สุดขณะสร้างอินสแตนซ์ของ แผนที่

แก้ไขข้อบกพร่องหน่วยความจำรั่วไหล

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

ก่อนเริ่มต้นใช้งาน คุณควรทำความคุ้นเคยกับวิธีที่ Android จัดการหน่วยความจำ ดูข้อมูลได้ที่ภาพรวมการจัดการหน่วยความจำของ Android

หากต้องการแก้ไขข้อบกพร่องของหน่วยความจำรั่ว ให้ทำตามกระบวนการต่อไปนี้

1. จำลองการเกิดปัญหา ขั้นตอนนี้จำเป็นต่อการแก้ไขข้อบกพร่อง
2. ตรวจสอบว่าการใช้งานหน่วยความจำเป็นไปตามที่คาดไว้หรือไม่ ตรวจสอบว่า การใช้งานที่เพิ่มขึ้นซึ่งดูเหมือนจะเป็นการรั่วไหลนั้นไม่ใช่หน่วยความจำ ที่จำเป็นต่อการเรียกใช้แอปพลิเคชัน
3. แก้ไขข้อบกพร่องในระดับสูง คุณใช้ยูทิลิตีหลายอย่างเพื่อแก้ไขข้อบกพร่องได้ ชุดเครื่องมือมาตรฐาน 3 ชุดช่วยในการแก้ไขข้อบกพร่องเกี่ยวกับปัญหาด้านหน่วยความจำใน Android ได้แก่ Android Studio, Perfetto และยูทิลิตีบรรทัดคำสั่ง Android Debug Bridge (adb)
4. ตรวจสอบการใช้หน่วยความจำของแอป รับฮีปดัมป์และติดตามการจัดสรร แล้ววิเคราะห์
5. แก้ไขหน่วยความจำรั่ว

ส่วนต่อไปนี้จะอธิบายขั้นตอนเหล่านี้โดยละเอียด

ขั้นตอนที่ 1: ทำซ้ำปัญหา

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

• ระบบจะเปิดใช้งานฟีเจอร์ชุดใด

• ลำดับการดำเนินการของผู้ใช้ที่เฉพาะเจาะจงใดที่ทำให้เกิดการรั่วไหล

  • คุณได้ลองเปิดใช้งานลําดับนี้หลายครั้งแล้วหรือยัง

• แอปผ่านสถานะวงจรใดมาบ้าง

  • คุณได้ลองทำซ้ำหลายครั้งในสถานะวงจรที่แตกต่างกันแล้วหรือยัง

ตรวจสอบว่าคุณสามารถจำลองปัญหาใน SDK เวอร์ชันล่าสุดได้ ปัญหาจากเวอร์ชันก่อนหน้าอาจได้รับการแก้ไขแล้ว

ขั้นตอนที่ 2: ตรวจสอบว่าการใช้งานหน่วยความจำของแอปเป็นไปตามที่คาดไว้หรือไม่

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

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

• การใช้งานหน่วยความจำที่คาดไว้: ระบบจะเรียกคืนหน่วยความจำหลังจากหยุดสถานการณ์

• การใช้งานหน่วยความจำที่อาจคาดการณ์ได้: การใช้งานหน่วยความจำเพิ่มขึ้นในช่วงระยะเวลาหนึ่ง แล้วค่อยๆ ลดลง ซึ่งอาจเกิดจากแคชที่มีขอบเขตหรือการใช้งานหน่วยความจำอื่นๆ ที่คาดการณ์ได้

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

ขั้นตอนที่ 3: แก้ข้อบกพร่องในระดับสูง

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

• เครื่องมือสร้างโปรไฟล์หน่วยความจำของ Android Studio (แนะนำ)

• ตัวนับหน่วยความจำของ Perfetto

• ยูทิลิตีบรรทัดคำสั่งของ Android Debug Bridge (adb)

• การติดตามการจัดสรร

เครื่องมือสร้างโปรไฟล์หน่วยความจำของ Android Studio

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

ตัวนับหน่วยความจำ Perfetto

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

ยูทิลิตีบรรทัดคำสั่งของ Android Debug Bridge (adb)

ข้อมูลส่วนใหญ่ที่คุณติดตามได้ด้วย Perfetto ยังมีให้ใช้งานเป็นadb ยูทิลิตีบรรทัดคำสั่งที่คุณสามารถค้นหาได้โดยตรง ตัวอย่างที่สำคัญ มีดังนี้

• Meminfo ช่วยให้คุณ ดูข้อมูลหน่วยความจำโดยละเอียด ณ จุดใดจุดหนึ่งได้

• Procstats แสดงสถิติรวมที่สำคัญบางอย่างในช่วงระยะเวลาหนึ่ง

สถิติที่สำคัญซึ่งควรดูในที่นี้คือร่องรอยการใช้หน่วยความจำที่ใช้สูงสุด (maxRSS) ที่แอปต้องการเมื่อเวลาผ่านไป MaxPSS อาจไม่แม่นยำเท่า ดูวิธีเพิ่มความแม่นยําได้ที่adb shell dumpsys procstats --help –start-testing

การติดตามการจัดสรร

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

ขั้นตอนที่ 4: ตรวจสอบการใช้หน่วยความจำของแอปด้วยฮีปดัมป์

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

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

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

Android Studio สามารถตรวจหาหน่วยความจำรั่วที่ GC แก้ไขไม่ได้ เมื่อคุณบันทึกฮีปดัมป์แล้ว Android Studio จะตรวจสอบว่ามีกิจกรรมหรือ Fragment ที่ยังเข้าถึงได้แต่ถูกทำลายไปแล้วหรือไม่

1. บันทึกฮีปดัมป์
2. วิเคราะห์ฮีปดัมป์เพื่อค้นหาหน่วยความจำรั่วไหล
3. แก้ไขหน่วยความจำรั่ว

โปรดดูรายละเอียดที่หัวข้อด้านล่าง

บันทึกฮีปดัมป์

หากต้องการบันทึกฮีปดัมป์ คุณสามารถใช้ Android Debug Bridge (adb) หรือ เครื่องมือสร้างโปรไฟล์หน่วยความจำของ Android Studio

ใช้ adb เพื่อบันทึกฮีปดัมป์

หากต้องการบันทึกฮีปดัมป์โดยใช้ adb ให้ทำตามขั้นตอนต่อไปนี้

1. เชื่อมต่ออุปกรณ์ Android กับคอมพิวเตอร์
2. เปิด Command Prompt แล้วไปที่ไดเรกทอรีที่มีเครื่องมือ adb

3. หากต้องการบันทึกฮีปดัมป์ ให้เรียกใช้คำสั่งนี้

   adb shell am dumpheap my.app.name $PHONE_FILE_OUT

4. หากต้องการเรียกข้อมูลฮีปดัมป์ ให้เรียกใช้คำสั่งนี้

   adb pull $PHONE_FILE_OUT $LOCAL_FILE.

ใช้ Android Studio เพื่อบันทึกฮีปดัมป์

หากต้องการบันทึกฮีปดัมป์โดยใช้เครื่องมือสร้างโปรไฟล์หน่วยความจำของ Android Studio ให้ทำตามขั้นตอนเหล่านี้ในส่วนบันทึกฮีปดัมป์ของ Android

วิเคราะห์ฮีปดัมป์เพื่อค้นหาหน่วยความจำรั่วไหล

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

1. เปิดโปรเจ็กต์ Android ใน Android Studio

2. เลือกเรียกใช้ แล้วเลือกการกำหนดค่าแก้ไขข้อบกพร่อง

3. เปิดแท็บ Android Profiler

4. เลือกความทรงจำ

5. เลือกเปิด Heap Dump แล้วเลือกไฟล์ Heap Dump ที่คุณสร้างขึ้น โปรไฟล์หน่วยความจำจะแสดงกราฟการใช้งานหน่วยความจำของแอป

6. ใช้กราฟเพื่อวิเคราะห์ฮีปดัมป์

   • ระบุออบเจ็กต์ที่ไม่ได้ใช้งานแล้ว

   • ระบุออบเจ็กต์ที่ใช้หน่วยความจำมาก

   • ดูว่าออบเจ็กต์แต่ละรายการใช้หน่วยความจำเท่าใด

7. ใช้ข้อมูลนี้เพื่อจำกัดหรือค้นหาแหล่งที่มาของหน่วยความจำรั่วไหลและแก้ไข

หมายเหตุ: ปัญหาที่ทราบ ใน Android Studio ทำให้ขนาดที่รายงานไว้ไม่ถูกต้อง ขนาด อาจประเมินต่ำหรือสูงเกินไปอย่างมาก ขึ้นอยู่กับเวอร์ชันของ Android Studio Google ขอแนะนำให้ใช้ขนาดแบบตื้นสำหรับการวิเคราะห์หน่วยความจำ

ขั้นตอนที่ 5: แก้ไขหน่วยความจำรั่ว

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

• ตรวจสอบว่าแอปจัดสรรและยกเลิกการจัดสรรหน่วยความจำตามที่แนะนำในหัวข้อ Android จัดการหน่วยความจำของแอป

• นําโค้ดหรือทรัพยากรที่ไม่ได้ใช้ออกจากแอป ดูรายละเอียดสําหรับแอป Android ได้ที่แนวทางปฏิบัติแนะนําสําหรับแอป Android

เครื่องมือแก้ไขข้อบกพร่องอื่นๆ

หลังจากทำตามขั้นตอนเหล่านี้แล้ว หากยังไม่พบและแก้ไข หน่วยความจำรั่ว ให้ลองใช้เครื่องมือต่อไปนี้

• แก้ไขข้อบกพร่องของหน่วยความจำในโค้ดแบบเนทีฟด้วยการติดตามการจัดสรร
• ระบุการรั่วไหลด้วย LeakCanary

แก้ไขข้อบกพร่องของหน่วยความจำในโค้ดแบบเนทีฟด้วยการติดตามการจัดสรร

แม้ว่าคุณจะไม่ได้ใช้โค้ดแบบเนทีฟโดยตรง แต่ไลบรารี Android ทั่วไปหลายรายการ ก็ใช้ รวมถึง Google SDK หากคิดว่าหน่วยความจำรั่วไหลอยู่ในโค้ดแบบเนทีฟ คุณสามารถใช้เครื่องมือหลายอย่าง เพื่อแก้ไขข้อบกพร่องได้ การติดตามการจัดสรรด้วย Android Studio หรือ heapprofd (ใช้ได้กับ Perfetto ด้วย) เป็นวิธีที่ยอดเยี่ยมในการระบุสาเหตุที่อาจทำให้เกิด หน่วยความจำรั่วไหล และมักเป็นวิธีที่เร็วที่สุดในการแก้ไขข้อบกพร่อง

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

ระบุหน่วยความจำรั่วด้วย LeakCanary

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

หมายเหตุ: เกี่ยวกับ LeakCanary และ SDK ของ Google Maps หรือ Navigation หลังจากที่ทำลายกิจกรรมหรือ Fragment ที่มี MapView แล้ว Maps SDK หรือ Navigation SDK อาจเก็บไว้ไม่เกิน 1 นาทีเพื่อวัตถุประสงค์ในการบันทึก เนื่องจาก LeakCanary ตรวจพบหน่วยความจำรั่วทันทีหลังจากที่กิจกรรมหรือ Fragment ถูกทำลาย จึงอาจรายงานกิจกรรมหรือ Fragment เป็นหน่วยความจำรั่ว Google แนะนําให้รอ 1 นาที แล้วจึงบันทึกฮีปดัมป์เพื่อดูว่า กิจกรรมหรือ Fragment ที่ถูกทําลายแล้วยังอยู่ในหน่วยความจําหรือไม่

วิธีรายงานปัญหาเกี่ยวกับ Google SDK

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

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

• Heap Dump ที่บันทึกจากแอปของคุณพร้อมปัญหาที่จำลองขึ้นใหม่ บันทึก Heap dumps ใน 2 ช่วงเวลาที่แตกต่างกันซึ่งแสดงให้เห็นว่าการใช้งานหน่วยความจำ เพิ่มขึ้นอย่างมาก

• หากคาดว่าจะเกิดหน่วยความจำรั่วไหลในโค้ดเนทีฟ ให้แชร์เอาต์พุตการติดตามการจัดสรรจาก heapprofd

• รายงานข้อบกพร่องที่สร้างขึ้นหลังจากที่คุณจำลองเงื่อนไขการรั่วไหลอีกครั้ง

• สแต็กเทรซของข้อขัดข้องที่เกี่ยวข้องกับหน่วยความจำ

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