Sistem berkas perangkat seluler: apa itu, struktur direktori dan cara kerjanya

Apa itu sistem berkas perangkat seluler?

Sistem berkas adalah komponen perangkat lunak dari sistem operasi yang mengelola bagaimana data ditulis, dibaca, dan diatur pada media fisik. Di perangkat seluler, sistem berkas menjalankan fungsi yang sangat penting: manajemen ruang memori flash, kontrol akses ke berkas berdasarkan izin, pencatatan perubahan untuk pemulihan setelah kegagalan, dan optimalisasi penulisan dengan mempertimbangkan karakteristik memori NAND flash.

Berbeda dengan sistem operasi desktop, sistem berkas seluler dirancang dengan mempertimbangkan sumber daya siklus penulisan ulang memori flash yang terbatas. Sel NAND dapat menahan jumlah operasi penghapusan yang terbatas — dari 3.000 hingga 10.000 siklus untuk memori TLC dan MLC masing-masing. Untuk memperpanjang masa pakai penyimpanan, sistem berkas menerapkan mekanisme wear leveling (perataan keausan) dan perintah TRIM. F2FS, yang dikembangkan oleh Samsung khusus untuk memori flash, mempertimbangkan geometri susunan NAND dan menempatkan data sedemikian rupa untuk meminimalkan fragmentasi dan jumlah operasi penghapusan blok.

Perangkat seluler modern menggunakan kombinasi beberapa sistem berkas. Memori internal (partisi /data) diformat dalam EXT4 atau F2FS di Android dan APFS di iOS. Kartu SD secara tradisional menggunakan exFAT untuk mendukung berkas yang lebih besar dari 4 GB atau FAT32 untuk kompatibilitas maksimal. Partisi /system di Android sering dipasang hanya-baca dan menggunakan EXT4 atau EROFS (Enhanced Read-Only File System) — sistem berkas terkompresi yang dikembangkan oleh Huawei untuk mengurangi ukuran partisi sistem.

Struktur direktori di Android

Hierarki direktori Android didasarkan pada struktur Linux dengan akar di /. Setiap partisi memiliki sistem berkas, hak akses, dan tujuannya sendiri. Aplikasi hanya dapat mengakses serangkaian direktori terbatas — sisanya dilindungi oleh hak root.

Partisi /data dan sandbox aplikasi

Partisi /data adalah partisi utama untuk menyimpan data pengguna, aplikasi yang terinstal, dan pengaturannya. Setiap aplikasi mendapatkan direktori sendiri di jalur /data/data/<package_name>/. Di dalam direktori ini, sistem secara otomatis membuat subdirektori: files/ untuk berkas aplikasi, cache/ untuk berkas sementara, databases/ untuk basis data SQLite, shared_prefs/ untuk SharedPreferences. Hak akses ke direktori ini ditetapkan saat pemasangan aplikasi dan tidak dapat diubah tanpa akses root. Partisi /data diformat dalam F2FS di sebagian besar perangkat modern, yang memberikan kecepatan penulisan acak hingga 40% lebih tinggi dibandingkan dengan EXT4.

Partisi /system dan komponen sistem

Partisi /system berisi sistem operasi, aplikasi sistem, dan pustaka. Partisi ini dipasang hanya-baca untuk mencegah perubahan tidak sengaja atau berbahaya pada berkas sistem. Pada perangkat dengan Android 10+ dan Project Treble, partisi /system bersifat dinamis dan dapat diperbarui melalui paket OTA tanpa perlu flashing ulang penuh. Untuk aplikasi, partisi /system tidak dapat diakses — upaya penulisan akan menyebabkan pengecualian SecurityException. Namun, aplikasi dapat membaca beberapa berkas dari /system, seperti font sistem dan berkas konfigurasi, jika memiliki izin yang sesuai.

Titik kait /sdcard

Titik kait /sdcard adalah tautan simbolis ke partisi penyimpanan eksternal yang diemulasi atau fisik. Pada perangkat tanpa kartu SD, /sdcard menunjuk ke subpartisi di dalam /data yang dialokasikan untuk akses bersama. Partisi ini terlihat oleh pengguna saat perangkat terhubung ke komputer melalui protokol MTP. Aplikasi mendapatkan akses ke /sdcard melalui izin READ_EXTERNAL_STORAGE dan WRITE_EXTERNAL_STORAGE, dan mulai Android 10 — melalui Scoped Storage menggunakan API MediaStore. Ukuran /sdcard biasanya mencapai 60–80% dari total volume memori flash perangkat, dan sisanya dicadangkan untuk partisi /data.

Struktur direktori di iOS

