[pigeon] Add FFI and JNI support to Swift and Kotlin - #11352
[pigeon] Add FFI and JNI support to Swift and Kotlin#11352tarrinneal wants to merge 176 commits into
Conversation
stuartmorgan-g
left a comment
stuartmorgan-g
left a comment
There was a problem hiding this comment.
Some code nits, but mostly just docs feedback at this point!
| // Copyright 2013 The Flutter Authors | ||
| // Use of this source code is governed by a BSD-style license that can be | ||
| // found in the LICENSE file. | ||
| // Autogenerated from Pigeon, do not edit directly. |
There was a problem hiding this comment.
Nit: maybe generate a blank link above this so it's easier to see that this isn't part of the boilerplate header?
There was a problem hiding this comment.
I'll do a follow up pr to change all the generators since this applies to all of them
| - **Consider Native Interop if**: | ||
| - Your plugin targets only Android, iOS, and/or macOS. | ||
| - Your plugin handles high-frequency messaging, large typed arrays (e.g., image processing, sensor data streams), or latency-sensitive communication where serialization overhead is a bottleneck. | ||
| - You need synchronous execution for platform APIs on the host thread. |
There was a problem hiding this comment.
I think we'll need to refine this, since currently it sounds like we don't think most people should consider native interop, but we can revisit that in follow-ups as part of the docs updates.
|
@stuartmorgan-g This last commit is worth taking a look at (the threading/isolate docs mostly) 77be3d4 |
I made that commit before reading your feedback, seems like most of the things you mentioned I had already changed. I still think it's worth a glance since my isolate work is minimal. |
stuartmorgan-g
left a comment
stuartmorgan-g
left a comment
There was a problem hiding this comment.
Small nits, but LGTM
| @@ -73,7 +67,11 @@ In your Pigeon Dart definition file (`pigeons/<messages_file>.dart`), update `@C | |||
| - **`appDirectory`**: Root path of the compiled Flutter **application** context required by `ffigen` and `jnigen` (use `'example/'` for plugins with an example app, or `'./'` for standalone Flutter apps). | |||
|
|
|||
| > [!WARNING] | |||
| > **Threading & TaskQueue**: Native Interop (FFI/JNI) calls execute directly in-process and always run on the main UI thread. `@TaskQueue` annotations are not supported with Native Interop and must be removed from your Pigeon file before generating code. | |||
| > **Threading, Isolates & TaskQueue**: Native Interop calls execute directly in-process on the calling isolate's OS thread (the main UI thread when called from the root isolate). | |||
There was a problem hiding this comment.
Remove "in-process"
There was a problem hiding this comment.
this is a great example of why skills are problematic in design
| Pigeon removes the necessity to manage strings across multiple platforms and languages. | ||
| It also improves efficiency over common method channel patterns. Most importantly though, | ||
| It also improves efficiency over common platform channel patterns. Most importantly though, | ||
| it removes the need to write custom platform channel code, since pigeon generates it for you. |
There was a problem hiding this comment.
How so; isn't the whole point of the FFI backend of Pigeon that clients don't have to write their own code translating from *gen code to idiomatic Dart code?
Right now, the docs say that the "most import" thing Pigeon does is something that doesn't apply when using the FFI backend, so it's not at all clear from reading this paragraph what FFI Pigeon is offering clients over using *gen directly, which is why I think we need to broaden the language here.
|
currently blocked by #12708 |
3 participants
This PR introduces optional Native Interop to Pigeon, enabling direct communication between Dart and native code without the overhead of traditional MethodChannel serialization. It leverages FFI (Foreign Function Interface) for Swift (iOS/macOS) and JNI (Java Native Interface) for Kotlin (Android).
This represents a significant architectural shift, moving from message-based passing to direct memory sharing and function calls. It also updates the concurrency model for asynchronous methods, moving from completion handlers/callbacks to modern language features: async/await in Swift and Coroutines in Kotlin.
Generators Covered
Swift Generator: Updated to support FFI bindings and async/await for asynchronous methods.
Kotlin Generator: Updated to support JNI bindings and Kotlin Coroutines for asynchronous methods.
Dart Generator: Updated to handle the generated interop bindings on the Dart side.
What's In Scope
Tests: Added ni_tests.dart and associated generated files and integration tests to verify the feature.
What's Out of Scope
work toward flutter/flutter#182230
design doc flutter/flutter#181430