详尽kmp_关于移动开发体系结构的详尽而详尽的指南

详尽kmp

by Jose Berardo Cunha

由Jose Berardo Cunha设计

关于移动开发体系结构的详尽而详尽的指南 (A deeply detailed but never definitive guide to mobile development architecture)

Native, Web, PWA, hybrid, Cross-Compiled… what is “the best” way to develop for Android and iOS platforms? What looks reasonable? And how are you supposed to choose among the options? In this article, I’ll lay it all out so you can make an informed decision.

本机，Web，PWA，混合，交叉编译...针对Android和iOS平台开发的“最佳”方法是什么？ 什么看起来合理？ 您应该如何选择呢？ 在本文中，我将对其进行全面介绍，以便您可以做出明智的决定。

First things first, let me provide you with a bit of context. I am an IT senior consultant, and the idea of putting together this guide was born from discussions with one of our clients about what could be the best approach for them. Yes, just for them. And we realized that we did not have a well-defined strategy, a solid and reliable foundation, to help us come up with the right answer.

首先，让我为您提供一些背景信息。 我是一名IT高级顾问，而编写本指南的想法源于与我们的一位客户讨论什么对他们来说最好的方法。 是的，只为他们。 而且我们意识到，我们没有一个明确的战略，坚实可靠的基础来帮助我们找到正确的答案。

And you know what? I could not find such a guide easily anywhere on the Internet, either. Although there are several articles about this topic, none of those I came across were reasonably complete. Unfortunately the majority overlook a lot of concepts or, even worse, are essentially wrong.

你知道吗？ 我也无法在Internet上的任何地方轻易找到这样的指南。 尽管有几篇有关该主题的文章，但我所遇到的文章都还不够完善。 不幸的是，大多数人忽略了很多概念，或者更糟的是，本质上是错误的。

Now, I’d like to take a wider look. And while I’m potentially helping someone make their own decisions, I’m also asking around the community for more thoughts on the subject.

现在，我想更广泛地看一下。 尽管我有可能帮助某人做出自己的决定，但我也在社区中询问有关该主题的更多想法。

This guide has two parts:

本指南分为两个部分：

1. Mobile Development Architectural Tiers (this)
   移动开发架构层(此)
2. How to make your decision
   如何做出决定

It's also available on YouTube as a series of 10 videos and as a free course on Udemy. There, you’ll find the same written material as here, the same videos from the YouTube series, as well as quizzes to fix all the topics and a final certification.

YouTube上还提供了一系列的10部视频，以及有关Udemy的免费课程 。 在这里，您会找到与此处相同的书面材料，YouTube系列的相同视频以及修复所有主题的测验和最终认证。

So let’s get started.

因此，让我们开始吧。

介绍 (Introduction)

When it comes to mobile platforms, it's arguable that there are just two big players: Android and iOS. Other technologies like Tizen, Blackberry, or Windows Phone are either dead or have been around for a while and have no prospects of reaching any significative market share.

对于移动平台， 可以说只有两个大公司 ：Android和iOS。 诸如Tizen，Blackberry或Windows Phone之类的其他技术已经死了，或者已经存在了一段时间，并且没有达到任何重要市场份额的前景。

A quick look at this massive duopoly might make you think that developers do not have many options when creating mobile apps. This idea can't be further from the truth, though. You can quickly spot a fistful of programming languages being used out there: C/C++, Java, Kotlin, Objective-C, Swift, JavaScript, TypeScript, C#, Dart, Ruby, and I'm pretty sure I’ve missed a few more.

快速浏览这种巨大的双头垄断可能会让您认为开发人员在创建移动应用程序时没有太多选择。 但是，这个想法离事实不远了。 您可以Swift发现其中使用了许多编程语言：C / C ++，Java，Kotlin，Objective-C，Swift，JavaScript，TypeScript，C＃，Dart，Ruby，而且我敢肯定我已经错过了一些更多。

The same is true of mobile development frameworks. Unless you are not a developer, or have somehow been unaware of new technologies for the last 10 years, you’ve probably heard about Cordova/PhoneGap, React Native, Xamarin, Ionic, Nativescript, or Flutter, just to name a few cross-platform solutions for mobile apps.

移动开发框架也是如此。 除非您不是开发人员，或者在过去的十年中一直不知道新技术，否则您可能听说过Cordova / PhoneGap，React Native，Xamarin，Ionic，Nativescript或Flutter，仅举几例：移动应用程序的平台解决方案。

So let’s look at all these pieces of the architecture and break things down a bit.

因此，让我们看一下架构的所有这些部分，并对它们进行分解。

TL; DR (TL;DR)

There's no clear winner. All approaches have pros and cons, and might be either the best fit or the worst fit for your next project. In this guide, I'm classifying many different solutions into various tiers according to the distance their architectures are from the native platform.

没有明确的赢家。 所有方法都各有利弊，可能是您下一个项目的最佳选择。 在本指南中，我将根据其架构与本机平台的距离将许多不同的解决方案分为不同的层。

本机应用 (Native Apps)

To start, let's go straight to the metal. Our first architectural tier is Native Apps.

首先，让我们直接开始。 我们的第一个架构层是本机应用程序。

This is the tier where you must be aware of the idiosyncrasies of each platform. It’s not my intention to dig into them, I just want to mention a few things in a bit of context.

这是您必须了解每个平台的特质的层。 我并不是要深入研究它们，我只是想在上下文中提及一些事情。

的iOS (iOS)

Starting on the iOS side, just because it's simpler, there's only Apple ruling the world. Originally, developers needed to learn Objective-C, a proprietary object-oriented variation of C with some inspiration from SmallTalk (and an insanely long-named API).

从iOS方面开始，只是因为它更简单，所以只有Apple统治世界。 最初，开发人员需要学习Objective-C，这是C的专有的面向对象的变种，并从SmallTalk( 和一个疯狂的长名API )中获得了启发。

In 2014, Apple announced Swift, a multi-paradigm language, which was a lot easier than its predecessor. It's still possible to deal with Objective-C legacy code, but Swift has reached high maturity levels. So, if you're planning to learn how to natively develop for iOS, Swift is definitely where you should start.

2014年，苹果发布了Swift，这是一种多范式语言，比其前身要容易得多。 仍然可以处理Objective-C的遗留代码，但是Swift已经达到了很高的成熟度。 因此，如果您打算学习如何为iOS进行原生开发，那么绝对应该从Swift开始。

安卓系统 (Android)

On the Android side, there are a number of different manufacturers. The vast majority of them rely upon ARM processors. But generally speaking, Android apps lay on virtual machine instances (instances of ART) to help deal with potential underlying specificities (not without many amazing tricks).

在Android方面，有许多不同的制造商。 他们中的绝大多数依靠ARM处理器 。 但总的来说，Android应用程序基于虚拟机实例( ART实例 )来帮助处理潜在的基础特性( 并非没有许多惊人的技巧 )。

That's why, originally, the language of choice was Java. It’s not only been the most popular language in the World for almost two decades (with a few position swaps with C), but it’s also notable for its Java Virtual Machine (JVM). This empowered developers to compile their code down to an intermediate bytecode that could be read and run by the JVM.

这就是为什么最初选择的语言是Java。 它不仅是近二十年来世界上最受欢迎的语言( 与C进行了一些位置互换 )，而且还因其Java虚拟机(JVM)而闻名。 这使开发人员能够将其代码编译为可由JVM读取和运行的中间字节码。

With the Android Native Development Kit (NDK), it's also possible to develop critical parts of the app directly in native code, writing in C/C++. In this case, you have to be aware of underlying platform quirks.

