كيفية توسيع نطاق عملية إثبات الهوية في SmileID لتشمل أكثر من 18,000 نوع من أجهزة Android باستخدام CameraX

تتطلّب تطبيقات إثبات الهوية للخدمات المصرفية وتسجيل شريحة SIM التقاط صور واضحة وعالية الدقة للوجه من أجل رصد عمليات الانتحال والتزييف العميق. يواجه مطوّرو تطبيقات الكاميرا على Android تحديًا شائعًا يتمثّل في التقاط لقطات واضحة بما يكفي لإجراء عمليات التحقّق من الحيوية ومكافحة الانتحال، بدون تعطُّل الأجهزة ذات الذاكرة المنخفضة.

بالنسبة إلى SmileID، وهي حزمة تطوير برامج (SDK) رائدة في مجال إثبات الهوية في أفريقيا، يتضاعف هذا التحدي بسبب تنوّع منظومة الأجهزة المتكاملة. يمثّل Android %85 من حصة السوق لأجهزة الاختبار في SmileID، بما في ذلك الهواتف الذكية الأساسية ذات المعالجات المحدودة للغاية، والنماذج الإقليمية غير المعروفة، وأجهزة نقاط البيع (POS) المخصّصة والمتينة.

قبل استخدام CameraX، واجهت SmileID عقبات هندسية معتادة ولكنها صعبة في ما يتعلّق بالكاميرا: خلاصات معاينة ممتدة واتجاهات أداة استشعار تم تدويرها وأعطال نفاد الذاكرة (OOM) وأخطاء مخصّصة للمصنّع الأصلي للجهاز (OEM). من خلال نقل حِزم تطوير البرامج (SDK) الأساسية لنظام التشغيل Android إلى CameraX، نجحت SmileID في تحويل هذه التحديات إلى ميزة تجارية كبرى.

وفقًا لشركة SmileID، حقّق نقل حِزم تطوير البرامج (SDK) لنظام التشغيل Android إلى CameraX النتائج التالية:

التحدي: الأجهزة المجزأة ومشاكل واجهات برمجة التطبيقات القديمة

للتأكّد من هوية المستخدم، يجب أن تلتقط حزمة تطوير البرامج (SDK) من SmileID لقطات سيلفي عالية الدقة لإجراء عمليات التحقّق من الحيوية على الجهاز فقط ورصد التزييف العميق المستنِد إلى السحابة الإلكترونية. 

في ظل واجهة برمجة التطبيقات القديمة Camera1 وعمليات تنفيذ واجهة برمجة التطبيقات Camera2 API المنخفضة المستوى، كان من الصعب تحقيق ذلك باستمرار لعدة أسباب: 

• تخصيصات المصنّعين الأصليين للأجهزة ومشاكلهم: أبلغت الأجهزة من شركات مصنّعة مختلفة عن اتجاهات أجهزة استشعار الكاميرا بشكل مختلف، ما أدى إلى ظهور معاينات تم تدويرها أو التقاط صور للوجه باتجاه غير صحيح.
• تشوّهات في نسبة العرض إلى الارتفاع: غالبًا ما يؤدي طلب حجم إطار معيّن على الأجهزة المنخفضة التكلفة إلى تمديد معاينة الكاميرا عموديًا أو أفقيًا، ما يؤدي إلى تشويه وجه المستخدم وجعل المصادقة البيومترية غير مجدية.
• أعطال نفاد الذاكرة (OOM): كانت معالجة الصور الأولية العالية الدقة على الأجهزة ذات ذاكرة الوصول العشوائي المنخفضة (غالبًا 1 غيغابايت أو أقل) تؤدي في كثير من الأحيان إلى أعطال فادحة في تخصيص الذاكرة.

بسبب هذه المشاكل، اقتصر نمو معدّل استخدام حزمة SDK في SmileID على الضعف أو ثلاثة أضعاف مقارنةً بالعام السابق، واضطر العديد من عمليات التحقّق إلى العودة إلى تحميل صور ثابتة عبر واجهة REST API ذات وقت استجابة طويل بدلاً من إجراء عمليات التحقّق من الحيوية في الوقت الفعلي على الجهاز فقط.

الحلّ: مسارات معالجة متّسقة باستخدام CameraX 

أعادت SmileID تصميم حِزم تطوير البرامج (SDK) للأجهزة الجوّالة من البداية باستخدام CameraX، المصمَّمة خصيصًا لتسهيل التعامل مع منظومة الأجهزة الأساسية المعقّدة وتوفير واجهة مطوّر متّسقة تراعي مراحل النشاط بشكل أصلي.

باستخدام حالات الاستخدام الأساسية في CameraX (خاصةً Preview وImageAnalysis)، أنشأت SmileID مسارًا قويًا للكاميرا ثنائي الغرض:

