MethodChannel payload marshalling vs Impeller raster thread: attributing jank across the Dart/native boundary

Context

A Flutter app streams high-frequency sensor data from Android/iOS native code to the Dart UI isolate via MethodChannel using the default StandardMessageCodec. Profiling in DevTools shows intermittent frame drops, but the timeline does not clearly separate marshalling overhead on the platform channel from rasterizer work on the Impeller or Skia backend.

Constraints and uncertainty

• Impeller is the default on iOS but its Android rollout remains version- and device-dependent; Skia may still be active on some targets.
• DevTools labels the raster thread differently across Flutter releases, making it difficult to compare UI-thread vs raster-thread saturation consistently.
• Channel calls are asynchronous; assuming synchronous round-trip timing conflates Dart-side callback scheduling with native serialization cost.

Goal

Determine whether optimization effort should target Dart-side widget rebuild reduction, channel payload frequency and codec choice, or the rendering backend configuration—without guessing which layer owns the bottleneck.

What measurement strategy reliably isolates MethodChannel marshalling latency from raster-thread frame production in a profile-mode timeline? How can the active rendering backend (Impeller vs Skia) be confirmed on a given device at runtime to correlate jank patterns? Does Pigeon-generated interop reduce per-call overhead enough to shift the bottleneck away from the channel boundary for per-frame payloads?