借助Android Native Development Kit(NDK)，还可以直接使用本机代码(用C / C ++编写)开发应用程序的关键部分。 在这种情况下，您必须了解基础平台的怪癖。

Kotlin is a language unveiled by JetBrains in 2011. When it first came out, despite its flexibility and conciseness, it wasn't more than yet another JVM language with more successful competitors like Scala, Clojure, or Groovy. However, after its first major release in 2016, it rapidly started to stand out from the crowd, especially after Google announced that it would be officially supported on the Android platform at Google I/O 2017.

Kotlin是JetBrains在2011年推出的一种语言。尽管它具有灵活性和简洁性，但它最初问世时不过是另一种具有Scala，Clojure或Groovy等成功竞争对手的JVM语言。 但是，在2016年首次重大发布之后，它Swift开始在人群中脱颖而出，特别是在Google在2017年I / O大会上宣布将正式支持Android平台之后。

Kotlin is becoming Google's first class language (currently Kotlin and Java — in this order — are used throughout Android's official documentation). A total Java replacement is expected even more so now that the US Federal Appeals Court has ruled on the endless lawsuit filed by Oracle accusing Google of violating Java copyrights.

Kotlin正在成为Google的一流语言(目前，Kotlin和Java(按此顺序使用)已在Android的官方文档中使用)。 预计Java的整体替代品将更加庞大，因此，现在美国联邦上诉法院已对Oracle指控Google侵犯Java版权的无休止的诉讼做出了裁决。

本机组件 (Native components)

Developing in this tier, you can also leverage all native APIs and, in particular, the native components. This saves your app from having to reinvent the wheel.

在这一层进行开发，您还可以利用所有本机API，尤其是本机组件。 这使您的应用程序不必重新发明轮子。

I've published a video demo of how to create a simple project on Xcode (iOS) and Android Studio. If you want to check it out:

我已经发布了有关如何在Xcode(iOS)和Android Studio上创建简单项目的视频演示。 如果您想检查一下：

本机应用程序的优势 (Native Apps advantages)

• Best performance and top user engagement
  最佳性能和最高用户参与度
• Bleeding edge native features
  流血的边缘本机功能
• Notably good IDEs Android Studio / Xcode
  出色的IDE，Android Studio / Xcode
• Modern high-level languages Kotlin / Swift
  现代高级语言Kotlin / Swift
• Very low-level approach with NDK
  使用NDK的非常底层的方法

本机应用程序的缺点 (Native Apps disadvantages)

• Two codebases to maintain
  维护两个代码库
• Require installation (except Android Instant Apps)
  需要安装(Android Instant Apps除外)
• Hard to analyze SEO
  难以分析SEO
• Very expensive to get users to download the app
  要让用户下载该应用程序非常昂贵

网络应用 (Web Apps)

On the other side of the spectrum, we have Web Apps. Web Apps are essentially apps run by the browser. You don't write code targeting the platform, but rather any browser running on top of it.

另一方面，我们有Web Apps。 Web Apps本质上是由浏览器运行的应用程序。 您无需编写针对该平台的代码，而可以编写在该平台上运行的任何浏览器。

In this tier you’ll find an insane number of contenders jumping at each other's throats. But they all use an arsenal consisting of the same weapons: HTML, CSS, and Javascript.

在这一层，您会发现疯狂的竞争者在彼此的喉咙跳来跳去。 但是他们都使用由相同武器组成的武器库：HTML，CSS和Javascript。

Web frameworks and libraries, even when leveraging CSS pre-compilers like LESS or SASS, even Javascript pre-compiled languages like TypeScript, CoffeeScript or Flow, even symbiosis like JSX or Elm, leaving alone tools like Babel used to transpile everything to Javascript with different configurable levels of conformance with ECMAScript yearly specifications (ES6 / ES7 / ES8, or if you prefer ES2015 / ES2016 / ES2017 / ES2018).

Web框架和库，即使利用了诸如LESS或SASS之类CSS预编译器，甚至还利用了TypeScript ， CoffeeScript或Flow之类的Javascript预编译语言，甚至是JSX或Elm之类的共生语言，也没有使用Babel之类的工具来将所有内容转换为具有不同含义的Java脚本。符合ECMAScript年度规范(ES6 / ES7 / ES8，或者如果您更喜欢ES2015 / ES2016 / ES2017 / ES2018)的可配置级别。

At the end of the day, they all are HTML, CSS, and JavaScript rendered and run by the browser. There's no direct access to native APIs like camera, vibration, battery status, or file system, but some of them can be achieved via Web API's:

归根结底，它们都是由浏览器呈现和运行HTML，CSS和JavaScript。 无法直接访问本机API，例如摄像机，振动，电池状态或文件系统，但是其中一些可以通过Web API实现：

The big issue with Web APIs is their maturity level. Many of them are not supported by some browsers. There are differences in implementations, especially across mobile browsers.

Web API的最大问题是它们的成熟度。 有些浏览器不支持其中的许多功能。 在实现上存在差异，尤其是在移动浏览器之间。

Web App的优势 (Web App advantages)

• Shared code between platforms and desktop browsers
  平台和桌面浏览器之间的共享代码
• Do not require previous installations, just navigate and use
  不需要以前的安装，只需导航并使用
• Tons of frameworks and libraries to go with them
  与之配套的大量框架和库
• Best for SEO
  最适合SEO

Web App的缺点 (Web App disadvantages)

• Lower performance
  效能低下
• Hard to get a native user experience
  难以获得本机用户体验
• Require an internet connection
  需要互联网连接
• Not available on official app stores
  不适用于官方应用程序商店
• API not as mature and reliable as native API
  API不如本机API成熟可靠

框架和Web组件 (Frameworks and Web components)

Angular, React, and Vue are probably the most popular web frameworks as of 2018. To be precise, however, React is considered just a library due to its flexible and less opinionated nature. Angular, on the other hand, is a strongly opinionated framework. Vue lives at some point in between them.

截至2018年， Angular ， React和Vue可能是最受欢迎的Web框架。但是，确切地说，由于React的灵活性和自以为是的性质，React只是一个库。 另一方面，Angular是一个强有力的框架。 Vue介于两者之间。

Angular, originally called AngularJS, was presented to the world in 2010 by Google. It quickly started to shine, due to its inversion of paradigms in comparison with other libraries from that time (like jQuery, the most popular back then). Instead of directly talking to HTML elements to manipulate the UI state, with AngularJS, templates were magically updated whenever the JavaScript model was updated.

Angular最初称为AngularJS ，于2010年由Google推出。 由于它与当时的其他库相比，其范例的倒置(如jQuery ，当时最流行)，它很快开始发光。 使用AngularJS可以直接对模板进行神奇的更新，而无需使用AngularJS与HTML元素进行直接对话来操纵UI状态。

As AngularJS became more and more popular, it also grew in purpose. It turned into a complete and opinionated framework that was one of the first that took SPAs (Single Page Apps) seriously. This growth (in both aspects) was responsible for some API bloats and performance issues.

随着AngularJS变得越来越流行，它的用途也越来越多。 它变成了一个完整而自以为是的框架，这是第一个认真对待SPA(单页应用程序)的框架之一。 这种增长(在两个方面)都造成了一些API膨胀和性能问题。

React was created by Facebook to solve their own needs on the presentation layer. It introduced many aspects that suddenly became very popular, like virtual DOM, one-way data flow (originally named Flux, especially popular through an implementation library called Redux), and a mixture of HTML and JavaScript called JSX.

