SharedPreferences: ที่จัดเก็บคีย์-ค่า Android คืออะไร

SharedPreferences คืออะไร?

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

แต่ละไฟล์ SharedPreferences เชื่อมโยงกับชื่อเฉพาะและโหมดการเข้าถึง โดยค่าเริ่มต้นใช้โหมด Context.MODE_PRIVATE ซึ่งจำกัดการเข้าถึงไฟล์เฉพาะแอปปัจจุบันเท่านั้น ก่อนหน้านี้ Android รองรับโหมด MODE_WORLD_READABLE และ MODE_WORLD_WRITEABLE แต่ถูกประกาศให้เลิกใช้ตั้งแต่ API Level 17 และถูกลบออกทั้งหมดใน Android 7.0 (API 24) ด้วยเหตุผลด้านความปลอดภัย

แม้จะมีความเรียบง่าย SharedPreferences ถูกใช้ในแอป Android นับล้าน ตามข้อมูลของ Google แอปมากกว่า 90% ที่เผยแพร่บน Google Play ใช้ SharedPreferences ในการจัดเก็บการตั้งค่า อย่างไรก็ตาม สำหรับสถานการณ์ที่ซับซ้อน (ข้อมูลปริมาณมาก ความปลอดภัยของชนิดข้อมูล อะซิงโครนัส) Google แนะนำโซลูชันที่ทันสมัยกว่า เช่น Preferences DataStore จากไลบรารี Android Jetpack

รูปแบบการจัดเก็บ: XML บนอุปกรณ์

ทางกายภาพ SharedPreferences ถูกจัดเก็บเป็นไฟล์ XML ในไดเรกทอรีของแอป: /data/data/{package_name}/shared_prefs/{file_name}.xml ไฟล์ประกอบด้วยองค์ประกอบราก <map> พร้อมองค์ประกอบย่อย <string>, <int>, <boolean>, <float> และ <long> ขึ้นอยู่กับชนิดของค่าที่จัดเก็บ ขนาดไฟล์ไม่จำกัด แต่สำหรับข้อมูลปริมาณมาก (เกิน 100 KB) ประสิทธิภาพการอ่านและเขียนเริ่มลดลงอย่างเห็นได้ชัด

ไฟล์ SharedPreferences ไม่ได้ถูกเข้ารหัสโดยค่าเริ่มต้น ข้อมูลถูกจัดเก็บเป็นข้อความธรรมดาในระบบไฟล์ของอุปกรณ์ สำหรับการจัดเก็บข้อมูลที่ละเอียดอ่อน (โทเค็น รหัสผ่าน) แนะนำให้ใช้ EncryptedSharedPreferences จากไลบรารี AndroidX Security ซึ่งเข้ารหัสคีย์และค่าโดยอัตโนมัติด้วย AES256-GCM

SharedPreferences ทำงานอย่างไรใน Android

SharedPreferences ทำงานบนหลักการแคชในหน่วยความจำพร้อมการซิงโครไนซ์กับดิสก์เป็นระยะ เมื่อเข้าถึงไฟล์ครั้งแรก (ผ่าน getSharedPreferences) Android จะโหลดไฟล์ XML ไปยัง RAM และแยกวิเคราะห์เป็นออบเจกต์ Map การอ่านครั้งต่อไปทั้งหมดจะทำจากหน่วยความจำโดยไม่ต้องอ่านจากดิสก์ซ้ำ ซึ่งช่วยให้เข้าถึงข้อมูลได้รวดเร็ว

การเขียนใช้ Editor — บัฟเฟอร์การเปลี่ยนแปลงภายใน เมื่อนักพัฒนาเรียก putString หรือ putBoolean การเปลี่ยนแปลงจะถูกเก็บในออบเจกต์ Editor ในหน่วยความจำ การเขียนลงดิสก์จริงเกิดขึ้นเมื่อเรียกเมธอด commit (ซิงโครนัส) หรือ apply (อะซิงโครนัส) จนกว่าจะเรียกเมธอดเหล่านี้ ข้อมูลจะไม่ถูกบันทึก และหากแอปขัดข้องโดยไม่คาดคิด การเปลี่ยนแปลงอาจสูญหาย

โหมดการเข้าถึงและบริบท

