ระบบไฟล์ของอุปกรณ์มือถือ: คืออะไร โครงสร้างไดเรกทอรี และทำงานอย่างไร

ระบบไฟล์ของอุปกรณ์มือถือคืออะไร

ระบบไฟล์ เป็นส่วนประกอบซอฟต์แวร์ของระบบปฏิบัติการที่จัดการวิธีการเขียน อ่าน และจัดระเบียบข้อมูลบนสื่อทางกายภาพ บนอุปกรณ์มือถือ ระบบไฟล์ทำหน้าที่ที่สำคัญอย่างยิ่ง: การจัดการพื้นที่หน่วยความจำแฟลช การควบคุมการเข้าถึงไฟล์ตามสิทธิ์ การบันทึกการเปลี่ยนแปลงเพื่อกู้คืนหลังจากระบบขัดข้อง และการปรับแต่งการเขียนโดยคำนึงถึงลักษณะเฉพาะของหน่วยความจำแฟลช NAND

แตกต่างจาก ระบบปฏิบัติการเดสก์ท็อป ระบบไฟล์มือถือถูกออกแบบโดยคำนึงถึงจำนวนรอบการเขียนซ้ำที่จำกัดของหน่วยความจำแฟลช เซลล์ NAND สามารถทนต่อจำนวนการลบที่จำกัด — ตั้งแต่ 3,000 ถึง 10,000 รอบสำหรับหน่วยความจำ TLC และ MLC ตามลำดับ เพื่อยืดอายุการจัดเก็บ ระบบไฟล์ใช้กลไก wear leveling (การปรับระดับการสึกหรอ) และคำสั่ง TRIM F2FS ซึ่งพัฒนาโดย Samsung สำหรับหน่วยความจำแฟลชโดยเฉพาะ คำนึงถึงเรขาคณิตของอาเรย์ NAND และวางข้อมูลในลักษณะที่ลดการกระจายตัวและจำนวนการดำเนินการลบบล็อก

อุปกรณ์มือถือสมัยใหม่ใช้ระบบผสมผสานของ ระบบไฟล์หลายชนิด หน่วยความจำภายใน (พาร์ติชัน /data) ถูกฟอร์แมตเป็น EXT4 หรือ F2FS บน Android และ APFS บน iOS การ์ด SD แบบดั้งเดิมใช้ exFAT สำหรับไฟล์ขนาดใหญ่กว่า 4 GB หรือ FAT32 เพื่อความเข้ากันได้สูงสุด พาร์ติชัน /system บน Android มักถูกเมาท์แบบอ่านอย่างเดียวและใช้ EXT4 หรือ EROFS (Enhanced Read-Only File System) — ระบบไฟล์แบบบีบอัดที่พัฒนาโดย Huawei เพื่อลดขนาดของพาร์ติชันระบบ

โครงสร้างไดเรกทอรีบน Android

ลำดับชั้นไดเรกทอรี ของ Android อิงตามโครงสร้าง Linux โดยมีรากที่ / แต่ละพาร์ติชันมีระบบไฟล์ สิทธิ์การเข้าถึง และวัตถุประสงค์ของตัวเอง แอปพลิเคชันสามารถเข้าถึงไดเรกทอรีได้เพียงชุดจำกัด — ส่วนที่เหลือได้รับการปกป้องโดยสิทธิ์ root

พาร์ติชัน /data และแซนด์บ็อกซ์ของแอป

พาร์ติชัน /data เป็นพาร์ติชันหลักสำหรับจัดเก็บข้อมูลผู้ใช้ แอปพลิเคชันที่ติดตั้ง และการตั้งค่าของพวกเขา แต่ละแอปพลิเคชันได้รับไดเรกทอรีของตัวเองที่ /data/data/<package_name>/ ภายในไดเรกทอรีนี้ ระบบจะสร้างไดเรกทอรีย่อยโดยอัตโนมัติ: files/ สำหรับไฟล์แอปพลิเคชัน cache/ สำหรับไฟล์ชั่วคราว databases/ สำหรับฐานข้อมูล SQLite shared_prefs/ สำหรับ SharedPreferences สิทธิ์การเข้าถึงไดเรกทอรีนี้ถูกกำหนดเมื่อติดตั้งแอปพลิเคชันและไม่สามารถเปลี่ยนแปลงได้หากไม่มีการเข้าถึง root พาร์ติชัน /data ถูกฟอร์แมตเป็น F2FS บนอุปกรณ์สมัยใหม่ส่วนใหญ่ ซึ่งให้ความเร็วในการเขียนแบบสุ่มสูงขึ้นถึง 40% เมื่อเทียบกับ EXT4

พาร์ติชัน /system และส่วนประกอบระบบ

