[Mobile翻译]MobileAtScale-第四章节-语言和跨平台方法

Sunbreak
316 阅读33分钟

第四部分：语言和跨平台方法。

构建移动应用程序的工具不断变化。新的语言、框架和方法不断出现，它们都承诺要解决移动工程的痛点。

但你应该选择哪种方法？你应该使用Objective C还是Swift来构建iOS应用？用Java或Kotlin开发Android？或者你应该投资于一种跨平台的方法，承诺 "一次编写，到处运行"，如Flutter、React Native、Cordova？或者退而求其次，重新使用用Kotlin、C#、C++或其他语言编写的业务逻辑？

在本节中，我们将介绍在构建移动应用时，关于语言、框架和跨平台方法的最常见的行业选择。关于如何构建应用程序，并不缺乏工具。这将取决于你愿意在你选择的方法中做出的限制和权衡，以便在iOS、Android--可能还有其他平台上构建。

25. 采用新的语言和框架。

我们应该什么时候开始使用一种新的语言？我们是否应该开始使用一个新的、有前途的框架？不幸的是，没有简单的答案，即使你做了研究，你也可能为你的决定而后悔。

你的应用程序越复杂，采用一种新的语言，或者切换到不同的 "核心 "框架，风险就越大。 我所说的 "核心 "框架，是指在整个应用程序中使用的框架，如网络库、依赖注入框架、实现跨平台业务逻辑的库，以及其他。

在2016年，Swift处于2.2版本。Uber的工程团队决定在重写Uber的Rider应用时100%使用Swift。这个决定几乎是一场灾难，主要是因为团队没有想到Swift的二进制大小是Objective C的数倍。前移动平台经理Chris Brauchli在这篇文章中更详细地解释了这些问题。

在吸取了经验之后，Uber更加谨慎地评估了采用新语言的每一个方面。对于Kotlin，团队做了广泛的评估和性能测量。

你会希望投入精力来评估一种新的语言或框架，这与采用该语言的工作意味着什么以及它的风险是一致的。 Uber投入了大量的精力来评估Kotlin，因为它的推出会影响到数百名Android工程师，以及每月产生数十亿美元收入的应用程序。

你要评估的领域与你评估跨平台框架的方式类似。在这些考虑之上，值得考虑的领域是。

  • 语言的成熟度/框架。API的稳定性如何？是否有在野外使用该语言或框架的成功案例，这与你试图建立的东西有关？
  • 迁移在未来会出现。如果你采用这种语言或框架，你是否需要将现有的代码迁移过来？这个工作会有多大？
  • 工程师的热情。 这是一项工程师们会很兴奋地工作的技术吗？团队中是否有足够的支持来继续采用这项技术？团队中有多大比例的人对该技术持怀疑态度，为什么？
  • 风险。 什么会出错？这可能会对应用程序、客户或业务产生什么影响？

用新的语言或框架建立一个较小的 "试点 "项目是一个很好的方法，可以更好地感受它，并回答关于可用性、明显的问题和工具的问题。

我个人的做法是支持尝试任何新事物，但要限制 "爆炸半径"。我们可以在应用程序的一个不太重要的部分使用新技术吗？我们可以在一个使用量较小的应用程序中进行试验吗？我们能不能先做一个改变，让只有公司员工测试这个新设置，然后再进一步行动？

移动工程不断发展，我们使用的语言、框架和工具也会不断发展。我们应该毫不畏惧地尝试新的方法，像Uber的Swift重写的故事应该提醒我们，当你没有 "B计划 "的时候会发生什么。

26. Kotlin多平台和KMM。

Kotlin多平台是通过共享Kotlin语言的共同代码来构建跨平台功能或应用程序的几种方法之一。我们将这种方法与其他跨平台功能开发和应用开发方法分开讨论，这要归功于它在大型应用和开发者团队中的迅速崛起。

Kotlin多平台是在2017年宣布的。有了它，你可以编写Kotlin并构建。

  • 用于Android的JVM库，或后端服务
  • 用于iOS和桌面的本地框架
  • 用于前端Web或后端服务的JavaScript构件

image.png

Kotlin多平台背后的想法：共享业务逻辑代码，保持视图代码为原生。上图：通用的想法。底部：Netflix如何实现KMM在他们的Prodicle电视制作应用中

