Platform Channel: ما هو، أنواعه وآلية عمله في تطوير التطبيقات المحمولة

ما هو Platform Channel في Flutter؟

Platform Channel هي تقنية Flutter توفر اتصالاً ثنائي الاتجاه بين كود Dart للتطبيق والكود الأصلي لأنظمة تشغيل Android وiOS. بدون Platform Channel، يقتصر تطبيق Flutter على الإمكانيات التي يوفرها الإطار ولا يمكنه الوصول مباشرة إلى واجهات برمجة تطبيقات الكاميرا أو أجهزة الاستشعار أو Bluetooth أو نظام الملفات أو الوظائف الأخرى منخفضة المستوى للجهاز.

تم بناء بنية Platform Channel على مبدأ التبادل غير المتزامن للرسائل. يرسل جانب Dart طلبًا عبر القناة، ويعالجه الجانب الأصلي ويعيد النتيجة. يتم تسلسل جميع الرسائل إلى تنسيق ثنائي ونقلها عبر مخزن رسائل Flutter Engine، مما يضمن أقل زمن انتقال عند نقل البيانات بين بيئات التنفيذ.

يتم تحديد كل Platform Channel بواسطة اسم منطقي فريد — سلسلة تعمل كعنوان لتوجيه الرسائل. يجب أن يستخدم جانبا Dart والأصلي نفس اسم القناة حتى يتم إنشاء الاتصال بشكل صحيح. يدعم Flutter عددًا غير محدود من القنوات في تطبيق واحد، وتعمل كل قناة بشكل مستقل عن الأخرى.

وفقًا للتوثيق الرسمي لـ Flutter، يعالج Platform Channel الرسائل بنفس الترتيب الذي تم إرسالها به، مما يضمن تسلسل استدعاءات يمكن التنبؤ به. هذا أمر بالغ الأهمية للسيناريوهات التي يؤثر فيها ترتيب المعالجة على الصحة، مثل التهيئة المتسلسلة للوحدات الأصلية أو سلاسل العمليات التابعة.

كيف يعمل Platform Channel: بنية تمرير الرسائل

تتكون آلية تمرير الرسائل عبر Platform Channel من ثلاث طبقات رئيسية: يرسل جانب Dart رسالة كـ Map أو List عبر invokeMethod، ويقوم Flutter Engine بتسلسلها باستخدام StandardMethodCodec، ويتلقى الجانب الأصلي الاستدعاء في معالجه. يتم إرجاع النتيجة عبر نفس المسار في الاتجاه المعاكس.

عملية التسلسل تحول تلقائيًا أنواع بيانات Dart إلى ما يعادلها في المنصات الأصلية. الأرقام والسلاسل والقيم المنطقية والقوائم والقواميس مدعومة دون تكوين إضافي من المطور. يجب تسلسل أنواع البيانات المخصصة يدويًا، على سبيل المثال إلى سلسلة JSON، قبل الإرسال عبر القناة.

على جانب Flutter Engine، تدخل الرسالة إلى قائمة السلسلة الرئيسية للمنصة الأصلية. في Android، هذه هي السلسلة الرئيسية للتطبيق، في iOS هي حلقة التشغيل الرئيسية. هذا يعني أن العمليات طويلة الأمد في معالج القناة تحظر واجهة المستخدم وتسبب التجميد. يُنصح المطورون بتنفيذ المهام الثقيلة في سلاسل الخلفية وإعادة النتائج بشكل غير متزامن عبر callback.

أداء Platform Channel مرتفع بما يكفي لمعظم حالات الاستخدام: وقت نقل الرسالة أقل من 1 مللي ثانية على الأجهزة الحديثة. ومع ذلك، للعمليات عالية التحميل مثل معالجة تدفق الفيديو في الوقت الفعلي، يُوصى باستخدام Dart FFI أو الإضافات الأصلية مع الوصول المباشر إلى ذاكرة الجهاز.

قيود رئيسية للبنية: لا يدعم Platform Channel تمرير واصفات الملفات أو مؤشرات الذاكرة أو الكائنات الأصلية. يجب أن تكون جميع البيانات قابلة للتسلسل إلى تنسيق ثنائي. لنقل كميات كبيرة من البيانات في نطاق الميغابايت، استخدم ملفات مؤقتة مع تمرير المسار عبر القناة.

ثلاثة أنواع من Platform Channel في تطوير Flutter

يوفر Flutter ثلاثة أنواع من Platform Channel، كل منها مصمم لسيناريو تفاعل محدد. يحدد اختيار نوع القناة الصحيح بنية التكامل وسهولة صيانة الكود على كلا الجانبين — Dart والأصلي — لذلك من المهم فهم الاختلافات بين MethodChannel وEventChannel وBasicMessageChannel.