การรับอินสแตนซ์ของ SharedPreferences ใช้สองเมธอด: getPreferences และ getSharedPreferences เมธอดแรกใช้ได้เฉพาะภายใน Activity และสร้างไฟล์ตามชื่อ Activity เมธอดที่สองยืดหยุ่นกว่า รับชื่อไฟล์และโหมดการเข้าถึง และเข้าถึงได้จากบริบทใดก็ได้ (Application, Activity, Service) แนะนำให้ใช้ getSharedPreferences กับชื่อไฟล์ที่ตรงกับโมดูลหรือฟังก์ชันของแอป

// การรับ SharedPreferences
val prefs = context.getSharedPreferences(
    "user_settings", Context.MODE_PRIVATE
)

// การเขียนข้อมูล
with(prefs.edit()) {
    putString("username", "แอนนา")
    putInt("age", 28)
    putBoolean("isLoggedIn", true)
    apply()
}

// การอ่านข้อมูล
val username = prefs.getString("username", "")
val age = prefs.getInt("age", 0)
val isLoggedIn = prefs.getBoolean("isLoggedIn", false)

เมื่อใช้ MODE_MULTI_PROCESS (เลิกใช้) SharedPreferences จะซิงโครไนซ์ระหว่างกระบวนการ อย่างไรก็ตาม การซิงโครไนซ์นี้ไม่รับประกันความเป็นอะตอม และ Google แนะนำให้หลีกเลี่ยง SharedPreferences ในสถานการณ์หลายกระบวนการ สำหรับกรณีเช่นนี้ ควรใช้ ContentProvider, Room ที่เข้าถึงระหว่างกระบวนการ หรือ DataStore

เมธอดหลักของ SharedPreferences

SharedPreferences จัดเตรียมชุดเมธอดสำหรับอ่านข้อมูลตามคีย์และอินเทอร์เฟซ Editor สำหรับเขียน แต่ละเมธอดอ่านรับพารามิเตอร์สองตัว: คีย์และค่าเริ่มต้นที่จะส่งคืนหากไม่พบคีย์ ค่าเริ่มต้นยังกำหนดชนิดที่ส่งคืน: getString ส่งคืน String, getInt ส่งคืน Int และอื่น ๆ

Editor และ apply เทียบกับ commit

Editor เป็นออบเจกต์ภายในของ SharedPreferences ที่รวบรวมการเปลี่ยนแปลงในบัฟเฟอร์ หลังจากทำการเปลี่ยนแปลงทั้งหมด นักพัฒนาเรียก commit() (เขียนแบบซิงโครนัส) หรือ apply() (เขียนแบบอะซิงโครนัส) ความแตกต่างสำคัญ: commit บล็อกเธรดปัจจุบันจนกว่าจะเขียนลงดิสก์เสร็จและส่งคืน boolean (สำเร็จ/ล้มเหลว) ในขณะที่ apply ทำการเขียนในเธรดพื้นหลังและส่งคืนการควบคุมทันทีแต่ไม่ส่งคืนผลลัพธ์

แนะนำให้ใช้ apply แทน commit ในทุกกรณีที่ไม่จำเป็นต้องทราบผลการเขียน apply เร็วกว่าและไม่บล็อกเธรด UI ควรใช้ commit เฉพาะเมื่อจำเป็นต้องทราบว่าข้อมูลถูกบันทึกสำเร็จหรือไม่ หรือเมื่อทำงานกับโหมดหลายกระบวนการ สำหรับการลบคีย์แต่ละรายการ ใช้เมธอด remove สำหรับการล้างทั้งหมด — clear การลบทั้งหมดก็ทำผ่าน Editor เช่นกัน

// การเปลี่ยนแปลงหลายรายการ - apply เดียว
prefs.edit {
    putString("theme", "dark")
    putBoolean("notifications", false)
    remove("old_key")
}

// ตัวฟังการเปลี่ยนค่า
prefs.registerOnSharedPreferenceChangeListener { prefs, key ->
    Log.d("TAG", "คีย์เปลี่ยนแล้ว: $key")
}

ตั้งแต่ Android 12 (API 31) SharedPreferences ได้รับการเสริมด้วยการสนับสนุน registerOnSharedPreferenceChangeListener พร้อมยกเลิกการสมัครอัตโนมัติผ่าน Lifecycle ซึ่งช่วยหลีกเลี่ยงการรั่วไหลของหน่วยความจำที่เกี่ยวข้องกับ listener ที่ถูกลืม ในเวอร์ชันเก่า นักพัฒนาต้องเรียก unregisterOnSharedPreferenceChangeListener ด้วยตนเองใน onDestroy หรือ onStop ของคอมโพเนนต์