Kotlin多平台移动（KMM） 于2020年发布，是Kotlin多平台之上的工具层。KMM为工程师提供了更容易进行IOS和Android开发的工具。这些工具包括

  • 丰富的IDE整合
  • 为移动应用程序提供更好的调试能力
  • 对Cocoapods的良好支持

一些较大的公司已经将Kotlin多平台项目投入生产。Netflix、Square、Careem和VMWare是其中的几个例子。采用这种方法有几个好处。

  • 使用Kotlin是许多移动工程师的自然选择。Android工程师可能已经在使用它了，而且如果你已经知道Swift的话，它很容易学习。对于iOS工程师来说，将他们的技能扩大到Android也是有益的。
  • KMM鼓励完全原生的UI组件。 与Flutter和React Native等工具采取的方法不同，KMM旨在让本地移动开发者以用户和开发者习惯的方式构建UI。
  • 来自JetBrains和谷歌的投资在Kotlin基金会拥有该项目。这也意味着在JetBrains IDEs和Android Studio中对Kotlin和KMM的一流支持。

Square的案例研究将Cash App转移到Kotlin多平台上，强调了一些团队可能采用这种方法的原因。Cash App团队希望将他们的大部分代码保持为本地代码，选择Kotlin作为共享组件的语言是有意义的。他们一开始就与Touchlab（本书的赞助商）合作测试该技术。他们注意到，由于平台对立的Kotlin与Swift相似，这种转变对iOS工程师来说是可控的。更重要的是，他们也有来自服务器团队的贡献。

采用KMM的缺点都来自于技术的不成熟。截至2021年，KMM工具是实验性的，会有一些可能影响早期采用者的突破性变化。较大的团队将发现痛苦的工具差距。VMWare团队指出，缺乏支持的库也是他们最终克服的一个挑战。

在所有的跨平台功能开发方法中，我认为Kotlin多平台和KMM是最有希望的。这是唯一一种跨平台的方法，现有的原生Android工程师在这里感到宾至如归，而iOS工程师在采用Kotlin和工具方面的学习曲线也将是最不陡峭的。

进一步阅读。

27. 跨平台的功能开发。

一次性编写移动应用的通用部分，并在iOS和Android上重复使用，这是一个明显的优化，有几个好处。

  • 通过一次性实现业务逻辑，减少构建功能的时间。大多数人都高估了在这方面节省的时间。当第一次构建时，你仍然需要在两个平台上进行测试。如果做得好，你会节省一些时间，但这并不是最大的胜利。
  • 减少iOS和Android的不一致性。 在单独工作时，iOS和Android团队经常以不同的方式或不一致的方式实现业务逻辑。有了共享的业务逻辑，这种情况就不会发生。
  • 减少了维护共享逻辑的时间。一个代码库而不是两个代码库。
  • 打破了iOS/Android的孤岛。 在许多组织中，iOS和Android团队是完全孤立的工作。即使是一个小小的跨功能开发也会打破这些孤岛。我只见过当iOS和Android工程师多谈而不是少谈的时候，事情会变得更好。

如何才能实现这个目标呢？有几种方法可以一次性编写业务逻辑，将其包装在一个库或组件中，然后在两个原生应用中重复使用这个逻辑。

image.png

跨平台功能和业务逻辑背后的想法：一次性编写与平台无关的逻辑，在不同的应用程序中重复使用它

有一个不断增长的跨平台功能开发方法库。

使用RIB的跨平台架构是我们在Uber使用的方法。在这种方法中，iOS和Android的代码库仍然是分开的；但是，架构术语和工具是共享的。RIBs的架构、工具和培训材料是开源的，被数百家公司使用。

