Platform Channel: 정의, 유형 및 모바일 개발에서의 동작

Flutter에서 Platform Channel이란?

Platform Channel은 애플리케이션의 Dart 코드와 Android 및 iOS 운영 체제의 네이티브 코드 간의 양방향 통신을 제공하는 Flutter 기술입니다. Platform Channel이 없으면 Flutter 애플리케이션은 프레임워크가 제공하는 기능으로 제한되며 카메라 API, 센서, Bluetooth, 파일 시스템 및 기타 저수준 기기 기능에 직접 액세스할 수 없습니다.

Platform Channel 아키텍처는 비동기 메시지 교환 원칙을 기반으로 구축되었습니다. Dart 측이 채널을 통해 요청을 보내고 네이티브 측이 이를 처리하여 결과를 반환합니다. 모든 메시지는 바이너리 형식으로 직렬화되어 Flutter Engine 메시지 버퍼를 통해 전송되므로 실행 환경 간 데이터 전송 시 지연 시간이 최소화됩니다.

각 Platform Channel은 고유한 논리적 이름(메시지 라우팅의 주소 역할을 하는 문자열)으로 식별됩니다. Dart 측과 네이티브 측은 통신이 올바르게 설정되도록 동일한 채널 이름을 사용해야 합니다. Flutter는 단일 애플리케이션에서 임의의 수의 채널을 지원하며 각 채널은 다른 채널과 독립적으로 작동합니다.

공식 Flutter 문서에 따르면 Platform Channel은 메시지가 전송된 순서대로 처리하여 예측 가능한 호출 순서를 보장합니다. 이는 네이티브 모듈의 순차적 초기화나 종속 작업 체인과 같이 처리 순서가 정확성에 영향을 미치는 시나리오에서 중요합니다.

Platform Channel 작동 방식: 메시지 전달 아키텍처

Platform Channel을 통한 메시지 전달 메커니즘은 세 가지 주요 계층으로 구성됩니다. Dart 측이 invokeMethod를 통해 Map 또는 List로 메시지를 보내고 Flutter Engine이 StandardMethodCodec을 사용하여 직렬화하며 네이티브 측이 핸들러에서 호출을 수신합니다. 결과는 동일한 경로를 통해 역방향으로 반환됩니다.

직렬화 프로세스는 Dart 데이터 유형을 자동으로 네이티브 플랫폼에 해당하는 것으로 변환합니다. 숫자, 문자열, 부울 값, 목록 및 사전은 개발자의 추가 구성 없이 지원됩니다. 사용자 정의 데이터 유형은 채널을 통해 보내기 전에 수동으로(예: JSON 문자열로) 직렬화해야 합니다.

Flutter Engine 측에서 메시지는 네이티브 플랫폼의 메인 스레드 큐에 들어갑니다. Android에서는 애플리케이션의 메인 스레드이고 iOS에서는 메인 런 루프입니다. 즉, 채널 핸들러에서 오래 실행되는 작업은 사용자 인터페이스를 차단하고 멈춤을 유발합니다. 개발자는 백그라운드 스레드에서 무거운 작업을 수행하고 콜백을 통해 비동기적으로 결과를 반환하는 것이 좋습니다.

Platform Channel의 성능은 대부분의 사용 사례에 충분히 높습니다. 최신 기기에서 메시지 전송 시간은 1밀리초 미만입니다. 그러나 실시간 비디오 스트림 처리와 같은 고부하 작업의 경우 Dart FFI 또는 기기 메모리에 직접 액세스하는 네이티브 플러그인을 권장합니다.

아키텍처의 주요 제한 사항: Platform Channel은 파일 디스크립터, 메모리 포인터 또는 네이티브 객체 전달을 지원하지 않습니다. 모든 데이터는 바이너리 형식으로 직렬화 가능해야 합니다. 메가바이트 범위의 대용량 데이터를 전송하려면 채널을 통해 경로를 전달하는 임시 파일을 사용하십시오.

Flutter 개발의 세 가지 Platform Channel 유형

Flutter는 세 가지 유형의 Platform Channel을 제공하며 각각 특정 상호 작용 시나리오를 위해 설계되었습니다. 올바른 채널 유형을 선택하면 Dart와 네이티브 양쪽의 통합 아키텍처와 코드 유지 관리 용이성이 결정되므로 MethodChannel, EventChannel 및 BasicMessageChannel의 차이점을 이해하는 것이 중요합니다.

MethodChannel — 네이티브 측에서 메서드 호출

MethodChannel은 원격 프로시저 호출 패턴을 구현하는 가장 일반적인 Platform Channel 유형입니다. Dart가 메서드 이름과 인수를 보내면 네이티브 측이 작업을 수행하고 결과를 반환합니다. 각 호출은 Future를 반환하므로 편리한 비동기 작업을 위해 Dart 코드에서 async 및 await 구문을 사용할 수 있습니다.