React是由Facebook创建的，旨在解决他们在表示层上的需求。 它介绍了许多突然变得非常流行的方面，例如虚拟DOM，单向数据流(最初称为Flux ，尤其是通过称为Redux的实现库流行)，以及HTML和JavaScript的混合(称为JSX) 。

Only in 2016, after long debates and unexpected big changes, Google launched version two of its popular web framework. They called it Angular, instead of AngularJS. But, as many people already called the first version “Angular” (without the "JS" suffix), people started calling the new version Angular 2. That turned into a naming problem, as Google also announced that it would release new major versions every 6 months.

仅在2016年，经过长时间的辩论和意料之外的重大变化，Google推出了其流行的Web框架的第二版。 他们称它为Angular，而不是AngularJS。 但是，由于许多人已经将第一个版本称为“ Angular”(不带“ JS”后缀)，所以人们开始将新版本称为Angular2。这变成了命名问题，因为Google还宣布将在每个版本发布新的主要版本。 6个月。

In my opinion, that was a mammoth mistake. I've seen this before (with Struts vs Struts 2/WebWork, for example). They have a massively popular product that appears to have reached its plateau, and it has started to be more criticized than praised. If Google decides to rebuild it from the ground up, they should never, by any means, just change its major version. How will people trust that they will not repeat it every new major version release? Version two is supposed to present breaking changes, but it doesn't mean it can be totally revamped.

我认为，这是一个巨大的错误。 我之前已经看过(例如，使用Struts vs Struts 2 / WebWork)。 他们有一个非常受欢迎的产品，似乎已经达到了平稳状态，并且开始受到批评而不是受到赞誉。 如果Google决定从头开始对其进行重建，则他们绝不应以任何方式更改其主要版本。 人们将如何相信他们不会在每个新的主要版本中都重复使用它？ 版本2应该具有重大更改，但这并不意味着可以完全对其进行修改。

Angular is a spectacular web framework, and I really feel passionate about it. However, it's a completely new beast. It does not have much to do with AngularJS. Even Vue, which is another amazing framework (probably one of the most pleasant to work with, by the way) looks more similar to AngularJS from a bird's-eye view. I believe this caused a significant movement away from Angular and contributed substantially to React's popularity.

Angular是一个引人入胜的Web框架，我对此真的充满热情。 但是，这是一个全新的野兽。 它与AngularJS无关。 从另一个角度来看，即使是Vue，它也是另一个令人惊奇的框架(顺便说一句，可能是最令人愉快的框架之一)，看起来也更类似于AngularJS。 我相信这引起了Angular的重大变革，并极大地促进了React的流行。

Vue is the only one of the three most popular web frameworks that is not backed by a big company. It was actually started by a former Google developer. Due to its formidable simplicity and tiny footprint, it got attention from a massive and enthusiastic community.

Vue是三个不受大型公司支持的最受欢迎的Web框架中的唯一一个。 它实际上是由一位前Google开发人员启动的。 由于其强大的简单性和很小的占用空间，它得到了广大热情社区的关注。

Although there are more complete solutions, they all work on top of the concept of web components. There's an open specification about them currently in progress in W3C, and some interesting implementations like Polymer, Stencil and X-Tag.

尽管有更完整的解决方案，但它们全都在Web组件的概念上起作用。 目前在W3C中有一个关于它们的开放规范，以及一些有趣的实现，例如Polymer ， Stencil和X-Tag 。

In the third video of the series, I don't spend too much time discussing frameworks but discuss web component libraries:

在本系列的第三个视频中，我没有花太多时间讨论框架，而是讨论了Web组件库：

移动应用与网络应用 (Mobile Apps vs Web Apps)

I’m not sure if you’ve noticed, but the order of tiers I'm presenting here follows what I think is the easiest path to learn all approaches. I started from the Native Tier, the most genuinely mobile development. Then I decided to fly directly to the other extreme to present the Web Tier, which is the tier that has been available since the first smartphones.

我不确定您是否注意到了，但是我在这里介绍的层级顺序遵循我认为是学习所有方法的最简单方法。 我从Native Tier开始，这是最真正的移动开发。 然后，我决定直接飞往另一个极端，以介绍Web层，这是自第一批智能手机以来就可以使用的层。

Only now, after elaborating on a comparison between the two edges of my diagram, will I start talking about many of the cross-platform approaches to build mobile apps.

仅在现在，在详细说明了图表的两个边缘之间的比较之后，我将开始讨论构建移动应用程序的许多跨平台方法。

There's a long debate between Mobile Apps vs Web Apps. Everything I say about Mobile Apps is not exclusive to the Native Tier. It is also applicable to all cross-platform tiers I present later on.

移动应用程序与网络应用程序之间存在很长的争论。 我所说的关于移动应用程序的所有内容都不是本机层专有的。 它也适用于我稍后介绍的所有跨平台层。

用户行为困境 (The user behavior dilemma)

According to a Comscore survey in 2017, a user's fidelity to a mobile app is way more relevant than it is to mobile websites. According to an aligned article on Forbes, this is usually because of convenience (for example, home screen buttons, widgets, top notifications), speed (for example, smoother interfaces, almost instant start ups), and stored settings (for example, offline content).

根据Comscore在2017年的一项调查 ，用户对移动应用程序的忠诚度比对移动网站的相关性更高。 根据《福布斯》上一篇专栏文章 ，这通常是由于便利(例如主屏幕按钮，小部件，顶部通知)，速度(例如界面更流畅，几乎立即启动)和存储的设置(例如离线)内容)。

On the other hand, in the same Comscore data, we learn that customers can be reached more easily from mobile websites, as they are not as much tied to their few apps of preference. If you compare the most popular websites versus the most downloaded apps, it's estimated that an average of 8.9 million unique web visitors per month access the top 1000 websites. That's almost three times more than the average unique users of the top 1000 most downloaded apps.

另一方面，在相同的Comscore数据中，我们了解到，通过移动网站可以更轻松地吸引客户，因为他们与他们的少数几个首选应用程序之间的联系并不多。 如果将最受欢迎的网站与下载次数最多的应用程序进行比较，则估计平均每月有890万独立访问者访问前1000个网站。 这几乎是下载量最高的1000个应用程序中平均唯一身份用户的三倍。

That's all about distribution vs engagement. Your web app has a higher chance of being accessed, as users are more likely to try new things when navigating through their mobile browsers. But Mobile Apps have been proven to be more engaging, and catch the users attention for much longer periods.

这就是分配与参与的关系。 您的Web应用被访问的可能性更高，因为用户在通过其移动浏览器导航时更有可能尝试新事物。 但是事实证明，移动应用程序更具吸引力，并且可以在更长的时间内吸引用户的注意力。

Now that you understand the dilemma, let's have a look at Progressive Web Apps. This is an approach so tied to the Web Apps tier that I classify it as just an addendum to Web Apps. But it's a big disruptor and a serious candidate for the most prominent new and cool thing in web and mobile development.

现在您已经了解了难题，接下来让我们看一下渐进式Web应用程序。 这是一种与Web Apps层紧密相关的方法，我将其归类为Web Apps的附录。 但这是Web和移动开发中最杰出的新事物和新事物的巨大破坏者和严肃的候选人。

渐进式Web应用 (Progressive Web Apps)

Progressive Web Apps (PWAs) are a set of tools used to give Web App users the same experience they are accustomed to when they run Mobile Apps. This means that Web Apps can leverage the potentially higher levels of distribution with more decent levels of engagement.

渐进式Web应用程序(PWA)是一组工具，用于为Web应用程序用户提供他们在运行Mobile Apps时所习惯的相同体验。 这意味着Web Apps可以利用潜在的更高发行级别和更高水平的参与度。