我从RIBs发布之前就开始使用它构建应用程序，以下是我对使用这种方法的团队的观察。

  • 实现了跨平台规划。 使用共享架构方法的最大好处之一是你现在可以使用RFC或类似的方法为两个平台设计功能。一个功能的大部分工作方式将被共享，iOS和Android的实现差异应该在这个阶段被叫出来。
  • 鼓励跨平台的代码审查。 业务逻辑仍然在iOS的Swift和Android的Java/Kotlin中实现。尽管如此，由于工程师们正在构建类似的结构，他们可以更好地审查对方的代码。
  • 鼓励入职 "其他 "平台。 如果你一直在做iOS，那么RIBs会让你更容易 "上手 "Android。在Uber，我估计有将近一半的本地工程师在 "其他 "平台上有过贡献。跨平台的规划过程和代码审查降低了准入门槛。
  • 工具是这种方法的核心。 RIBs为iOS和Android提供了组件生成功能，消除了手工连接类的问题。在Uber，我们还对 "监督 "架构一致性的 "刷新 "规则进行了大量的投资。
  • 最大的缺点是这种方法的 "重量级 "性质。RIBs给iOS和Android的代码库带来了结构性的变化--这种结构对许多工程师来说是一种限制。

共享C++库是一种经过战斗考验的方式，可以在iOS和Android应用程序中共享代码--或专门的业务逻辑。构建游戏、音频和视频处理应用程序以及其他性能密集型用例的团队经常选择这种方法。

在Skype，大部分的呼叫逻辑从早期就用C++构建，并在所有平台上共享，包括Mac和Windows。Slack也采取了类似的方法在2017年的客户端应用开发中，在iOS、Android、Windows和Linux上编写、也优化和重用了数据获取、解析和缓存流逻辑。PSPDFKit在2016年选择了C++作为他们的跨平台语言，在评估了其他替代方案。

当使用C++组件时，你需要为Android（Java）和iOS（Objective C）生成自定义头文件。Djinni是这方面比较流行的一个库，你必须建立一个构建管道来持续地做这件事。

选择C++的最大好处是你可以使用这个库，不仅仅是在iOS和Android上，还可以在Windows、Mac和Linux客户端上。对库的性能和资源使用有更多的控制是另一个主要的好处。

最大的缺点是入门门槛。大多数原生移动工程师不会流利地使用C++，你的团队中可能有一些工程师喜欢使用不那么低级的语言。将正确的工具安装到位可能需要更多的努力，你需要有深厚的C++专业知识的人在出现问题时进行调试和解决。

其他跨平台库选项包括Go Mobile（从Go包中生成绑定并在Android或iOS上调用），J2ObjC（共享用Java编写的业务逻辑）或使用JavaScript以及iOS和Android解释器，以执行共享JS业务逻辑。所有的方法都是可行的，尽管这两种方法都没有在构建复杂的移动应用的团队中获得很大的普及。

缺乏可见的成功案例并不意味着你应该把它们排除在外。Freshworks选择了Go Mobile作为他们的跨平台方法，并对结果普遍感到满意。他们最大的痛点不是技术，而是一些本地移动工程师对不得不维护Go代码库感到不满。

你的应用越复杂，你就越有理由考虑跨平台的业务逻辑。 RIBs可以成为打破iOS和Android孤岛的良好第一步，但不需要转移到新的技术。对于想要接受现代Kotlin语言的团队来说，Kotlin多平台是一项非常有前途的技术。而C++是一种经过实战检验的语言，对于业务逻辑不仅在移动端共享，而且在桌面端也共享的应用来说特别有用。

不要低估共享跨平台代码的开销。 直到2019年，Dropbox使用C++在iOS和Android之间共享代码。然而，他们发现，以非标准方式编写代码的开销，最终比仅仅编写两次代码更昂贵。他们在其工程博客上分享了他们的挑战。自定义框架和库的开销、自定义开发环境、平台差异以及培训、雇用和重新培训开发人员的开销，都是促使Dropbox将其做法与行业标准接轨的原因。

许多采用跨平台代码共享的公司往往特别低估了失去优秀的本地移动工程师的成本。例如，如果你选择的共享组件的语言不是Swift或Kotlin，你很可能会失去团队中一些最强的原生iOS或Android工程师；这些人希望在尖端的原生环境中工作。

进一步阅读。

28. 跨平台应用开发与本地的比较

用共享语言编写业务逻辑和库可以保持移动UI的原生性，同时共享业务逻辑的代码。像Flutter、React Native或Cordova这样的跨平台应用开发框架让你别无选择，只能共享应用的UI层。对于那些想要更复杂，或者在原生UI层有更多控制权的应用程序，跨平台的业务逻辑解决方案可能更有意义。

