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

Short answer

You cannot attribute this jank from the DevTools timeline alone. MethodChannel marshalling happens on the platform thread (Android main thread / iOS main thread), which DevTools does not render as a first-class track. The reliable strategy is to measure three things separately and correlate them: (1) channel transit time via timestamps, (2) pure marshalling cost via a no-op handler, and (3) raster contribution by disabling the stream entirely. Only then decide whether to optimize rebuilds, payloads, or the backend.

Measurement strategy

Always measure in flutter run --profile on a physical device; debug-mode marshalling numbers are misleading.

1. Channel transit floor: Add a native handler that replies immediately without touching the payload. Time the round trip from Dart. This is your per-call floor cost (codec + thread hops), independent of payload processing.
2. Pure marshalling: Timestamp payload creation natively and receipt in Dart (e.g., Timeline.instantSync markers or a simple monotonic clock diff logged periodically). The gap is transit + serialization.
3. Raster isolation: Run the same UI with the sensor stream stubbed to replay canned data inside Dart. If jank persists, the rasterizer/scene owns it; if it vanishes, the channel boundary is implicated.
4. Native-side confirmation: Capture Android Studio Profiler or Instruments traces alongside the DevTools timeline and look for platform-thread codec work aligning with dropped frames.

Confirming Impeller vs Skia at runtime

Backend behavior is version- and device-dependent, so verify per target rather than assuming:

• iOS: Impeller has been the default on recent stable releases unless opted out via FLTEnableImpeller in Info.plist. Check your plist and Flutter version.
• Android: Rollout varies by Flutter version and device/GPU. Use the manifest meta-data flag or adb shell setprop debug.impeller.enabled true/false on debuggable builds for A/B comparison, and confirm via device logs at engine startup.

Run the identical workload with the backend toggled and compare jank frequency. Note that Impeller largely eliminates Skia-era shader-compilation jank, so residual raster spikes under Impeller more likely indicate scene complexity or texture uploads.

Does Pigeon shift the bottleneck?

Mostly no, for your case. Pigeon generates typed bindings but still uses StandardMessageCodec under the hood by default. It removes hand-written casting and some boxing, but per-call marshalling cost is fundamentally unchanged. For per-frame sensor payloads, the higher-leverage fixes are:

• Batch samples into typed data (Float64List/Uint8List), which the codec copies as a block instead of serializing element-by-element like boxed lists/maps.
• Reduce call frequency — batch N samples per message rather than one message per sample. Per-call overhead (thread hops) dominates for high-frequency small payloads.

Recommendation order

Establish the no-op floor first. If transit time is small but frames still drop, look at the raster thread and widget rebuilds. If transit is significant, batch into typed buffers before considering Pigeon or backend changes. One missing detail that would change this advice: your payload shape and message rate — if you are already batching typed data at low frequency, the channel is unlikely to be the bottleneck.