Di iOS, sistem berkas diatur melalui kontainer Sandbox aplikasi. Setiap aplikasi mendapatkan direktori terisolasi yang aksesnya dibatasi di tingkat kernel XNU. Partisi pengguna menggunakan sistem berkas APFS (Apple File System), diperkenalkan di iOS 10.3. APFS mendukung snapshot, kloning berkas, dan enkripsi di tingkat berkas, yang membuatnya optimal untuk perangkat seluler.

Direktori standar kontainer Sandbox

Kontainer Sandbox iOS mencakup empat direktori utama: Documents, Library, tmp, dan SystemData. Setiap direktori memiliki kebijakan cadangan, periode penyimpanan data, dan tingkat aksesnya sendiri. Documents secara otomatis disertakan dalam cadangan iCloud dan iTunes. Library berisi subdirektori Caches (tidak dicadangkan), Preferences (dicadangkan), dan Application Support (dicadangkan). Direktori tmp ditujukan untuk berkas sementara — iOS dapat menghapusnya jika ruang tidak mencukupi dan tidak disertakan dalam cadangan. SystemData digunakan oleh sistem itu sendiri dan tidak dapat diakses oleh aplikasi melalui API standar.

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!

Setiap direktori kontainer Sandbox memiliki kelas perlindungan sendiri (protection class). iOS mendukung empat kelas: Complete Protection (berkas tidak dapat diakses saat perangkat terkunci), Protected Unless Open (berkas yang sudah dibuka dapat diakses saat terkunci), Protected Until First User Authentication (berkas dapat diakses setelah pembukaan kunci pertama), dan No Protection (berkas selalu dapat diakses setelah perangkat dinyalakan). Secara default, semua berkas di Documents dan Library mendapatkan kelas Complete Protection, yang menjamin perlindungan maksimal data pengguna. Saat membuat berkas, kelas perlindungan lain dapat ditentukan secara eksplisit jika aplikasi latar belakang harus memiliki akses ke data saat perangkat terkunci.

Hak akses dan keamanan sistem berkas

Manajemen akses ke berkas di perangkat seluler adalah perbedaan utama antara Android dan iOS. Android menggunakan model hak akses Linux klasik (baca, tulis, eksekusi) dengan ekstensi untuk isolasi aplikasi. iOS menerapkan model Sandbox yang lebih ketat, di mana setiap aplikasi berjalan dalam kontainer terisolasi dan tidak memiliki akses ke berkas aplikasi lain tanpa mekanisme khusus.

Izin di Android

Di Android, setiap aplikasi dijalankan dengan UID (User ID) terpisah. Semua berkas yang dibuat oleh aplikasi di sandbox-nya dimiliki oleh UID ini dan tidak terlihat oleh aplikasi lain. Untuk mengakses direktori bersama (penyimpanan eksternal), aplikasi harus meminta izin READ_EXTERNAL_STORAGE dan WRITE_EXTERNAL_STORAGE. Mulai Android 11, izin harus diminta saat runtime, dan aplikasi dengan targetSdkVersion 30+ untuk mengakses berkas aplikasi lain harus menggunakan SAF. Pelanggaran model izin menyebabkan SecurityException, yang ditangani oleh blok try-catch standar. Google Play secara otomatis memeriksa kepatuhan aplikasi terhadap kebijakan izin sebelum publikasi.

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

Sandbox di iOS dan Keychain

iOS Sandbox diimplementasikan di tingkat kernel XNU dan tidak mengizinkan aplikasi keluar dari kontainernya. Bahkan jika aplikasi mendapatkan akses ke URI berkas eksternal melalui Document Picker, sistem operasi membuat salinan sementara di kontainer aplikasi, alih-alih memberikan akses langsung ke aslinya. Untuk berbagi berkas antar aplikasi, iOS menggunakan mekanisme Share Sheet dan UIActivityViewController, yang menyalin berkas dari kontainer satu aplikasi ke kontainer lainnya. Untuk penyimpanan aman kredensial (token, kata sandi, kunci), iOS menyediakan Keychain — penyimpanan terenkripsi yang dapat diakses sistem di tingkat kernel. Keychain bukan bagian dari kontainer Sandbox dan dikelola oleh daemon securityd terpisah, yang memberikan lapisan perlindungan tambahan bahkan jika aplikasi dikompromikan.

Karakteristik sistem berkas: EXT4, APFS, F2FS

Pilihan sistem berkas secara langsung memengaruhi kinerja dan keandalan penyimpanan data. Setiap sistem berkas memiliki arsitektur, optimalisasi, dan keterbatasannya sendiri. Berguna bagi pengembang untuk memahami perbedaan ini guna memprediksi perilaku aplikasi di berbagai perangkat.