Google defined three main qualifications for PWAs: they must be Reliable, Fast, and Engaging.

Google为PWA定义了三个主要条件：它们必须是Reliable，Fast和Engaging 。

Features called Service Workers and the App Shell are the foundation of Progressive Web Apps. They were created to promote apps’ reliability as they are now designed to work regardless of the device’s connection status. That includes offline mode, as well as poor connections. They also provide significant perceived performance boost, as apps launch using locally cached data, which eliminates delays for synchronous content downloads.

称为Service Workers和App Shell的功能是Progressive Web Apps的基础。 创建它们的目的是提高应用程序的可靠性，因为它们现在设计为无论设备的连接状态如何都可以工作。 其中包括离线模式以及连接不良。 当应用程序使用本地缓存的数据启动时，它们还提供了明显的性能提升，从而消除了同步内容下载的延迟。

You could consider reliability an indirect vector of engagement. Users are not affected while commuting by train, for example. They can stay engaged.

您可以将可靠性视为参与的间接载体。 例如，乘火车上下班时，用户不会受到影响。 他们可以保持订婚。

The same applies to speed. According to Google:

速度也一样。 根据Google的说法：

53% of users will abandon a site if it takes longer than 3 seconds to load!

如果加载时间超过3秒，则53％的用户将放弃网站！

However, being exclusively reliable and fast on load doesn't necessarily guarantee high engagement. PWAs leverage mobile-related features that used to be exclusive to mobile apps, like an “Add to Home Screen” option and Push Notifications.

但是，仅靠可靠性和快速加载并不一定能保证高参与度。 PWA利用了以前与移动应用程序有关的与移动相关的功能，例如“添加到主屏幕”选项和“推送通知”。

When it comes to to the “Add to Home Screen” feature, you might notice that Apple has had a similar feature since the very first iPhone. Some people even argue that Progressive Web Apps are Google's fancy new name for an original Apple idea.

关于“添加到主屏幕”功能，您可能会注意到，自第一款iPhone以来，苹果公司就具有类似的功能。 甚至有人认为，渐进式Web应用程序是Google最初的Apple创意的新名称 。

And you really can’t completely disagree. Some ideas are actually cycling. They come, go away, and then come back with a new name and some enhancements (for instance, Service Workers), so they can finally stick around.

您真的不能完全不同意。 一些想法实际上正在循环。 他们来了，走了，然后又回来了，有了一个新名称和一些增强功能(例如，Service Workers)，因此他们最终可以坚持下去。

On the other hand, it’s hard to completely agree. Steve Jobs’ speech about Web 2.0 + AJAX and the memorable announcement of the iPhone back in WWDC 2007 are not convincing enough to call him as the father, or even the prophet, of PWAs.

另一方面，很难完全同意。 史蒂夫·乔布斯(Steve Jobs)关于Web 2.0 + AJAX的演讲以及iPhone在WWDC 2007中令人难忘的发布，不足以令人信服地称呼他为PWA的父亲，甚至是先知。

To be fair, the Add to Home Screen capability on iPhone has been nothing more than a subtle, almost hidden, feature to generate desktop icons that just start up Web Apps in fullscreen mode. It has all the burden of HTTP request-response cycles and no clear path around caches.

公平地讲，iPhone上的“添加到主屏幕”功能只是生成桌面图标的微妙，几乎隐藏的功能，而该图标仅以全屏模式启动Web Apps。 它承担了HTTP请求-响应周期的全部负担，并且没有围绕缓存的明确路径。

PWAs start from the right point. They explore how previous installations of Web Apps aren’t necessary without losing the client-side bootstrap of Mobile Apps. This means that everything a user needs for their first interaction following startup might be locally cached (read: App Shell) and kept available as soon as they hit “Add to Home Screen.”

PWA从正确的位置开始。 他们探讨了如何在不丢失Mobile Apps客户端引导程序的情况下不需要先前安装Web Apps的情况。 这意味着，用户在启动后进行首次交互所需的所有内容都可以在本地缓存(阅读：App Shell)，并在单击“添加到主屏幕”后立即可用。

Moving onto another well-known characteristic of PWAs, let’s talk about the super engaging (or re-engaging) feature of the Mobile Apps world: Push Notifications. They are alert-style messages that appear on the top notification bar / area, as well as on lock screens. They have the power of pulling users back to your app once they receive the notification.

转到PWA的另一个众所周知的特征，让我们谈谈移动应用程序世界的超级参与(或重新参与)功能：推送通知。 它们是警报样式的消息，显示在顶部的通知栏/区域以及锁定屏幕上。 一旦收到通知，他们就可以将用户拉回到您的应用程序。

To reinforce the appeal of PWAs, Google has been pulling all modern Web APIs under the PWA umbrella. So expect to see things like Payment Requests, Credential Management, WebVR, Sensors, WebAssembly, and WebRTC in the context of Progressive Web Apps. But these feature are not necessarily tied to PWAs, and some were even born before the term PWA was coined.

为了增强PWA的吸引力，Google一直将所有现代Web API都放在PWA的保护下。 因此，期望在渐进式Web应用程序的上下文中看到诸如付款请求，凭据管理，WebVR，传感器，WebAssembly和WebRTC之类的内容。 但是这些功能并不一定与PWA相关，有些甚至是在PWA这个术语诞生之前诞生的。

PWA和苹果 (PWA and Apple)

Apple, on the other hand, announced their first solid milestones towards PWAs only in March 2018. Although there are still some limitations, the progress is appreciable. Some of the limitations might be related to the fact that Safari has fallen behind its competitors. Others could be attributed to Apple's philosophy of tight control.

另一方面，苹果公司仅在2018年3月宣布了其针对PWA的第一个坚实的里程碑。 尽管仍然存在一些局限性，但进展是可观的 。 某些限制可能与Safari落后于竞争对手的事实有关。 其他原因可以归因于苹果公司严格控制的理念。

Still, Apple has a more profitable App Store than Google. Apple's asserts that more criteria on app publications brings more overall reliability, and PWAs are bound to hurt the App Store's revenue. This suggests that some limitations that seem to be intentionally imposed (like 50Mb of PWA maximum cache size) will cost more to be revoked.

不过， 苹果拥有比Google更为有利可图的App Store 。 苹果公司断言，关于应用程序发布的更多标准会带来更高的整体可靠性，而PWA势必会损害应用程序商店的收入。 这表明似乎有意施加的某些限制(例如PWA最大高速缓存大小为50Mb)将被取消。

不幸的是，PWA并不完美 (Unfortunately PWAs are not perfect)

Web solutions and, on different levels, all cross-platform solutions struggle to attain the excellence and comprehensiveness of Native Apps. Every new feature, and every detail particular to Android or iOS makes that native feel harder and harder to access as you distance your app from the native tier.

Web解决方案以及不同级别的所有跨平台解决方案都在努力实现Native Apps的卓越性和全面性。 当您将应用程序与本机层分开时，每个新功能以及Android或iOS特有的每个细节都使该本机变得越来越难访问。

Overall, PWAs fix some issues in the Web Apps tier. But there are other issues that can’t be fixed by a solution working on top of a browser.

总体而言，PWA解决了Web Apps层中的某些问题。 但是还有其他问题无法通过在浏览器上运行的解决方案来解决。

PWA修复了什么 (What PWAs fix)

• More “native” experience
  更多“本地”体验
• Faster load times
  加载时间更快
• Do not require an internet connection
  不需要互联网连接
• Force web developers to be aware of situations where there’s no connection as well as a bad connection
  强制Web开发人员注意没有连接以及连接不良的情况
