Hệ thống tệp của thiết bị di động: định nghĩa, cấu trúc thư mục và cách hoạt động

Hệ thống tệp thiết bị di động là gì?

Hệ thống tệp là một thành phần phần mềm của hệ điều hành quản lý cách dữ liệu được ghi, đọc và tổ chức trên phương tiện vật lý. Trên thiết bị di động, hệ thống tệp thực hiện các chức năng quan trọng: quản lý không gian bộ nhớ flash, kiểm soát truy cập tệp dựa trên quyền, ghi nhật ký thay đổi để khôi phục sau sự cố và tối ưu hóa ghi có tính đến đặc điểm của bộ nhớ flash NAND.

Không giống như hệ điều hành máy tính để bàn, hệ thống tệp di động được thiết kế có tính đến số lượng chu kỳ ghi lại hạn chế của bộ nhớ flash. Các ô NAND có thể chịu được số lần xóa giới hạn — từ 3.000 đến 10.000 chu kỳ cho bộ nhớ TLC và MLC tương ứng. Để kéo dài tuổi thọ lưu trữ, hệ thống tệp sử dụng cơ chế cân bằng mài mòn (wear leveling) và lệnh TRIM. F2FS, được Samsung phát triển dành riêng cho bộ nhớ flash, xem xét hình dạng mảng NAND và đặt dữ liệu theo cách giảm thiểu phân mảnh và số lượng thao tác xóa khối.

Các thiết bị di động hiện đại sử dụng kết hợp nhiều hệ thống tệp. Bộ nhớ trong (phân vùng /data) được định dạng là EXT4 hoặc F2FS trên Android và APFS trên iOS. Thẻ SD theo truyền thống sử dụng exFAT cho tệp lớn hơn 4 GB hoặc FAT32 để tương thích tối đa. Phân vùng /system trên Android thường được gắn chỉ đọc và sử dụng EXT4 hoặc EROFS (Enhanced Read-Only File System) — một hệ thống tệp nén do Huawei phát triển để giảm kích thước phân vùng hệ thống.

Cấu trúc thư mục trên Android

Hệ thống phân cấp thư mục của Android dựa trên cấu trúc Linux với thư mục gốc tại /. Mỗi phân vùng có hệ thống tệp, quyền truy cập và mục đích riêng. Ứng dụng chỉ có thể truy cập một tập hợp thư mục giới hạn — phần còn lại được bảo vệ bởi quyền root.

Phân vùng /data và sandbox ứng dụng

Phân vùng /data là phân vùng chính để lưu trữ dữ liệu người dùng, ứng dụng đã cài đặt và cài đặt của chúng. Mỗi ứng dụng nhận được thư mục riêng tại /data/data/<package_name>/. Bên trong thư mục này, hệ thống tự động tạo các thư mục con: files/ cho tệp ứng dụng, cache/ cho tệp tạm thời, databases/ cho cơ sở dữ liệu SQLite, shared_prefs/ cho SharedPreferences. Quyền truy cập vào thư mục này được thiết lập khi cài đặt ứng dụng và không thể thay đổi nếu không có quyền root. Phân vùng /data được định dạng là F2FS trên hầu hết các thiết bị hiện đại, cung cấp tốc độ ghi ngẫu nhiên cao hơn tới 40% so với EXT4.

Phân vùng /system và các thành phần hệ thống

Phân vùng /system chứa hệ điều hành, ứng dụng hệ thống và thư viện. Phân vùng này được gắn ở chế độ chỉ đọc để ngăn chặn việc sửa đổi vô tình hoặc độc hại các tệp hệ thống. Trên các thiết bị có Android 10+ và Project Treble, phân vùng /system là động và có thể được cập nhật qua gói OTA mà không cần flash lại toàn bộ. Đối với ứng dụng, phân vùng /system không thể truy cập được — cố gắng ghi sẽ gây ra SecurityException. Tuy nhiên, ứng dụng có thể đọc một số tệp từ /system, như phông chữ hệ thống và tệp cấu hình, nếu chúng có quyền phù hợp.

