سیستم فایل دستگاه موبایل: چیست، ساختار دایرکتوری‌ها و نحوه کار

سیستم فایل دستگاه موبایل چیست؟

سیستم فایل یک جزء نرم‌افزاری از سیستم‌عامل است که نحوه نوشتن، خواندن و سازماندهی داده‌ها روی حافظه فیزیکی را مدیریت می‌کند. در دستگاه‌های موبایل، سیستم فایل وظایف حیاتی را انجام می‌دهد: مدیریت فضای حافظه فلش، کنترل دسترسی به فایل‌ها بر اساس مجوزها، ثبت تغییرات برای بازیابی پس از خرابی و بهینه‌سازی نوشتن با در نظر گرفتن ویژگی‌های حافظه NAND فلش.

برخلاف سیستم‌عامل‌های دسکتاپ، سیستم‌های فایل موبایل با در نظر گرفتن تعداد محدود چرخه‌های بازنویسی حافظه فلش طراحی می‌شوند. سلول‌های NAND تعداد محدودی عملیات پاک شدن را تحمل می‌کنند — از ۳٬۰۰۰ تا ۱۰٬۰۰۰ چرخه برای حافظه‌های TLC و MLC به ترتیب. برای افزایش عمر حافظه، سیستم‌های فایل از مکانیسم‌های wear leveling (تراز کردن فرسایش) و دستورات TRIM استفاده می‌کنند. F2FS که توسط سامسونگ به طور خاص برای حافظه فلش توسعه یافته، هندسه آرایه NAND را در نظر گرفته و داده‌ها را به گونه‌ای قرار می‌دهد که تکه‌تکه شدن و تعداد عملیات پاک شدن بلوک‌ها به حداقل برسد.

دستگاه‌های موبایل مدرن از ترکیبی از چندین سیستم فایل استفاده می‌کنند. حافظه داخلی (پارتیشن /data) در Android با EXT4 یا F2FS و در iOS با APFS فرمت می‌شود. کارت‌های SD به طور سنتی از exFAT برای پشتیبانی از فایل‌های بزرگتر از ۴ گیگابایت یا FAT32 برای حداکثر سازگاری استفاده می‌کنند. پارتیشن /system در Android اغلب فقط خواندنی نصب می‌شود و از EXT4 یا EROFS (Enhanced Read-Only File System) — یک سیستم فایل فشرده توسعه یافته توسط هواوی برای کاهش اندازه پارتیشن سیستم — استفاده می‌کند.

ساختار دایرکتوری در Android

سلسله‌مراتب دایرکتوری Android بر اساس ساختار Linux با ریشه در / است. هر پارتیشن سیستم فایل، مجوزهای دسترسی و کاربرد خاص خود را دارد. برنامه فقط به مجموعه محدودی از دایرکتوری‌ها دسترسی دارد — بقیه با مجوز root محافظت می‌شوند.

پارتیشن /data و سندباکس برنامه‌ها

پارتیشن /data پارتیشن اصلی برای ذخیره‌سازی داده‌های کاربر، برنامه‌های نصب شده و تنظیمات آنهاست. هر برنامه یک دایرکتوری اختصاصی در مسیر /data/data/<package_name>/ دریافت می‌کند. در داخل این دایرکتوری، سیستم به طور خودکار زیرشاخه‌هایی ایجاد می‌کند: files/ برای فایل‌های برنامه، cache/ برای فایل‌های موقت، databases/ برای پایگاه‌های داده SQLite، shared_prefs/ برای SharedPreferences. مجوزهای دسترسی به این دایرکتوری در هنگام نصب برنامه تنظیم می‌شود و بدون دسترسی root قابل تغییر نیست. پارتیشن /data در اکثر دستگاه‌های مدرن با F2FS فرمت می‌شود که سرعت نوشتن تصادفی را تا ۴۰٪ در مقایسه با EXT4 افزایش می‌دهد.

پارتیشن /system و اجزای سیستم

