Disk Cache: คืออะไร แคชดิสก์ iOS และหลักการทำงาน

Disk Cache ใน iOS คืออะไร?

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

iOS มีการแคชสองระดับหลัก: แบบระเอาได้ (NSCache, หน่วยความจำ) และแบบดิสก์ (URLCache, ระบบไฟล์) แคชดิสก์ช้ากว่าแคชแบบระเอาได้ 10–100 เท่า แต่เร็วกว่าการร้องขอเครือข่ายอย่างมาก — ความแตกต่างอาจสูงถึง 2 ถึง 3 ลำดับของขนาด กลยุทธ์ที่ดีที่สุดคือการใช้แคชสองระดับ: หน่วยความจำสำหรับข้อมูลร้อน และดิสก์สำหรับข้อมูลเย็น

ตาม Apple Performance Optimization Guide, 2023, Disk Cache ที่กำหนดค่าอย่างเหมาะสมช่วยลดเวลาโหลดเนื้อหาได้ 60–80% สำหรับการดูซ้ำ และลดการใช้ปริมาณทราฟิกได้ 40–70% สำหรับแอปพลิเคชันที่มีข้อมูลมัลติมีเดีย (ภาพ, วิดีโอ, เสียง), การแคชเป็นปัจจัย UX ที่สำคัญ

URLCache: กลไกการแคชในตัว

URLCache เป็นคลาส Foundation ในตัวที่ใช้งานแคชแบบรวมสำหรับคำขอ URLSession โดยจะบันทึกคำตอบของเซิร์ฟเวอร์ไว้บนดิสก์และหน่วยความจำโดยอัตโนมัติ และจัดการขนาดแคชและนโยบายการทำให้ใช้การไม่ได้โดยอัตโนมัติโดยอิง Cache-Control, Expires และ ETag เป็นต้น

import Foundation

let cache = URLCache(
    memoryCapacity: 50 * 1024 * 1024,
    diskCapacity: 200 * 1024 * 1024,
    diskPath: "network-cache"
)

URLCache.shared = cache

let config = URLSessionConfiguration.default
config.urlCache = cache
config.requestCachePolicy = .returnCacheDataElseLoad

let session = URLSession(configuration: config)

นโยบายการแคชของ URLCache กำหนดเมื่อใดควรใช้ข้อมูลในแคชและเมื่อใดควรทำคำขอใหม่ นโยบายหลักได้แก่: useProtocolCachePolicy (ตามส่วนหัวของเซิร์เวอร์), reloadIgnoringLocalCacheData (จากเซิร์เวอร์เสมอ), returnCacheDataElseLoad (แคชก่อน), returnCacheDataDontLoad (แคชเท่านั้น — โหมดออฟไลน์)

Cache-Control เป็นส่วนหัว HTTP ที่เซิร์เวอร์ส่งพร้อมกับคำตอบ, ระบุ max-age (อายุเป็นวินาที), must-revalidate (ตรวจสอบความสดส\u0ee25ะ), no-cache (ห้ามใช้โดยไม่มีการตรวจสอบ) และ no-store (ห้ามแคช) iOS ปฏิบัติตามส่วนหัวเหล่านี้อย่างเข้มงวดโดยอัตโนมัติเมื่อใช้ URLCache กับนโยบาย useProtocolCachePolicy

กลยุทธ์การแคชแบบกำหนดเองและการทำให้ใช้การไม่ได้

แคชแบบกำหนดเอง จำเป็นเมื่อ URLCache ในตัวไม่เพียงพอ — สำหรับการเก็บภาพที่ผ่านการประมวลผลแล้ว, โมเดลข้อมูลที่ถูกสร้างลำดับหรือผลลัพธ์การคำนวณ ในกรณีเหล่านี้, นักพัฒนาจะสร้างระบบแคชของตนเองโดยอิงไดเรกทอรี Caches ใน Sandbox ของแอปพลิเคชัน

class DiskCache<T: Codable> {
    private let cacheDir: URL
    private let encoder = JSONEncoder()
    private let decoder = JSONDecoder()

    init() {
        let paths = FileManager.default
            .urls(for: .cachesDirectory,
                     in: .userDomainMask)
        cacheDir = paths[0].appendingPathComponent(
            "data-cache", isDirectory: true
        )
        try? FileManager.default
            .createDirectory(at: cacheDir,
                             withIntermediateDirectories: true)
    }

    func set(value: T, for key: String) {
        let url = cacheDir.appendingPathComponent(
            SHA256.hash(key)
        )
        if let data = try? encoder.encode(value) {
            try? data.write(to: url)
        }
    }

    func get(for key: String) -> T? {
        let url = cacheDir.appendingPathComponent(
            SHA256.hash(key)
        )
        guard let data = try? Data(contentsOf: url) else { return nil }
        return try? decoder.decode(T.self, from: data)
    }

    func clearAll() {
        try? FileManager.default
            .removeItem(at: cacheDir)
    }
}