พาร์ติชัน /system ประกอบด้วยระบบปฏิบัติการ แอปพลิเคชันระบบ และไลบรารี พาร์ติชันนี้ถูกเมาท์แบบอ่านอย่างเดียวเพื่อป้องกันการแก้ไขไฟล์ระบบโดยไม่ได้ตั้งใจหรือเป็นอันตราย บนอุปกรณ์ที่มี Android 10+ และ Project Treble พาร์ติชัน /system เป็นแบบไดนามิกและสามารถอัปเดตผ่านแพ็กเกจ OTA โดยไม่ต้องแฟลชใหม่ทั้งหมด สำหรับแอปพลิเคชัน พาร์ติชัน /system ไม่สามารถเข้าถึงได้ — การพยายามเขียนจะทำให้เกิด SecurityException อย่างไรก็ตาม แอปพลิเคชันสามารถอ่านไฟล์บางไฟล์จาก /system เช่น แบบอักษรระบบและไฟล์กำหนดค่า หากมีสิทธิ์ที่เหมาะสม

จุดเมาท์ /sdcard

จุดเมาท์ /sdcard เป็นลิงก์สัญลักษณ์ไปยังพาร์ติชันพื้นที่จัดเก็บภายนอกที่จำลองหรือทางกายภาพ บนอุปกรณ์ที่ไม่มีการ์ด SD /sdcard ชี้ไปยังพาร์ติชันย่อยภายใน /data ที่กำหนดไว้สำหรับการเข้าถึงร่วมกัน พาร์ติชันนี้ผู้ใช้จะมองเห็นได้เมื่ออุปกรณ์เชื่อมต่อกับคอมพิวเตอร์ผ่านโปรโตคอล MTP แอปพลิเคชันเข้าถึง /sdcard ผ่านสิทธิ์ READ_EXTERNAL_STORAGE และ WRITE_EXTERNAL_STORAGE และเริ่มจาก Android 10 — ผ่าน Scoped Storage โดยใช้ MediaStore API ขนาดของ /sdcard โดยปกติคือ 60–80% ของหน่วยความจำแฟลชทั้งหมด และส่วนที่เหลือจะสงวนไว้สำหรับพาร์ติชัน /data

โครงสร้างไดเรกทอรีบน iOS

บน iOS ระบบไฟล์ถูกจัดระเบียบผ่าน คอนเทนเนอร์ Sandbox ของแอปพลิเคชัน แต่ละแอปพลิเคชันได้รับไดเรกทอรีที่แยกออกจากกันซึ่งการเข้าถึงถูกจำกัดในระดับเคอร์เนล XNU พาร์ติชันผู้ใช้ใช้ APFS (Apple File System) ซึ่งเปิดตัวใน iOS 10.3 APFS รองรับสแนปชอต การโคลนไฟล์ และการเข้ารหัสระดับไฟล์ ทำให้เหมาะสมที่สุดสำหรับอุปกรณ์มือถือ

ไดเรกทอรีมาตรฐานของคอนเทนเนอร์ Sandbox

คอนเทนเนอร์ Sandbox ของ iOS ประกอบด้วยสี่ไดเรกทอรีหลัก: Documents, Library, tmp และ SystemData แต่ละไดเรกทอรีมีนโยบายสำรองข้อมูล ระยะเวลาการเก็บข้อมูล และระดับการเข้าถึงของตัวเอง Documents จะรวมอยู่ในการสำรองข้อมูล iCloud และ iTunes โดยอัตโนมัติ Library ประกอบด้วยไดเรกทอรีย่อย Caches (ไม่สำรอง), Preferences (สำรอง) และ Application Support (สำรอง) ไดเรกทอรี tmp สำหรับไฟล์ชั่วคราวที่ iOS อาจลบเมื่อพื้นที่เก็บข้อมูลไม่เพียงพอ — ไม่รวมอยู่ในการสำรองข้อมูล SystemData ถูกใช้โดยระบบเองและไม่สามารถเข้าถึงได้โดยแอปพลิเคชันผ่าน API มาตรฐาน

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!

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

สิทธิ์การเข้าถึงและความปลอดภัยของระบบไฟล์

การควบคุมการเข้าถึง ไฟล์บนอุปกรณ์มือถือเป็นความแตกต่างหลักระหว่าง Android และ iOS Android ใช้รูปแบบสิทธิ์ Linux แบบคลาสสิก (อ่าน เขียน ดำเนินการ) พร้อมส่วนขยายสำหรับการแยกแอปพลิเคชัน iOS ใช้รูปแบบ Sandbox ที่เข้มงวดกว่า โดยแต่ละแอปพลิเคชันทำงานในคอนเทนเนอร์ที่แยกออกจากกันและไม่สามารถเข้าถึงไฟล์ของแอปพลิเคชันอื่นได้หากไม่มีกลไกพิเศษ

