บันทึกสถานะ UI

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

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

หากต้องการลดช่องว่างระหว่างความคาดหวังของผู้ใช้กับลักษณะการทำงานของระบบ ให้ใช้ วิธีการต่อไปนี้ร่วมกัน

• ViewModel ออบเจ็กต์
• สถานะที่บันทึกไว้ในบริบทต่อไปนี้
  • Composable: rememberSerializable และ rememberSaveable
  • ViewModel: SavedStateHandle
• พื้นที่เก็บข้อมูลในเครื่องเพื่อคงสถานะ UI ไว้ในระหว่างการเปลี่ยนแอปและหน้าจอ

โซลูชันที่เหมาะสมที่สุดขึ้นอยู่กับความซับซ้อนของข้อมูล UI Use Case ของแอป และการหาสมดุลระหว่างความเร็วในการเข้าถึงข้อมูลกับการใช้หน่วยความจำ

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

ความคาดหวังของผู้ใช้และลักษณะการทำงานของระบบ

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

การปิดสถานะ UI ที่ผู้ใช้เริ่ม

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

• ปัดแอปออกจากหน้าจอภาพรวม (ล่าสุด)
• การปิดหรือบังคับปิดแอปจากหน้าจอการตั้งค่า
• รีบูตอุปกรณ์
• การดำเนินการ "เสร็จสิ้น" บางอย่าง (ซึ่งได้รับการสนับสนุนจาก Activity.finish())

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

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

การปิดสถานะ UI ที่ระบบเริ่มดำเนินการ

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

โปรดทราบว่าคุณสามารถลบล้างลักษณะการทำงานเริ่มต้นสำหรับการเปลี่ยนแปลงการกำหนดค่าได้ (แม้ว่าเราจะไม่แนะนำ) ดูรายละเอียดเพิ่มเติมได้ที่การจัดการ การเปลี่ยนแปลงการกำหนดค่า

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

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

ตัวเลือกในการเก็บรักษาสถานะ UI

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

ตัวเลือกแต่ละรายการสำหรับการรักษาสถานะ UI จะแตกต่างกันไปตามมิติข้อมูลต่อไปนี้ ซึ่งส่งผลต่อประสบการณ์ของผู้ใช้

ใช้ ViewModel เพื่อจัดการการเปลี่ยนแปลงการกำหนดค่า

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

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

ViewModel จะถูกทำลายในระหว่างการสิ้นสุดการประมวลผลที่ระบบเริ่มต้น ซึ่งต่างจากสถานะที่บันทึกไว้ หากต้องการโหลดข้อมูลซ้ำหลังจากที่ระบบเริ่มการสิ้นสุดการประมวลผลใน ViewModel ให้ใช้ SavedStateHandle API หรือหากข้อมูลเกี่ยวข้องกับ UI และไม่จำเป็นต้องเก็บไว้ใน ViewModel ให้ใช้ rememberSerializable สำหรับ ประเภทข้อมูลดั้งเดิมหรือสถานการณ์ที่คุณไม่ต้องการใช้ @Serializable ให้ใช้ rememberSaveable หากข้อมูลเป็นข้อมูลแอปพลิเคชัน การบันทึกลงในดิสก์อาจเป็นวิธีที่ดีกว่า

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

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

API เช่น rememberSerializable และ rememberSaveable ใน Compose และ SavedStateHandle ใน ViewModel จะจัดเก็บข้อมูลที่จำเป็นในการโหลดสถานะ UI อีกครั้งหากระบบทำลายและสร้างคอมโพเนนต์ใหม่ในภายหลัง SavedStateHandle รองรับ Kotlinx Serialization ผ่านส่วนขยาย saved {} เพื่อจัดการโครงสร้างข้อมูลที่ซับซ้อนได้อย่างมีประสิทธิภาพยิ่งขึ้น ซึ่งช่วยให้คุณจัดเก็บและกู้คืนออบเจ็กต์ที่ปลอดภัยตามประเภทได้อย่างราบรื่นควบคู่ไปกับประเภทดั้งเดิมมาตรฐาน ดูวิธี ใช้สถานะที่บันทึกไว้โดยใช้ rememberSaveable ได้ที่สถานะและ Jetpack Compose

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

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

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

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

ในทั้ง 2 กรณีนี้ คุณยังคงควรใช้ ViewModel เพื่อหลีกเลี่ยง การเสียรอบการโหลดข้อมูลจากฐานข้อมูลซ้ำๆ ในระหว่างการเปลี่ยนแปลงการกำหนดค่า

ในกรณีที่ข้อมูล UI ที่จะเก็บรักษานั้นเรียบง่ายและมีขนาดเล็ก คุณอาจใช้ API สถานะที่บันทึกไว้เพียงอย่างเดียวเพื่อเก็บรักษาข้อมูลสถานะ

