出品| CSDN（ID：CSDNnews）
以下为译文：
直到今年，我们公司的主要应用程序 Easy Diet Diary 还只有 iOS 原生版本。 这是美国的一款通用减肥追踪应用程序，有一个专门用于研究和那些不幸患有肝炎的人的版本。 申请的总体状况如下：
后来Flutter出来了（2018年4月2日出Beta版）。 只有Flutter能够为我们提供足够的功能：跨平台、性能好、实现快速、原生体验、开源。 我们只需要构建一个版本的 Flutter 即可同时服务 iOS 和 Android。
六个月后，我在没有使用本机代码的情况下发布了 Google Open Beta。
本文基于公开测试版：
本文的主要内容包括：
代码行数和开发速度
在导出代码的时候，我真切地感受到了声明式编程是多么的高效，以及不受基于XML的storyboard的限制，能够复用接口代码是多么的方便。 好吧，随着 Jetpack Compose 和 SwiftUI 的引入，这似乎已经变得司空见惯了。
我最终得到了 35,000 行 Dart 代码。 此外，还有 3000 行 Objective-C/Swift 代码负责处理 HealthKit 等 iOS 特定逻辑，以及 500 行 Java 图像处理代码。
导入完成后，Flutter应用程序的代码行数仅为原生iOS应用程序的一半。
谷歌公开测试版
我花了很多时间通过 Apple 的 TestFlight 流程来操作应用程序，结果发现将不断增长的应用程序交到广大受众手中是多么困难。 而且我不认为这些情况会在短期内得到改善，因为苹果认为其初步审查流程是确保应用程序符合某些标准的一种方式，而且他们并没有恶意欺骗。 对于一个能力强、热情高的开发者来说，这似乎是一个沉重的打击。
相比之下，用户可以像其他应用程序一样使用Google Open Beta流程在App Store中搜索测试版应用程序，并且还可以无缝加入测试版计划，使用此应用程序并提供（有限的）反馈。 如果您对 Open Beta 版本感到满意，可以升级到即将发布的版本。 如果应用程序使用得当，用户会很快接受并提供建设性的反馈。 至少这是我个人的经验——这是一个很好的开发方法。
随着我添加功能和修复错误，Easy Diet Diary 积累了 10,000 个测试版用户。 所以，我在三月份发布了1.0 Android版本。
建筑学
当我去年开始时，我不熟悉声明式 UI 编程以及随之而来的状态管理。 对我来说，依赖异步流的 Redux 和 BLoC 的学习曲线很陡峭，最终我在 InheritedWidgets 的帮助下实现了 widget 树中的状态同步。 我寻找将业务逻辑与表示逻辑分离的方法，但没有使用状态管理框架来强制分离。
从那时起，人们对状态管理的兴趣越来越浓厚，讨论也越来越热烈。 将 Flutter 中状态管理的开源演变与 SwiftUI 的响应式编程框架（该框架正在由一个更大的团队秘密开发，非常史蒂夫·乔布斯风格）进行对比是很有趣的。 Matt Gallagher 对 Apple 的合并框架进行了一些有趣的剖析。
在 2019 年的 Google I/O 大会上，为了缓解开发者对于状态管理的焦虑（我想这也是部分原因），抑制越来越多的 InheritedWidget 封装库的出现，Flutter 团队推广了 Remi Provider 开发的 widget Rousselet，请点击此处查看详细说明（www.didierboelens.com/2019/07/provider---points-of-interest---points-to-care-about/）。 提供者给了我很大的帮助。 但我从未使用过更新的状态管理方法，例如 BLoC 或 MobX（两者都可以与 Provider 一起使用），因为它需要大量代码更改。
读完 Didier Boelens 的博客后，我对状态管理的理解加速了。 虽然他是 BLoC 的粉丝，但他善于客观地解释该技术。
后端服务（亚马逊AWS）
除了 Crashlytics 和 ML Kit 之外，Easy Diet Diary 的所有云服务都位于 Amazon AWS 上。
不幸的是，截至目前，我们还没有适用于 AWS 的官方 Flutter SDK，而且与 AWS 相关的插件也很少。
对我来说，这不是一个大问题，因为在我们的中国联通应用程序和所有AWS服务之间，我们仍然有自己的服务器......除了S3（云文件存储）。 我们的服务器负责验证和同步 DynamoDB 中存储的用户日志。
iOS原生应用程序可以绕过我们的服务器，通过AWS S3 SDK直接上传和下载合影照片。 如果我想切换到 Flutter，我只能使用预签名的 S3 URL（由 AWS 通过我们的服务器提供）。 这个方法的效果是相当不错的。
虽然我认为迁移到 Flutter 不会太痛苦，但我认为如果 Flutter 有 AWS SDK 插件（不一定是即将推出的插件），它会更受欢迎。 如果说云服务商的收入能够大致代表中国联通应用对云服务的使用情况，那么AWS就是目前的市场领导者。
我希望也能够通过 Dart 尝试大量的 AWS 服务。 我确信 Azure 也是如此，尽管我不使用 Azure。
表现
我在 Easy Diet Diary 上测试 Flutter 的方式是在屏幕中间显示一个可连接的 DSLR 层，或者在读取数百个约 20KB 的 JSON 文件后显示一个图表。
当将应用程序的 iOS 原生版本与 Flutter 版本进行比较时，我们的测试人员（实际上我们只有一名主要测试人员）没有发现手机上有明显的性能下降，除了 iPhone 6（该应用程序在 6S 上运行良好）。 iPhone 6 于 2014 年发布，但仍然有售，我十几岁的母亲也有一台。 当我们在其他手机上进行测试时，我们发现了一些速度较慢的设备，包括三星 Galaxy J5 Pro 和诺基亚 G5S Plus（移植时我的手机）。
一开始iPhone 6有点卡，有一些晃动，尤其是联通单反的层层。 不过，随着几个月后 Flutter 新版本的发布，这种现象逐渐减缓（但并没有完全消失）。 该应用程序在其他速度较慢的测试手机上运行良好。
题外话：我现在的个人手机是 Pixel 3a，一款运行 Android 10 的中端手机。它运行轻松饮食日记很流畅，具有 Android 的开放性和灵活性，同时比我见过的任何其他 Android 手机更接近 iPhone 的体验用过的。 这款手机很符合我继续开发跨平台概念的愿望，它只是需要更灵活的应用。
本机代码
在移植过程中，我仍然试图避免使用原生代码。
然而，在图像处理、HealthKit 集成和升级老用户方面我却有所欠缺。
对于 HealthKit 和升级旧版用户功能，我仅依赖本机 iOS Swift 和 Objective C 代码。
对于图像处理，我编写了第一个 Java 代码，允许用户在各种情况下拍照。 在现代手机上拍摄的百万像素照片会占用大量空间，因此我在显示或上传它们之前对其进行了裁剪、缩放和压缩，所有这些都需要本机 iOS 和 Android 代码。 我找不到合适的插件（尤其是正确保存 EXIF 元数据的插件），因此我使用开源插件、StackOverflow 答案和旧的 Objective-C 代码构建了自己的解决方案。
按照这条指令写插件包就很方便了（）。 应用启动并运行后，可以通过配置、设置断点等方式启动原生代码，当然不支持热重载。
我希望将这个处理放在一个隔离的区域，这样他们就可以自由地花时间处理和上传图像。 然而没想到无法从隔离区调用插件代码，只好在原生插件中创建线程。
跨平台设计
您可以使用 Flutter 来控制应用程序的本机状态。 由于我想为现有用户编写原生 iOS 应用程序的替代品，因此我希望这个 Flutter 应用程序非常接近原始版本。
首先，我构建了一个 Material Design 应用程序。 为了让自己沉浸在这个过程中，我把 iPhone 换成了中档 Android 设备——摩托罗拉 G5S Plus——我不想要任何太花哨的东西。
然后，通过Open Beta流程完善了应用程序的管理后，我准备制作iOS版本。 如果是明天，我绝对不会这样做。 刚开始的时候，我选择了一些iOS风格的小部件。 然后，它逐渐扩展，现在可以创建兼具 Material Design 和 iOS 风格的应用程序手游引擎完整源码在哪找，并且还可以根据需要替换 widget 树中的 widget。
我不会在本文中详细介绍构建跨平台应用程序的过程。 简而言之：
完成这项工作后，我发现了这个文档：Platform-Specific Behaviours and Changes()。 我希望我能首先看到这份文件！
风格和方案
Flutter旨在通过相同的代码重构可以在多个平台上运行的应用程序，但是如何通过相同的代码重构一个平台上的多个应用程序呢？
对我来说，我花在这上面的时间比我预期的要多得多。 但最终我也吸取了很多教训。
看起来很简单。 Flutter 有一个命令行开关（可以通过 IDE 设置），允许您将构建样式指定为 Gradle 产品样式或 Xcode 方案。
flutter build --flavor research
我希望复制本机 Xcode 项目中的设置。 在 Xcode 中，您可以使用方案名称来识别应用程序的版本。 方案易于使用。 创建时，您只需告诉 Xcode 您要使用的配置和目标：
在本机 iOS 应用程序中，不同版本的应用程序有不同的目标。 大多数人都使用这些方法。 然而，如果你想让Flutter使用不同的目标，那么你就得下功夫了（换句话说，Flutter的多目标几乎可以工作了）。
最后我得出了与 Salvatore Giordano 相同的推理，我使用单一目标并完全依赖配置。 后来读到Matt Thompson写的这篇好文章（.com/xcconfig/），我就释然了。 根据 Mattt 的说法，单目标配置文件可以提供以下好处：
此外，无法在 iOS 中使用不同的目标让我理解了为什么 iOS 应用程序会因版本而异，也让我体会到配置 Android 产品样式的简单性。
总结
如何构建 Flutter 应用程序：
所有这些优点都很棒。
Flutter需要改进的地方（根据我的经验）：
一些想法：
后记
无论 SwiftUI 或 Jetpack Compose 多么迷人手游引擎完整源码在哪找，大多数公司趋之若鹜的始终是优秀的跨平台连接解决方案。 至少，我的经验是这么告诉我的。 另外，在构建了替代更大的iOS原生应用的能力之后，我个人觉得Flutter值得考虑。
欢迎您在下方留言。
原文：.com/flutter-community/finished-porting-a-75-000-line-native-ios-app-to-flutter-b5c0bff93715
作者：Gary Hunter，iOS 原生和 Flutter 开发者。
