preface
Many front-end developers have looked for cross-platform App solutions, including those who have not independently developed native apps for both iOS and Android, and have come across or seen Google’s Flutter framework. I am familiar with iOS native development and Vue.js based Web development, and have applied the Flutter framework to an ongoing Bluetooth hardware project. After a long adaptation, in this article I will look at the Flutter framework from the perspective of iOS native developers and Web developers. Briefly list the advantages and disadvantages of Flutter.
Advantages of Flutter
The advantages of Flutter are obvious. If you choose a cross-platform framework, Flutter has the best experience, performance and build mentality compared to many htML-based cross-platform frameworks.
Powerful performance, smooth
The performance of the Flutter compared to weex and React Native is obvious. Render based on dom tree native components, it is difficult to on a par with directly on the underlying view drawing performance, Google as a giant wheel, directly on the two platforms to rewrite their UIKit, to receive the underlying platform, reduce the multilayer switch UI layer, UI performance can match the native, this advantage is especially pronounced when sliding and the animation.
Excellent Routing design
The route to Flutter is very convenient. Push a route and return a Future object (i.e. Promise object). Use await or.then to receive the return value when the destination route pop returns to the current page. This reverse transfer value design is basically abandoned wechat small program street. Some operations, such as pop-up dialogs, are also used with little worry about passing values
The singleton pattern
Flutter supports singletons, which are very simple to implement. The singleton pattern solves some problems well. In contrast, a JS singleton is not a real singleton, or a simple singleton, due to the context in which JS is run. The singleton pattern is not always rational and is open to abuse. However, in the initial development of App, a singleton that is easy to implement can help us quickly complete some logical construction.
Excellent animation design
The animation of Flutter is incredibly simple. Animate objects generate many floating points per second (typically 60) depending on the screen refresh rate. Simply associate a component property with the animation object via the Tween, and Flutter ensures that the correct component is rendered in each frame to create a coherent animation. One of the magic of Flutter is that this very violent operation is not apparent on Flutter. In contrast, other cross-platform frameworks can barely animate… You tend to experience very serious performance problems.
UI cross-platform stability
Google directly rewrites UIKit in the bottom layer on the two platforms, does not rely on Css and other external interpreters, there is almost no unsatisfactory UI expression, rendering abnormal situation, can obtain very stable UI expression effect. Css behaves differently in different browsers, and it is difficult to achieve stable UI performance in cross-platform CSS-BASED frameworks.
Optional static language, excellent language features
Dart is a static language, which gives it an advantage over JS. Dart can be compiled to JS, but looks more like Java. Static languages can avoid errors, get more editor prompts, and greatly increase maintainability. Many JS libraries have been rewritten in TS, and Vue3.0 will be written entirely in TS. The advantages of static languages are self-evident.
Flutter shortcomings
Pretend to be cross-platform and can’t hide from native code
This is the biggest problem. The cross-platform framework basically means THE UI cross-platform, and finally runs on the native platform. The two platforms are completely different from each other, and it is not realistic for one set of code to eat up iOS and Android in the actual application. The ability of Flutter to interact with native code is very scientific, but the problem becomes more obvious — how am I a front-end engineer to know what a UIViewController is and what an Activity is? If I am familiar with both ends of Flutter, it is unnecessary to learn Flutter. This is a very paradoxical point, especially in a team, where only a few front-end developers suddenly want to learn Flutter will never make a big project, if there are native developers, there is no need to do Flutter.
The idea of composition rather than inheritance
Flutter advocates “combination”, not “inheritance”. In iOS development, we often inherit UIView, override one of UIView’s lifecycle functions, and add some methods and properties to create a custom View. But none of this is possible with Flutter — properties are final. If you inherit a Container, for example, you cannot modify its properties during its lifetime. You always need to nest several widgets, such as Row, Container, ListView, and so on. This approach is very counterintuitive, and it’s hard to figure out how to build a complete component when you’re first learning it.
The type of Widget is difficult to choose
Flutter widgets are divided into statefulWidgets and statelesswidgets. One is statfulwidget and the other is StatelessWidget. It was difficult to figure out which one to use when we first developed Flutter because statelessWidgets can also store values. The difference is that the framework uses State to refactor the UI. If it’s a StatelessWidget, the value temporarily stored in it is gone. But the problem is far more than this simple, fortunately, it is only a little trouble, does not affect the product performance.
Poor UI control API
While Google does its best to let us customize our widgets through constructors, there are also omissions. For example, once I wanted to change the height of an Appbar, I couldn’t find the height attribute. Reading the source code, I found that the height was const. Having said that there is no way to change component properties through the lifecycle, writing Appbar myself is unnecessary because I still want to use the convenience features of Appbar. Finally I can only copy all his source code, directly modify the height to use. Beginner frameworks, and some beginner developers, are unlikely to be able to read the source code quickly (and should not be a problem as a framework). Some custom UI Api design is often missing, but FORTUNATELY I am basically used to it. In addition to complex components such as Appbar, it is easy to write a widget yourself.
Poor resource management design
This is the stupidest one, Flutter supports dynamic loading of images at different resolutions, but the directory design is too stupid. Simply put, multi-resolution resources derived from Sketch are almost impossible to drag directly into Flutter to use, extremely, extremely, cumbersome.
conclusion
The main problem with Flutter is that it requires a thorough understanding of the native environment. Even cross-platform frameworks are like this, and it is unfair for serious native developers to try to take down the two-end development task with a cross-platform API. The main advantage is the smooth animation, which many developers report is smoother than native Android (doubtful), at least on iOS, where you can’t see the lag, and android’s animation is stable, showing Google’s hard power in terms of performance