需要考虑的跨平台应用程序开发方法的动机：。

  • "对速度的需求"。 对在两个平台上建立一个功能可能需要多长时间感到沮丧。如果有一种方法能保证更快的功能开发时间，并且在两个平台上都能做到，那不是很好吗？
  • 我们希望一个工程师能在两个平台上工作， 而不是需要两个工程师。为了运送最简单的用户界面变化，两个工程师需要在两个平台上做两个独立的变化。两者都需要进行测试，而且推出时往往需要进行协调。如果同一个人可以做这两件事，那不是很好吗？
  • 希望iOS和Android应用的工作方式完全相同。 同一产品的iOS和Android应用往往会有细微的不同。一个错误会出现在安卓上，但在iOS上却没有。如果两个应用程序以相同的方式工作，岂不是很好？
  • 统一iOS和Android应用程序的外观和感觉。 随着时间的推移，设计团队将倡导共享UI/UX方法。这从品牌的角度来看会有很大的意义，同时也会将两个平台的设计工作减少到一个统一的平台。
  • 对 "热重载 "的渴望， 超过对构建列车的等待。即使是最小的移动应用程序的改变也需要几周的时间，因为代码的改变需要通过App Store来运送。如果可以选择进行实验或运送错误修复，而不必等待构建列车，那不是很好吗？

虽然跨平台功能开发有助于统一iOS和Android应用程序之间的许多业务逻辑，但跨平台应用程序开发更进一步，在两个平台之间统一了UI层。你可以选择几种技术来构建你的跨平台应用程序。以下是最受欢迎的技术。

Flutter是2021年迄今为止似乎采用势头最强的框架。宝马已经完全过渡到Flutter，eBay Motors和Nubank已经选择Flutter作为其跨平台应用开发技术。谷歌正在对Flutter进行大量投资，并且只使用这种技术来构建其大部分新的应用程序，其规模之大是其他跨平台应用程序开发方法所不具备的。

最大的缺点是你必须学习并使用Dart开发才能使用它。这种语言很容易掌握，除此之外，似乎没有什么理由不投资这种方法。截至2021年，Flutter是市场上最成熟的跨平台应用开发方法，一些公司正在全力以赴地使用Flutter进行应用开发，这也是这种方法的证明。

使用Flutter的公司的例子。

React Native在2016年有很强的势头，但在2018年，Airbnb在投资了两年时间使其发挥作用后移开了它。在详细的事后总结中，他们分享了他们面临的技术和组织问题。然而，Shopify在2020年宣布押注React Native，但比其他几家公司采取的方法要谨慎的多。

其他大型科技公司，如拥有Office和Skype的微软、Coinbase、特斯拉和亚马逊都在采取同样的谨慎态度，在其部分应用中引入React Native。亚马逊甚至有自己的内部React Native会议，有数百名工程师在一些项目中使用React Native。

React Native对于拥有大量现有网络工程师和熟悉使用JavaScript构建原生移动应用的人的公司来说是一个好方法。许多用RN构建的应用开始时都是MVP，或独立的、不太复杂的应用。随着技术的成熟，我们可以期待看到用这种方法构建和维护更复杂的应用程序。

使用React Native的公司的例子，或从React Native转移到其他公司。

Xamarin/MAUI是一个流行的使用C#的跨平台框架。微软宣布在2021年底 "刷新 "Xamarin作为.NET MAUI框架的地位。拥有C#代码库的公司在用这个框架在后端和本地应用程序之间共享代码方面取得了巨大成功。

对于拥有C#工程师的.NET商店和公司来说，Xamarin是一个可行的选择，可以引导应用程序。围绕Xamarin的社区比Flutter或React Native小得多。然而，由于微软对该平台的投资，这种方法很可能会继续流行下去。

使用Xamarin/MAUI的公司的例子。

  • DraftKings建立他们的体育博彩和赌场应用程序
  • BBVA--西班牙最大的银行之一--构建其Valora View应用程序
  • 飞利浦建立其VitaHealth Engage平台

其他跨平台框架包括Cordova（以前的PhoneGap）、Ionic和NativeScript。在这些技术上建立的复杂应用程序的公开案例较少。在Cordova/Ionic上构建的较大的应用之一是荷兰的Rabobank应用，大约有50万客户在使用。在大规模项目中采用这些技术的最大障碍通常是性能和工具问题。

