جعل تخزين محاكي المتصفح موثوقًا عبر المتصفحات

محاكاة المتصفح ليست مجرد ترجمة كود أصلي إلى WebAssembly. تحتاج بيئة التشغيل المفيدة أيضًا إلى حفظ بيانات اللعبة بأمان، والعمل مع قدرات المتصفحات المختلفة، وعدم حجب الصفحة عند بدء المحاكي. تشرح هذه الملاحظة الحدود الهندسية التي يستخدمها Emu666 حول نظام الملفات الخاص بالأصل (OPFS) وEmscripten WasmFS وWeb Workers.

هذا شرح تقني، وليس معيار أداء أو شهادة توافق.

الحد المهم: أي خيط يملك التخزين؟

يمكن الوصول إلى OPFS عبر JavaScript وعبر خلفية WasmFS. هذان المساران غير قابلين للاستبدال. وبالأخص، قد يؤدي تمرير عمليات WasmFS لمسارات OPFS بشكل متزامن من الخيط الرئيسي للمتصفح إلى حالة جمود في بعض إصدارات Safari.

لذلك يفصل التصميم بين مسؤوليتين:

  • قبل بدء المحاكي، يستخدم JavaScript واجهات OPFS الأصلية للمتصفح للبيانات التي يجب أن تكون موجودة مسبقًا.
  • بعد البدء، يركّب المحاكي نظام الملفات المدعوم بـ OPFS من pthread worker بدلًا من تركيبه من الخيط الرئيسي.

يمنع هذا الفصل الكتابة أثناء التهيئة من أن تستبدلها عملية تركيب لاحقة، ويمنع ربط استجابة الصفحة بوكيل نظام ملفات متزامن.

مسار البدء

صفحة المتصفح
  │
  ├─ يكتب JavaScript البيانات المطلوبة بواجهات OPFS الأصلية
  │
  ├─ ينشئ Emscripten بيئة WebAssembly
  │
  └─ يركّب pthread worker خلفية WasmFS OPFS
       │
       └─ يقرأ المحاكي تخزينه المركّب ويبدأ

التفصيل مهم: لا يُعامل المسار الذي ينتمي إلى بيئة OPFS على الخيط الرئيسي باعتباره مسار module.FS عامًا. يمكن أن تبقى البيانات المؤقتة الصغيرة في نظام الملفات داخل الذاكرة، بينما تتبع البيانات الدائمة مسار OPFS الأصلي حتى تصبح بيئة worker جاهزة.

فحوص القدرات بدلًا من قواعد اسم المتصفح

لا يكفي اسم المتصفح وحده. يفحص تقرير التوافق القدرات التي تحتاجها بيئة التشغيل فعليًا، ومنها WebAssembly والذاكرة المشتركة والخيوط وBigInt وOPFS وWorkers وWebGL وميزات الصوت وGamepad API.

يُستخدم user-agent فقط لعرض اسم مفهوم للمتصفح ونظام التشغيل؛ أما تقرير توفر الميزة فيعتمد على فحص القدرة. يمكنك تشغيل الفحوص نفسها في تقرير التوافق.

الكتابة الآمنة عبر تطبيقات المتصفح

توفر بعض المتصفحات createWritable() لملفات OPFS، بينما تحتاج متصفحات أخرى إلى مسار SyncAccessHandle قائم على Worker. تخفي طبقة التخزين هذا الاختلاف خلف واجهة واحدة، وتنتظر كل كتابة في الطابور قبل إغلاق الملف لتجنب فقدان الأجزاء الأخيرة في التطبيقات الأكثر صرامة.

بالنسبة إلى البيانات الكبيرة، تستخدم بيئة التشغيل عمليات ملفات متدفقة بدل تحميل ملف كامل إلى WebAssembly heap. يجعل ذلك استخدام الذاكرة أكثر قابلية للتوقع وأنسب للجلسات الطويلة.

ما الذي لا تدّعيه هذه الملاحظة؟

  • لا تدّعي دعم كل متصفح أو جهاز.
  • لا تنشر مقارنة أداء عامة.
  • لا توفر ملفات ألعاب أو firmware أو مصادر تنزيل أو إرشادات لتجاوز حقوق النشر.
  • لا تحل محل وثائق موردي المتصفحات أو اختبار قابل لإعادة الإنتاج لتطبيق محدد.

الهدف أضيق: توثيق حد عملي بين worker والتخزين يجعل بيئة WebAssembly في المتصفح أسهل للفهم والاختبار والتحسين.

أعد إنتاج الفحوص ذات الصلة

استخدم تقرير توافق المتصفح لرؤية نتائج الميزات في متصفحك الحالي. ويجب أن تقترن أي مناقشة عامة للتنفيذ بمثال صغير لا يتعلق بالألعاب وبمصفوفة واضحة للمتصفح والإصدار.

قراءة إضافية