具体内容稍后整理后更新...
更新中ing
git
Flutter1.17正式发布github
此版本的主要重点是在性能和内存改进方面继续进行整体工做。只需将您的应用程序升级到此版本,您的用户就会看到更快的动画,更小的应用程序和更低的内存利用率。在此版本中,默认导航状况(不透明的不透明路线)的速度将提升20%-37%。对于简单的iOS动画,您还将看到最多减小40%的CPU / GPU使用率,具体取决于硬件(在PR 14104和PR 13976中进行了详细介绍)。web
此版本还提供了一个至关大的应用程序大小的改善是因为几个 补丁 是 添加 了一个大的结果。例如,Android的FlutterGallery示例在2019年末为9.6MB,如今为8.1MB,减小了18.5%。express
对于内存使用,此版本将快速滚动浏览大图像减小了70%的内存,这也可能致使性能提升,具体取决于设备的内存量。app
苹果公司在iOS上对Metal的支持几乎能够直接访问底层GPU,而且是苹果公司推荐的图形API。在彻底支持Metal的iOS设备上,Flutter如今默认状况下使用它,这使您的Flutter应用程序大多数时候运行得更快,平均将渲染速度提升了约50%(取决于您的工做量)。less
对于不彻底支持Metal的设备(A7处理器以前的版本或运行10以前的iOS版本的设备),Flutter会像过去同样使用OpenGL,从而为较旧的设备提供本地渲染速度。ide
在此版本中,咱们添加NavigationRail了一个新的小部件,该小部件提供了响应式应用程序导航模型。它是由Google Material Design团队设计和实施的。该NavigationRail是伟大的,可由于它是很容易在一个交换的移动和台式机外形之间切换应用程序BottomNavigator为您的应用程序的屏幕尺寸的增大。工具
在此版本中,Flutter团队完成了2018 Material Design规范的Type Scale部分的实现,同时没有破坏现有的Flutter应用程序。2018年10月的PR 22330中增长了对新配置的选择加入支持,但不对新名称提供支持。现有的文本样式名称未更改,由于这样作是一个重大的API更改,可能会影响大多数应用程序。此版本更新了TextThemeAPI以匹配当前的Material规范,但保留了旧名称,以使您的代码不会中断。可是,旧名称已被弃用,所以您将收到警告,以鼓励您采用新名称.性能
文字和字体齐头并进,所以,若是您对新的Material Text Scale实现感到兴奋,那么您可能也会对新的Flutter v1.0版Google字体感到兴奋。测试
Google字体容许开发人员在其应用中轻松地尝试和使用fonts.google.com中的任何字体。当应用程序准备发布时,开发人员将决定用户是否经过从API下载字体来接收字体,或者它与应用程序包预先捆绑在一块儿。
在此发行版中,咱们已完成了所有工做,包括滚动,文本 字段和其余输入小部件的可访问性修复程序。您将在GitHub的该版本中看到有关可访问性问题的完整列表。咱们鼓励您测试本身的应用程序的可访问性,而且还经过一些推荐的最佳实践更新了此版本中的文档。
此版本使咱们很是接近将Dart DevTools的当前版本换成新的Flutter版本。若是您想尝试一下,请启动DevTools并单击DevTools右上角的“烧杯”图标。
Devtools还有其它不少有趣的更新等待你的发掘。
The Flutter Engine will migrate to using the Metal Rendering API instead of OpenGL on iOS.
A Flutter user interface is displayed on screen by accessing the GPU on the platform using an accelerated graphics API. This API has been some version of OpenGL ES on iOS. OpenGL ES and associated APIs were formally deprecated by Apple in 2018 with the introduction of iOS 12. Metal is now the recommended API for low-level, low-overhead rendering on iOS and Mac. While the cross platform aspects of OpenGL were certainly useful, the Flutter team agrees with the case for Metal. The deprecation of OpenGL ES also appears to have resulted in a less well maintained OpenGL driver on iOS. There is an uptick in iOS specific OpenGL issues that are increasingly harder to debug and unlikely to be fixed. For these reasons, a migration to Metal on iOS is imperative.
Metal will be used on Apple A7 devices or later running iOS 10 or above. When Metal cannot be used, OpenGL will be used instead.
Flutter currently supports running on iOS 8 and above. This includes devices on which Metal itself is not available. Specifically, Metal is only available on iOS devices with Apple A7 or later. This would exclude devices like the iPhone 5C that can be updated to iOS 10 but only have an Apple A6 SOC. A policy that mandates the use of Metal everywhere would mean we would have to leave some devices behind. That is not something we are prepared to consider now.
That still leaves a small number of devices that support iOS versions between 8 and 10 that have an Apple A7 SOC (or later) but have not updated to the latest iOS versions. Flutter could technically use Metal on these devices as well but currently doesn’t. This is because versions of the Metal API on earlier versions of iOS weren’t expressive enough for the features needed by Flutter (specifically the Skia rendering library used by Flutter). This requires authoring workarounds or fallbacks for cases like dual-source blending. To reduce the implementation and testing burden it was decided to pick iOS 10 as the baseline instead. This decision can be revised if necessary.
Does this change the minimum version of iOS supported by Flutter? No. Flutter will use Metal on newer devices and iOS versions but the OpenGL backend remains as-is and present. It will be used when Metal is unavailable.
Except for the highly unlikely case that your application makes assumptions about Flutter using OpenGL under the hood, no. The updated Flutter Engine requires no changes to the Flutter application or how it is embedded.
Yes. The size of the uncompressed Flutter Engine binary will increase by ~250KB. Incremental reductions to this size will continue to be made but a significant reduction requires the removal of the OpenGL backend. This is not something we have considered yet.
Yes. There are no updates necessary to these plugins and they will continue to work as expected. All plugins in the Flutter Plugins repo have also been tested to work with the Metal backend.
The rendering API used by Flutter is an implementation detail of the Flutter Engine. However, Flutter does provide the ability for the underlying platform to provide textures for inline composition within a Flutter hierarchy. Developers (or plugins) do this by using a Texture widget in their applications and writing some platform specific code to provide and update these textures. If the platform specific code that operates on the textures provided to the Flutter Engine does not specify that the texture may interoperate with the Metal API, inline composition of these textures may fail. For guidance on ensuring your textures are interoperable with Metal, please follow the documentation on how to “Create an Interoperable Texture”. Specifically, the kCVPixelBufferMetalCompatibilityKey must be specified in addition to the kCVPixelBufferOpenGLCompatibilityKey key when creating the pixel buffer describing the texture is given to Flutter.
If you application does not use the Texture widget, there is nothing to do. If it does, the texture provided to Flutter must be checked to see that they are interoperable with Metal.
This is a very unique use case and no plugins in the Flutter Plugins repo use this mechanism.
Yes. As mentioned earlier, as long as the textures provided to Flutter are interoperable with Metal, you may continue to use OpenGL to update the texture and Flutter will composite the same using Metal.
The FlutterViewControllers view will have a class that is a CAMetalLayer. Flutter will always use either Metal or OpenGL. That is, in a process, there is no chance of some Flutter application instances using Metal and others OpenGL.
No. Not currently. Flutter will continue to use the software backend on iOS simulators as before. Flutter on simulators is something on the radar though.