เชื่อมต่อกับสถานะที่บันทึกไว้โดยใช้ SavedStateRegistry

ตั้งแต่ Fragment 1.1.0 หรือทรัพยากร Dependency แบบทรานซิทีฟ Activity 1.0.0 เป็นต้นไป คอมโพเนนต์ UI เช่น ComponentActivity จะใช้ SavedStateRegistryOwner และมี SavedStateRegistry ที่ เชื่อมโยงกับคอมโพเนนต์นั้น SavedStateRegistry ช่วยให้คอมโพเนนต์เชื่อมต่อกับ สถานะที่บันทึกไว้เพื่อใช้หรือมีส่วนร่วมในสถานะดังกล่าว เช่น Saved State module for ViewModel ใช้ SavedStateRegistry เพื่อสร้าง SavedStateHandle และส่งไปยังออบเจ็กต์ ViewModel คุณสามารถดึงข้อมูลSavedStateRegistryจากเจ้าของวงจรผลิตภัณฑ์ได้โดยโทรไปที่ savedStateRegistry

คอมโพเนนต์ที่มีส่วนทำให้เกิดสถานะที่บันทึกไว้ต้องใช้ SavedStateRegistry.SavedStateProvider ซึ่งกำหนดเมธอดเดียวที่ชื่อ saveState() เมธอด saveState() ช่วยให้คอมโพเนนต์ของคุณ ส่งคืน Bundle ที่มีสถานะใดๆ ที่ควรบันทึกจากคอมโพเนนต์นั้น SavedStateRegistry จะเรียกใช้เมธอดนี้ในระหว่างระยะการบันทึกสถานะของวงจรของเจ้าของวงจร

  class SearchManager : SavedStateRegistry.SavedStateProvider {
      companion object {
          private const val QUERY = "query"
      }

      private val query: String? = null

      ...

      override fun saveState(): Bundle {
          return bundleOf(QUERY to query)
      }
  }

หากต้องการลงทะเบียน SavedStateProvider ให้โทรหา registerSavedStateProvider() ใน SavedStateRegistry โดยส่งคีย์เพื่อเชื่อมโยงกับข้อมูลของผู้ให้บริการและผู้ให้บริการ ระบบจะเรียกข้อมูลที่บันทึกไว้ก่อนหน้านี้สำหรับผู้ให้บริการได้จากสถานะที่บันทึกไว้โดยการเรียกใช้ consumeRestoredStateForKey() ใน SavedStateRegistry โดยส่งคีย์ที่เชื่อมโยงกับข้อมูลของผู้ให้บริการ

ภายใน ComponentActivity คุณสามารถลงทะเบียน SavedStateProvider ใน onCreate() หลังจากโทรหา super.onCreate() หรือจะตั้งค่า LifecycleObserver ใน SavedStateRegistryOwner ซึ่งใช้ LifecycleOwner และลงทะเบียน SavedStateProvider เมื่อ เกิดเหตุการณ์ ON_CREATE ก็ได้ การใช้ LifecycleObserver จะช่วยให้คุณแยกการลงทะเบียนและการดึงข้อมูลสถานะที่บันทึกไว้ก่อนหน้านี้ออกจาก SavedStateRegistryOwner เองได้

  class SearchManager(registryOwner: SavedStateRegistryOwner) : SavedStateRegistry.SavedStateProvider {
      companion object {
          private const val PROVIDER = "search_manager"
          private const val QUERY = "query"
      }

      private val query: String? = null

      init {
          // Register a LifecycleObserver for when the Lifecycle hits ON_CREATE
          registryOwner.lifecycle.addObserver(LifecycleEventObserver { _, event ->
              if (event == Lifecycle.Event.ON_CREATE) {
                  val registry = registryOwner.savedStateRegistry

                  // Register this object for future calls to saveState()
                  registry.registerSavedStateProvider(PROVIDER, this)

                  // Get the previously saved state and restore it
                  val state = registry.consumeRestoredStateForKey(PROVIDER)

                  // Apply the previously saved state
                  query = state?.getString(QUERY)
              }
          }
      }

      override fun saveState(): Bundle {
          return bundleOf(QUERY to query)
      }

      ...
  }

  class SearchActivity : ComponentActivity() {
    private var searchManager = SearchManager(this)

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Set up your Compose UI here
        setContent {
            // ...
        }
    }
  }

ใช้การคงอยู่ของข้อมูลในเครื่องเพื่อจัดการการสิ้นสุดการประมวลผลสำหรับข้อมูลที่ซับซ้อนหรือมีขนาดใหญ่

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