跨平台应用开发的承诺是难以忽视的。

  • 成本。 最大的好处。只需编写一次代码，就可以在iOS和Android上部署，最好还能在网络和桌面上部署。
  • 可重复使用。在这两个平台之间重复使用代码，也许还可以在网络上使用。
  • 新奇和一个可以尝试的很酷的新技术。我们的工程师经常因为使用新的、有趣的东西而感到兴奋，比如一个新兴的框架。
  • 在iOS和Android上有相同的功能。不再需要担心两个应用程序的工作方式不同。
  • 假设更容易雇用或（重新）培训网络工程师。一些工程领导认为，通过使用跨平台的框架，他们现有的工程师可以快速掌握移动开发，而且可以在Android和iOS上运送移动应用的人更少。这是一个经常不符合现实的承诺。

这种方法有明显的缺点，即使是较小的应用程序，也能看到这些缺点。

  • 还有一个可能出错的地方。React Native和Flutter都在iOS和Android原生代码的基础上增加了一层。它们确实抽象了一些复杂性，但当你看到一个错误只发生在一个平台上时，你必须调试问题是出在你的代码上，还是出在React Native/Flutter上，还是出在平台层面。
  • 本机代码（仍然）需要，特别是对于高级部分。使用跨平台的框架并不能消除在半高级的情况下编写本地代码的需要，也不能消除对平台特定功能的需要。
  • 总是落后一步。每次iOS或Android引入新的API，这些框架都需要几个月的时间--如果不是更长的话--才能想出一个抽象的方法来包装这些API。如果你是这些API的早期采用者，你必须原生实现它们。

有一些你以后才会看到的坏处。

  • 假设那些启动转型的工程师多年后还在。有几家公司因为跟随一两个有发言权的工程师做出向框架过渡的决定而被烧毁。然而，一旦这些工程师离开，团队发现他们不确定是否应该继续前进，或者回头。
  • 大多数移动工程师总是喜欢原生的。你要么很难聘请到对移动体验有深切关注的工程师，要么他们会对跨平台的方法怨声载道，并寻求将事情转回原生。
  • 工具变化的痛苦是大多数团队大大低估了的东西。
  • 跨平台框架总是比原生框架对你的限制更大，而且这些限制会不断出现。这可能是用户体验、性能或如何完成一些事情；你必须投入非同小可的时间来处理这些问题。

在引入React Native、Flutter、Cordova或其他大型应用或团队的跨应用框架之前，你需要仔细评估这些权衡。以下是你在决定引入这些框架之前要评估的几个方面，或者说要放弃这些框架。

  1. 性能与本地的比较。应用程序的启动时间是如何影响的？屏幕加载的速度如何？你有多大的余地来优化UI性能？
  2. 开发经验与本地的比较。开发过程中是否支持热重载？在开发环境中测试变化的速度如何？开发者工具的质量和可靠性如何？
  3. 工具。 调试的支持程度如何？性能和内存剖析？编写自动化测试、做linting/静态分析有多容易或困难？CI/CD工具的情况如何？
  4. 设备支持 - 特别是低端设备。该框架在旧机型上的表现如何？公司或应用程序期望在这些机型上做多少业务？
  5. UX/UX "原生 "外观和感觉，以及围绕它们的权衡。许多跨平台框架带来了更多的 "通用 "UX，与原生iOS或Android应用的感觉 "格格不入"。该框架在这个层面上的表现如何？
  6. 发布速度和质量。 发布有多容易？一个版本的执行速度有多快？哪些质量检查可以自动化，框架不支持哪些检查？
  7. 二进制大小影响。使用这些框架会给应用程序增加多少占用空间？实现一个屏幕或一个类会有多大？
  8. 平台限制。 iOS和Android平台有哪些已知的问题，何时以及如何解决对应用程序很重要的问题？
  9. 与本机代码的混合。 在本机代码中添加有多容易或困难？工具方面如何，例如加入测试和静态分析？
  10. 框架和本地代码之间接口的类型安全。你可以如何安全地来回传递对象？
  11. 构建性能。 构建和运行测试的速度有多慢或多快？构建速度成为大型开发团队的一个症结所在。
  12. 版本选择，以防React Native出现类似热重载的解决方案。你如何处理只向某个版本以上的应用推出代码？
  13. 移动团队在决定是否使用框架时的自主权。如果使用或不使用跨平台框架的决定不是由工程团队做出的，那么你的工程师最终会比他们做出决定的时候权力小。

