How does Dart/Flutter get compiled to Android? - android

I can't find any concrete resources on this, does Dart get compiled to JVM, or did the Google's team compile the Dart VM to be run on the JVM and then run Dart inside Dart VM inside JVM?
The former makes more sense and it goes inline with the "no bridge" mantra, but the latter seems more inline with how integration between native & flutter code looks like

Dart is compiled to native machine code (ARM, Intel, ...) executable and bundled with some native platform code (Java, Kotlin, Objective-C/Swift) to interact with the native platform.
See also
How does Flutter run my code on Android? The engine’s C and C++ code
are compiled with Android’s NDK. The Dart code (both the SDK’s and
yours) are ahead-of-time (AOT) compiled into a native, ARM library.
That library is included in a “runner” Android project, and the whole
thing is built into an APK. When launched, the app loads the Flutter
library. Any rendering, input or event handling, and so on, are
delegated to the compiled Flutter and app code. This is similar to the
way many game engines work.
Debug mode builds use a virtual machine (VM) to run Dart code (hence
the “debug” banner they show to remind people that they’re slightly
slower) in order to enable stateful hot reload.
How does Flutter run my code on iOS? The engine’s C and C++ code are
compiled with LLVM. The Dart code (both the SDK’s and yours) are
ahead-of-time (AOT) compiled into a native, ARM library. That library
is included in a “runner” iOS project, and the whole thing is built
into an .ipa. When launched, the app loads the Flutter library. Any
rendering, input or event handling, and so on, are delegated to the
compiled Flutter and app code. This is similar to the way many game
engines work.
Debug mode builds use a virtual machine (VM) to run Dart code (hence
the “debug” banner they show to remind people that they’re slightly
slower) in order to enable stateful hot reload.
https://flutter.io/docs/resources/faq#how-does-flutter-run-my-code-on-android
See also https://proandroiddev.com/flutters-compilation-patterns-24e139d14177

Sometimes you find the answer immediately after you ask it -_- Found this reddit answer
Both!
When developing, Flutter uses the VM so you can get nice things such
hot reloading.But for production it compiles down (AOT) to a native
ARM library then uses NDK on Android and LLVM on iOS to embed on
native apps (runners).
That is why you get a debug/slow mode banner on the top-right corner,
to remember you that, you are using the VM.
Check https://flutter.io/faq/#technology
Also https://www.youtube.com/watch?v=FUxV4MIhS3g
P.S. This doesn't mean that Dart VM isn't suitable for production
environments, you can still use it on server-side or long-running
tasks, just like JVM, CRL, Node.js etc. I'm personally using it for a
HTTP API and really enjoying it.

Related

What does android folder and gradle means in Flutter?

I've been using Flutter for almost a year now, I never used Android Studio or Android application development with Java/Kotlin. Most often I get these errors related to Gradle, changing classpaths and implementation and I don't seem to understand any of that.
Any app in the Flutter is created with the help of three languages Dart, C and C++. Here you can also tell that every flutter application is a combination of these three language’s code.
The Entire Flutter framework is created in Dart and it is also used by us to develop an app. Here also notice that we do not directly use C and C++ code to write apps, instead, C and C++ code is used in Graphic rendering engine and Dart Virtual machine to perform their tasks.
Let's dig deeper on how flutter compiles for Android
Graphics Engine’s C and C++ code are compiled with the help of
Android’s NDK (Native Development Kit).
The dart code both SDK’s and ours are compiled through AOT (Ahead-of-Time) compilation process to native ARM and x86 libraries.
After successful compilation, the APK file is generated.
Any widget rendering, input-output, event handling and so on is done by compiled app code.
Here notice that Debug mode builds use a Dart virtual machine to run Dart code in order to enable stateful hot reload.
So related to the folder structure, ios contains part of iOS code and uses CocoaPods to manage dependencies. The android contains part of Android code and uses Gradle to manage dependencies. The lib contains part of Dart code and uses pub to manage dependencies. Cocoapods in iOS corresponds to Podfile and Podfile.lock while pub corresponds to pubspec.yaml and pubspec.lock.
The iOS/Android project under Flutter is still essentially a standard iOS/Android project. Flutter only generates and embeds App.framework and Flutter.framework (iOS) by adding a shell to the BuildPhase. Flutter also adds flutter.jar and vm/isolate_snapshot_data/instr (Android) through gradle to compile Flutter-related code and embed them into a native App.
If you want more depth information about the compilation process see this article https://www.alibabacloud.com/blog/an-in-depth-understanding-of-flutter-compilation-principles-and-optimizations_597747

