4 ms·

Flutter ships with a functional-reactive style framework, inspired by React. Flutter gives developers access to any service or API that the host operating syste

Flutter ships with a functional-reactive style framework, inspired by React. Flutter gives developers access to any service or API that the host operating system provides, via Mojo’s IPC system If I can write android apps with the SAME performance as Java, then this is effectively a replacement for me. I was seriously considering Kotlin, but with Google making a play here - this is the way I'll go.

pjmlp 11y ago
It will always be slower than Java on Android, because you need to pay the price of JNI calls to the Framework libraries.
- sandGorgon 11y ago
  they are using Mojo to call native.
  - pjmlp 11y ago
    Had to search for what it is. https://github.com/domokit/mojo https://github.com/domokit/mojo I doubt it is faster than Java ART for access to Android Frameworks. Call JNI from C++ it might have delays around 300ms or more per call.
    - badlogic 11y ago
      300ms for a JNI call? In all my years using JNI with Dalvik/ART i have never seen such a degradation. Can you give an example?
      - pjmlp 11y ago
        This is a number I had on my head from the "Using the NDK Performantly (Big Android BBQ 2015)" talk. https://www.youtube.com/watch?v=Wb5HAI73QRE&list=PLWz5rJ2EKKc_HyE1QX9heAgTPdAMqc50z&index=11 https://www.youtube.com/watch?v=Wb5HAI73QRE&list=PLWz5rJ2EKK... From some examples using buffers, maybe I am wrong.
    - mda 11y ago
      I think they update their benchmark results to https://chromeperf.appspot.com/ https://chromeperf.appspot.com/ (browse for benchmarks with mofo prefix) Looks like pretty damn fast to me.
      - pjmlp 11y ago
        This is rendering performance. I mean calling Android APIs via JNI vs calling them from Java.
- moonchrome 11y ago
  It's a custom UI framework, you will only need to use JNI to call system services which shouldn't be a bottleneck - rendering engine is written in C++ AFAIK and it then uses IPC to talk with it.
  - pjmlp 11y ago
    Skia is already used by the Android UI stack. IPC is usually slower than JNI specially on ART, because ART can optimize native calls across the boundaries better than Dalvik since the interpreter/JIT execution mix no longer happens.
    - moonchrome 11y ago
      That's assuming it is using Dart IPC -> Skia and not Dart IPC -> Higher Level GUI C++ rendering API -> Skia
    - kllrnohj 11y ago
      > Skia is already used by the Android UI stack. Android's hardware renderer does not use Skia for 2D drawing. So if your canvas returns true from canvas.isHardwareAccelerated() (and it should unless you're running on Gingerbread), it does not use Skia.
diggan 11y ago
pjmlp, according to the FAQ, the mention the performance in a section "You can expect excellent performance on both Android and iOS. Flutter is designed to help developers easily achieve a constant 60fps. Flutter apps run via natively compiled code, no interpreters are involved" But I'm no Android developer so might just be marketing fluff.

pjmlp 11y ago

It will always be slower than Java on Android, because you need to pay the price of JNI calls to the Framework libraries.

sandGorgon 11y ago
they are using Mojo to call native.
- pjmlp 11y ago
  Had to search for what it is. https://github.com/domokit/mojo https://github.com/domokit/mojo I doubt it is faster than Java ART for access to Android Frameworks. Call JNI from C++ it might have delays around 300ms or more per call.
  - badlogic 11y ago
    300ms for a JNI call? In all my years using JNI with Dalvik/ART i have never seen such a degradation. Can you give an example?
    - pjmlp 11y ago
      This is a number I had on my head from the "Using the NDK Performantly (Big Android BBQ 2015)" talk. https://www.youtube.com/watch?v=Wb5HAI73QRE&list=PLWz5rJ2EKKc_HyE1QX9heAgTPdAMqc50z&index=11 https://www.youtube.com/watch?v=Wb5HAI73QRE&list=PLWz5rJ2EKK... From some examples using buffers, maybe I am wrong.
  - mda 11y ago
    I think they update their benchmark results to https://chromeperf.appspot.com/ https://chromeperf.appspot.com/ (browse for benchmarks with mofo prefix) Looks like pretty damn fast to me.
    - pjmlp 11y ago
      This is rendering performance. I mean calling Android APIs via JNI vs calling them from Java.
moonchrome 11y ago
It's a custom UI framework, you will only need to use JNI to call system services which shouldn't be a bottleneck - rendering engine is written in C++ AFAIK and it then uses IPC to talk with it.
- pjmlp 11y ago
  Skia is already used by the Android UI stack. IPC is usually slower than JNI specially on ART, because ART can optimize native calls across the boundaries better than Dalvik since the interpreter/JIT execution mix no longer happens.
  - moonchrome 11y ago
    That's assuming it is using Dart IPC -> Skia and not Dart IPC -> Higher Level GUI C++ rendering API -> Skia
  - kllrnohj 11y ago
    > Skia is already used by the Android UI stack. Android's hardware renderer does not use Skia for 2D drawing. So if your canvas returns true from canvas.isHardwareAccelerated() (and it should unless you're running on Gingerbread), it does not use Skia.

diggan 11y ago

pjmlp, according to the FAQ, the mention the performance in a section "You can expect excellent performance on both Android and iOS. Flutter is designed to help developers easily achieve a constant 60fps. Flutter apps run via natively compiled code, no interpreters are involved" But I'm no Android developer so might just be marketing fluff.