• Incorporate features from Mobile Apps like Push Notifications, Geolocation, or Speech Recognition
  整合来自移动应用程序的功能，例如推送通知，地理位置或语音识别

他们不做什么 (What they don’t)

• Inherent slowness
  内在的缓慢
• Not available on app stores (just yet)
  在应用商店上不可用(暂时)
• Still not fully supported by all browsers
  仍然不是所有浏览器都完全支持
• Still lack mobile features like NFC, Ambient Light, Geofencing
  仍然缺乏NFC，Ambient Light，Geofencing等移动功能
• Also lack support for peculiarities of Android or iOS like PiP, smart app banners, launch screen widgets, and 3D touch
  还缺乏对Android或iOS特性的支持，例如画中画，智能应用横幅，启动屏幕小部件和3D触摸

In the video below, I do a brief overview of PWAs.

在下面的视频中，我简要概述了PWA。

混合应用 (Hybrid Apps)

At this level, we begin to dive into the Mobile App world. We’ll start from the most distant tier: Hybrid Apps.

在此级别上，我们开始深入研究移动应用程序世界。 我们将从最遥远的层次开始：混合应用程序。

The term Hybrid is also commonly applied to all cross-platform solutions. Here, however, I’m restricting it to Apps that work inside mobile components, called WebViews.

术语“混合”通常也适用于所有跨平台解决方案。 但是，在这里，我将其限制为可在移动组件(称为WebViews)中运行的Apps。

In the demos in the second video, my purpose for adding WebView as the Hello World example was to make clear that there's a native component for each platform that is able to perform like an actual browser.

在第二个视频的演示中，我添加WebView作为Hello World示例的目的是要弄清楚每个平台都有一个本机组件，能够像实际的浏览器一样运行。

科尔多瓦/ PhoneGap (Cordova/PhoneGap)

Solutions like Cordova/PhoneGap close the gap (sorry for the uninspired pun) between Web and Mobile Apps. They provide tools to package developer's HTML, JavaScript, and CSS code (as well as any extra assets like images or videos) and transform them into Mobile Apps (yes, real Android or iOS apps). These apps have their WebView exclusively to interpret and run the original web code, starting with the “index.html” file in the app’s main folder (normally called “www”). They also bridge the JavaScript code to native APIs through plugins which are partially implemented in JavaScript and partially in a native language.

像Cordova / PhoneGap这样的解决方案弥合了Web和移动应用程序之间的鸿沟(对不起眼的双关语很抱歉)。 它们提供了打包开发人员HTML，JavaScript和CSS代码(以及图像或视频等任何其他资产)并将其转换为移动应用程序(是的，真正的Android或iOS应用程序)的工具。 这些应用程序的WebView专门用于解释和运行原始Web代码，从应用程序主文件夹(通常称为“ www”)中的“ index.html”文件开始。 他们还通过插件将JavaScript代码桥接到本机API，这些插件部分以JavaScript实现，部分以本机语言实现。

So, let's make things clearer. Hybrid Apps are able to access native APIs (instead of Web APIs), but they are enclosed by the WebView. A button with Cordova must be an HTML button rendered by a WebView instead of a mobile native button.

因此，让我们弄清楚点。 混合应用程序能够访问本机API(而不是Web API)，但是它们被WebView封闭。 带Cordova的按钮必须是由WebView呈现HTML按钮，而不是移动本机按钮。

This is the magical tier that allows companies to port their Web Apps to Mobile Apps to be shipped by app stores. So any web framework is allowed here.

这是一个神奇的层，它允许公司将其Web应用程序移植到移动应用程序，以由应用程序商店运送。 因此，此处允许使用任何Web框架。

离子性 (Ionic)

Frameworks like Ionic wrap Cordova into their own solutions. With Ionic, you don't need to use Cordova’s command line interface (CLI), because all of its commands are wrapped by the Ionic CLI.

像Ionic这样的框架将Cordova打包成自己的解决方案。 使用Ionic，您不需要使用Cordova的命令行界面(CLI)，因为其所有命令都由Ionic CLI打包。

Recently, the Ionic team decided to take the reins of the entire stack of Hybrid Apps. So they launched a proposed replacement for Cordova called Capacitor. Capacitor has support for Cordova plugins, and can also be used by a non-Ionic project.

最近，Ionic团队决定掌控整个Hybrid Apps堆栈。 因此，他们推出了拟议的Cordova替代品Capacitor 。 电容器支持Cordova插件，也可以由非离子项目使用。

You can watch me going through a Cordova Hello World sample in the fifth video of the series:

您可以观看我在该系列的第五个视频中浏览Cordova Hello World示例的过程：

混合应用程序的优势 (Hybrid Apps advantages)

• They are essentially web apps that are shippable to official app stores
  它们本质上是可交付给官方应用商店的Web应用
• Can be used along with any JavaScript framework / library
  可以与任何JavaScript框架/库一起使用
• The code is still highly shareable across platforms
  该代码在各个平台之间仍可高度共享
• Access to native features (for instance, camera, accelerometer, contact list)
  访问本机功能(例如，摄像头，加速度计，联系人列表)

混合应用程序的缺点 (Hybrid Apps disadvantages)

• Struggle with performance issues and memory consumption, as web views are responsible for rendering everything on screen
  努力解决性能问题和内存消耗，因为Web视图负责在屏幕上呈现所有内容
• Have to mimic all native UI components on top of a single web view
  必须在单个Web视图顶部模拟所有本机UI组件
• Harder to be accepted and published on App Store
  难以被接受并在App Store上发布
• Usually take longer to have native features available for these environments
  通常需要更长的时间才能在这些环境中使用本机功能

网络原生 (Web Native)

Web Native is a relatively new and often misunderstood tier. That's where Web Apps meet native components. Although Appcelerator (Axway) Titanium has been around a long time, there are some relatively new competitors that justify making this a completely separate category of mobile apps.

Web Native是一个相对较新且经常被误解的层。 这就是Web Apps与本机组件结合的地方。 尽管Appcelerator(Axway)Titanium已有很长的历史了，但还是有一些相对较新的竞争对手证明其是完全独立的移动应用类别。

As you can see above, there's no web view to render and run your application. So, how is your JavaScript executed? Is it compiled? Well, if you consider transpilation (compilation from one language to another — for example TypeScript to JavaScript), bundling, minification, mangling, and obfuscation all together as a compilation, yes JavaScript is compiled.

正如您在上面看到的，没有Web视图可以呈现和运行您的应用程序。 那么，如何执行JavaScript？ 它被编译了吗？ 好吧，如果您考虑将编译(从一种语言编译为另一种语言，例如从TypeScript转换为JavaScript)，捆绑，最小化，修改和混淆等全部作为编译，那么可以编译JavaScript。

But the problem is, this doesn't make your JavaScript something directly understood by Android or iOS operational systems. And, in theory, there's no native component that only serves as a JavaScript engine without the bloat of the HTML layout engine.

但是问题是，这不会使您JavaScript成为Android或iOS操作系统可以直接理解的东西。 而且，从理论上讲，没有本机组件只能充当JavaScript引擎，而不会引起HTML布局引擎的膨胀。

The strategy is to ship JavaScript engines (normally V8 for Android and JavaScriptCore for iOS) along with your code. Although they have small footprints and are very fast, they are something external that must be provided by your app.

该策略是将JavaScript引擎(通常是Android的V8和iOS的JavaScriptCore )与代码一起发布。 尽管它们占用空间小且速度很快，但是它们是应用程序必须提供的外部功能。