이 채널 유형은 요청-응답 작업(배터리 잔량 확인, 센서 데이터 읽기, 네이티브 측 계산 또는 시스템 서비스에서 데이터 요청)에 적합합니다. MethodChannel은 StandardMethodCodec을 통해 표준 데이터 유형을 지원하며 최신 Dart의 Null safety 지원 덕분에 null 값도 포함됩니다.

실제 프로젝트에서 MethodChannel은 대부분의 공식 Flutter 플러그인에서 사용됩니다. 예를 들어 camera, battery 및 path_provider 패키지는 이 채널 유형을 통해 작동하여 각 플랫폼에 대한 사용자 정의 통합 코드를 작성하지 않고도 네이티브 API에 액세스할 수 있도록 합니다.

EventChannel — 이벤트 스트림 구독

EventChannel은 네이티브 측이 시간이 지남에 따라 연속적인 이벤트 스트림을 생성하는 시나리오를 위해 설계되었습니다. 데이터는 Stream을 통해 Dart로 전달되어 실시간 업데이트를 구독할 수 있습니다. 일반적인 사용 사례로는 가속도계 판독값, 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 구현을 살펴보겠습니다. 이 예제는 Dart 측에서 MethodChannel 선언, Android 및 iOS에서 핸들러 구현, 데이터를 사용할 수 없거나 필요한 권한이 없는 경우 오류를 올바르게 처리하는 전체 워크플로를 보여줍니다.

Dart 측의 MethodChannel

Dart 측에서는 고유한 문자열 채널 이름으로 MethodChannel 인스턴스가 생성됩니다. invokeMethod 메서드는 네이티브 측에 요청을 보내고 Future로 결과를 기다립니다. 오류 처리는 요청 처리 중 예외가 발생할 때 네이티브 측이 반환하는 PlatformException을 catch하여 수행됩니다.

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 측에서는 configureFlutterEngine 메서드를 통해 MainActivity에 핸들러가 등록됩니다. 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 시스템 API에 액세스하여 배터리 잔량을 가져온 후 결과를 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)
  }
}

Flutter 프로젝트에서 Platform Channel이 필요한 경우

Platform Channel은 Flutter 애플리케이션이 표준 패키지에 구현되지 않은 기기 기능에 액세스해야 할 때마다 필요합니다. 개발자는 카메라, 생체 인식, NFC, Bluetooth Low Energy용 네이티브 SDK와 통합하거나 애플리케이션 샌드박스 외부의 파일 시스템으로 작업할 때 사용자 정의 채널을 만들어야 합니다.

첫 번째 일반적인 시나리오는 Dart에서 직접 액세스할 수 없는 네이티브 API 사용입니다. 여기에는 Android 및 iOS 시스템 서비스, 비표준 데이터 전송 프로토콜이 있는 하드웨어 센서, 사용자 정의 처리 로직이 있는 푸시 알림 및 보안 키 저장을 위해 HSM(하드웨어 보안 모듈)이 필요한 암호화 작업이 포함됩니다.

두 번째 시나리오는 Flutter 프로젝트에 기존 네이티브 코드 통합입니다. 회사가 이미 Android 또는 iOS용 네이티브 라이브러리를 개발한 경우 Platform Channel을 사용하면 Dart로 포팅하지 않고 재사용할 수 있습니다. 이는 하이브리드 애플리케이션의 Flutter 마이그레이션을 가속화하고 기존 네이티브 코드와 축적된 비즈니스 로직에 대한 투자를 보존합니다.

세 번째 시나리오는 pub.dev에 사용자 정의 Flutter 플러그인 게시입니다. 모든 인기 플러그인은 Platform Channel을 사용하여 내부적으로 각 플랫폼의 네이티브 코드를 호출하는 통합 Dart API를 제공합니다. 이는 Flutter 팀이 두 모바일 플랫폼을 모두 지원하는 재사용 가능한 패키지를 만들기 위해 권장하는 표준 접근 방식입니다.

사용자 정의 Platform Channel을 만들거나 pub.dev에서 기성 패키지를 사용할지 선택할 때는 먼저 기존 솔루션의 가용성을 확인하는 것이 좋습니다. camera, geolocator, shared_preferences 및 path_provider 패키지는 대부분의 일반적인 요구 사항을 충족합니다. 사용자 정의 Platform Channel은 적합한 패키지가 없거나 기존 솔루션이 제공하지 않는 네이티브 동작의 심층 사용자 정의가 필요한 경우에만 정당화됩니다.