نقل ArrayBuffer في JavaScript: أين تذهب البايتات بعد structuredClone؟

الخلاصة السريعة

• يحدد transfer الموارد التي تنقل بدلا من نسخها. [1]
• ضع المخزن نفسه في القائمة، لا Uint8Array. [2]
• في اختبارنا بقيت النسخة كما كانت بعد تعديل الأصل.
• بعد النقل رأينا طول الأصل صفرا، وطول الناتج أربعة.
• اختبار إنشاء عرض جديد على المخزن القديم أعاد TypeError.

أربعة بايتات ومساران منفصلان

اخترنا القيم [18,52,86,120] لتتبعها واحدة واحدة. نفذنا تجربتين مستقلتين بالبيانات نفسها؛ لم نستعمل الأصل الذي عدلناه في تجربة النسخ مدخلا لتجربة النقل. هذا الفصل مهم كي لا ننسب تغيرا سبق حدوثه إلى العملية التالية.

شغلنا المثال في Node.js 24.19.0 وEdge 155.0.4283.45. سجلنا محتوى الناتج وطول الطرفين، ثم قارناهما بتوقعات مكتوبة قبل التنفيذ. الأرقام هنا نتائج تجربة محلية صغيرة، وليست قياسا لاستهلاك الذاكرة أو لسرعة نقل ملفات.

ابدأ بنسخة وأبق الأصل

أنشأنا المصفوفة، ثم نسخناها، وبعد ذلك استبدلنا أول قيمة في الأصل بالعدد 99. أظهر الأصل [99,52,86,120]، بينما أظهرت النسخة [18,52,86,120]. بقي طول كل منهما أربعة بايتات، ولم يظهر التعديل في النسخة.

اقرأ الترتيب في الشيفرة: حدث التعديل بعد النسخ. لو سجلنا القيم قبل التعديل فقط، لاتفق الطرفان، ولما كانت تلك القراءة وحدها كافية لبيان أثر تعديل لاحق. نقارن موضعا بعينه بدلا من الاكتفاء بأن العدد الإجمالي متساو.

const a = Uint8Array.of(18,52,86,120);
const c = structuredClone(a);
a[0] = 99;
console.log([...a], [...c]);

[1]

أعد البداية ثم انقل المورد

Uint8Array قابل للتسلسل، لكن المورد القابل للنقل هنا هو ArrayBuffer الموجود في buffer. كما أن قائمة النقل لا تحل محل تضمين البيانات في القيمة المرسلة. [2]

في الشيفرة التالية بدأنا من القيم الأربع الأصلية. احتفظنا باسم old للمخزن قبل النقل، ثم مررنا المصفوفة قيمة للعملية ومخزنها ضمن القائمة. ظهر في السجل طول الأصل 0 وطول الناتج 4، وكانت قيم الناتج [18,52,86,120].

الصفر في خانة طول الأصل لم يعن أن الأرقام الأربعة اختفت من نتيجة العملية. وجدناها في الطرف الجديد بالترتيب الذي بدأنا به. لذلك جمعنا في الجدول بين الطول والمحتوى؛ قراءة خانة واحدة كانت ستترك نصف النتيجة غير ظاهر.

const a = Uint8Array.of(18,52,86,120);
const old = a.buffer;
const b = structuredClone(a,
  {transfer:[old]});
console.log(a.byteLength,
  b.byteLength,[...b]);
try { new Uint8Array(old); }
catch(e) { console.log(e.name); }

[1] [2]

اختبر المرجع القديم بفعل محدد

بعد النقل حاولنا إنشاء Uint8Array جديد من old داخل كتلة المحاولة. سجلت كتلة الالتقاط الاسم TypeError. هذا هو الفعل الذي نفذناه؛ لا نبدل الوصف بعبارة واسعة تقول إن كل تعبير يستعمل الاسم القديم سيرفع الاستثناء نفسه.

احتفظنا أيضا بقراءة طول المخزن القديم، فكانت صفرا. وجود المتغير old في الشيفرة لم يثبت استمرار إمكان استعمال المخزن لإنشاء العرض المطلوب. يوضح الرسم الداخلي ترتيب القراءات، ويضع نتيجة المحاولة في موضعها بعد النقل.

اكتب توقعك قبل المقارنة

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

لم نشغل عاملا خلفيا، ولم نختبر تزامنا أو سرعة أو موارد من أنواع أخرى. النتيجة العملية لهذا المثال محددة: احتجنا عند متابعة القيم المنقولة إلى الطرف الجديد، بينما ظلت قراءة الأصل المعدل متاحة في تجربة النسخ المستقلة.

المراجع

1. MDN — structuredClone
   https://developer.mozilla.org/en-US/docs/Web/API/Window/structuredClone
2. MDN — Transferable objects
   https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Transferable_objects