On the other hand, this approach tends to have better UI performance, as all the components are the same (or are based on the same thing for React Native, for example) as the ones used by Native Apps.

另一方面，这种方法往往具有更好的UI性能，因为所有组件都与Native Apps使用的组件相同(例如，对于React Native而言，基于相同的事物)。

Web Native Apps的优势 (Web Native Apps advantages)

• Reach both platforms with one single codebase
  只需一个代码库即可同时使用两个平台
• Roughly the same performance as native apps, as they also deal with native UI components
  与本地应用程序大致相同的性能，因为它们还处理本地UI组件
• Tweaks are necessary, but the code is still shareable with web development
  需要进行调整，但是代码仍可与Web开发共享

Web Native Apps的缺点 (Web Native Apps disadvantages)

• Even with one single codebase, the developer must be aware of native components
  即使只有一个代码库，开发人员也必须了解本机组件
• Steeper learning curve than Hybrid / Web Apps for web developers, especially when it comes to layout
  对于Web开发人员来说，混合学习/ Web Apps的学习曲线更陡峭，尤其是在布局方面

React本机 (React Native)

In part 6 of the series, I do a quick Hello World in React Native. This shows, on Android Studio's Layout Inspector, what components were rendered in the emulator. I compare with the previous examples, ensuring that there's no WebView whatsoever.

在本系列的第6部分中，我将在React Native中快速做一个Hello World。 这将在Android Studio的布局检查器上显示在模拟器中渲染了哪些组件。 我将与前面的示例进行比较，以确保没有任何WebView。

原语 (Nativescript)

Another amazing framework that I've been particularly interested in over the last two years (I have a course on Udemy about it — in Portuguese), is Nativescript. It’s similar to React Native but is not tied to the React world (there's an unofficial integration, Nativescript-Preact, though).

在过去两年中，我一直特别感兴趣的另一个惊人的框架( 我的课程是Udemy的葡萄牙语课程 )是Nativescript 。 它类似于React Native，但与React世界无关(尽管有一个非正式的集成，Nativescript-Preact )。

With Nativescript, you can develop using vanilla JavaScript, TypeScript, Angular and, more recently, Vue. Of course you can use other frameworks, but those are the ones officially supported. It’s fairly well documented too, by the way.

使用Nativescript，您可以使用原始JavaScript，TypeScript，Angular以及最近的Vue进行开发。 当然，您可以使用其他框架，但是这些框架是官方支持的框架。 顺便说一下，它的文档也相当好。

Nativescript has tools like Nativescript Sidekick and Nativescript Playground, as well as project structures based on templates that can be provided by the community. This should help you in project creation, giving you the ability to start, deploy, test, and run on simulators on the cloud and iPhone devices even when you are not developing using a Mac.

Nativescript具有诸如Nativescript Sidekick和Nativescript Playground之类的工具，以及基于社区可以提供的模板的项目结构。 这应该可以帮助您创建项目，即使您不使用Mac进行开发，也可以在云和iPhone设备上的模拟器上启动，部署，测试和运行。

In the seventh part of the series, I do a Hello World using Sidekick along with another project started from the CLI and a WhatsApp clone template I created for learning purposes.

在本系列的第七部分中，我将使用Sidekick以及从CLI开始的另一个项目以及为学习目的而创建的WhatsApp克隆模板来使用Hello World。

It's important to have a look at the Layout Inspector when your app is running on an Android emulator. With Nativescript, it shows the native components (again, no WebView), and direct instances of common Android classes like TextView. This is different than React Native, which has its own classes to wrap the native components.

当您的应用程序在Android模拟器上运行时，请务必查看Layout Inspector，这一点很重要。 使用Nativescript，它可以显示本机组件(同样，没有WebView)，以及常见Android类(如TextView)的直接实例。 这不同于React Native，后者有自己的类来包装本机组件。

That's probably why Nativescript claims that there’s no delay between when a new feature is available on iOS and Android and when you can use it in a Nativescript project. For example, they posted on their blog an AR project on the same day iOS 11 was officially released with the new ARKit API.

这可能就是为什么Nativescript声称在iOS和Android上有可用的新功能以及您可以在Nativescript项目中使用它之间没有延迟的原因。 例如， 他们在 iOS 11使用新的ARKit API正式发布的同一天在其博客上发布了一个AR项目。

威克斯 (Weex)

Another framework worth mentioning in this category is Weex. It's a project developed by Alibaba, and is currently incubated at Apache Sofware Foundation (ASF). It uses common HTML tags like <div> and CSS commands inside &lt;style> tags to call native components instead. From their documentation:

此类中值得一提的另一个框架是Weex 。 这是阿里巴巴开发的一个项目，目前在Apache Sofware Foundation(ASF)进行孵化。 它使用常见HTML标签(例如<d iv>和CSS命令nside & lt; style>标签)来调用本机组件。 从他们的文档中：

Although components in Weex look like HTML tags, you are not able to use all of them. Instead, you can only use the built-in components and your custom components.

尽管Weex中的组件看起来像HTML标记，但是您无法使用所有组件。 相反，您只能使用内置组件和自定义组件。

交叉编译 (Cross Compiled)

At this level, it’s time to jump off the Web bandwagon. This is the closest tier to native development, but has the advantage of using one single codebase to target Android and iOS.

在这个级别上，是时候摆脱网络潮流了。 这是最接近本机开发的层，但是具有使用单个代码库定位Android和iOS的优势。

RubyMotion和Xamarin (RubyMotion and Xamarin)

There are solutions like RubyMotion. This is a way to write mobile apps using Ruby and compile directly to the targeted platform (as it was created using any "native" language).

有像RubyMotion这样的解决方案。 这是一种使用Ruby编写移动应用程序并直接编译到目标平台的方法(因为它是使用任何“本机”语言创建的)。

Another option is Xamarin, where you write in C#, compile to an intermediate bytecode, and deploy your app along with an instance of the Mono common language runtime. This approach has the same drawback as Web Native (where V8 and JavaScriptCore are delivered by your app), but can also rely upon JIT compilations to optimize the app at runtime.

另一个选择是Xamarin ，您可以在其中使用C＃编写，编译为中间字节码，然后将应用程序与Mono公共语言运行时实例一起部署。 这种方法与Web Native(由您的应用程序提供V8和JavaScriptCore)具有相同的缺点，但是也可以依赖JIT编译在运行时优化应用程序。

扑 (Flutter)

Last but not least, I'd like to bring up Flutter. It’s Google's newest cool initiative for mobile development. It fits in the Cross Compiled tier because you write apps using the Dart language and compile them down to the native platform.

最后但并非最不重要的一点是，我想提出Flutter 。 这是Google进行移动开发的最新举措。 它适合使用Cross Compiled层，因为您使用Dart语言编写应用程序并将其编译为本机平台。

Flutter has innovated in some aspects. Probably the most outstanding one is the fact that it provides its own set of components.

Flutter在某些方面进行了创新。 可能最杰出的一个事实是它提供了自己的一组组件。

What? Own set of components?

什么？ 自己的组件集？

Yes, Flutter provides a number of different components so you can completely skip the ones from the platform. It has generic components as well as Material Design components for Android, and Cupertino components for iOS.

是的，Flutter提供了许多不同的组件，因此您可以完全从平台上跳过这些组件。 它具有通用组件以及Android的Material Design组件和iOS的Cupertino组件。

Rather than .Net virtual machine (as Xamarin) or JavaScript engines (as Web Native frameworks), with Flutter your app will deliver the components you decide to use.

