flutter
Flutter is Google’s approach to application development for the Fuchsia operating system.
To be compatible with cheap IoT devices, Fuchsia OS requires lower hardware consumption, and in order to avoid litigation with Oracle’s Java, Fuchsia uses Dart language + Flutter interface library.
Comparison and analysis
Performance analysis and writing contrast
As an interface library, the only thing Flutter does is render the interface. Unlike HTML5, the Flutter interface library doesn’t even have video, location, etc. It’s a pure typesetting engine that draws text, buttons, images, and other common interface controls. This typesetting engine is characterized by simplicity and high performance.
Improving performance comes at a price, and you can’t have both ease of development and performance.
Here’s an example of how to implement the same interface with HTML and Flutter:
<div class="greybox">
<div class=redbox>
smaple text
</div>
</div>
.greybox {
display: flex;
align-items: center;
justify-content: center;
background-color: #e0e0e0; /* grey 300 */
width: 320px;
height: 240px;
font: 18px
}
.redbox {
background-color: #ef5350; /* red 400 */
padding: 16px;
color: #ffffff
}var container = new Container( // grey box child: new Center( child: new Container( // red box child: New Text("smaple Text ", style: new TextStyle(color: Colors. White, fontSize: 18.0,),), decoration: decoration: Color: color; color: color; color: color; color: color; color: color; color: color; color: color; 240.0 color: Colors. Grey [300],);As can be seen, from the perspective of code writing, Flutter does not have the words of tag and style, let alone selector. It only has Dart language from beginning to end. Its interface controls are created with the Dart code new, and the style of each control is the JSSON writing parameter set in the new.
Flutter’s performance is high. In addition to its simplicity and strictness, another characteristic is that the logic layer and the view layer are unified and run under the same set of DART virtual machines.
We know that RN and WEEX, which are also native rendered, have better performance than WebView. But how could the same native render be slower than the Flutter? It’s not that native rendering is slow, it’s that JS and native communication are slow.
RN and weex are using an independent JS engine (iOS is JScore, Android is V8, the latest version of RN began to make their own JS engine Hermes on Android), from JS and Dart comparison, the performance is slightly inferior. But this is not a major problem, because the V8 JIT is not covered and is compiled to be parsed by native code. The main performance issues are: RN, WEEX’s JS engine, and the native rendering layer are two running environments.
When the JS engine networked to obtain data, notify the native view layer to update the interface, there is a cross-environment communication breakdown. Similarly, this communication breakdown occurs when a user sends notifications to the JS engine when working with the native view layer on the screen.
However, in most scenarios, the user will not feel this performance difference. The scene affected by Flutter is the hand-drawn frame animation of JS response operations, or the JS continuous operation of interface elements, which is less broken.
This communication breakdown is a common problem in all frameworks that separate logic and view, including many small programs.
Back to Flutter, it has only one Dart engine and has no performance issues associated with back and forth communication. However, everything has its pros and cons. Flutter is efficient at drawing ordinary interfaces, but when it comes to native interfaces, it will encounter more problems.
As mentioned above, Flutter is just a basic typesetting engine and lacks many capabilities. When we need to embed a native extension control for video playback in the Flutter interface (Flutter does not have built-in video playback capabilities), or the native AutoNavi SDK, then when we drag the video progress, drag the map, Flutter also generates communication between native and dart, causing performance depletion.
In fact, since the Flutter is drawn in a Canvas like environment, it is not easy to embed a native control between some elements of the Flutter layout, and there are many problems.
To be fair, the performance of RN/WEEX call native rendering is not significantly different from that of Flutter in terms of user experience, or even in many scenarios, from that of WebView rendering applets.
Also briefly about WebView rendering applet, why the performance is high, the core is preload. Click on a new page, WebView is created in advance, will not go complex WebKit, V8 initialization process, even the developer’s JS code, is also preloaded. So when you click on a new page, it renders just as fast as a native app. Of course, there is also a disadvantage, is a slow start. WeChat starts the small program speed looks OK, in fact, WeChat before the start of the small program, has already initialized the small program running environment in advance.
UI library
Either RN or Flutter has a design that is very un-Chinese. They use two sets of UI libraries on iOS and Android.
“Cross-platform” typographic engines like RN and Flutter, whose cross-platform nature has been compromised for Chinese developers.
In fact, similar to the small program UI style, is able to good across iOS and Android experience, no matter what mobile phone, open the small program will not feel a problem.
The uni-app defaults to this generic UI style. The developers of Uni-App only need to write a set of UI, which can be adapted to the users of different mobile phones, true write once, run anywhere.
dynamic
WebView, RN/WEEX, all have a feature, can be remote dynamic load JS code, can update the local JS code. Front-end developers take dynamics for granted, but Flutter doesn’t support it.
Flutter has the concept of compilation optimization, and if it provides dynamic support, it will affect its performance.
Except for Flutter, RN /weex/uni-app can be dynamically hot updated.
The difference between a cross-platform typesetting engine and a cross-platform application development engine
A page that is cross-platform and an app that is cross-platform are two very different things.
WebView, RN /weex, Flutter are all rendering engines. WebView has added some capabilities such as location services, multimedia, etc due to the development of HTML5. While RN /weex, Flutter is really just a pure typesetting engine without any native capabilities.
What is a cross-platform application development engine? Not only should typography be cross-platform, but development APIs should also be cross-platform.
Application development cannot be separated from the ability call of OS or three-party SDK. If it is a simple typesetting engine, once the OS ability and SDK call is involved, it must be coordinated by engineers of iOS and Android to write different native codes and integrate them together. It’s not cross-platform.
Uni-App is not designed as a cross-platform publishing engine, but as a cross-platform application development engine.
Therefore, in the layout part of UNI-APP, you can choose small programs to enhance the WebView engine and weex engine, and you can switch between them according to your own needs. At the capability level, Uni-App provides HtmlPlus API, native.js and plug-in market, which solves the problem of JS of Native capabilities.
Uni-apps allow developers to build complete cross-platform apps without really knowing anything about native development. For extremely individual needs, developers can also go to the plug-in market to find someone to customize a native plug-in. They still use JS to integrate, and they can still directly package in the cloud.
Cost of learning, difficulty
RN, requires developers to learn React, requires mastery of Flex layouts, and requires native development collaboration.
Flutter, for example, requires developers to learn Dart, understand Dart and Flutter’s APIs, be proficient in Flex layouts, and require native development collaboration.
Weex is already embedded in uni-app, so we won’t mention it separately.
Uni-App requires developers to learn Vue and understand applets.
ecological
Any development engine cannot be separated from ecology.
For foreign developers, RN and Flutter certainly have a better ecosystem than uni-apps, such as Facebook login sharing, Google Maps, etc.
But for domestic developers, it’s the other way around. All the full-end push (Unipush integrates iOS, Huawei, Xiaomi, Oppo and many other original push manufacturers), various domestic login, payment, sharing SDK, various domestic maps, various UI libraries, and Echart charts that Chinese developers need are all in the Uni-App system. In this respect, the ecology is much richer than that of RN and Flutter. The Uni-App plug-in market, with thousands of plugins, is not exhaustive, but it is the richest ecosystem of cross-end development frameworks.
In addition, the ecology of UNI-APP is better than other competing products in the following aspects:
- Apps and H5 provide RenderJS technology, which allows browser-specific libraries to be used in apps and H5, such as Echart, Threejs, etc
- It is compatible with WeChat applet JS SDK, and the rich applet ecosystem content can be directly introduced into UNI-APP, and is generally used in APP side
- Compatible with WeChat small program custom components, and APP, H5 side general
conclusion
Comparison between Flutter and Uni-app:
Relative advantages of Flutter versus Uni-App:
- The performance is good. Compared with RN, WEEX/UNI-APP with BindingX and WXS has advantages, but there is no obvious gap in practical development.
Relative Disadvantages of Flutter vs. Uni-App:
- Native collaboration is required and three sets of codes are maintained, which cannot effectively reduce development costs and improve development efficiency
- Nesting hell, the code is hard to maintain
- Hot updates are not supported
- The current quality and maturity is very low
- Poor integration of native visual controls, such as WebView, Video, and Map
- The UI library is not suitable for the country
- High cost of learning
- With limited application scenarios, Dart’s future is uncertain
The flutter can also be used in the uni-app. The author of the plugin provides a plugin to open the flutter on certain pages of the uni-app
Comparison of RN and UNI-APP
Relative advantages of RN and UNI-APP:
- Although RN has fewer pits than weex, uni-app has filled many pits in weex. There is not much difference.
- The ecology of RN is richer than that of Weex. However, the reverse is true for Uni-app. The richness of domestic application ecology of Uni-app exceeds that of RN.
- RN is pure single page, and it is flexible to embed native apps. The uni-app is the whole concept of the app. If you want to embed other native apps, you need to embed the whole uni-app in the native app. That is, to integrate the UNI applet SDK.
Relative disadvantages of RN and UNI-APP:
- Native collaboration is required and three sets of codes are maintained, which cannot effectively reduce development costs and improve development efficiency
- Small programs are not supported and can not be published directly to H5
- Not as good as uni-app
- The plug-in ecosystem in China is not as rich as Uni-App
- UI library is not suitable for national conditions, learn once, write anywhere
- High learning cost and high employment cost are not conducive to developers to reduce development costs
- RN is a pure single-page application. If an application has many pages, it will crash to write in RN, and the variable pollution and interference are serious. While weex/uni-app supports multiple pages, with context isolation between pages, which is more suitable for large applications with more writing pages
- In addition, React has far less market share in China than Vue. This is also the different characteristics of China and foreign countries.
The original address: https://ask.dcloud.net.cn/art…