File system ng mobile device: ano ito, istraktura ng direktoryo at paano ito gumagana

Ano ang file system ng mobile device?

File system ay isang software component ng operating system na namamahala kung paano isinusulat, binabasa at inaayos ang data sa physical media. Sa mga mobile device, ang file system ay gumaganap ng mga kritikal na mahahalagang function: pamamahala ng espasyo ng flash memory, kontrol sa pag-access sa mga file batay sa mga pahintulot, pag-log ng mga pagbabago para sa pagbawi pagkatapos ng mga pagkabigo, at pag-optimize ng pagsulat na isinasaalang-alang ang mga katangian ng NAND flash memory.

Hindi tulad ng desktop operating system, ang mga mobile file system ay dinisenyo na isinasaalang-alang ang limitadong resource ng rewrite cycles ng flash memory. Ang mga NAND cell ay kayang tumagal ng limitadong bilang ng erase operations — mula 3,000 hanggang 10,000 cycle para sa TLC at MLC memory ayon sa pagkakasunod. Upang pahabain ang buhay ng storage, ang mga file system ay naglalapat ng mga mekanismo ng wear leveling (pagpapantay ng pagkasira) at TRIM command. Ang F2FS, na binuo ng Samsung na espesyal para sa flash memory, ay isinasaalang-alang ang geometry ng NAND array at inilalagay ang data sa paraang mababawasan ang fragmentation at bilang ng block erase operations.

Ang mga modernong mobile device ay gumagamit ng kumbinasyon ng maraming file system. Ang internal memory (partisyon /data) ay naka-format sa EXT4 o F2FS sa Android at APFS sa iOS. Ang mga SD card ay tradisyonal na gumagamit ng exFAT para sa suporta ng mga file na mas malaki sa 4 GB o FAT32 para sa maximum na compatibility. Ang partisyon /system sa Android ay madalas na naka-mount na read-only at gumagamit ng EXT4 o EROFS (Enhanced Read-Only File System) — isang naka-compress na file system na binuo ng Huawei upang bawasan ang laki ng system partition.

Istraktura ng direktoryo sa Android

Hierarchy ng direktoryo ng Android ay batay sa Linux structure na may ugat sa /. Ang bawat partisyon ay may sariling file system, karapatan sa pag-access at layunin. Ang isang app ay makaka-access lamang sa limitadong set ng mga direktoryo — ang iba ay protektado ng mga karapatan ng root.

Partisyon /data at sandbox ng mga app

Partisyon /data ang pangunahing partisyon para sa pag-iimbak ng data ng user, naka-install na apps at kanilang mga setting. Ang bawat app ay nakakakuha ng sariling direktoryo sa path na /data/data/<package_name>/. Sa loob ng direktoryong ito, awtomatikong gumagawa ang system ng mga subdirectory: files/ para sa mga file ng app, cache/ para sa pansamantalang file, databases/ para sa SQLite database, shared_prefs/ para sa SharedPreferences. Ang mga karapatan sa pag-access sa direktoryong ito ay nakatakda sa pag-install ng app at hindi mababago nang walang root access. Ang partisyon /data ay naka-format sa F2FS sa karamihan ng mga modernong device, na nagbibigay ng hanggang 40% na mas mataas na bilis ng random write kumpara sa EXT4.

Partisyon /system at mga component ng system

Partisyon /system ay naglalaman ng operating system, system apps at library. Ang partisyong ito ay naka-mount na read-only upang maiwasan ang aksidental o malisyosong pagbabago ng mga system file. Sa mga device na may Android 10+ at Project Treble, ang partisyon /system ay dynamic at maaaring i-update sa pamamagitan ng OTA packages nang hindi kailangan ng full reflash. Para sa mga app, ang partisyon /system ay hindi accessible — ang pagtatangkang magsulat ay magdudulot ng SecurityException. Gayunpaman, ang mga app ay maaaring magbasa ng ilang file mula sa /system, halimbawa system fonts at configuration file, kung mayroon silang naaangkop na mga pahintulot.

Mount point /sdcard

Ang mount point /sdcard ay isang symbolic link sa partisyon ng emulated o physical na external storage. Sa mga device na walang SD card, ang /sdcard ay tumuturo sa isang subpartition sa loob ng /data na nakalaan para sa shared access. Ang partisyong ito ay nakikita ng user kapag ang device ay konektado sa computer sa pamamagitan ng MTP protocol. Ang mga app ay nakakakuha ng access sa /sdcard sa pamamagitan ng mga pahintulot na READ_EXTERNAL_STORAGE at WRITE_EXTERNAL_STORAGE, at simula sa Android 10 — sa pamamagitan ng Scoped Storage gamit ang MediaStore API. Ang laki ng /sdcard ay karaniwang 60–80% ng kabuuang volume ng flash memory ng device, at ang natitira ay nakalaan para sa partisyon /data.

Istraktura ng direktoryo sa iOS