使用Flutter，您的应用程序将交付您决定使用的组件，而不是.Net虚拟机(如Xamarin)或JavaScript引擎(如Web Native框架)。

Are they native components?

它们是本机组件吗？

Yes, they are. Your app is native, too. Everything is compiled to the native architecture. However, bear in mind they are not the pre-existing native components.

对，他们是。 您的应用也是本地的。 一切都编译为本地体系结构。 但是，请记住，它们不是预先存在的本机组件。

What's the point of that?

这有什么意义呢？

Well, in my opinion, this solution is clever and audacious. I've been waiting to talk about advantages and disadvantages, but as it's just one particular technology, let me address them now.

好吧，在我看来，这种解决方案既聪明又大胆。 我一直在等待谈论优点和缺点，但是由于它只是一种特定的技术，因此让我现在解决它们。

One of the biggest challenges for Web Native and Cross Compiled solutions (remember, above Native but below the WebView in our tiers) is how to deal with native components. For example, an important problem is how to lay them out. That's because they were not created to be used by those external resources. Also, they were not created with a counterpart in the other platform in mind. The Android NavBar doesn't work like iOS UINavBar, for example.

Web本机和交叉编译解决方案(请记住，在我们的层中本机之上但在WebView之下)的最大挑战之一是如何处理本机组件。 例如，一个重要的问题是如何布置它们。 那是因为它们不是为那些外部资源使用而创建的。 同样，它们并不是在考虑其他平台上的对应对象的情况下创建的。 例如，Android NavBar不能像iOS UINavBar那样工作。

With Flutter, components are created with cross-platform always in mind. So let's have a look at the pros and cons of the Cross Compiled Apps tier:

使用Flutter，创建组件时必须始终牢记跨平台。 因此，让我们看一下交叉编译应用程序层的优缺点：

交叉编译应用程序的优势 (Cross Compiled Apps advantages)

• Reach both platforms with one single language
  用一种语言到达两个平台
• Roughly the same performance as native apps, as they also deal with native UI components
  与本地应用程序大致相同的性能，因为它们还处理本地UI组件

交叉编译的应用程序的缺点 (Cross Compiled Apps disadvantages)

• Slightly delayed support for the latest platform updates
  对最新平台更新的支持略有延迟
• Code not shareable with web development
  无法与Web开发共享代码
• Even with one single codebase, the developer must be aware of native components
  即使只有一个代码库，开发人员也必须了解本机组件

PS: With Flutter, you’ll provide your own set of widgets along with your app's code

PS：使用Flutter，您将提供自己的一组小部件以及应用程序的代码

移动应用运行时架构 (Mobile Apps runtime architecture)