پارتیشن /system شامل سیستم‌عامل، برنامه‌های سیستمی و کتابخانه‌هاست. این پارتیشن فقط خواندنی نصب می‌شود تا از تغییر تصادفی یا مخرب فایل‌های سیستمی جلوگیری کند. در دستگاه‌های دارای Android 10+ و Project Treble، پارتیشن /system پویا است و می‌تواند بدون نیاز به فلش کامل از طریق بسته‌های OTA به‌روزرسانی شود. برای برنامه‌ها، پارتیشن /system غیرقابل دسترسی است — تلاش برای نوشتن باعث ایجاد خطای SecurityException می‌شود. با این حال، برنامه‌ها می‌توانند برخی فایل‌ها را از /system بخوانند، مانند فونت‌های سیستمی و فایل‌های پیکربندی، اگر مجوزهای لازم را داشته باشند.

نقطه اتصال /sdcard

نقطه اتصال /sdcard یک پیوند نمادین به پارتیشن حافظه خارجی شبیه‌سازی شده یا فیزیکی است. در دستگاه‌های بدون کارت SD، /sdcard به زیرپارتیشنی در داخل /data اشاره می‌کند که برای دسترسی عمومی اختصاص داده شده است. این پارتیشن زمانی که دستگاه از طریق پروتکل MTP به رایانه متصل می‌شود برای کاربر قابل مشاهده است. برنامه‌ها از طریق مجوزهای READ_EXTERNAL_STORAGE و WRITE_EXTERNAL_STORAGE و از Android 10 به بعد از طریق Scoped Storage با استفاده از MediaStore API به /sdcard دسترسی پیدا می‌کنند. اندازه /sdcard معمولاً ۶۰–۸۰٪ از کل حجم حافظه فلش دستگاه را تشکیل می‌دهد و بقیه برای پارتیشن /data ذخیره می‌شود.

ساختار دایرکتوری در iOS

در iOS، سیستم فایل از طریق کانتینرهای Sandbox برنامه‌ها سازماندهی می‌شود. هر برنامه یک دایرکتوری ایزوله دریافت می‌کند که دسترسی به آن در سطح هسته XNU محدود شده است. پارتیشن کاربر از سیستم فایل APFS (Apple File System) استفاده می‌کند که در iOS 10.3 معرفی شد. APFS از snapshot، کلون کردن فایل و رمزگذاری در سطح فایل پشتیبانی می‌کند که آن را برای دستگاه‌های موبایل بهینه می‌سازد.

دایرکتوری‌های استاندارد کانتینر 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 از چهار کلاس پشتیبانی می‌کند: Complete Protection (فایل در هنگام قفل بودن دستگاه در دسترس نیست)، Protected Unless Open (فایل‌های از قبل باز شده در هنگام قفل در دسترس هستند)، Protected Until First User Authentication (فایل‌ها پس از اولین باز کردن قفل در دسترس هستند) و No Protection (فایل‌ها همیشه پس از بوت شدن دستگاه در دسترس هستند). به طور پیش‌فرض، همه فایل‌های Documents و Library کلاس Complete Protection را دریافت می‌کنند که حداکثر محافظت از داده‌های کاربر را تضمین می‌کند. هنگام ایجاد فایل می‌توان به صراحت کلاس محافظتی دیگری تعیین کرد اگر برنامه‌ای که در پس‌زمینه کار می‌کند باید در هنگام قفل بودن دستگاه به داده‌ها دسترسی داشته باشد.

مجوزهای دسترسی و امنیت سیستم فایل

مدیریت دسترسی به فایل‌ها در دستگاه‌های موبایل تفاوت کلیدی بین 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 پیاده‌سازی شده و به برنامه اجازه نمی‌دهد از کانتینر خود خارج شود. حتی اگر برنامه از طریق Document Picker به URI یک فایل خارجی دسترسی پیدا کند، سیستم‌عامل یک کپی موقت در کانتینر برنامه ایجاد می‌کند به جای ارائه دسترسی مستقیم به اصل فایل. برای تبادل فایل بین برنامه‌ها، iOS از مکانیسم‌های Share Sheet و UIActivityViewController استفاده می‌کند که فایل را از کانتینر یک برنامه به کانتینر دیگری کپی می‌کنند. برای ذخیره امن اطلاعات احراز هویت (توکن‌ها، رمزهای عبور، کلیدها)، iOS Keychain را فراهم می‌کند — یک مخزن رمزگذاری شده که در سطح هسته برای سیستم قابل دسترسی است. Keychain بخشی از کانتینر Sandbox نیست و توسط دیمن جداگانه‌ای به نام securityd مدیریت می‌شود که سطح حفاظت اضافی حتی در صورت به خطر افتادن برنامه فراهم می‌کند.