Sa iOS, ang file system ay nakaayos sa pamamagitan ng mga Sandbox container ng apps. Ang bawat app ay nakakakuha ng nakahiwalay na direktoryo, na ang access ay limitado sa antas ng XNU kernel. Ang user partition ay gumagamit ng APFS (Apple File System) file system, na ipinakilala sa iOS 10.3. Sinusuportahan ng APFS ang mga snapshot, file cloning at encryption sa antas ng file, na ginagawa itong optimal para sa mga mobile device.

Mga karaniwang direktoryo ng Sandbox container

Ang Sandbox container ng iOS ay may apat na pangunahing direktoryo: Documents, Library, tmp at SystemData. Ang bawat direktoryo ay may sariling backup policy, panahon ng pag-iimbak ng data at antas ng access. Ang Documents ay awtomatikong kasama sa iCloud at iTunes backup. Ang Library ay naglalaman ng mga subdirectory na Caches (hina-back up), Preferences (bina-back up) at Application Support (bina-back up). Ang direktoryo ng tmp ay para sa pansamantalang file — maaaring tanggalin ng iOS ang mga ito kapag kulang ang space at hindi kasama sa backup. Ang SystemData ay ginagamit ng system mismo at hindi accessible sa app sa pamamagitan ng standard APIs.

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!

Ang bawat direktoryo ng Sandbox container ay may sariling protection class. Sinusuportahan ng iOS ang apat na klase: Complete Protection (file ay hindi accessible kapag naka-lock ang device), Protected Unless Open (mga file na nakabukas na ay accessible habang naka-lock), Protected Until First User Authentication (mga file ay accessible pagkatapos ng unang pag-unlock) at No Protection (mga file ay laging accessible pagkatapos mag-boot ang device). Bilang default, lahat ng file sa Documents at Library ay tumatanggap ng Complete Protection class, na ginagarantiya ang maximum na proteksyon ng data ng user. Sa paggawa ng file, maaaring tahasang itakda ang ibang protection class kung ang background app ay dapat magkaroon ng access sa data habang naka-lock ang device.

Mga karapatan sa pag-access at seguridad ng file system

Pamamahala ng access sa mga file sa mobile device ay isang pangunahing pagkakaiba sa pagitan ng Android at iOS. Android ay gumagamit ng klasikong Linux model ng mga karapatan sa pag-access (basa, sulat, execute) na may mga extension para sa isolation ng app. iOS ay naglalapat ng mas mahigpit na Sandbox model, kung saan ang bawat app ay tumatakbo sa isang nakahiwalay na container at walang access sa mga file ng ibang app nang walang mga espesyal na mekanismo.

Mga pahintulot sa Android

Sa Android, ang bawat app ay tumatakbo na may hiwalay na UID (User ID). Lahat ng file na ginawa ng app sa sandbox nito ay pagmamay-ari ng UID na ito at hindi nakikita ng ibang apps. Para ma-access ang mga shared directory (external storage), ang app ay dapat humingi ng mga pahintulot na READ_EXTERNAL_STORAGE at WRITE_EXTERNAL_STORAGE. Simula sa Android 11, ang mga pahintulot ay dapat hilingin sa runtime, at ang app na may targetSdkVersion 30+ para ma-access ang mga file ng ibang apps ay dapat gumamit ng SAF. Ang paglabag sa model ng pahintulot ay nagdudulot ng SecurityException, na hinahawakan ng standard try-catch block. Awtomatikong sinusuri ng Google Play ang pagsunod ng app sa patakaran ng pahintulot bago ang publikasyon.

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

Sandbox sa iOS at Keychain

iOS Sandbox ay ipinatupad sa antas ng XNU kernel at hindi pinapayagan ang app na lumabas sa labas ng container nito. Kahit na makakuha ang app ng access sa URI ng external file sa pamamagitan ng Document Picker, ang operating system ay gumagawa ng pansamantalang kopya sa container ng app sa halip na magbigay ng direktang access sa orihinal. Para sa pagpapalitan ng file sa pagitan ng apps, iOS ay gumagamit ng Share Sheet at UIActivityViewController mechanisms, na kumokopya ng file mula sa container ng isang app papunta sa container ng isa pa. Para sa secure na pag-iimbak ng credentials (token, password, key), iOS ay nagbibigay ng Keychain — isang naka-encrypt na imbakan na accessible sa system sa antas ng kernel. Ang Keychain ay hindi bahagi ng Sandbox container at pinamamahalaan ng isang hiwalay na securityd daemon, na nagbibigay ng karagdagang antas ng proteksyon kahit na sa kaso ng compromisation ng app.

Mga katangian ng file system: EXT4, APFS, F2FS

Ang pagpili ng file system ay direktang nakakaapekto sa performance at reliability ng pag-iimbak ng data. Ang bawat file system ay may sariling arkitektura, optimisasyon at limitasyon. Kapaki-pakinabang para sa developer na maunawaan ang mga pagkakaibang ito upang mahulaan ang pag-uugali ng app sa iba't ibang device.