MethodChannel — استدعاء الطرق على الجانب الأصلي

MethodChannel هو النوع الأكثر شيوعًا من Platform Channel، والذي يطبق نمط استدعاء الإجراء عن بُعد. يرسل Dart اسم الطريقة والوسائط، وينفذ الجانب الأصلي العملية ويعيد النتيجة. كل استدعاء يعيد Future، مما يسمح باستخدام بنيتي async وawait في كود Dart للعمليات غير المتزامنة الملائمة.

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

في المشاريع الحقيقية، يُستخدم MethodChannel في معظم الإضافات الرسمية لـ Flutter. على سبيل المثال، تعمل حزم camera وbattery وpath_provider عبر هذا النوع من القنوات، مما يوفر الوصول إلى واجهات برمجة التطبيقات الأصلية دون الحاجة إلى كتابة كود تكامل مخصص لكل منصة.

EventChannel — الاشتراك في تدفقات الأحداث

EventChannel مصمم للسيناريوهات التي يولد فيها الجانب الأصلي تدفقًا مستمرًا من الأحداث بمرور الوقت. يتم تمرير البيانات إلى Dart عبر Stream، مما يسمح بالاشتراك في الوقت الفعلي للتحديثات. تشمل حالات الاستخدام النموذجية قراءات مقياس التسارع وإحداثيات GPS وتغييرات حالة Bluetooth والإشعارات من خدمات النظام.

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

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

BasicMessageChannel — تبادل حر للرسائل

BasicMessageChannel هو النوع الأكثر مرونة من Platform Channel، مصمم للتبادل غير المتزامن العشوائي للرسائل. على عكس MethodChannel، حيث تحتوي كل رسالة على اسم طريقة ووسائط، ينقل BasicMessageChannel فقط الحمولة بدون توجيه مدمج. يرسل المرسل رسالة، ويعالجها المستقبل ويعيد ردًا.

هذا النوع من القنوات مناسب لبروتوكولات التفاعل المخصصة، حيث يمكن أن يتغير هيكل الرسالة ديناميكيًا حسب حالة التطبيق. يستخدم BasicMessageChannel StandardMessageCodec افتراضيًا ولكنه يدعم إدخال MessageCodec مخصص لتنسيقات تسلسل البيانات غير القياسية.

من الناحية العملية، يُستخدم BasicMessageChannel بشكل أقل من MethodChannel لأنه يتطلب معالجة يدوية لتوجيه الرسائل دون نمط تسمية مدمج. ومع ذلك، لا غنى عنه عند التكامل مع المكتبات الأصلية التي تتوقع تنسيق رسالة محددًا مختلفًا عن نمط الطلب-الاستجابة القياسي المطبق في MethodChannel.

تنفيذ Platform Channel: مثال كود على Dart والمنصات الأصلية

لنفحص تنفيذًا عمليًا لـ Platform Channel باستخدام مثال الحصول على مستوى بطارية الجهاز. يوضح هذا مثال سير العمل الكامل: إعلان MethodChannel على جانب Dart، وتنفيذ المعالج على Android وiOS، ومعالجة الأخطاء بشكل صحيح عندما تكون البيانات غير متاحة أو الأذونات اللازمة مفقودة.

MethodChannel على جانب Dart

على جانب Dart، يتم إنشاء مثيل MethodChannel باسم قناة سلسلة فريد. ترسل طريقة invokeMethod طلبًا إلى الجانب الأصلي وتنتظر النتيجة كـ Future. يتم معالجة الأخطاء عبر التقاط PlatformException، الذي يعيده الجانب الأصلي عند حدوث استثناء أثناء معالجة الطلب.

import 'package:flutter/services.dart';

class BatteryPlugin {
  static const _channel = MethodChannel(
    'samples.flutter.dev/battery',
  );

  Future<String> getBatteryLevel() async {
    try {
      final result = await _channel.invokeMethod<int>(
        'getBatteryLevel',
      );
      return 'Battery level: $result%';
    } on PlatformException catch (e) {
      return 'Failed: ${e.message}';
    }
  }
}

المعالجة على جانب Android في Kotlin

على جانب Android، يتم تسجيل المعالج في MainActivity عبر طريقة configureFlutterEngine. داخل setMethodCallHandler، يتم التحقق من اسم الطريقة الواردة، وإجراء استدعاء أصلي لـ BatteryManager للحصول على مستوى البطارية، وإرجاع النتيجة عبر كائن result. للطرق غير المدعومة من القناة، يتم استدعاء result.notImplemented.

import android.os.BatteryManager
import io.flutter.embedding.android.FlutterActivity
import io.flutter.plugin.common.MethodChannel

class MainActivity : FlutterActivity() {
  private val CHANNEL = "samples.flutter.dev/battery"