SharedPreferences เทียบกับทางเลือกการจัดเก็บ

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

DataStore — ทางเลือกที่ทันสมัย

DataStore เป็นไลบรารี Android Jetpack ที่ Google นำเสนอเพื่อแทนที่ SharedPreferences มีสองรูปแบบ: Preferences DataStore (คีย์-ค่า เหมือน SharedPreferences) และ Proto DataStore (การจัดเก็บแบบระบุชนิดผ่าน Protocol Buffers) DataStore ใช้ coroutine และ Flow สำหรับการทำงานแบบอะซิงโครนัส รับประกันความปลอดภัยของชนิดข้อมูล และจัดการการโยกย้ายเวอร์ชันโดยอัตโนมัติ Google แนะนำ DataStore สำหรับโปรเจกต์ใหม่ทั้งหมด

ข้อได้เปรียบหลักของ DataStore คือความเป็นอะซิงโครนัสที่ระดับ API การอ่านทั้งหมดส่งคืน Flow และการเขียนเป็นฟังก์ชัน suspend ซึ่งกำจัดการบล็อกเธรด UI ที่อาจเกิดขึ้นกับการอ่านแบบซิงโครนัสของ SharedPreferences โดยสิ้นเชิง นอกจากนี้ DataStore รับประกันความสอดคล้องของข้อมูล: การเขียนทำในธุรกรรม และเมื่อล้มเหลว การเปลี่ยนแปลงทั้งหมดจะถูกย้อนกลับ

ตัวอย่างการใช้ SharedPreferences ในแอป

ลองพิจารณาตัวอย่างที่ใช้งานได้จริง: การตั้งค่าธีม (สว่าง/มืด/ระบบ) ในแอป Android ผู้ใช้เลือกธีม และตัวเลือกถูกบันทึกใน SharedPreferences เมื่อเปิดแอปในครั้งถัดไป ธีมจะถูกกู้คืนจากการตั้งค่าที่บันทึกไว้ สำหรับการอัปเดต UI แบบตอบสนอง ใช้การสังเกตการเปลี่ยนแปลงผ่าน SharedPreferences.OnSharedPreferenceChangeListener

การบันทึกการตั้งค่าผู้ใช้

มาสร้างคลาส ThemePreferences ที่ห่อหุ้มการทำงานทั้งหมดกับ SharedPreferences สำหรับธีม คลาสให้เมธอด getTheme (อ่าน), setTheme (เขียน) และ observeTheme (สังเกต) ชื่อไฟล์การตั้งค่าจะเป็น “app_preferences” ด้วยโหมด MODE_PRIVATE เพื่อความสะดวก คีย์ถูกวางใน companion object เป็นค่าคงที่

class ThemePreferences(context: Context) {
    companion object {
        private const val PREF_NAME = "app_preferences"
        private const val KEY_THEME = "theme_mode"
        const val THEME_LIGHT = "light"
        const val THEME_DARK = "dark"
        const val THEME_SYSTEM = "system"
    }

    private val prefs = context
        .getSharedPreferences(PREF_NAME, Context.MODE_PRIVATE)

    fun getTheme(): String =
        prefs.getString(KEY_THEME, THEME_SYSTEM) ?: THEME_SYSTEM

    fun setTheme(theme: String) {
        prefs.edit { putString(KEY_THEME, theme) }
    }

    fun observeTheme(callback: (String) -> Unit) {
        prefs.registerOnSharedPreferenceChangeListener { _, key ->
            if (key == KEY_THEME) {
                callback.invoke(getTheme())
            }
        }
    }
}

ใน Activity หรือ Fragment การรับอินสแตนซ์ ThemePreferences ทำผ่านบริบทของแอป เมื่อเริ่มต้น เรียก getTheme เพื่อตั้งค่าธีมปัจจุบัน เมื่อผู้ใช้เลือกธีมใหม่ เรียก setTheme และผ่าน observeTheme อินเทอร์เฟซถูกอัปเดตโดยไม่ต้องรีสตาร์ท Activity สิ่งสำคัญคือต้องยกเลิกการสมัคร listener ใน onDestroy เพื่อป้องกันการรั่วไหลของหน่วยความจำ โดยเฉพาะหาก Activity ถูกสร้างใหม่เมื่อเปลี่ยนการกำหนดค่า

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