发布时间：2019年2月18日 - 11分钟阅读
从移动应用开发的早期开始，就有一场激烈的争论，是使用原生平台技术还是跨平台技术来构建应用。Flutter为这场争论创造了一个新的维度，因为它同时具有多平台和跨平台的特点。
Flutter的承诺和开发社区的兴趣意味着值得在原生与Flutter的背景下再次列举这场辩论。
以下是我们认为在看待跨平台移动开发时的重要因素：
- 最好的原生应用体验与更容易的工具链。
- 平台专业性VS抽象成本。
- 平台专业编程语言 vs 通用语言。
- 最新的平台发展 vs 追赶。
- 多代码库和测试工作 vs 单一代码库和增量测试工作。
- 平台专用测试框架 vs 通用测试框架。
关于Flutter的一点背景
让我们先非常快速地概述一下为什么Flutter与其他跨平台的工作不同。简单来说，Flutter采用了类似于手机游戏引擎的方法，并分解为这三块
- iOS(.ipa)和Android(.apk)应用，作为运行器，但不包含编译后的应用代码本身。
- 原生运行时引擎处理低级职责，如绘制用户界面和设备和/或平台库访问的互操作设施。对于iOS来说，这个引擎是通过LLVM交付的，而Android则是通过NDK交付的。
- 应用程序代码编译成ARM库，与引擎一起创造应用程序体验。
这与跨平台的Ionic/Cordova以Web视图运行，ReactNative以JavaScript为核心，并与原生UI组件进行互操作有很大的区别。
Flutter之所以能让更多人重新关注跨平台，是因为它：
- 运行时性能非常快，解决了持续困扰基于JavaScript的解决方案（Ionic/Cordova或ReactNative）的滞后问题。 Flutter的工具链意味着可以在模拟器和设备上进行开发（就像原生开发一样）与使用Chrome开发工具进行移动应用开发（Ionic/Cordova或ReactNative）。
- 一流的IDE支持。在工具方面有大量的投资，这也是现在对谷歌的期望。
- Google在移动操作系统方面的血统让Flutter具有合法性。它是由Adam Barth等杰出的谷歌工程师构思的。
下面我们重述一下我们对原生与跨平台的看法，并在Flutter的背景下重新评估这些看法。
同类最佳的原生应用体验VS更简单的工具链
我们的观点是什么？
原生应用基于速度、平台符合性和最新功能的使用提供最佳的用户体验。跨平台产品关注的是使用来自非移动世界的编程语言和运行时，其基础是这样可以简化开发。
这在Flutter身上是怎么看的呢？
从表面上看，Flutter只是之前的变种。事实上，你可以重新利用React、Cordova或Xamarin的语句来描述Flutter *。 在这方面，Flutter并没有挑战我们当前的思维。
然而，Flutter的故事有3个方面是不同的，也是比较有趣的。
首先，它正在颠覆原生开发者对自己原生工具链的看法。
Flutter惊人的Hot Reload是原生开发者长期以来所需要的。源代码的变化会立即反映在设备/模拟器上。Flutter正引领着原生应用开发的方式。（参见Android Studio最近对即时运行的更新 bit.ly/2N6YcTo ）。
其次，Flutter正在实现原生开发者会满意的应用性能。即使是在Android One这样资源紧张的设备上，Flutter示例应用的流畅度也远超预期。 之所以能够做到这一点，是因为Flutter是按照ARM指令编译的（通过Android的NDK和iOS的LLVM）。更具创新性的是Flutter采用的独特的渲染模型，即通过widget（又称视图）层次结构的一个通道实现渲染。此外，无状态与有状态widget的概念允许布局的缓存。然而，Flutter还很年轻，在性能方面，陪审团还没有出来。
第三，Flutter使用了一种较新的现代编程语言。
我们对JavaScript这种语言有偏见。(很遗憾，我们在这里没有时间去讨论这个话题。)Flutter有趣的地方在于它使用了Dart语言，这意味着开发者得到了一种现代的、成熟的编程语言，也是非常熟悉的。(未来我们会写一篇关于Dart的文章)。
这意味着什么呢？
虽然很明显，Flutter与之前的跨平台努力相比是一个更令人信服的出发点，但它无法摆脱一些缺陷，这继续形成我们的想法，即Flutter仍然是一流的原生体验和工具链简单性之间的妥协。
Flutter的UI小部件是原生小部件的摹本。因此，它们的感觉并不总是很正确。另外，Flutter将处于不断追赶的状态，因为它必须对iOS和Android的创新和改进做出反应。例如，Flutter并没有（尚未）让你访问ARKit/iOS或ARCore/Android。
*用 "Flutter "代替其他工具的名称时，其他跨平台工具的说法似乎还算成立。
"[Flutter] R̵e̵a̵c̵t̵N̵a̵t̵i̵v̵e̵让你只用[Dart] J̵a̵v̵a̵S̵c̵r̵i̵p̵t̵. ....让你从声明式组件中组成一个丰富的移动UI"。(React Native facebook.github.io/react-nativ…)
"[Flutter]A̵p̵a̵c̵h̵e̵C̵o̵r̵d̵o̵v̵a̵是一个开源的移动开发框架。它允许你使用标准的[Dart]w̶e̶b̶技术--H̵T̵Mn_335̵5̵,̵C̵S̵S̵3̵,̵a̵d̵J̵a̵v̵a̵S̵c̵r̵i̵p̵t̵进行跨平台开发。" (Cordova bit.ly/2Br2enX)
"用一个共享的[Dart].̵N̵E̵T̵代码库来交付原生的Android、iOS和Windows应用。" (Xamarin)
平台专业知识与抽象成本
我们的观点是什么？
平台的专业性意味着对API和SDK的访问和理解是平台开发者的意图。因此，本地开发不需要任何抽象成本。所有跨平台的努力都是试图将开发者从底层平台的现实中抽象出来。开发者的代价是，跨平台工具要么是一个未知的黑盒子，要么是开发者必须同时兼顾原生平台和跨平台抽象的一些知识。
这在Flutter上是怎么看的呢？
使用Flutter开发并没有改变跨平台工具的局限性--它们提供了原生开发者可用的功能子集。如果你想超越这个子集，你需要一个互操作机制和平台专业知识。Flutter也不例外，采用了插件机制来实现与原生代码的互操作性。
然而Flutter是与众不同的。
首先，你不用特别担心底层平台，因为Flutter承担了很多平台本来要做的事情。Flutter自带引擎，包括Skia图形库，用于绘制所有UI元素。Flutter框架负责整个UI的渲染。你不需要同时了解Android和iOS视图和渲染的差异，因为你使用Flutter的widget。Flutter的小部件也让你很容易推出自己的小部件。
其次，另一个常见的抽象成本来为什么剖析跨平台应用性能。跨平台运行时（通常是性能最关注的领域）通常不直接可能用原生iOS和Android剖析工具来剖析。在这些情况下，回到Chrome开发工具是一种常见的剖析方法。
Flutter确实带来了自己的剖析工具(bit.ly/2PXMIDo)--我们对这些工具的了解还不足以形成意见，所以这可能是未来文章的主题。
这意味着什么？
Flutter并没有使用原生平台UI渲染，因此该框架并不是对底层平台进行抽象，而是提供一个替代的运行时。
然而仍然需要访问底层设备服务，和其他跨平台框架一样，这是通过插件机制完成的。抽象的成本即使比其他跨平台技术少，也是存在的。
平台专用编程语言VS通用语言
我们的观点是什么？
Swift和Kotlin（含Android扩展）是iOS和Android平台上事实上的语言。苹果和谷歌已经投入了大量的资金，以确保这些语言在编译和运行时的性能上得到优化，并在工具、文档和社区参与方面提供卓越的支持。跨平台方法的明确目标是将语言从移动开发背景之外，并创建一个环境，使它们可以在本地环境中重复使用。
Flutter的情况如何？
Flutter应用是使用Dart构建的，这是一种相对陌生的编程语言。Dart的起源可以追溯到7年前，最初的希望是让它成为JavaScript的现代替代品。这从未实现，因为Dart虚拟机从未进入Chrome。今天，Dart通常被移植到JavaScript中或编译成机器代码。Dart虚拟机仍然存在，但其关注度不如以前。
因此很容易看出，Dart与使用JavaScript或C#的跨平台表兄弟非常一致--它显然是一种来自移动开发背景之外的语言。
然而，最近发布的Dart 2.0是该语言的 "重启"，专门 "让移动和Web开发更加愉快和高效"（ bit.ly/2MLR828 ）。Dart已经发展成为一种专门为Flutter和Angular Dart服务的语言。这与JavaScript等语言形成鲜明对比，这些语言从来就不是为了移动开发而设计的。
这意味着什么？
Dart是幸运的，它的重启主要是为了服务Flutter和Angular Dart。事实上，Flutter的开发很大程度上要归功于JIT（Just-in-Time）编译的能力，即当热重载，或Ahead-of-Time（AOT）编译。这就是热重装的基础。 Dart很容易学习。它的异步编程模型以及它是一种单线程语言的事实会让JavaScript开发人员特别熟悉--它甚至共享async/await语法。 然而，另一种编程语言的前景很可能成为接受的障碍。
最新的平台发展与追赶
我们的意见是什么？
原生应用开发者总是受益于最新的平台更新和功能。跨平台方法只能对变化做出反应。根据平台变化的大小和重要性，在跨平台应用反映原生应用已经接受的内容之前，可能会有显著的延迟。
Flutter的情况如何？
再次，Flutter与其他跨平台方法一致。随着iOS和Android功能的改进，Flutter团队必须做出反应，将这些改进带到框架中。 Flutter比其他的优势之一是，谷歌可以选择让Flutter跟上Android的步伐。这并不确定，因为Flutter和Android团队有单独的路线图和优先级。然而，最近对Material Design的更新，Flutter与Android和iOS同时得到了支持。
不太令人鼓舞的是，谷歌自己的服务在支持程度上还处于相对早期阶段。举个例子，Flutter/Dart中对Firebase的支持还比iOS和Android落后不少。
这意味着什么呢？
Flutter与Google的关系意味着它可能会在其他跨平台框架上占据优势。然而，在提供最新功能方面，Flutter仍然比原生应用开发落后几步。作为证据，Flutter并没有为iOS或Android提供增强现实功能的访问。最新的iOS和Android版本中的机器学习功能也没有提供。
这仍然是跨平台开发方式的一个缺点。
多个代码库和测试工作与单一代码库和增量测试工作的对比。
我们的看法是什么？
对于原生开发来说，两次构建相同的应用是一个现实。除了额外的努力和成本之外，长期保持两个应用程序的功能均等也是一个挑战。然而，来自战壕的故事显示，跨平台代码并不能实现一刀切的承诺。
支持平台UI和交互的差异开始侵蚀单一代码库的诱惑力。特定于平台或设备的UI故障也导致越来越多的平台特定代码。用一个代码库在广泛的设备和操作系统版本上实现性能也是一个挑战。我们期待着有一天，更多的代码可以跨平台共享。我们不相信今天的跨平台方法是答案。
Flutter的情况如何？
到目前为止，看起来Flutter在不同的移动操作系统和设备上始终运行良好，这主要得益于它的UI渲染方法。在这方面，Flutter似乎提供了单一代码库的优势。
然而，无法避免的是，需要在Flutter代码中加入操作系统的特殊考虑。例如应用正确的iOS或Android外观和感觉，或者在UI中使用iOS与Android小部件。
这意味着什么？
与其他跨平台方法一样，Flutter意味着iOS和Android的单一代码库。这确实意味着代码仍然要照顾到所支持平台上UI呈现的差异。 虽然Flutter很新，但并没有很多最佳实践和既定模式来管理这种代码中的差异。它落在开发者身上，以一种可维护的方式干净地管理这些差异。在某些情况下，不可避免地会导致一堆意大利面条。然而随着Flutter足迹的增加，好的实践将会出现。
特定平台的测试框架与一般测试框架的比较
我们的意见是什么？
测试移动应用有一些独特的挑战。单元测试孤立运行，工具化测试需要访问平台服务或库。集成测试需要在无头模式或设备上运行。原生开发者可以使用测试框架来正面解决这些挑战。跨平台开发者必须使用非移动测试框架或通过appium或类似的东西进行一般的黑盒测试。
这在Flutter上是怎么看的？
测试Flutter应用并没有使用原生测试框架。而是使用Dart单元测试机制和Flutter特定的单元测试包进行测试。这些包支持测试Widget（即UI视图）和黑盒集成测试。Widget测试是在应用程序的上下文之外运行，而集成测试必须在设备上或模拟器中运行。
这意味着什么？
在测试方面，谷歌的支持变得很明显。Flutter超越了其他跨平台框架所提供的功能，并将测试支持作为Flutter的重点。
在其他跨平台项目中，测试并不是一个核心话题。在React Native文档中，并没有任何关于测试的具体指导。Ionic有一篇博客文章来涵盖这个话题，但没有更多的内容。他们似乎把它留给了JavaScript测试框架，比如Mocha或Jasmine。Xamarin似乎有一些测试支持，但我一直在文档中找到死链接--比如到 bit.ly/2wQO5f6 。
这让Flutter又处于原生能力和跨平台现实的中间位置。像Flutter的其他方面一样，该框架从一定程度的自我控制中获利。
TL;DR
在Snapp，我们对我们的立场感到满意，即与原生开发相比，跨平台方法代表了一系列的妥协和缺点。我们长期以来一直认为，跨平台倡导者提出的 "银弹 "说法在现实中并不存在。最近AirBnB等公司对跨平台方法的偏离就是很好的例子。 Flutter是谷歌的一项有趣举措，其野心远超移动设备。与所有新技术一样，随着时间的推移，Flutter在现实世界中的优势、劣势和现实情况还需要一些时间来观察。 我们将饶有兴趣地关注Flutter。
通过www.DeepL.com/Translator（免费版）翻译