• المعاينة: تعرض معاينة في الوقت الفعلي لخلاصة الكاميرا بنِسب مثالية لتوجيه المستخدم.
• ImageAnalysis: تعالج هذه الفئة اللقطات باستمرار على الجهاز في الوقت الفعلي لتنفيذ عمليات الرصد الآلي للوجه في اللقطة والتحقّق من أنّ الصورة حية، واستخراج لقطة السيلفي التي تم التحقّق منها.

لالتقاط تفاصيل فائقة الدقة من أجل رصد التزييف العميق بدون حدوث أعطال بسبب نفاد الذاكرة، أضافت SmileID واجهة برمجة التطبيقات ResolutionSelector الحديثة من CameraX مباشرةً إلى إعدادات ImageAnalysis. وتتيح للمطوّرين طلب دقة مستهدَفة واختيار قاعدة احتياطية عندما لا يتوافق الجهاز مع هذا الحجم بالضبط. على سبيل المثال، يوضّح المخطّط البياني التالي ونموذج الإعدادات كيفية تقييم ResolutionSelector للأحجام المرشّحة حول هدف ‎1200x900:

في ما يلي الرمز النموذجي المقابل الذي يوضّح كيفية إقران ResolutionSelector مع STRATEGY_KEEP_ONLY_LATEST في تطبيقك (استخدِم FALLBACK_RULE_CLOSEST_HIGHER_THEN_LOWER لإعطاء الأولوية للوضوح، أو FALLBACK_RULE_CLOSEST_LOWER_THEN_HIGHER لتحديد الحد الأقصى لاستخدام الذاكرة):

import android.util.Size
import androidx.camera.core.CameraSelector
import androidx.camera.core.ImageAnalysis
import androidx.camera.core.Preview
import androidx.camera.core.resolutionselector.AspectRatioStrategy
import androidx.camera.core.resolutionselector.ResolutionSelector
import androidx.camera.core.resolutionselector.ResolutionStrategy
import androidx.camera.lifecycle.ProcessCameraProvider
import androidx.lifecycle.LifecycleOwner

fun configureCameraX(cameraProvider: ProcessCameraProvider, lifecycleOwner: LifecycleOwner, 
                     surfaceProvider: Preview.SurfaceProvider, 
                     executor: java.util.concurrent.Executor, analyzer: ImageAnalysis.Analyzer) {
    // 1. Define a resolution strategy requesting high quality (for example, 1200x900px) 
    // and selecting the closest higher (or, if unavailable, lower) resolution.
    val resolutionSelector = ResolutionSelector.Builder()
        .setResolutionStrategy(
            ResolutionStrategy(
                Size(1200, 900),
                ResolutionStrategy.FALLBACK_RULE_CLOSEST_HIGHER_THEN_LOWER
            )
        )
        .setAspectRatioStrategy(AspectRatioStrategy.RATIO_4_3_FALLBACK_AUTO_STRATEGY)
        .build()

    // 2. Configure the ImageAnalysis use case with the resolution selector
    // and a backpressure strategy that keeps the UI responsive on slow processors.
    val imageAnalysis = ImageAnalysis.Builder()
        .setResolutionSelector(resolutionSelector)        
        // Drops older frames if the device's CPU is still busy analyzing the previous one
        .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST)
        .build()

    // 3. Set up the preview stream and attach the Analyzer and SurfaceProvider
    imageAnalysis.setAnalyzer(executor, analyzer)
    val preview = Preview.Builder().build().also { it.surfaceProvider = surfaceProvider }

    // 4. Bind both use cases concurrently to the lifecycle provider
    try {
        cameraProvider.unbindAll()
        cameraProvider.bindToLifecycle(
            lifecycleOwner,
            CameraSelector.DEFAULT_FRONT_CAMERA,
            preview,
            imageAnalysis
        )
    } catch (exc: Exception) {
        // Handle binding failure safely
    }
}

من خلال طلب لقطات ذات كثافة بكسل عالية ومعالجتها محليًا، حقّقت SmileID زيادة بمقدار 4 أضعاف في دقة صور السيلفي التي يتم التقاطها. ضغطت SmileID أيضًا منطقة الوجه التي تم اقتصاصها على الجهاز، وبذلك ظلّ حجم التحميل على الشبكة مطابقًا لنظامها السابق. وقد ضمنت هذه البنية بيانات أكثر دقة لنماذج تعلُّم الآلة بدون زيادة تكاليف بيانات شبكة الجوّال للمستخدمين.

كيفية حلّ CameraX للاختلافات في الأجهزة

يعني توحيد المعايير في CameraX أنّ SmileID يمكنها الاعتماد على طبقتَين من هندسة التوافق للحفاظ على استقرار حزمة تطوير البرامج (SDK) على جميع الأجهزة:

1. مختبر اختبار الكاميرا والوسائط في Google