ویژگی‌های سیستم‌های فایل: EXT4، APFS، F2FS

انتخاب سیستم فایل به طور مستقیم بر عملکرد و قابلیت اطمینان ذخیره‌سازی داده تأثیر می‌گذارد. هر سیستم فایل معماری، بهینه‌سازی و محدودیت‌های خاص خود را دارد. برای توسعه‌دهنده مفید است که این تفاوت‌ها را درک کند تا رفتار برنامه را در دستگاه‌های مختلف پیش‌بینی کند.

• EXT4 — سیستم فایل استاندارد Linux با Journaling، پشتیبانی از فایل‌های تا ۱۶ ترابایت و حجم تا ۱ اگزابایت. در Android به عنوان سیستم اصلی قبل از معرفی F2FS استفاده می‌شود. به دلیل ژورنال قابلیت اطمینان را فراهم می‌کند، اما در سرعت نوشتن تصادفی به دلیل نیاز به به‌روزرسانی inode و bitmap بلوک‌ها در هر عملیات از F2FS پایین‌تر است
• F2FS — سیستم فایل توسعه یافته توسط سامسونگ در سال ۲۰۱۲ به طور خاص برای حافظه NAND فلش. هندسه آرایه فلش را در نظر می‌گیرد، از معماری log-structured استفاده می‌کند و ۲۵–۴۰٪ عملکرد نوشتن تصادفی بالاتری نسبت به EXT4 ارائه می‌دهد. از Android 11، F2FS توسط Google به عنوان سیستم فایل اصلی برای پارتیشن /data توصیه می‌شود
• APFS — سیستم فایل Apple که در سال ۲۰۱۷ معرفی شد. از snapshot، کلون کردن فایل (copy-on-write)، رمزگذاری در سطح فایل و کنترل دقیق یکپارچگی داده از طریق جمع‌های کنترلی پشتیبانی می‌کند. APFS برای SSD بهینه شده و از دستورات TRIM برای حفظ عملکرد در طول عمر حافظه استفاده می‌کند
• exFAT — سیستم فایل مایکروسافت که در کارت‌های SD و درایوهای USB استفاده می‌شود. از فایل‌های بزرگتر از ۴ گیگابایت و حجم تا ۱۲۸ پتابایت پشتیبانی می‌کند. Journaling ندارد، بنابراین قطع ناگهانی برق ممکن است به داده‌ها آسیب برساند. برای رسانه‌های قابل جابجایی توصیه می‌شود اما نه برای پارتیشن‌های سیستمی

هنگام توسعه برنامه‌ها در نظر بگیرید که سیستم‌های فایل مختلف محدودیت‌های متفاوتی برای طول نام فایل (۲۵۵ بایت برای EXT4 و F2FS، ۲۵۵ کاراکتر Unicode برای APFS)، حداکثر اندازه فایل و پشتیبانی از کاراکترهای خاص دارند. به عنوان مثال، APFS کاراکترهای Unicode از جمله ایموجی را در نام فایل‌ها مجاز می‌داند، در حالی که EXT4 به ASCII محدود است. اگر برنامه فایل‌هایی با نام به زبان‌های مختلف ایجاد می‌کند، عملکرد را روی همه دستگاه‌های هدف آزمایش کنید — نام فایلی که به درستی در APFS ایجاد شده ممکن است در EXT4 کوتاه شود.

توصیه‌هایی برای کار با سیستم فایل

کار قابل اعتماد با سیستم فایل دستگاه موبایل مستلزم رعایت چند قانون کلیدی است. آنها بر اساس تحلیل خطاهای رایج توسعه‌دهندگان و توصیه‌های مستندات رسمی هستند.

• از مسیرهای سخت‌کد شده استفاده نکنید به دایرکتوری‌ها. همیشه مسیرها را از طریق APIهای سیستم دریافت کنید: context.filesDir در Android، NSSearchPathForDirectoriesInDomains در iOS. مسیرهای سخت بین نسخه‌های سیستم‌عامل و دستگاه‌ها تغییر می‌کنند
• استثناها را مدیریت کنید عملیات فایل: IOException، FileNotFoundException، SecurityException. در iOS همه عملیات FileManager ممکن است خطا ایجاد کنند — آنها را در 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() استفاده کنید که جداکننده‌ها را در پلتفرم‌های مختلف به درستی مدیریت می‌کنند.