Thư mục Bộ nhớ đệm của Ứng dụng — Khái niệm, Mục đích và Cách Xóa trong Phát triển Di động

Thư mục Bộ nhớ đệm của Ứng dụng là gì?

Thư mục bộ nhớ đệm là một thư mục đặc biệt trong bộ nhớ trong (hoặc ngoài) của ứng dụng được thiết kế cho các tệp tạm thời. Sự khác biệt chính so với Internal Storage: hệ thống có quyền xóa tệp khỏi bộ nhớ đệm mà không cần thông báo nếu thiết bị thiếu dung lượng trống. Do đó, ứng dụng không bao giờ được lưu bản sao duy nhất của dữ liệu người dùng quan trọng trong bộ nhớ đệm. Bộ nhớ đệm phù hợp nhất cho hình ảnh đã tải xuống, phản hồi máy chủ, tài nguyên đã biên dịch trước và bất kỳ dữ liệu nào khác có thể được khôi phục từ xa hoặc tạo lại bằng chương trình.

Trên Android, thư mục bộ nhớ đệm nằm tại /data/data/<package>/cache/ và có thể truy cập qua context.cacheDir. Kích thước bộ nhớ đệm không bị giới hạn rõ ràng, nhưng Google Play khuyến nghị không vượt quá 100 MB vì ứng dụng có bộ nhớ đệm lớn thường nhận được đánh giá tiêu cực từ người dùng. Trên iOS, thư mục bộ nhớ đệm nằm trong vùng chứa Sandbox tại Library/Caches/ và có thể truy cập qua NSCachesDirectory. iOS có thể xóa tệp khỏi Caches khi khôi phục thiết bị từ bản sao lưu hoặc khi thiếu dung lượng nghiêm trọng — người dùng cần được thông báo về điều này trong tài liệu ứng dụng.

Hiểu dữ liệu nào có thể đặt an toàn trong bộ nhớ đệm và dữ liệu nào nên lưu trong Internal Storage hoặc Documents là kỹ năng quan trọng của nhà phát triển. Sử dụng bộ nhớ đệm không đúng cách dẫn đến hai vấn đề đối lập: hoặc ứng dụng chiếm quá nhiều dung lượng (nếu nhà phát triển lưu trong bộ nhớ đệm thứ đáng lẽ phải ở Documents) hoặc người dùng mất dữ liệu (nếu nhà phát triển lưu trong bộ nhớ đệm thứ đáng lẽ phải được lưu trữ vĩnh viễn). Hãy tuân theo một quy tắc đơn giản: nếu dữ liệu có thể khôi phục — bộ nhớ đệm, nếu không thể khôi phục — Internal Storage hoặc Documents.

Mục đích và Loại Dữ liệu được Lưu trong Bộ nhớ đệm

Các loại dữ liệu khác nhau có tốc độ tạo lại và yêu cầu không gian khác nhau. Hiểu các đặc điểm này giúp nhà phát triển chọn đúng tệp nào nên đặt trong bộ nhớ đệm và tệp nào trong bộ nhớ vĩnh viễn.

Bộ nhớ đệm Hình ảnh và Tệp Phương tiện

Loại dữ liệu được lưu trong bộ nhớ đệm phổ biến nhất là hình ảnh tải xuống từ mạng. Các thư viện Glide, Picasso và Coil tự động lưu hình ảnh đã tải xuống vào thư mục bộ nhớ đệm của ứng dụng. Kích thước bộ nhớ đệm hình ảnh điển hình trong ứng dụng xã hội dao động từ 50 đến 200 MB. Kích thước bộ nhớ đệm phụ thuộc vào độ phân giải màn hình thiết bị và lượng nội dung được xem. Glide sử dụng bộ nhớ đệm hai cấp: đầu tiên kiểm tra bộ nhớ đệm L1 trong RAM (thuật toán LRU), sau đó bộ nhớ đệm L2 trên đĩa. Điều này đảm bảo tải nhanh hình ảnh được xem nhiều lần mà không cần yêu cầu mạng bổ sung. Cấu hình kích thước tối đa của bộ nhớ đệm đĩa qua DiskCacheStrategy cho phép kiểm soát không gian chiếm dụng: khi vượt quá giới hạn, thư viện tự động xóa các tệp ít được sử dụng nhất.

val cacheDir = File(context.cacheDir, "image_cache")
val maxSize = 50 * 1024 * 1024 // 50 MB

val cache = DiskLruCache.open(cacheDir, 1, 1, maxSize)
cache.edit("key")?.let { editor ->
    editor.newOutputStream(0).use { stream ->
        // ghi dữ liệu vào bộ nhớ đệm
    }
}

Bộ nhớ đệm Yêu cầu Mạng