• EXT4 — standard Linux file system na may journaling, suporta para sa mga file hanggang 16 TB at volume hanggang 1 EB. Ginagamit sa Android bilang pangunahing bago ang pagpapakilala ng F2FS. Nagbibigay ng reliability salamat sa journal, ngunit mas mababa sa F2FS sa bilis ng random write dahil sa pangangailangang mag-update ng inodes at block bitmaps sa bawat operasyon
• F2FS — file system na binuo ng Samsung noong 2012 na espesyal para sa NAND flash memory. Isinasaalang-alang ang geometry ng flash array, gumagamit ng log-structured architecture at nagbibigay ng 25–40% na mas mataas na random write performance kumpara sa EXT4. Simula sa Android 11, ang F2FS ay inirerekomenda ng Google bilang pangunahing file system para sa partisyon /data
• APFS — file system ng Apple, ipinakilala noong 2017. Sinusuportahan ang mga snapshot, file cloning (copy-on-write), encryption sa antas ng file at mahigpit na kontrol ng integridad ng data sa pamamagitan ng checksums. Ang APFS ay na-optimize para sa SSD at gumagamit ng TRIM commands para mapanatili ang performance sa buong buhay ng storage device
• exFAT — file system ng Microsoft, ginagamit sa SD cards at USB drives. Sinusuportahan ang mga file na mas malaki sa 4 GB at volume hanggang 128 PB. Walang journaling, kaya ang biglaang pagkawala ng kuryente ay maaaring magdulot ng pagkasira ng data. Inirerekomenda para sa removable media, ngunit hindi para sa system partitions

Sa pag-develop ng apps, isaalang-alang na ang iba't ibang file system ay may iba't ibang limitasyon sa haba ng pangalan ng file (255 bytes para sa EXT4 at F2FS, 255 Unicode characters para sa APFS), maximum na laki ng file at suporta para sa mga espesyal na character. Halimbawa, pinapayagan ng APFS ang Unicode characters sa mga pangalan ng file, kabilang ang emoji, habang ang EXT4 ay limitado sa ASCII. Kung ang app ay gumagawa ng mga file na may pangalan sa iba't ibang wika, subukan ang operasyon sa lahat ng target device — ang pangalan ng file na tama na ginawa sa APFS ay maaaring maputol sa EXT4.

Mga rekomendasyon para sa pagtatrabaho sa file system

Maaasahang pagtatrabaho sa file system ng mobile device ay nangangailangan ng pagsunod sa ilang pangunahing patakaran. Ang mga ito ay batay sa pagsusuri ng mga tipikal na pagkakamali ng mga developer at mga rekomendasyon mula sa opisyal na dokumentasyon.

• Huwag gumamit ng hard-coded na mga path sa mga direktoryo. Palaging kunin ang mga path sa pamamagitan ng system APIs: context.filesDir sa Android, NSSearchPathForDirectoriesInDomains sa iOS. Ang mga hard path ay nagbabago sa pagitan ng mga bersyon ng operating system at device
• Pangasiwaan ang mga exception ng mga file operations: IOException, FileNotFoundException, SecurityException. Sa iOS, lahat ng FileManager operations ay maaaring magtapon ng error — balutin ang mga ito sa do-catch. Sa Android, ang mga operasyon sa external storage ay maaaring magtapos sa error dahil sa kawalan ng media
• Suriin ang available space bago magsulat. Gamitin ang File.getUsableSpace() sa Android at URLResourceValues.volumeAvailableCapacityKey sa iOS. Babalaan ang user kung hindi sapat ang libreng espasyo
• Iwasan ang pag-iimbak ng malalaking file sa mga direktoryo na kasama sa backup. Sa iOS, ibukod ang cache mula sa backup sa pamamagitan ng isExcludedFromBackup. Sa Android, mas piliin ang cacheDir para sa pansamantalang file
• Subukan ang pag-uugali sa pagpuno ng storage at biglaang pagkawala ng kuryente. Gumamit ng transactional write: sumulat sa isang pansamantalang file, pagkatapos ay atomic na palitan ang pangalan

Bigyan ng espesyal na atensyon ang cross-platform na pagkakaiba. Ang mga path sa file sa Android ay binuo gamit ang forward slash (/data/data/.../files/), sa iOS — sa pamamagitan ng URL scheme (file:///var/mobile/.../Documents/). Kung ang iyong app ay gumagamit ng multi-platform framework (Flutter, React Native, Kotlin Multiplatform), i-unify ang mga file operations sa pamamagitan ng platform adapters. Halimbawa, ang Flutter ay nagbibigay ng path_provider package, na nagbabalik ng tamang path sa Documents o filesDir sa parehong platform nang hindi nagsusulat ng platform-dependent code. Huwag kailanman mag-concatenate ng mga path gamit ang string operations — gamitin ang File.join() o URL.appendingPathComponent(), na tama na humahawak ng mga separator sa iba't ibang platform.