As you can see, Cross Compiled solutions can be spread across three of the four different quadrants. In the top-left, you find Native and Cross Compiled (for example RubyMotion), where your app (in green) is compiled to native binaries. It talks directly to OEM Widgets (Original Equipment Manufacturer widgets — what we've been calling native components) as well as the native API.

如您所见，交叉编译解决方案可以分布在四个不同象限的三个象限中。 在左上角，找到“本机和交叉编译”(例如RubyMotion)，其中您的应用程序(绿色)被编译为本机二进制文件。 它直接与OEM窗口小部件(原始设备制造商窗口小部件-我们一直称为本机组件)以及本机API进行通信。

The top-right quadrant is exclusive to Hybrid Apps. Your app is necessarily HTML/CSS/JavaScript executed by the native WebView (as we did in the fifth video of the series). Cordova/PhoneGap or Capacitor can provide a bridge to allow your JavaScript code to talk to native APIs.

右上象限是混合应用程序独有的。 您的应用程序必须是由本机WebView执行HTML / CSS / JavaScript(就像在本系列的第五个视频中所做的那样)。 Cordova / PhoneGap或Capacitor可以提供一个桥梁，以允许您JavaScript代码与本机API对话。

The bottom-left quadrant is where all Web Native solutions, as well as Xamarin, fit in. Your app is not compiled to native code (but rather to a binary stream in Xamarin) and it wraps an interpreter to act as a bridge to everything in the platform.

左下象限是所有Web Native解决方案以及Xamarin都适合的位置。您的应用程序未编译为本地代码(而是Xamarin中的二进制流)，并且包装了解释程序以充当所有内容的桥梁。在平台上。

Finally, at the bottom-right, I could have said Cross Compiled, but it seems very particular to Flutter. It’s different than other Cross Compiled strategies that seem more traditional. In this case, there's no bridge, but there's also no contact to OEM Widgets (at least no need for that).

最后，在右下角，我可以说是Cross Compiled，但对于Flutter来说似乎很特别。 与其他看起来更传统的交叉编译策略不同。 在这种情况下，没有桥梁，但也没有与OEM小部件的联系(至少不需要这样做)。

Notice that Web Apps (even including PWAs) are not in the graph, because they don't touch the native environment at all.

请注意，Web应用程序(甚至包括PWA)不在图中，因为它们根本不涉及本机环境。

In Part 8 of the series, I discuss Cross Compiled Apps and focus on Flutter with a Hello World project.

在本系列的第8部分中，我将讨论Cross Compiled Apps，并通过Hello World项目关注Flutter。

结语 (Wrapping up)

To sum up, I hope it's clear to you that there's no big winner here. It's not easy to spot the idiosyncrasies and points in common for a general classification. My intention was not to present the market share of each strategy or try to find the most productive, pleasant, or reliable way to build mobile apps.

综上所述，我希望您很清楚，这里没有大赢家。 识别一般分类的共同点和特质并不容易。 我的意图不是展示每种策略的市场份额，也不是试图找到构建移动应用程序的最有效，最愉快或最可靠的方法。

My intention was to present an overview of the players, and the approaches they take, so you can choose what best suits your needs.

我的目的是介绍玩家的概况以及他们采取的方法，以便您可以选择最适合自己的需求。

一些提示，以帮助您找到自己的出路 (A few tips to help you find your way)

Please allow me being a bit more opinionated at this point and bring up some questions and answers that hopefully pave your way.

在这一点上，请允许我多一些意见，提出一些问题和答案，希望可以为您铺平道路。

Before we go ahead, guess what? Exactly! I put together another video covering what I'm about to say:

在我们继续之前，您猜怎么着？ 究竟！ 我整理了另一个视频，讲述了我要说的话：

1.我的应用程序是否需要密集的CPU进程？ (1. Does my app need intensive CPU processes?)

If the answer is yes: Native Apps.Remember: the lower you get, the more performant your app tends to be.

如果答案是肯定的 ：Native Apps.Remember：您得到的数值越低，您的应用程序往往性能越好。

Apps that need intensive computation power, for instance Machine Learning (even just running pre-trained models), are good candidates for the Native tier (or, at least, Cross Compiled).

需要大量计算能力的应用程序，例如机器学习(甚至只是运行经过预先训练的模型)，都是本机层(或至少是交叉编译)的不错选择。

If you are thinking about games, you might have heard about the Unreal and Unity game engines. They are the way to go for many gaming companies, and I feel like they kind of fit in the Cross Compiled layer. I decided to leave them off this list just because I'm starting to be concerned about the length of this post. :)

如果您在考虑游戏，您可能已经听说过虚幻和Unity游戏引擎。 对于许多游戏公司来说，它们是必经之路，我觉得它们适合交叉编译层。 I decided to leave them off this list just because I'm starting to be concerned about the length of this post. :)

2. Is my team BIG enough to maintain two codebases? (2. Is my team BIG enough to maintain two codebases?)

If the answer is no: Everything but Native Apps.Remember: the higher you get, the more abstract and platform-independent you are.

If the answer is no : Everything but Native Apps.Remember: the higher you get, the more abstract and platform-independent you are.

That's the biggest thing that pulls people back when considering Native Apps. Generally speaking, two codebases make things costly and hard to evolve. In theory, you don't want to have an app with significantly more features on Android than iOS, or vice-versa.

That's the biggest thing that pulls people back when considering Native Apps. Generally speaking, two codebases make things costly and hard to evolve. In theory, you don't want to have an app with significantly more features on Android than iOS, or vice-versa.

If both items 1 and 2 are relevant to your app, your must nominate which one is crucial. Or, again, consider a middle ground with the Cross Compiled approach.

If both items 1 and 2 are relevant to your app, your must nominate which one is crucial. Or, again, consider a middle ground with the Cross Compiled approach.

3. What does my team do best? (3. What does my team do best?)

If the answer is C#: Xamarin.If the answer is Java: Native (Android).If the answer is Web/Javascript: From Web to Web Native.

If the answer is C# : Xamarin.If the answer is Java : Native (Android).If the answer is Web/Javascript : From Web to Web Native.

It seems obvious but, believe me, I've seen cases where people take it for granted. Except when Apple came up with Objective-C, thus throwing away Steve Job's bet on a PWA-like approach for apps on iPhone, all solutions are built with developers' previous abilities in mind.

It seems obvious but, believe me, I've seen cases where people take it for granted. Except when Apple came up with Objective-C, thus throwing away Steve Job's bet on a PWA-like approach for apps on iPhone, all solutions are built with developers' previous abilities in mind.

4. Where do my users come from? (4. Where do my users come from?)

If the answer is Unknown (or any other than app stores): Progressive Web Apps.Remember: Having to install apps from App Stores is causes extra friction.

If the answer is Unknown (or any other than app stores): Progressive Web Apps.Remember: Having to install apps from App Stores is causes extra friction.

We discussed the Web distribution power over mobile apps in general (every tier below the browser).

We discussed the Web distribution power over mobile apps in general (every tier below the browser).

Mix of approaches (Mix of approaches)

Web technologies allow you to have a mixed codebase, and target not only mobile platforms but also desktops. I know solutions like Electron make it easy to deploy your app to Windows, Mac, or Linux computers. But I’m talking about making a Web App (or even better a PWA) share code with a Mobile App.

Web technologies allow you to have a mixed codebase, and target not only mobile platforms but also desktops. I know solutions like Electron make it easy to deploy your app to Windows, Mac, or Linux computers. But I'm talking about making a Web App (or even better a PWA) share code with a Mobile App.

OK, you might think Cordova does it pretty decently. Well, I agree. Hybrid Apps are Web apps run by a WebView, but I'm still trying to convince you to think out of the box. What if you want a Web App, with HTML templates, that shares code with a Web Native App?

OK, you might think Cordova does it pretty decently. 好吧，我同意。 Hybrid Apps are Web apps run by a WebView, but I'm still trying to convince you to think out of the box. What if you want a Web App, with HTML templates, that shares code with a Web Native App?

Depending on what architectural pattern you use to structure your app, things can be facilitated by reusing the business logic and a lot of boilerplate code, like routing and state management. You just need to define two sets of templates, one for web, another for mobile.

Depending on what architectural pattern you use to structure your app, things can be facilitated by reusing the business logic and a lot of boilerplate code, like routing and state management. You just need to define two sets of templates, one for web, another for mobile.

There are some project seeds to help you to start. For example, with Angular-Native-Seed you start an Angular project that’s ready to deploy on mobile devices. It can be as simple as creating a template file with different extensions:

There are some project seeds to help you to start. For example, with Angular-Native-Seed you start an Angular project that's ready to deploy on mobile devices. It can be as simple as creating a template file with different extensions:

Extension                      | Platform------------------------------ | --------------------------.{html/scss}                   | Recommended for Web.tns.{html/scss}               | Only for mobile.tns.ios.{html/scss}           | Only for iOS.tns.android.{html/scss}       | Only for Android.tns.ios.phone.{html/scss}     | Only for iOS Phone .tns.android.phone.{html/scss} | Only for Android Phone

Just decorate your Angular component with a templateUrl and the right template file will be picked up according to which platform is running.

Just decorate your Angular component with a templateUrl and the right template file will be picked up according to which platform is running.

In the snippet above, my-component.android.html would be automatically picked up when running on Android.

In the snippet above, my-component.android.html would be automatically picked up when running on Android.

Sometimes things are not dead simple. There's a chance that you might have a completely separate component just for one particular platform. But having this managed by your app in a single codebase shouldn't be a big deal.

Sometimes things are not dead simple. There's a chance that you might have a completely separate component just for one particular platform. But having this managed by your app in a single codebase shouldn't be a big deal.

Have a look here and see how to achieve something similar with React (Web) and React Native.

Have a look here and see how to achieve something similar with React (Web) and React Native.

That leads to another question. When should you go Hybrid and when should you go Web Native?

That leads to another question. When should you go Hybrid and when should you go Web Native?

My 10 cents on that is this: if performance and native user experience are what you aim for, simply go Web Native. On the other hand, if keeping the layout consistent across all targets is the big deal, and managing two or more sets of templates and stylesheets sounds overwhelming, just go Hybrid.

My 10 cents on that is this: if performance and native user experience are what you aim for, simply go Web Native. On the other hand, if keeping the layout consistent across all targets is the big deal, and managing two or more sets of templates and stylesheets sounds overwhelming, just go Hybrid.

As you can see, when it comes to mobile development, any of those approaches might work for you. As long as the vendors or maintainers support their products, there’s a good reason to try each one mentioned in this study.

As you can see, when it comes to mobile development, any of those approaches might work for you. As long as the vendors or maintainers support their products, there's a good reason to try each one mentioned in this study.

I hope this has been helpful and that you have enjoyed this journey through many different mobile development solutions and strategies.

I hope this has been helpful and that you have enjoyed this journey through many different mobile development solutions and strategies.

下一步是什么？ (What's next?)

You might have noticed that I didn't add the last video of the series. Ok, there we go:

You might have noticed that I didn't add the last video of the series. Ok, there we go:

This one is all about helping you decide what is the best mobile technology to learn in 2018. If you’re asking what’s the best technology to pick up for your next project, then I’d say it depends. I don’t just want to say "Whatever. Just pick and choose. Wish you all the best". I'd like to provide you with a path for a more efficient learning process, so you can master more than one technology quickly. So check out that last video.

This one is all about helping you decide what is the best mobile technology to learn in 2018. If you're asking what's the best technology to pick up for your next project, then I'd say it depends. I don't just want to say "Whatever. Just pick and choose. Wish you all the best" . I'd like to provide you with a path for a more efficient learning process, so you can master more than one technology quickly. So check out that last video.

There's a convergence happening across mobile platforms and languages are getting more and more similar. Watch this last video, even if you don't code. I present many features from Kotlin, Swift, and TypeScript. In the end, I just want you to realize that they are not that different. Trust me. Have a look at the video and let me know in the comments section. I really look forward to hearing your thoughts on that.

There's a convergence happening across mobile platforms and languages are getting more and more similar. Watch this last video, even if you don't code. I present many features from Kotlin, Swift, and TypeScript. In the end, I just want you to realize that they are not that different. 相信我。 Have a look at the video and let me know in the comments section. I really look forward to hearing your thoughts on that.

Thank you for reading!

感谢您的阅读！

翻译自: https://www.freecodecamp.org/news/a-deeply-detailed-but-never-definitive-guide-to-mobile-development-architecture-6b01ce3b1528/

详尽kmp