Phản hồi của yêu cầu API có thể được lưu vào bộ nhớ đệm để truy cập ngoại tuyến và giảm tải máy chủ. OkHttp cung cấp hỗ trợ bộ nhớ đệm tích hợp qua lớp Cache. Các tiêu đề phản hồi Cache-Control và ETag quản lý chính sách bộ nhớ đệm: máy chủ chỉ định thời gian phản hồi được coi là hợp lệ. Với cấu hình phù hợp, bộ nhớ đệm yêu cầu mạng có thể giảm thời gian tải dữ liệu 60–80% khi truy cập lại và cung cấp chức năng ứng dụng cơ bản mà không cần kết nối internet. Kích thước bộ nhớ đệm yêu cầu mạng hiếm khi vượt quá 10–20 MB, nhưng khi sử dụng nhiều có thể đạt 50 MB. Cấu hình kích thước bộ nhớ đệm tối đa qua hàm tạo OkHttpClient.Builder và kiểm tra tính hợp lệ của dữ liệu đã lưu trong bộ nhớ đệm mỗi khi khởi động ứng dụng.

Bộ nhớ đệm Cơ sở dữ liệu và Dữ liệu Biên dịch Trước

Cơ sở dữ liệu SQLite có thể tạo tệp tạm thời trong quá trình hoạt động: tệp WAL (Write-Ahead Log), nhật ký rollback và trang chỉ mục. Các tệp này được lưu cùng với cơ sở dữ liệu chính, nhưng đối với cơ sở dữ liệu tạm thời (ví dụ: tìm kiếm toàn văn bản hoặc phân tích), có thể chỉ định vị trí trong thư mục bộ nhớ đệm. Các chương trình shader OpenGL và Vulkan đã biên dịch trước cũng được lưu trong bộ nhớ đệm tại thư mục này, giúp tăng tốc lần tải đầu tiên của cảnh đồ họa. Trên iOS, NSCachesDirectory được khuyến nghị để lưu trữ dữ liệu Core Data đã biên dịch trước và các tệp xử lý hình ảnh tạm thời.

Cách Xóa Bộ nhớ đệm Hoạt động trên Android và iOS

Việc xóa bộ nhớ đệm có thể diễn ra tự động (bởi hệ thống) hoặc thủ công (bởi người dùng hoặc ứng dụng). Hiểu hành vi của hệ thống trong các tình huống khác nhau là cần thiết để ngăn mất dữ liệu.

Xóa Tự động bởi Hệ thống

Trên Android, hệ thống bắt đầu quá trình xóa bộ nhớ đệm khi dung lượng trống trên phân vùng /data giảm xuống dưới ngưỡng quan trọng (thường là 500 MB). Quá trình cacheflush phân tích kích thước bộ nhớ đệm của tất cả ứng dụng đã cài đặt và xóa các tệp ít được sử dụng nhất, bắt đầu từ tệp cũ nhất. Người dùng cũng có thể xóa thủ công bộ nhớ đệm của tất cả ứng dụng qua cài đặt hệ thống: “Cài đặt → Bộ nhớ → Bộ nhớ đệm → Xóa bộ nhớ đệm.” Trên iOS, việc xóa tự động Caches xảy ra khi khôi phục thiết bị từ bản sao lưu — iOS không khôi phục nội dung của Library/Caches/. Ngoài ra, iOS có thể xóa chọn lọc tệp khỏi Caches khi hết dung lượng trống, sử dụng cơ chế lưu trữ có thể xóa cho dữ liệu cách ly.

let fm = FileManager.default
let cachesURL = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let contents = try fm.contentsOfDirectory(
    at: cachesURL,
    includingPropertiesForKeys: nil
)
for fileURL in contents {
    try fm.removeItem(at: fileURL)
}

Xóa Bộ nhớ đệm theo Chương trình bởi Ứng dụng

Nhà phát triển có thể triển khai xóa bộ nhớ đệm theo chương trình theo yêu cầu của người dùng hoặc theo lịch trình. Trên Android, để xóa bộ nhớ đệm của chính ứng dụng, chỉ cần xóa tất cả tệp trong context.cacheDir và context.externalCacheDir. Trên iOS, hãy xóa nội dung của Library/Caches/ nhưng không xóa chính thư mục — chỉ xóa nội dung của nó. Khuyến nghị hiển thị cho người dùng kích thước bộ nhớ đệm hiện tại trong cài đặt ứng dụng cùng với nút “Xóa bộ nhớ đệm” có xác nhận. Theo Google Play Console, ứng dụng có nút xóa bộ nhớ đệm nhận được ít hơn 22% khiếu nại về thiếu dung lượng so với ứng dụng không có tính năng này. Xóa bộ nhớ đệm phải an toàn: ứng dụng phải xử lý chính xác tình huống khi các tệp đã lưu trong bộ nhớ đệm bị xóa và tải lại chúng một cách minh bạch khi truy cập tiếp theo.

Sự Khác biệt Giữa cacheDir trên Android và iOS