一些没有采用较知名的跨平台框架的大公司，有时会实施解决方案来解决上述一个或多个问题。或者它可能是一个允许某种程度的 "热重载 "的框架。它可能是一个跨平台的声明式UI框架。当你有足够的资源来建立这样的东西时，这可能是一项有意义的投资。然而，当你没有的时候，你仍然需要弄清楚这些问题有多紧迫，以及你打算如何解决它们。

跨平台应用程序在规模上的最大障碍似乎是工具支持，以及在使用跨平台应用程序解决方案时不得不放弃UI级别的控制。许多大型应用希望在用户界面层面保持精细的控制，以确保一流的性能，因此坚持使用两个本地代码库，或转向跨平台功能开发。

评估你需要做什么，而不是照搬其他公司已经在做的事情。跨平台功能开发以及应用开发工具集都在快速发展，你有很多方法可以选择。

为了弄清楚哪种方法适合你，请回答这些问题：哪些是最大的移动工程痛点，你的限制条件是什么？伴随着权衡的跨平台框架工具是否为你的用例提供了正确的好处类型和可接受的缺点？

29. 网络、PWA和后台驱动的移动应用。

无法即时更新移动应用是原生应用的许多主要痛点的来源，也是我们在错误难改和应用版本的长尾章节中所涉及的。但是，如果我们有一根魔法棒，让这一切都消失，瞬间更新应用程序，那会怎样？

事实证明，我们确实有即时更新移动应用程序的魔杖。事实上，有几根魔杖。

PWA（渐进式网络应用程序） 使用网络浏览器API来构建类似于本地的用户体验。PWA可以支持拥有一个应用外壳，在安卓上推送通知或资产缓存。PWA可以说是增强移动网络的下一个自然步骤。Pinterest是早期投资于构建渐进式PWA的公司之一，以努力提高他们的移动网络使用率。

对于复杂的应用程序来说，PWA不太可能成为本地应用程序的替代品或竞争者。然而，值得关注的是该技术的发展。

将网络屏幕嵌入到移动应用中是最常见和最简单的方法。对于你想拥有动态内容的应用部分，在iOS上添加一个WKWebView或在Android上添加一个WebView可能是一种明智的做法。值得注意的是，苹果公司明确表示，他们拒绝只包装网站而不增加功能的应用程序，但应用程序中的网络视图和额外的业务逻辑是可以的。

构建对应用程序离线时的支持是挑战之一。在这种情况下，你必须从本地数据加载网络视图的内容，然后在连接恢复时将本地数据同步回来。

对操作系统来说，用户体验感觉不 "自然 "通常是这种方法的最大缺点。你必须花大量的精力来设计组件的样式，使它们感觉是你的应用程序的原生。不过，在基于webview的方法中，你有无法复制的动画，比如在iOS上从主视图转到详细视图时的动画。

对于Android来说，这种方法有几个问题需要注意，特别是在旧设备和操作系统版本上。在iOS上，使用JavascriptCore几乎总是有性能方面的缺陷。Lucidchart迁移他们的混合应用程序到WKWebView，看到了10-15倍的主要性能改进。请注意，对于那些只做简单的JavaScript操作的应用程序来说，这种性能改进可能不太明显。

优化网页是你要大力投入的事情，以便为嵌入式网页屏幕提供良好的性能。UberEats团队花了相当多的时间将提供的内容修剪成移动端需要的内容，优化服务器端的处理时间，并测量改进的效果。这项工作建立在m.uber.com团队在减少包的大小和依赖性方面所做的许多移动网络优化。

后台驱动的移动应用是使本地应用更容易即时更新的自然下一步，但不必依赖网络视图或第三方框架。在构建本地应用程序时，你可以对用户体验、资源使用和性能进行最佳控制。最大的权衡是你需要如何运送二进制变化，以使应用程序的业务逻辑发生变化。

