يلتقط تطبيق سطح المكتب لدينا الاجتماعات دون روبوت ويبثها إلى السحابة. لشهور، كان محرك التسجيل أصعب جزء في المنتج لتحقيق الموثوقية. كنا نصلح فئة واحدة من الحالات الحدية، ونطلقها، ثم تظهر حالة جديدة في الأسبوع التالي. أسباب جذرية مختلفة، والنمط نفسه. كان المحرك يعمل في عملية العرض لتطبيق Electron لدينا. جربنا الإصلاحات الواضحة: إدارة أكثر صرامة لدورة الحياة، ونقل العمل خارج الخيط الرئيسي، وعزله عن دورة عرض React. ساعد كل تغيير بشكل هامشي، لكن لا أحد منها عالج المشكلة الحقيقية. عملية العرض هي المكان الخطأ للقيام بالتقاط الصوت والفيديو في الوقت الفعلي. لا يمكن لمحرك الالتقاط أن يتسامح مع توقفات GC أو التقييد أو أي من الأشياء الأخرى التي تقوم بها بيئة تشغيل المتصفح للبقاء مستجيبًا.
لذا انتقلنا إلى الحل الأصلي: Screen Capture Kit على macOS، و libobs على Windows، وطبقة Swift مشتركة تربطها معًا. عادةً ما يعني ربط بيئة تشغيل أصلية بـ React كتابة روابط الإضافات الأصلية يدويًا. ماذا لو أصبحت كل خاصية @Published في Swift تلقائيًا ذرة Jotai في React؟ هذا بالضبط ما تفعله أداتنا الداخلية Atomic.
على macOS، نستقبل مخازن عينات خام من ثلاثة مصادر مستقلة ونجمّع الملف بأنفسنا. على Windows، تعمل عمليات الالتقاط والخلط والترميز والتجميع (muxing) كرسم بياني واحد. نستخدم Windows Graphics Capture (WGC) كطريقة أساسية، وإذا لم تسلّم الإطارات في الوقت المناسب، نعود إلى Bit Blt. نكتشف أيضًا الإطارات السوداء بالكامل ونبدّل الطريقة في منتصف التسجيل.
الانهيار في الدقيقة 30 يفقد في أقصى الحالات الثانية الأخيرة فقط. تذهب المقاطع إلى التخزين المحلي والسحابة في آن واحد. إذا انقطعت الشبكة، تبقى المقاطع محليًا ويستأنف الرفع تلقائيًا عند عودة الاتصال. كان تسجيل سطح المكتب أحد أكثر مصادر تذاكر الدعم شيوعًا لدينا. الآن إنه جزء ممل من التطبيق يعمل ببساطة.
المصدر: Hacker News · لخّصه HeadlinesBriefing