Flutter Porting Guide: Everywhere

Slide Note
Embed
Share

Flutter is a portable UI framework with a C/C++ backend and Dart frontend. This guide covers the basics, checking out the engine, compiling, cross-compiling, and an example for WebOS (linux, armv7). Learn how to port Flutter to various platforms efficiently.


Uploaded on Oct 05, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Porting Flutter As a Guide Everywhere

  2. Basics Flutter is a portable ui framework. - - - - - - - - It has C/C++ Backend and Dart as a Frontend It depends on a very limited set of system dependencies (m rt pthread dl) libc included! It needs a runner in Native land to operate, can be anything (Even in GO/RUST). It has a somewhat stable ABI (Application Binary Interface) for embedding It has a multitude of compile targets by default (linux, mac, ios, android, windows) It support the most common architectures (arm, x86-x64, mips etc) It is encapsulated, and supports Hot reload for all platforms! (Just use the observatory) It does not provide you anything more for the target platforms then needed.

  3. Checking out In order to port Flutter, we need to check out the latest stable engine (or non-stable ofc) - The flutter tool depends on the engine (revision has can be found in the engine.version file) It assumes by default a peer directory is engine (eg: engine folder is next to flutter) It requires depot tools to check out. - - See flutter/engine-s repository for more info on checking it out!

  4. Compiling - - - - - - - - Toolchain is needed (for host and target, host is the BUILD machine in this case) Clang preferred, GCC can be used too but requires more configuration Build a host debug first, as the Dart assets (for the engine) will use that to compile Build the targets afterwards (more on next slide) Use the artifact build in out/target_type for a custom Runner/Shell/Embedder Use the artifact builds to build flutter bundles (sh: flutter build bundle) set in pubspec Run the custom Embedder (make sure it loads to correct Dart assets (eg: debug) Profit!

  5. Cross-compile - - - - We need a toolchain capable of compiling for the target Sysroot/buildroot (for linux that is, /usr /lib /opt etc.) Preferred a toolchain with clang and clang++ and a binutils (linker, assembler) up to date Repeat the Compile steps with additional flags: - ./gn --target-sysroot=/path/to/sysroot --target-triple=your-target-triple --target- toolchain=/path/to/toolchain ...otherflags Use these artifacts for the Runner/Shell/Embedder Profit! :) - -

  6. Example: WebOS (linux, armv7) - - - - - We know that an older LG Device will run on armv7, with glibc. Target triple is therefore: arm-linux-gnueabi We don t have an NDK so, build llvm/clang from source, don t forget Binutils! Use the built clang and binutils as a toolchain Use ssh (or package and install) and copy the device dirs (/usr, /lib /opt), make sure to fix symlinks! Get the missing headers (the device has SDL2 on it, so we will checkout that repo and include it just for the headers) otherwise make sure to compile the dependencies. Repeat the Cross-compile steps with this toolchain and sysroot. Use the artifacts and Profit! :) - - -

  7. Ex: Tizen (nacl, .net, wasm) - - - Tizen has more options to run C then WebOS We could use samsung s pepper sdk (update clang if fails) to simply pass it to the engine We could use dotnet and load native .so and PInvoke them, requires samsung s steps to do so. In the end you will have an armv7is libflutter_engine.so to invoke. We could use flutters web target and load it with wasm support, atm Samsung is working on the documentation for this. Summary: Use pepper sdk to build nacl version or use a bare kernel and clang just like on webos, for wasm the default web target with flutter should do. Profit! :) Try again with the .NET sdk - - - -

  8. Extra (RPI4 Cortex-A72 (ARM v8) 64-bit ) - The steps are same as for WebOS, but you can probably download a cross gcc/clang for armv8 Basically almost all linux environments use the same steps with different configurations The sysroot can be downloaded (tar.gz and mount) or rsync for the real device. Use and profit :) - - -

  9. Runner/Shell/Embedder Flutter has a C ABI to help custom embedders. - - - It requires to the native app (it could be C, or GO (ex: go-flutter) or whatever you pick. It requires the native app to handle input, normalize and pass it to the engine. It requires the native app to pass a configuration so the engine could work. - UI/Render: makeCurrent, clearCurrent, present, fbo (if needed), procResolver (GL) - Thread/Events: task runner (or let the engine to create and manage it for you) - IO: Pass the asset paths to load the app (flutter build bundle, icudtl from the built artifacts) - Extra cli arguments (for custom observatory port etc) - Plugins (for loading plugins on native side) It can used with other libs to work (eg: Wayland can be used with egl to have input and output) or SDL2/GLFW for a simpler API. -

  10. Performance: - By default the engine tries to keep a 60-ish FPS (still you should care about the display Hz) It will have 16ms windows to calculate and update, on a lower end device that s not always possible. It might struggle with merged Threads (main, render) and block certain updates to happen, it s up to you to handle this correctly! Input io should not block! On a 2015 Webos device with a debug build, 30-40 FPS (same on rpi1) is the mainline, with reduced clutter it can be improved. Memory footprint on idle is 1-4 mb which is awesome, on load it can spike up to 60mb - Keep your images tights (size, density, headers etc) - Don t overuse animations or anything that requires more time to calc (eg: shadows) - - - - -

  11. Questions! - Is it production ready? - NO and YES! It really depends on the custom code you write! Support for custom embedders don t have priority, but they accept PR-s! Is it approved by any vendors? - (Samsung, LG) For LG you need a NDA signed, Samsung is ok with it just make sure you pass the tests. Others might differ, but you can try to do the same with a Tesla :) -

Related


More Related Content