How flutter determine written code is for android or ios?

Could anyone please explain behind the scenes of the flutter determines written code is for android or ios.
Dart is ahead-of-time (AOT) compiled into fast native X86 or ARM code for Android and iOS devices. Flutter can also call out to Android and use Android features only available in Java (same with iOS). Flutter is written in DART so we can't call that it compiles but DART does and it's rendering engine does.
Flutter Framework provides all widgets and packages whereas Flutter SDK allows you to build apps for android and IOS
The engine’s C/C++code is compiled with Android’s NDK or iOS’ LLVM. Both pieces are wrapped in a “runner” Android and iOS project, resulting in an apk or ipa file respectively. On app launch, any rendering, input, or event is delegated to the compiled Flutter engine and app code.
I thought images would be much clear instead of writing many things.
More of these:
https://docs.flutter.dev/resources/faq#run-android

Does every flutter app contain Flutter engine?

I am trying to digest the following information from Flutter site.
How does Flutter run my code on Android?
The engine’s C and C++ code are compiled with Android’s NDK. The Dart
code (both the SDK’s and yours) are ahead-of-time (AOT) compiled into
native, ARM, and x86 libraries. Those libraries are included in a
“runner” Android project, and the whole thing is built into an APK.
When launched, the app loads the Flutter library. Any rendering,
input, or event handling, and so on, is delegated to the compiled
Flutter and app code. This is similar to the way many game engines
work.
Is each Flutter app (more precisely each Android app that is created with Flutter) published with Flutter engine attached?
Yes, it is included in every app. There is no code sharing between apps on Android/iOS. Also each app could have a different version of the engine (depending on when it was compiled)
Note that the with the upcoming Flutter 1.0, the overhead (on Android) is less than 5M, which is not bad. I believe the overhead is similar on iOS.
libflutter.so is 27.1MB on my emulator for each of a full / production app and a hello world app.

How Flutter uses its own DartVM for native apps

I've read that Dart uses its own DartVM.
Thus Flutter can use JIT (for things like hot-reload) while developing your app and AOT to build the latter into a "native" app (.apk/.ipa).
According to the docs for both platforms (Android/iOS):
ahead-of-time (AOT) compiled into a native, ARM library
But how does Flutter use its own DartVM, for example, on Android, if the app already runs via Dalvik/ART? And does the VM is built into our .apk so it can be delivered to a real Android device?
If DartVM isn't used for the end-builds then what about the GC stuff? Flutter tends to create a lot of short-lived objects which is fine for DartVM's Generational GC but isn't so good for the ART's one.
The Flutter engine uses the Dart VM in two distinct modes:
Running in debug mode at development time, the flutter run command watches the host filesystem for changes to Dart source, and when it detects such changes, quickly compiles the Dart source to kernel (intermediate) format. This is then synced to the engine running on the device via hot-reload, and executed in JIT mode (Android) or interpreted mode (iOS).
Running in profile or release mode, the Dart source is first compiled to kernel intermediate form, then run through gen_snapshot, which emits AOT ARM machine code, which is then linked into the final app. You can find a detailed explanation of AOT mode operation on our wiki.
Note that there's a thin set of platform bindings for Android written in Java that interface with the engine via JNI, but the core of Flutter's engine is written in C++ and built with the NDK, as such those bits aren't relying on Dalvik/ART.

can native only code run on android as standalone application

We want to migrate a huge complex native program to Android system ,running it as a background service accepting command sent from Java Program using JNI along with IPC. However, the Android NDK state following words:
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Does that mean we have no way to run an standalone native-only application on Android as a background service? The native code can only exist in the form of library that will be loaded to the virtual machine through JNI?
The NDK itself is only for creating libraries, though if you do some web searching you will find that there are at least two sets of wrapper scripts or instructions for (ab)using its toolchain to make standalone executables linked against android's bionic libc (something you would not get from a non-android arm toolchain).
The google folks do not encourage people to do this. Unfortunately, their vision of android only includes java applications, with optional native libraries in support - it does not include any "stable" means of installing or launching a native executable, in the sense that they warn the methods you might be able to use today may not continue to work in new versions. This is really too bad, as it means giving up a lot of the general-purpose-computer potential of the device.
Well, it can be done. But to be honest i've never tried it using the NDK, but i've managed to create native applications using the toolchains provided with the android source code.
Your phone (incase your talking about phones) should be rooted.

Categories

Resources