  override fun configureFlutterEngine(
    flutterEngine: FlutterEngine
  ) {
    super.configureFlutterEngine(flutterEngine)
    MethodChannel(
      flutterEngine.dartExecutor.binaryMessenger,
      CHANNEL
    ).setMethodCallHandler { call, result ->
      if (call.method == "getBatteryLevel") {
        val level = getBatteryLevel()
        if (level != -1) {
          result.success(level)
        } else {
          result.error(
            "UNAVAILABLE",
            "Battery level not available",
            null
          )
        }
      } else {
        result.notImplemented()
      }
    }
  }

  private fun getBatteryLevel(): Int {
    val manager = getSystemService(BATTERY_SERVICE) as BatteryManager
    return manager.getIntProperty(
      BatteryManager.BATTERY_PROPERTY_CAPACITY
    )
  }
}

المعالجة على جانب iOS في Swift

على منصة iOS، يتم تسجيل المعالج في فئة AppDelegate عبر FlutterMethodChannel. يتلقى كود Swift الاستدعاء الوارد، ويصل إلى واجهة برمجة تطبيقات النظام UIDevice للحصول على مستوى البطارية ويعيد النتيجة إلى Flutter. تسمح المعالجة غير المتزامنة مع التقاط weak self بتنفيذ الطلبات دون خطر دورات المراجع القوية في الذاكرة.

import UIKit
import Flutter

@UIApplicationMain
class AppDelegate: FlutterAppDelegate {
  override func application(
    application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    let controller = window?.rootViewController as! FlutterViewController
    let channel = FlutterMethodChannel(
      name: "samples.flutter.dev/battery",
      binaryMessenger: controller.binaryMessenger
    )
    channel.setMethodCallHandler { [weak self] call, result in
      if call.method == "getBatteryLevel" {
        let level = self?.getBatteryLevel() ?? -1
        if level >= 0 {
          result(level)
        } else {
          result(FlutterError(
            code: "UNAVAILABLE",
            message: "Battery level not available",
            details: nil
          ))
        }
      } else {
        result(FlutterMethodNotImplemented)
      }
    }
    return super.application(
      application: application,
      didFinishLaunchingWithOptions: launchOptions
    )
  }

  private func getBatteryLevel() -> Int {
    let device = UIDevice.current
    device.isBatteryMonitoringEnabled = true
    return Int(device.batteryLevel * 100)
  }
}

متى يكون Platform Channel ضروريًا في مشاريع Flutter

Platform Channel ضروري كلما تطلب تطبيق Flutter الوصول إلى إمكانيات الجهاز غير المنفذة في الحزم القياسية. يجب على المطور إنشاء قناة مخصصة عند التكامل مع SDKs الأصلية للكاميرا أو القياسات الحيوية أو NFC أو Bluetooth Low Energy أو عند العمل مع نظام الملفات خارج بيئة التطبيق.

السيناريو النموذجي الأول هو استخدام واجهات برمجة التطبيقات الأصلية التي لا يمكن الوصول إليها مباشرة من Dart. يشمل ذلك خدمات النظام في Android وiOS وأجهزة الاستشعار مع بروتوكولات نقل بيانات غير قياسية وإشعارات الدفع بمنطق معالجة مخصص وعمليات التشفير التي تتطلب وحدة أمان الأجهزة للتخزين الآمن للمفاتيح.

السيناريو الثاني هو دمج الكود الأصلي الحالي في مشروع Flutter. إذا كانت الشركة قد طورت بالفعل مكتبة أصلية لـ Android أو iOS، يسمح Platform Channel بإعادة استخدامها دون نقلها إلى Dart. هذا يسرع هجرة التطبيقات الهجينة إلى Flutter ويحافظ على الاستثمارات في الكود الأصلي الحالي ومنطق الأعمال المتراكم.

السيناريو الثالث هو نشر إضافة Flutter مخصصة على pub.dev. تستخدم جميع الإضافات الشائعة Platform Channel لتوفير واجهة برمجة تطبيقات Dart موحدة تستدعي داخليًا الكود الأصلي لكل منصة. هذا هو النهج القياسي الذي يوصي به فريق Flutter لإنشاء حزم قابلة لإعادة الاستخدام مع دعم كلا المنصتين المحمولتين.

عند الاختيار بين إنشاء Platform Channel مخصص واستخدام حزمة جاهزة من pub.dev، يُوصى أولاً بالتحقق من توفر حل موجود. تغطي حزم camera وgeolocator وshared_preferences وpath_provider معظم الاحتياجات النموذجية. يكون Platform Channel المخصص مبررًا فقط عندما لا توجد حزمة مناسبة أو عندما تكون هناك حاجة إلى تخصيص عميق للسلوك الأصلي لا يوفره الحل الحالي.