สิทธิ์บน Android

บน Android แต่ละแอปพลิเคชันทำงานภายใต้ UID (รหัสผู้ใช้) ที่แยกต่างหาก ไฟล์ทั้งหมดที่สร้างโดยแอปพลิเคชันในแซนด์บ็อกซ์ของมันเป็นของ UID นี้และมองไม่เห็นโดยแอปพลิเคชันอื่น ในการเข้าถึงไดเรกทอรีที่ใช้ร่วมกัน (พื้นที่จัดเก็บภายนอก) แอปพลิเคชันต้องขอสิทธิ์ READ_EXTERNAL_STORAGE และ WRITE_EXTERNAL_STORAGE เริ่มจาก Android 11 ต้องขอสิทธิ์ในขณะรันไทม์ และแอปพลิเคชันที่มี targetSdkVersion 30+ ต้องใช้ SAF เพื่อเข้าถึงไฟล์ของแอปพลิเคชันอื่น การละเมิดรูปแบบสิทธิ์จะทำให้เกิด SecurityException ซึ่งจัดการโดยบล็อก try-catch มาตรฐาน Google Play จะตรวจสอบการปฏิบัติตามนโยบายสิทธิ์ของแอปพลิเคชันโดยอัตโนมัติก่อนเผยแพร่

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

Sandbox บน iOS และ Keychain

iOS Sandbox ถูกนำไปใช้ในระดับเคอร์เนล XNU และไม่อนุญาตให้แอปพลิเคชันออกจากคอนเทนเนอร์ของมัน แม้ว่าแอปพลิเคชันจะได้รับการเข้าถึง URI ไฟล์ภายนอกผ่าน Document Picker ระบบปฏิบัติการจะสร้างสำเนาชั่วคราวในคอนเทนเนอร์ของแอปพลิเคชันแทนที่จะให้การเข้าถึงต้นฉบับโดยตรง สำหรับการแชร์ไฟล์ระหว่างแอปพลิเคชัน iOS ใช้กลไก Share Sheet และ UIActivityViewController ซึ่งคัดลอกไฟล์จากคอนเทนเนอร์ของแอปพลิเคชันหนึ่งไปยังอีกคอนเทนเนอร์หนึ่ง สำหรับการจัดเก็บข้อมูลประจำตัว (โทเค็น รหัสผ่าน คีย์) อย่างปลอดภัย iOS มี Keychain — พื้นที่จัดเก็บที่เข้ารหัสซึ่งระบบสามารถเข้าถึงได้ในระดับเคอร์เนล Keychain ไม่ได้เป็นส่วนหนึ่งของคอนเทนเนอร์ Sandbox และถูกจัดการโดย daemon securityd ที่แยกต่างหาก ซึ่งให้ชั้นการป้องกันเพิ่มเติมแม้ในกรณีที่แอปพลิเคชันถูกบุกรุก

คุณลักษณะของระบบไฟล์: EXT4, APFS, F2FS

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

• EXT4 — ระบบไฟล์ Linux มาตรฐานที่มีการบันทึกประจำ รองรับไฟล์สูงสุด 16 TB และโวลุ่มสูงสุด 1 EB ใช้บน Android เป็นระบบไฟล์หลักก่อนการนำ F2FS มาใช้ ให้ความน่าเชื่อถือผ่านการบันทึกประจำ แต่ด้อยกว่า F2FS ในความเร็วการเขียนแบบสุ่มเนื่องจากจำเป็นต้องอัปเดต inode และบิตแมปบล็อกในแต่ละการดำเนินการ
• F2FS — ระบบไฟล์ที่พัฒนาโดย Samsung ในปี 2012 สำหรับหน่วยความจำแฟลช NAND โดยเฉพาะ คำนึงถึงเรขาคณิตของอาเรย์แฟลช ใช้สถาปัตยกรรมแบบบันทึกโครงสร้าง และให้ประสิทธิภาพการเขียนแบบสุ่มสูงกว่า EXT4 25–40% เริ่มจาก Android 11 Google แนะนำ F2FS เป็นระบบไฟล์หลักสำหรับพาร์ติชัน /data
• APFS — ระบบไฟล์ของ Apple ที่เปิดตัวในปี 2017 รองรับสแนปชอต การโคลนไฟล์ (คัดลอกเมื่อเขียน) การเข้ารหัสระดับไฟล์ และการควบคุมความถูกต้องของข้อมูลอย่างเข้มงวดผ่านเช็คซัม APFS ถูกปรับให้เหมาะสมสำหรับ SSD และใช้คำสั่ง TRIM เพื่อรักษาประสิทธิภาพตลอดอายุการใช้งานของพื้นที่จัดเก็บ
• exFAT — ระบบไฟล์ของ Microsoft ที่ใช้บนการ์ด SD และไดรฟ์ USB รองรับไฟล์ขนาดใหญ่กว่า 4 GB และโวลุ่มสูงสุด 128 PB ไม่มีการบันทึกประจำ ดังนั้นการตัดไฟกะทันหันอาจทำให้ข้อมูลเสียหาย แนะนำสำหรับสื่อที่ถอดได้ แต่ไม่แนะนำสำหรับพาร์ติชันระบบ