• EXT4 — sistem berkas standar Linux dengan jurnal, mendukung berkas hingga 16 TB dan volume hingga 1 EB. Digunakan di Android sebagai sistem utama sebelum penerapan F2FS. Memberikan keandalan berkat jurnal, tetapi kalah dari F2FS dalam kecepatan penulisan acak karena kebutuhan memperbarui inode dan bitmap blok pada setiap operasi
• F2FS — sistem berkas yang dikembangkan oleh Samsung pada tahun 2012 khusus untuk memori NAND flash. Mempertimbangkan geometri susunan flash, menggunakan arsitektur log-terstruktur, dan memberikan kinerja penulisan acak 25–40% lebih tinggi dibandingkan dengan EXT4. Mulai Android 11, F2FS direkomendasikan oleh Google sebagai sistem berkas utama untuk partisi /data
• APFS — sistem berkas Apple, diperkenalkan pada tahun 2017. Mendukung snapshot, kloning berkas (copy-on-write), enkripsi di tingkat berkas, dan kontrol integritas data yang ketat melalui checksum. APFS dioptimalkan untuk SSD dan menggunakan perintah TRIM untuk mempertahankan kinerja sepanjang masa pakai penyimpanan
• exFAT — sistem berkas Microsoft, digunakan di kartu SD dan drive USB. Mendukung berkas lebih besar dari 4 GB dan volume hingga 128 PB. Tidak memiliki jurnal, sehingga pemadaman listrik mendadak dapat menyebabkan kerusakan data. Direkomendasikan untuk media yang dapat dilepas, tetapi tidak untuk partisi sistem

Saat mengembangkan aplikasi, pertimbangkan bahwa sistem berkas yang berbeda memiliki batasan panjang nama berkas (255 byte untuk EXT4 dan F2FS, 255 karakter Unicode untuk APFS), ukuran maksimal berkas, dan dukungan untuk karakter khusus yang berbeda. Misalnya, APFS mengizinkan karakter Unicode dalam nama berkas, termasuk emoji, sementara EXT4 terbatas pada ASCII. Jika aplikasi membuat berkas dengan nama dalam berbagai bahasa, uji pengoperasian di semua perangkat target — nama berkas yang dibuat dengan benar di APFS dapat dipotong di EXT4.

Rekomendasi untuk bekerja dengan sistem berkas

Pengoperasian yang andal dengan sistem berkas perangkat seluler memerlukan kepatuhan terhadap beberapa aturan utama. Aturan ini didasarkan pada analisis kesalahan umum pengembang dan rekomendasi dari dokumentasi resmi.

• Jangan gunakan jalur yang dikodekan keras ke direktori. Selalu dapatkan jalur melalui API sistem: context.filesDir di Android, NSSearchPathForDirectoriesInDomains di iOS. Jalur keras berubah antar versi sistem operasi dan perangkat
• Tangani pengecualian operasi berkas: IOException, FileNotFoundException, SecurityException. Di iOS, semua operasi FileManager dapat menghasilkan kesalahan — bungkus dengan do-catch. Di Android, operasi dengan penyimpanan eksternal dapat gagal karena tidak adanya media
• Periksa ruang yang tersedia sebelum menulis. Gunakan File.getUsableSpace() di Android dan URLResourceValues.volumeAvailableCapacityKey di iOS. Peringatkan pengguna jika ruang kosong tidak mencukupi
• Hindari menyimpan berkas besar di direktori yang masuk dalam cadangan. Di iOS, kecualikan cache dari cadangan melalui isExcludedFromBackup. Di Android, preferensikan cacheDir untuk berkas sementara
• Uji perilaku saat penyimpanan penuh dan pemadaman listrik mendadak. Gunakan penulisan transaksional: tulis ke berkas sementara, lalu ganti nama secara atomik

Berikan perhatian khusus pada perbedaan lintas platform. Jalur ke berkas di Android dibangun dengan garis miring (/data/data/.../files/), di iOS — melalui skema URL (file:///var/mobile/.../Documents/). Jika aplikasi Anda menggunakan kerangka kerja multi-platform (Flutter, React Native, Kotlin Multiplatform), seragamkan operasi berkas melalui adaptor platform. Misalnya, Flutter menyediakan paket path_provider, yang mengembalikan jalur yang benar ke Documents atau filesDir di kedua platform tanpa menulis kode khusus platform. Jangan pernah menggabungkan jalur dengan operasi string — gunakan File.join() atau URL.appendingPathComponent(), yang menangani pemisah dengan benar di berbagai platform.