Điểm gắn kết /sdcard

Điểm gắn kết /sdcard là một liên kết tượng trưng đến phân vùng lưu trữ ngoài được mô phỏng hoặc vật lý. Trên thiết bị không có thẻ SD, /sdcard trỏ đến một phân vùng con bên trong /data được chỉ định cho truy cập chia sẻ. Phân vùng này hiển thị với người dùng khi thiết bị được kết nối với máy tính qua giao thức MTP. Ứng dụng truy cập /sdcard thông qua quyền READ_EXTERNAL_STORAGE và WRITE_EXTERNAL_STORAGE, và từ Android 10 — thông qua Scoped Storage sử dụng API MediaStore. Kích thước của /sdcard thường là 60–80% tổng bộ nhớ flash, phần còn lại được dành riêng cho phân vùng /data.

Cấu trúc thư mục trên iOS

Trên iOS, hệ thống tệp được tổ chức thông qua vùng chứa Sandbox của ứng dụng. Mỗi ứng dụng nhận một thư mục biệt lập có quyền truy cập bị hạn chế ở cấp nhân XNU. Phân vùng người dùng sử dụng APFS (Apple File System), được giới thiệu trong iOS 10.3. APFS hỗ trợ ảnh chụp nhanh, nhân bản tệp và mã hóa cấp tệp, khiến nó trở nên tối ưu cho thiết bị di động.

Các thư mục tiêu chuẩn của vùng chứa Sandbox

Một vùng chứa Sandbox iOS bao gồm bốn thư mục chính: Documents, Library, tmp và SystemData. Mỗi thư mục có chính sách sao lưu, thời gian lưu giữ dữ liệu và mức truy cập riêng. Documents tự động được bao gồm trong sao lưu iCloud và iTunes. Library chứa các thư mục con Caches (không sao lưu), Preferences (có sao lưu) và Application Support (có sao lưu). Thư mục tmp dành cho các tệp tạm thời mà iOS có thể xóa khi thiếu dung lượng — nó không được bao gồm trong sao lưu. SystemData được hệ thống tự sử dụng và không thể truy cập được bởi ứng dụng thông qua API tiêu chuẩn.

let fm = FileManager.default

let documents = fm.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first!

let caches = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let appSupport = fm.urls(
    for: .applicationSupportDirectory,
    in: .userDomainMask
).first!

Mỗi thư mục vùng chứa Sandbox có lớp bảo vệ riêng. iOS hỗ trợ bốn lớp: Bảo vệ hoàn toàn (tệp không thể truy cập khi thiết bị bị khóa), Bảo vệ trừ khi mở (tệp đã mở có thể truy cập khi khóa), Bảo vệ cho đến khi xác thực người dùng lần đầu (tệp có thể truy cập sau lần mở khóa đầu tiên) và Không bảo vệ (tệp luôn có thể truy cập sau khi khởi động thiết bị). Theo mặc định, tất cả tệp trong Documents và Library nhận lớp Bảo vệ hoàn toàn, đảm bảo bảo vệ tối đa dữ liệu người dùng. Khi tạo tệp, bạn có thể chỉ định rõ ràng một lớp bảo vệ khác nếu ứng dụng nền cần truy cập dữ liệu khi thiết bị bị khóa.

Quyền truy cập và bảo mật hệ thống tệp

Kiểm soát truy cập vào tệp trên thiết bị di động là điểm khác biệt chính giữa Android và iOS. Android sử dụng mô hình quyền Linux cổ điển (đọc, ghi, thực thi) với các phần mở rộng để cách ly ứng dụng. iOS sử dụng mô hình Sandbox chặt chẽ hơn, nơi mỗi ứng dụng chạy trong một vùng chứa biệt lập và không có quyền truy cập vào tệp của ứng dụng khác nếu không có cơ chế đặc biệt.

Quyền trên Android