เมื่อพัฒนาแอปพลิเคชัน โปรดทราบว่าระบบไฟล์ต่างกันมี ข้อจำกัดความยาวชื่อไฟล์ ที่แตกต่างกัน (255 ไบต์สำหรับ EXT4 และ F2FS, 255 อักขระ Unicode สำหรับ APFS) ขนาดไฟล์สูงสุดและการสนับสนุนอักขระพิเศษ ตัวอย่างเช่น APFS อนุญาตให้ใช้อักขระ Unicode ในชื่อไฟล์ รวมถึงอีโมจิ ในขณะที่ EXT4 จำกัดเฉพาะ ASCII หากแอปพลิเคชันของคุณสร้างไฟล์ด้วยชื่อในภาษาต่าง ๆ ให้ทดสอบบนอุปกรณ์เป้าหมายทั้งหมด — ชื่อไฟล์ที่สร้างอย่างถูกต้องบน APFS อาจถูกตัดทอนบน EXT4

คำแนะนำในการทำงานกับระบบไฟล์

การทำงานที่เชื่อถือได้ กับระบบไฟล์ของอุปกรณ์มือถือจำเป็นต้องปฏิบัติตามกฎสำคัญหลายข้อ กฎเหล่านี้อิงจากการวิเคราะห์ข้อผิดพลาดทั่วไปของนักพัฒนาและคำแนะนำจากเอกสารอย่างเป็นทางการ

• อย่าใช้พาธที่ฮาร์ดโค้ด ไปยังไดเรกทอรี รับพาธผ่าน API ของระบบเสมอ: context.filesDir บน Android, NSSearchPathForDirectoriesInDomains บน iOS พาธที่ฮาร์ดโค้ดเปลี่ยนแปลงระหว่างเวอร์ชันระบบปฏิบัติการและอุปกรณ์
• จัดการข้อยกเว้น ของการดำเนินการไฟล์: IOException, FileNotFoundException, SecurityException บน iOS การดำเนินการ FileManager ทั้งหมดสามารถthrowข้อผิดพลาด — ห่อหุ้มด้วย do-catch บน Android การดำเนินการกับพื้นที่จัดเก็บภายนอกอาจล้มเหลวเนื่องจากไม่มีสื่อ
• ตรวจสอบพื้นที่ว่าง ก่อนเขียน ใช้ File.getUsableSpace() บน Android และ URLResourceValues.volumeAvailableCapacityKey บน iOS เตือนผู้ใช้หากพื้นที่ว่างไม่เพียงพอ
• หลีกเลี่ยงการจัดเก็บไฟล์ขนาดใหญ่ ในไดเรกทอรีที่รวมอยู่ในการสำรองข้อมูล บน iOS ให้ยกเว้นแคชจากการสำรองข้อมูลผ่าน isExcludedFromBackup บน Android ให้เลือก cacheDir สำหรับไฟล์ชั่วคราว
• ทดสอบพฤติกรรม เมื่อพื้นที่จัดเก็บเต็มและการตัดไฟกะทันหัน ใช้การเขียนแบบธุรกรรม: เขียนไปยังไฟล์ชั่วคราว จากนั้นเปลี่ยนชื่อแบบอะตอมมิก

ให้ความสนใจเป็นพิเศษกับ ความแตกต่างข้ามแพลตฟอร์ม พาธไฟล์บน Android ใช้เครื่องหมายทับ (/data/data/.../files/) บน iOS — โครงสร้าง URL (file:///var/mobile/.../Documents/) หากแอปพลิเคชันของคุณใช้เฟรมเวิร์กข้ามแพลตฟอร์ม (Flutter, React Native, Kotlin Multiplatform) ให้รวมการดำเนินการไฟล์ผ่านอะแดปเตอร์แพลตฟอร์ม ตัวอย่างเช่น Flutter มีแพ็คเกจ path_provider ซึ่งส่งคืนพาธที่ถูกต้องไปยัง Documents หรือ filesDir บนทั้งสองแพลตฟอร์มโดยไม่ต้องเขียนโค้ดที่ขึ้นกับแพลตฟอร์ม อย่าต่อพาธด้วยการดำเนินการสตริง — ใช้ File.join() หรือ URL.appendingPathComponent() ซึ่งจัดการตัวคั่นบนแพลตฟอร์มต่าง ๆ ได้อย่างถูกต้อง