ทั้ง ViewModel และสถานะที่บันทึกโดยใช้ rememberSerializable, rememberSaveable หรือ SavedStateHandle ไม่ใช่โซลูชันการจัดเก็บข้อมูลระยะยาวและ จึงไม่สามารถใช้แทนที่เก็บข้อมูลในเครื่อง เช่น ฐานข้อมูล แต่คุณควรใช้กลไกเหล่านี้เพื่อจัดเก็บสถานะ UI ชั่วคราวเท่านั้น และใช้พื้นที่เก็บข้อมูลแบบถาวรสำหรับข้อมูลแอปอื่นๆ ดูรายละเอียดเพิ่มเติมเกี่ยวกับวิธีใช้ประโยชน์จากที่เก็บข้อมูลในเครื่องเพื่อคงข้อมูลโมเดลแอปในระยะยาว (เช่น เมื่อรีสตาร์ทอุปกรณ์) ได้ที่คำแนะนำเกี่ยวกับสถาปัตยกรรมของแอป

การจัดการสถานะ UI: แบ่งและพิชิต

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

• การคงอยู่ของข้อมูลในเครื่อง: จัดเก็บข้อมูลแอปพลิเคชันทั้งหมดที่คุณไม่ต้องการให้สูญหายหาก คุณเปิดและปิดแอป
  • ตัวอย่าง: คอลเล็กชันของออบเจ็กต์เพลง ซึ่งอาจมีไฟล์เสียง และข้อมูลเมตา
• ViewModel: จัดเก็บข้อมูลทั้งหมดที่จำเป็นต่อการแสดง UI ที่เชื่อมโยงไว้ในหน่วยความจำ ซึ่งก็คือสถานะ UI ของหน้าจอ
  • ตัวอย่าง: ออบเจ็กต์เพลงของการค้นหาล่าสุดและคำค้นหาล่าสุด
• สถานะที่บันทึกไว้ (rememberSerializable, rememberSaveable และ SavedStateHandle): จัดเก็บข้อมูลจำนวนเล็กน้อยที่จำเป็นต่อการโหลดสถานะ UI อีกครั้ง หากระบบหยุดทำงานแล้วสร้าง UI ขึ้นมาใหม่ แทนที่จะจัดเก็บออบเจ็กต์ที่ซับซ้อนไว้ที่นี่ ให้จัดเก็บออบเจ็กต์ที่ซับซ้อนไว้ในพื้นที่เก็บข้อมูลในเครื่องและจัดเก็บรหัสที่ไม่ซ้ำกันสำหรับออบเจ็กต์เหล่านี้ใน API สถานะที่บันทึกไว้
  • ตัวอย่าง: จัดเก็บคำค้นหาล่าสุด

ตัวอย่างเช่น ลองพิจารณาแอปที่ให้คุณค้นหาในคลังเพลง วิธีจัดการเหตุการณ์ต่างๆ มีดังนี้

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

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

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

คืนค่าสถานะที่ซับซ้อน: ประกอบชิ้นส่วนใหม่

เมื่อถึงเวลาที่ผู้ใช้กลับมาที่แอป จะมีสถานการณ์ที่เป็นไปได้ 2 อย่าง ในการสร้าง UI ขึ้นใหม่ ดังนี้

• ระบบจะสร้าง UI ขึ้นใหม่หลังจากที่ระบบสิ้นสุดกระบวนการสมัคร ระบบได้บันทึกการค้นหาโดยใช้ API สถานะที่บันทึกไว้ ViewModel (ใช้ SavedStateHandle) หรือ Composable (ใช้ rememberSerializable หรือ rememberSaveable) จะกู้คืนการค้นหาโดยอัตโนมัติ หากฟังก์ชันที่ใช้ร่วมกันได้ กู้คืนการค้นหา ฟังก์ชันจะส่งการค้นหาไปยัง ViewModel ViewModel พบว่าไม่มีผลการค้นหาที่แคชไว้ จึงมอบหมายให้โหลดผลการค้นหาโดยใช้คำค้นหาที่ระบุ
• ระบบจะสร้าง UI ใหม่หลังจากการเปลี่ยนแปลงการกำหนดค่า เนื่องจากไม่ได้ทำลายViewModelอินสแตนซ์ ViewModelจึงมีข้อมูลทั้งหมด ที่แคชไว้ในหน่วยความจำและไม่จำเป็นต้องค้นหาฐานข้อมูลอีกครั้ง

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

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

• เอกสารประกอบเลเยอร์ UI
• การบันทึกสถานะ UI ใน Compose
• เอกสารประกอบเกี่ยวกับสถานะและ Jetpack Compose

Codelab

• สถานะใน Jetpack Compose
• สถานะขั้นสูงและผลสะท้อนใน Jetpack Compose

ดูเนื้อหา

• บันทึกสถานะ UI (มุมมอง)