يتم دعم توافق CameraX من خلال التحقّق المستمر من الأجهزة المادية. في مركز اختبار الكاميرا والوسائط المخصّص من Google، يتم تشغيل حزمة اختبارية مبرمَجة يوميًا على مصفوفة ضخمة ومتغيّرة تضم أكثر من 190 طرازًا من أجهزة Android المادية. ويشمل ذلك الأجهزة التي تمثّل شرائح تعريف وإصدارات أنظمة تشغيل وإمكانات أجهزة مختلفة. 

لتحقيق سلوك أكثر اتساقًا على الأجهزة الشائعة، يرصد "مختبر اختبار الكاميرا والوسائط" من Google تلقائيًا حالات تراجع المكتبة قبل أن تؤثر في رمز الإنتاج.

2. الحلول البديلة التلقائية لمشاكل الأجهزة

تختلف القيود المادية باختلاف أجهزة Android. وقد يتعذّر على بعضها ضبط إعدادات التعرّض المخصّصة، بينما قد يعرض البعض الآخر بيانات صور معكوسة عند استخدام نِسب عرض إلى ارتفاع معيّنة. لمنع المطوّرين من تلويث قواعد الرموز البرمجية الخاصة بهم باستخدام كتل شرطية معقدة استنادًا إلى الشركة المصنّعة للجهاز وطرازه، تحتفظ CameraX بفئات داخلية لعيوب الأجهزة، مثل DeviceQuirks وCameraQuirks في camera-camera2 (DeviceQuirksLoader.kt). عندما ترصد واجهة CameraX جهازًا يتضمّن مشكلة معروفة، فإنّها تُدخِل تلقائيًا حلاً مخصّصًا. بالنسبة إلى SmileID، يعني ذلك أنّ حزمة SDK الخاصة بها يمكن أن تعمل بشكل موثوق على أكثر من 18,000 نوع من أجهزة Android بدون الحاجة إلى تصحيحات خاصة بالأجهزة في قاعدة الرموز البرمجية.

توسيع نطاق عمليات التحقّق لتصل إلى أكثر من 160 مليون عملية

من خلال الانتقال إلى CameraX، سهّلت SmileID عملية دمج حزمة تطوير البرامج (SDK) لمطوّري التطبيقات الخارجيين. 

من خلال التخلص من تشوّهات نسبة العرض إلى الارتفاع، وبطء المعاينات، والأعطال المفاجئة الناتجة عن نفاد الذاكرة، حقّقت الشركة زيادة بنسبة %20 في معدلات اجتياز عمليات التحقّق للخدمات التي تستخدم حِزم تطوير البرامج (SDK) الخاصة بها. بالنسبة إلى المؤسسات المالية وتطبيقات الأموال على الأجهزة الجوّالة في جميع أنحاء أفريقيا، تعني زيادة معدلات النجاح بنسبة %20 انضمام مئات الآلاف من المستخدمين الشرعيين بنجاح بدلاً من مغادرتهم.

وقد لاحظ المطوّرون ذلك. أدّت سهولة دمج حزمة SDK المستندة إلى CameraX إلى زيادة في معدّل الاستخدام بمقدار 15 ضعفًا في العام الأول، وارتفع إلى 20 ضعفًا بحلول العام الثاني. حتى الآن، نجحت SmileID في معالجة أكثر من 160 مليون عملية إثبات هوية باستخدام CameraX.

إنشاء قصة التوافق باستخدام مهارة CameraX

ليس من الضروري أن يكون تطوير تطبيقات الكاميرات أمرًا صعبًا. لمساعدة فريقك في استخدام أنماط CameraX نفسها التي استخدمتها SmileID، أطلق Android مهارة CameraX لوكلاء الترميز المستندين إلى الذكاء الاصطناعي. 

عند استخدام مهارة CameraX في بيئة التطوير، تطبّق برامج الذكاء الاصطناعي المخصّصة للترميز، مثل Gemini، أنماط CameraX الحالية للنقل وربط مراحل النشاط و ConcurrentCamera و MlKitAnalyzer. سواء كنت بصدد إعداد خلاصات الكاميرا المزدوجة، أو ضبط معاينة باستخدام PreviewView أو CameraXViewfinder، أو إدارة تحليل تعلُّم الآلة في الوقت الفعلي، توجّه مهارة CameraX وكيلك لإنشاء رمز برمجي دقيق وجاهز للإنتاج.

• استكشاف مهارة CameraX: انتقِل إلى دليل مهارات مطوّري برامج Android أو شغِّل android skills add camerax باستخدام Android CLI لإضافة المهارة إلى أداة الترميز المستندة إلى الذكاء الاصطناعي.
• بدء استخدام CameraX: يمكنك الانتقال إلى مستندات CameraX الرسمية وتشغيل تجربة الكاميرا في أي مكان.