Mặc dù cùng mục đích, việc triển khai thư mục bộ nhớ đệm trên Android và iOS có những khác biệt đáng kể. Nhà phát triển cần tính đến chúng để ứng dụng hoạt động chính xác trên cả hai nền tảng.

Android cung cấp thư mục bộ nhớ đệm ngoài riêng qua context.externalCacheDir — nó nằm trên thẻ SD (nếu được cài đặt) và không bị xóa khi gỡ cài đặt ứng dụng. Điều này thuận tiện cho các tệp phương tiện lớn, nhưng tạo rủi ro để lại rác trên thẻ nhớ. iOS không có khái niệm bộ nhớ đệm ngoài: tất cả tệp tạm thời được lưu trong vùng chứa Sandbox và được đảm bảo xóa khi gỡ cài đặt. Trên Android, bộ nhớ đệm hiển thị với người dùng trong cài đặt ứng dụng và họ có thể xóa thủ công. Trên iOS, cài đặt hệ thống không hiển thị kích thước bộ nhớ đệm của từng ứng dụng — người dùng chỉ có thể xóa bộ nhớ đệm bằng cách xóa và cài đặt lại ứng dụng, trừ khi nhà phát triển đã thêm nút xóa trong giao diện.

Một khác biệt quan trọng — hành vi khi khôi phục. Trên iOS, khi khôi phục từ bản sao lưu iTunes hoặc iCloud, thư mục Caches không được khôi phục vì iOS cho rằng dữ liệu trong bộ nhớ đệm sẽ được tạo lại khi khởi động lần đầu. Trên Android, khi khôi phục từ Google Drive, chỉ Internal Storage được sao lưu — bộ nhớ đệm vẫn trống sau khi khôi phục. Trong cả hai trường hợp, ứng dụng phải hoạt động chính xác với bộ nhớ đệm trống, không hiển thị lỗi cho người dùng hoặc mất chức năng.

Khuyến nghị Quản lý Bộ nhớ đệm

Quản lý bộ nhớ đệm đúng cách là một trong những yếu tố ảnh hưởng đến trải nghiệm người dùng và xếp hạng ứng dụng. Các khuyến nghị sau đây sẽ giúp tránh các vấn đề điển hình và tăng sự hài lòng của người dùng.

• Đặt giới hạn kích thước cho bộ nhớ đệm. Sử dụng DiskLruCache hoặc thư viện tương tự với chỉ định dung lượng tối đa tính bằng megabyte. Khi vượt quá giới hạn, thư viện tự động xóa các tệp ít được sử dụng nhất
• Triển khai nút xóa bộ nhớ đệm trong cài đặt ứng dụng. Hiển thị kích thước bộ nhớ đệm hiện tại (ở định dạng “12,5 MB”) và yêu cầu xác nhận trước khi xóa. Sau khi xóa, cập nhật kích thước hiển thị
• Không lưu trong bộ nhớ đệm các tệp không thể khôi phục. Nếu dữ liệu quan trọng cho hoạt động của ứng dụng, hãy lưu chúng trong Internal Storage (Android) hoặc Documents (iOS), và chỉ đặt một bản sao trong bộ nhớ đệm để truy cập nhanh
• Kiểm tra khả dụng của bộ nhớ đệm ngoài trước khi ghi. Trên Android, context.externalCacheDir có thể trả về null nếu thẻ SD không được cài đặt hoặc không khả dụng. Luôn dự phòng sang bộ nhớ đệm trong
• Sử dụng chính sách TTL cho dữ liệu trong bộ nhớ đệm. Không lưu tệp lâu hơn cần thiết: cho hình ảnh — 24–48 giờ, cho phản hồi API — từ 5 phút đến 1 giờ tùy theo tần suất cập nhật dữ liệu

Thường xuyên theo dõi kích thước bộ nhớ đệm trong phân tích ứng dụng. Tích hợp báo cáo chỉ số kích thước bộ nhớ đệm vào Firebase Analytics hoặc hệ thống tương tự. Nếu kích thước bộ nhớ đệm trung bình vượt quá 100 MB, hãy tối ưu hóa chiến lược lưu vào bộ nhớ đệm: giảm TTL cho dữ liệu ít sử dụng, triển khai nén hình ảnh trước khi lưu vào bộ nhớ đệm (WebP thay vì PNG, giảm chất lượng JPEG xuống 85%), sử dụng phân trang để tải nội dung từ máy chủ. Hãy nhớ rằng người dùng có thiết bị 16–32 GB đặc biệt nhạy cảm với kích thước ứng dụng: khi bộ nhớ đệm đạt 200 MB, nhiều người dùng bắt đầu tìm cách xóa hoặc đơn giản là gỡ cài đặt ứng dụng. Theo khảo sát của Google, 38% người dùng đã xóa ít nhất một ứng dụng do bộ nhớ đệm tăng không kiểm soát và tiêu tốn dung lượng.