Trên Android, mỗi ứng dụng chạy với một UID (ID người dùng) riêng biệt. Tất cả tệp do ứng dụng tạo trong sandbox của nó thuộc về UID này và không hiển thị với các ứng dụng khác. Để truy cập thư mục chia sẻ (bộ nhớ ngoài), ứng dụng phải yêu cầu quyền READ_EXTERNAL_STORAGE và WRITE_EXTERNAL_STORAGE. Bắt đầu từ Android 11, quyền phải được yêu cầu trong thời gian chạy và ứng dụng có targetSdkVersion 30+ phải sử dụng SAF để truy cập tệp của ứng dụng khác. Vi phạm mô hình quyền sẽ dẫn đến SecurityException, được xử lý bằng khối try-catch tiêu chuẩn. Google Play tự động kiểm tra sự tuân thủ ứng dụng với chính sách quyền trước khi xuất bản.

if (ContextCompat.checkSelfPermission(
    context,
    Manifest.permission.READ_EXTERNAL_STORAGE
) != PackageManager.PERMISSION_GRANTED) {
    ActivityCompat.requestPermissions(
        activity,
        arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE),
        REQUEST_CODE
    )
}

Sandbox trên iOS và Keychain

Sandbox iOS được triển khai ở cấp nhân XNU và không cho phép ứng dụng rời khỏi vùng chứa của nó. Ngay cả khi ứng dụng có quyền truy cập vào URI tệp bên ngoài thông qua Document Picker, hệ điều hành tạo một bản sao tạm thời trong vùng chứa của ứng dụng thay vì cung cấp quyền truy cập trực tiếp vào bản gốc. Để chia sẻ tệp giữa các ứng dụng, iOS sử dụng cơ chế Share Sheet và UIActivityViewController, sao chép tệp từ vùng chứa của ứng dụng này sang vùng chứa của ứng dụng khác. Để lưu trữ an toàn thông tin xác thực (token, mật khẩu, khóa), iOS cung cấp Keychain — một kho lưu trữ mã hóa mà hệ thống có thể truy cập ở cấp nhân. Keychain không phải là một phần của vùng chứa Sandbox và được quản lý bởi một daemon securityd riêng biệt, cung cấp một lớp bảo vệ bổ sung ngay cả trong trường hợp ứng dụng bị xâm phạm.

Đặc điểm hệ thống tệp: EXT4, APFS, F2FS

Việc lựa chọn hệ thống tệp ảnh hưởng trực tiếp đến hiệu suất và độ tin cậy của bộ nhớ. Mỗi hệ thống tệp có kiến trúc, tối ưu hóa và giới hạn riêng. Nhà phát triển cần hiểu những khác biệt này để dự đoán hành vi của ứng dụng trên các thiết bị khác nhau.

• EXT4 — hệ thống tệp Linux tiêu chuẩn với nhật ký, hỗ trợ tệp lên đến 16 TB và ổ đĩa lên đến 1 EB. Được sử dụng trên Android làm hệ thống tệp chính trước khi áp dụng F2FS. Cung cấp độ tin cậy nhờ nhật ký nhưng kém hơn F2FS về tốc độ ghi ngẫu nhiên do cần cập nhật inode và bản đồ bit khối cho mỗi thao tác
• F2FS — hệ thống tệp do Samsung phát triển vào năm 2012 dành riêng cho bộ nhớ flash NAND. Xem xét hình dạng mảng flash, sử dụng kiến trúc cấu trúc nhật ký và cung cấp hiệu suất ghi ngẫu nhiên cao hơn 25–40% so với EXT4. Bắt đầu từ Android 11, Google khuyến nghị F2FS làm hệ thống tệp chính cho phân vùng /data
• APFS — hệ thống tệp của Apple được giới thiệu vào năm 2017. Hỗ trợ ảnh chụp nhanh, nhân bản tệp (sao chép-khi-ghi), mã hóa cấp tệp và kiểm soát tính toàn vẹn dữ liệu nghiêm ngặt thông qua tổng kiểm tra. APFS được tối ưu hóa cho SSD và sử dụng lệnh TRIM để duy trì hiệu suất trong suốt vòng đời lưu trữ
• exFAT — hệ thống tệp của Microsoft được sử dụng trên thẻ SD và ổ USB. Hỗ trợ tệp lớn hơn 4 GB và ổ đĩa lên đến 128 PB. Không có nhật ký, do đó mất điện đột ngột có thể dẫn đến hỏng dữ liệu. Được khuyến nghị cho phương tiện di động nhưng không cho phân vùng hệ thống