如果业务逻辑由后台驱动，而移动应用的一部分就像一个解释这些指令的应用外壳，会怎么样呢？

这个想法对于所有复杂的应用程序来说迟早会出现。它将引发讨论，特别是对于那些业务需要频繁变化的领域，或者需要根据地区、用户或其他细分情况表现得略有不同的应用程序的部分。

发送可执行逻辑以在移动应用程序上运行时执行是如履薄冰。苹果公司在2017年之前一直禁止所有形式的原生可执行代码，之后他们软化了这一政策为开发者工具。目前，从后端向移动应用发送JavaScript代码是被允许的，但仅限于不会实质性改变你的应用工作方式的情况。然而，苹果可能决定在未来改变这一政策。

发送控制移动应用行为的元数据是一种更常见的方法。这种解决方案在iOS上是面向未来的，即使苹果决定禁止向应用程序发送Javascript可执行代码。这个想法是创建一个解释元数据的外壳，并在应用程序中动态地构建界面和功能。像这样的应用程序仍然无法绕过移动外壳不能轻易更新的事实。除了解释后端指令之外，shell不应该包含任何客户端的业务逻辑。即使是这个外壳的v1版，你也需要提前考虑几个后端版本。

后台将需要意识到不同的移动版本，并确保它向每个客户端发送兼容的 "信息"。这导致需要决定如何处理版本问题；何时对API进行修改，何时引入新的API版本，或何时创建一个新的端点。幸运的是，版本管理和向后兼容的构建都不是新问题。不过，如果你决定建立一个解释元数据的移动外壳，你可能会面临一个挑战。

后台将需要意识到不同的移动版本，并确保它向每个客户端发送兼容的 "信息"。这导致需要决定如何处理版本问题；何时对API进行修改，何时引入新的API版本，或何时创建一个新的端点。幸运的是，版本管理和向后兼容的构建都不是新问题。不过，如果你决定建立一个能解释元数据的移动外壳，你可能会面临挑战。

在Uber，我们建立了一个与此类似的内部系统，并学会了如何在外壳代码中不发送硬编码的客户端逻辑，如何正确地进行版本管理，以及这样一个系统的测试是多么具有挑战性。Lyft, Airbnb, Zalando, 和其他许多公司都建立了自己的后台驱动的UI方法。你可以在这个移动原生基金会的讨论中阅读更多关于各种方法的内容。

进一步阅读。

章节摘要

由Bitrise的Kevin Toms撰写，作为本书的补充。

用于创建移动应用程序的语言和框架不断发展，一些领先的工具随着时间的推移而失去了知名度，并逐渐淡出人们的视野。由于有两个主要的平台--iOS和Android--需要满足，在特定平台的工具和跨平台的工具之间总是存在着权衡。采用新的语言可能是有风险的。它可能得到大公司的支持，如苹果，但可能仍需要进一步发展。语言供应商的目标是采用，但决定什么时候采用一种新的语言并利用其声明的好处仍然是一个挑战。

在采用一种新的语言时，有一系列的事情需要考虑，包括语言的成熟度和迁移现有代码的困难。你现有的工程团队的意见和热情也很重要--如果你的工程师真正参与到这个过程中，成功采用一种新语言的可能性就更大。风险总是存在的，但也有办法来减轻这种风险。例如，Kotlin多平台和Kotlin多平台移动提供了解决方案，其优点和缺点已在本章中描述。

保持跨平台一致性的一种方法是使用跨平台特性开发框架。其主要思想是，关键的业务逻辑代码在iOS和Android之间是相同的。本章讨论了一些工具选项，以显示如何做到这一点。把它提升到另一个层次，接下来评估跨平台应用开发。在这种情况下，整个应用程序是在一个跨平台工具中构建的，旨在为iOS和Android提供一套代码。

本章介绍了一些框架，如Flutter、React Native和Xamarin。每个工具都可以解决iOS和Android之间的差异问题，并提供不同的权衡。此外，由于iOS和Android都有集成的网络应用程序组件，因此有可能创建网络应用程序，甚至是移动应用程序，包裹iOS和Android的网络应用。虽然这提供了可移植性，但它也限制了移动架构和UI组件的使用。

www.deepl.com 翻译

avatar
文章
阅读
粉丝