กลยุทธ์การทำให้แคชใช้การไม่ได้ กำหนดเมื่อข้อมูลที่เก็บไว้ถือว่าล้าสมัย: TTL (Time-To-Live) — ข้อมูลมีอายุคงหนึ่งหลังจากการเขียน; ตามเหตุการณ์ — การทำให้ใช้การไม่ได้โดยอิงตามเหตุการณ์ (เช่น การอัพเดทข้อมูลบนเซิร์เวอร์); ตามเวอร์ชัน — การทำให้ใช้การไม่ได้เมื่อเปลี่ยนแปลงเวอร์ชัน API หรือรูปแบบข้อมูล; LRU (Least Recently Used) — การลบรายการที่ไม่ได้ใช้เลยออกโดยอัตโนมัติเมื่อเกินขีดจำกัดด้านขนาด

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

ประสิทธิภาพและข้อจำกัดของแคช

ประสิทธิภาพของ Disk Cache วัดด้วย hit ratio — เปอร์เซินต์ของคำขอที่ได้รับจากแคชโดยไม่ต้องเรียกเครือข่าย hit ratio ทั่วไปสำหรับแคชรูปภาพที่กำหนดค่าอย่างดีคือ 70–90%, สำหรับคำตอบ API — 40–60%, สำหรับวิดีโอสตรีมมิ่ง — 30–50%

ข้อจำกัดของ Disk Cache ใน iOS: ระบบสามารถลบเนื้อหาของไดเรกทอรี Caches ได้ตลอดเวลาเมื่อพื้นที่วางบนดิสก์ไม่เพียงพอ พฤติกรรมนี้ไม่สามารถกำหนดค่าได้ — iOS เป็นผู้ตัดสินใจว่าจะลบไฟล์แคชเมื่อใดและไฟล์ใดบ้าง ดังนั้น, แคชไม่ควรมีข้อมูลที่ไม่สามารถกู้คืนจากเครือข่ายหรือแหล่งอื่นๆ

ผลกระทบต่อหน่วยความจำแฟลช: การเขียนบ่อยครั้งใน Disk Cache เร่งการสกุดหรือของหน่วยความจำแฟลช iOS ใช้ TRIM และ wear leveling เพื่อลดการสกุดหรือให้น้อยที่สุด แต่แนะนำให้นักพัฒนาหลีกเลี่ยงการเขียนมากเกินไป: อัพเดทแคชไม่เกินหนึ่งครั้งทุก 5 นาทีสำหรับไฟล์เดียวกัน; รวมการเขียนเล็กๆ เข้าด้วยกัน; ใช้ NSCache สำหรับข้อมูลชั่วคราวที่ไม่จำเป็นต้องเก็บไว้บนดิสก์

แนวปฏิบัติที่ดีที่สุดสำหรับการแคชใน iOS

แคชสองระดับ เป็นสถาปัตยกรรมมาตรฐานสำหรับแอปพลิเคชัน iOS: หน่วยความจำ (NSCache) สำหรับข้อมูลที่เข้าถึงบ่อยครั้ง และดิสก์ (URLCache หรือแบบกำหนดเอง) สำหรับข้อมูลที่ต้องคงอยู่ระหว่างเซสชัน อายุในหน่วยความจำ — นาที, บนดิสก์ — ชั่วโมงหรือวัน

การแคชรูปภาพ: ใช้ไลบรารีเฉพาะทาง (Kingfisher, SDWebImage, Nuke) ที่ใช้งานแคชสองระดับโดยมีการทำให้ใช้การไม่ได้โดยอัตโนมัติ, การจัดการหน่วยความจำ และการเขียนดิสก์แบบไม่อยู่กับการรองสัญเครื่องมือสื่อสาร การใช้งานแคชรูปภาพแบบกำหนดเองต้องคำนึงถึงการถอดรหัส, พื้นที่สี และการปรับขนาด

แคชและความปลอดภัย: อย่าแคชข้อมูลที่อ่อนไหว (รหัสผ่าน, โทเคน, ข้อมูลส่วนบุคคล) บนดิสก์โดยไม่มีการเข้ารหัส URLCache ไม่ได้เข้ารหัสข้อมูลโดยคุณสมบัติ — ใช้ NSFileProtection หรือการเข้ารหัสระดับแอปพลิเคชันสำหรับเนื้อหาที่อ่อนไหว สำหรับคำขอเครือข่ายที่ได้รับอนุญาต, ใช้นโยบาย .reloadIgnoringLocalCacheData

การตรวจสอบแคช: ติดตาม hit ratio, ขนาดแคชปัจจุบัน และจำนวนการเขียนต่อนาที หาก hit ratio ลดลงต่ำกว่า 30% แคชจะไม่มีประสิทธิภาพและจำเป็นต้องรับการปรับปรุงกลยุทธ์หรือเพิ่มขนาด ตาม Point-Free (2024), การตรวจสอบแคชเป็นหนึ่งในแนวปฏิบัติการปรับปรุงประสิทธิภาพแอปพลิเคชัน iOS ที่ถูกมองข้ามความสำคัญมากที่สุด