Khi phát triển ứng dụng, hãy nhớ rằng các hệ thống tệp khác nhau có giới hạn độ dài tên tệp khác nhau (255 byte cho EXT4 và F2FS, 255 ký tự Unicode cho APFS), kích thước tệp tối đa và hỗ trợ ký tự đặc biệt. Ví dụ, APFS cho phép ký tự Unicode trong tên tệp, bao gồm biểu tượng cảm xúc, trong khi EXT4 bị giới hạn ở ASCII. Nếu ứng dụng của bạn tạo tệp với tên bằng các ngôn ngữ khác nhau, hãy kiểm tra trên tất cả thiết bị mục tiêu — tên tệp được tạo chính xác trên APFS có thể bị cắt ngắn trên EXT4.

Khuyến nghị khi làm việc với hệ thống tệp

Làm việc đáng tin cậy với hệ thống tệp của thiết bị di động đòi hỏi tuân thủ một số quy tắc chính. Chúng dựa trên phân tích các lỗi điển hình của nhà phát triển và khuyến nghị từ tài liệu chính thức.

• Không sử dụng đường dẫn cứng đến thư mục. Luôn lấy đường dẫn thông qua API hệ thống: context.filesDir trên Android, NSSearchPathForDirectoriesInDomains trên iOS. Đường dẫn cứng thay đổi giữa các phiên bản hệ điều hành và thiết bị
• Xử lý ngoại lệ của thao tác tệp: IOException, FileNotFoundException, SecurityException. Trên iOS, tất cả thao tác FileManager có thể ném lỗi — hãy bọc chúng trong do-catch. Trên Android, thao tác với bộ nhớ ngoài có thể thất bại do thiếu phương tiện
• Kiểm tra dung lượng khả dụng trước khi ghi. Sử dụng File.getUsableSpace() trên Android và URLResourceValues.volumeAvailableCapacityKey trên iOS. Cảnh báo người dùng nếu dung lượng trống không đủ
• Tránh lưu trữ tệp lớn trong thư mục được bao gồm trong sao lưu. Trên iOS, loại trừ bộ nhớ đệm khỏi sao lưu qua isExcludedFromBackup. Trên Android, ưu tiên cacheDir cho tệp tạm thời
• Kiểm tra hành vi khi tràn bộ nhớ và mất điện đột ngột. Sử dụng ghi giao dịch: ghi vào tệp tạm thời, sau đó đổi tên nguyên tử

Đặc biệt chú ý đến sự khác biệt đa nền tảng. Đường dẫn tệp trên Android sử dụng dấu gạch chéo (/data/data/.../files/), trên iOS — lược đồ URL (file:///var/mobile/.../Documents/). Nếu ứng dụng của bạn sử dụng framework đa nền tảng (Flutter, React Native, Kotlin Multiplatform), hãy thống nhất các thao tác tệp thông qua bộ điều hợp nền tảng. Ví dụ, Flutter cung cấp gói path_provider, trả về đường dẫn chính xác đến Documents hoặc filesDir trên cả hai nền tảng mà không cần viết mã phụ thuộc vào nền tảng. Không bao giờ nối đường dẫn bằng thao tác chuỗi — sử dụng File.join() hoặc URL.appendingPathComponent(), xử lý chính xác các dấu phân cách trên các nền tảng khác nhau.