为什么在 Web 视图中渲染组件会变慢？
Why is rendering components inside web views slower?
根据关于问题过于宽泛的反馈，我正在缩小问题的范围并保留删除线中的原始问题，以保留下面 Jim 的回答的含义，这非常有用和信息。
这里是问题的更具体版本：
执行渲染图像、文本或 UI 元素或从网络视图容器（Android 的 WebView 和 AJAX 发送网络服务请求）等任务UIWebView/WKWebView for iOS) 比通过其他本机组件做同样的事情效率低。这是为什么？是 web 视图容器本身的初始加载速度慢还是有其他技术原因？我假设最终，在较低的层次上，相同的本机代码正在执行这些功能。为什么使用网络视图会导致性能下降？
人们常说，在 Web 视图中呈现混合移动应用程序比本机应用程序慢。我很好奇对于一个简单的电子商务类型的应用程序来说是否如此，在这种应用程序中，产品数据通常无论如何都是从服务器加载的，并且该应用程序具有简单的用户界面。
具体来说，我感兴趣的是为什么以下内容在 Web 视图组件中会比原生组件慢：
用户界面：如果用户界面是用 HTML5 组件和简单的 JavaScript 开发的，并在应用程序安装时保存在文件系统中，渲染它们会更慢比呈现本机用户界面组件？如果答案是肯定的，我很好奇为什么。为什么按钮在 iOS 应用程序中加载速度更快，但在 iOS 应用程序中嵌入的 Web 视图中加载速度较慢？
图像：如果与 HTML 页面关联的图像存储在本地文件系统中，渲染它们会比与本机应用程序关联的图像慢吗？如果是这种情况，我会感到惊讶，并且真的很想知道原因。
从服务器加载的数据：如果使用 [=53= 从服务器加载的数据（json、XML 等）加载速度会变慢] 与本机应用程序使用的任何方法？从服务器加载的图片呢？我认为网络速度是这里的限制因素，但我可能是错的。
我是否遗漏了一个简单的电子商务应用程序的其他部分，其中本机应用程序比 Web 视图应用程序具有明显的性能优势？
此外，Facebook 和 LinkedIn 从 Web 视图类型应用程序切换到原生应用程序获得的最大优势是什么？在我看来，他们的应用程序具有简单的 UIs（与游戏相比）并且大部分数据在访问时通过网络加载。我错过了什么吗？
最后，原生平台所有者（Apple 和 Google）在故意减慢 web 视图类型的应用程序以推动他们的平台向前发展方面是否有优势？ （我很难相信 Google 会那样做，但你永远不知道 Apple）。
编辑：我的问题可能太长太宽泛。问题的要点是：与其他本机组件相比，在 Web 视图中显示文件系统中的图像或进行 Web 服务调用等简单操作需要更长的时间吗？如果是这样，为什么？
你的问题很宽泛，需要发表意见和猜测。为了尽量减少意见和猜测，我将尝试解决它。并尝试指出 speculative/opinionated 过程中的各个方面。
要使用您的按钮示例，按钮的本机实现不需要加载 WebView 来呈现按钮。它也不需要第二个框架（WebView 框架）来将对象放置在屏幕上。基于 Web 的渲染速度较慢并不奇怪，因为 Web 容器必须完成其确定渲染的工作，然后通过本机框架来实际执行显示。本质上，它是 "two step process" 与 "one step process." 相比，本机实现可以比任何组件更容易地利用硬件级优化。充其量，组件（如 WebView）可以识别本机系统，以类似的方式检测优化并将其对渲染的影响降至最低。但这有很多问题，而且在大多数情况下可能不会发生。
这个答案和第一个问题差不多。渲染图像需要原生框架。除了本机框架之外，其他任何东西（比如 WebView 容器）都会进行自己的处理。充其量，它将是一个 "pass through" 但仍然有负担。也就是说，它会花费更长的时间，即使它不会被用户察觉。
AJAX 在容器中实现（同样，如 WebView）受容器的限制和优化。本机应用程序可以根据开发人员的要求适应特定服务 - 包括使用快捷方式或连接，这些快捷方式或连接在容器中不可用或未针对特定应用程序进行优化。有问题的特定应用程序可能会或可能能够规避或通过更大的优化来实现，但它很可能可以。这忽略了开发人员的便利性（换句话说，您可能更难实现本机应用程序，但这绝对不会使其成为最佳选择）。
要回答您的未编号系列问题，简单的答案是 "yes, native will almost always win over a container"。您可以更好地控制缓存，您可以随时使用非HTML requests/responses，您可以自定义标记数据、自定义加密、自定义压缩等。
UI 也获得了显着的优势，因为您不受限于容器的限制。例如，HTML 渲染有其局限性，根据定义，这些局限性充其量与本机框架相同。在最坏的情况下，本机框架会施加容器必须考虑的额外限制。通常，限制远大于原生框架。在容器中，屏幕元素在大小、行为和交互等方面有更多限制。他们不可能拥有更大的能力——框架不会支持它。 Facebook等的具体原因切换可能与这些核心问题有关，但您可以自行阅读和理解。
最后，Google 或 Apple 的动机并未公开。这里的任何答案都是猜测。也就是说，一个或另一个可能与 Facebook 等公司结盟以试图获得优势。然而，Facebook 不太可能享受这样的结盟。更有可能的是，任何一家公司都在确保其品牌浏览器（Chrome 或 Safari）比通用本机组件具有优势方面具有优势。换句话说，本地组件似乎不太可能比那些公司的品牌产品具有更多的功能和支持，因此这些组件在任何给定时间都可能不是最佳的。虽然这只是猜测，但我希望看到任何证据表明两家公司都热衷于在更大程度上支持这些组件而不是他们的品牌产品。
也就是说，在我看来，与 "free" 品牌产品相比，应用程序开发人员是否有可能为每家公司带来更多收入或增加更多价值。如果是这样，并且他们认可并重视它，那么扭转局面并通过这些组件引领发展，然后将其传递给他们的品牌产品，将符合他们的最大利益。我相信应用程序开发人员比他们的品牌浏览器带来更多价值，但似乎其他因素（如公司政治、产品投资等）并没有使公司成为现实。或许我只是有错误的数据或错误的看法。
编辑：
关于 "native" 与 "webview" 的一个警告 - 在极少数情况下，本机实现在调整图像和本机组件的大小和缩放方面做得很差，理论上，容器可以进行预处理即，当传递给本机框架时，绕过本机框架实现中的次优或其他问题。虽然这是可能的，但在 IMO 看来，这种情况很少见，而且不应作为避免使用本机框架的理由。曾经。
根据关于问题过于宽泛的反馈，我正在缩小问题的范围并保留删除线中的原始问题，以保留下面 Jim 的回答的含义，这非常有用和信息。
这里是问题的更具体版本：
执行渲染图像、文本或 UI 元素或从网络视图容器（Android 的 WebView 和 AJAX 发送网络服务请求）等任务UIWebView/WKWebView for iOS) 比通过其他本机组件做同样的事情效率低。这是为什么？是 web 视图容器本身的初始加载速度慢还是有其他技术原因？我假设最终，在较低的层次上，相同的本机代码正在执行这些功能。为什么使用网络视图会导致性能下降？
人们常说，在 Web 视图中呈现混合移动应用程序比本机应用程序慢。我很好奇对于一个简单的电子商务类型的应用程序来说是否如此，在这种应用程序中，产品数据通常无论如何都是从服务器加载的，并且该应用程序具有简单的用户界面。
具体来说，我感兴趣的是为什么以下内容在 Web 视图组件中会比原生组件慢：
用户界面：如果用户界面是用 HTML5 组件和简单的 JavaScript 开发的，并在应用程序安装时保存在文件系统中，渲染它们会更慢比呈现本机用户界面组件？如果答案是肯定的，我很好奇为什么。为什么按钮在 iOS 应用程序中加载速度更快，但在 iOS 应用程序中嵌入的 Web 视图中加载速度较慢？
图像：如果与 HTML 页面关联的图像存储在本地文件系统中，渲染它们会比与本机应用程序关联的图像慢吗？如果是这种情况，我会感到惊讶，并且真的很想知道原因。
从服务器加载的数据：如果使用 [=53= 从服务器加载的数据（json、XML 等）加载速度会变慢] 与本机应用程序使用的任何方法？从服务器加载的图片呢？我认为网络速度是这里的限制因素，但我可能是错的。
我是否遗漏了一个简单的电子商务应用程序的其他部分，其中本机应用程序比 Web 视图应用程序具有明显的性能优势？
此外，Facebook 和 LinkedIn 从 Web 视图类型应用程序切换到原生应用程序获得的最大优势是什么？在我看来，他们的应用程序具有简单的 UIs（与游戏相比）并且大部分数据在访问时通过网络加载。我错过了什么吗？
最后，原生平台所有者（Apple 和 Google）在故意减慢 web 视图类型的应用程序以推动他们的平台向前发展方面是否有优势？ （我很难相信 Google 会那样做，但你永远不知道 Apple）。
编辑：我的问题可能太长太宽泛。问题的要点是：与其他本机组件相比，在 Web 视图中显示文件系统中的图像或进行 Web 服务调用等简单操作需要更长的时间吗？如果是这样，为什么？
你的问题很宽泛，需要发表意见和猜测。为了尽量减少意见和猜测，我将尝试解决它。并尝试指出 speculative/opinionated 过程中的各个方面。
要使用您的按钮示例，按钮的本机实现不需要加载
WebView来呈现按钮。它也不需要第二个框架（WebView框架）来将对象放置在屏幕上。基于 Web 的渲染速度较慢并不奇怪，因为 Web 容器必须完成其确定渲染的工作，然后通过本机框架来实际执行显示。本质上，它是 "two step process" 与 "one step process." 相比，本机实现可以比任何组件更容易地利用硬件级优化。充其量，组件（如WebView）可以识别本机系统，以类似的方式检测优化并将其对渲染的影响降至最低。但这有很多问题，而且在大多数情况下可能不会发生。这个答案和第一个问题差不多。渲染图像需要原生框架。除了本机框架之外，其他任何东西（比如
WebView容器）都会进行自己的处理。充其量，它将是一个 "pass through" 但仍然有负担。也就是说，它会花费更长的时间，即使它不会被用户察觉。AJAX 在容器中实现（同样，如
WebView）受容器的限制和优化。本机应用程序可以根据开发人员的要求适应特定服务 - 包括使用快捷方式或连接，这些快捷方式或连接在容器中不可用或未针对特定应用程序进行优化。有问题的特定应用程序可能会或可能能够规避或通过更大的优化来实现，但它很可能可以。这忽略了开发人员的便利性（换句话说，您可能更难实现本机应用程序，但这绝对不会使其成为最佳选择）。
要回答您的未编号系列问题，简单的答案是 "yes, native will almost always win over a container"。您可以更好地控制缓存，您可以随时使用非HTML requests/responses，您可以自定义标记数据、自定义加密、自定义压缩等。
UI 也获得了显着的优势，因为您不受限于容器的限制。例如，HTML 渲染有其局限性，根据定义，这些局限性充其量与本机框架相同。在最坏的情况下，本机框架会施加容器必须考虑的额外限制。通常，限制远大于原生框架。在容器中，屏幕元素在大小、行为和交互等方面有更多限制。他们不可能拥有更大的能力——框架不会支持它。 Facebook等的具体原因切换可能与这些核心问题有关，但您可以自行阅读和理解。
最后，Google 或 Apple 的动机并未公开。这里的任何答案都是猜测。也就是说，一个或另一个可能与 Facebook 等公司结盟以试图获得优势。然而，Facebook 不太可能享受这样的结盟。更有可能的是，任何一家公司都在确保其品牌浏览器（Chrome 或 Safari）比通用本机组件具有优势方面具有优势。换句话说，本地组件似乎不太可能比那些公司的品牌产品具有更多的功能和支持，因此这些组件在任何给定时间都可能不是最佳的。虽然这只是猜测，但我希望看到任何证据表明两家公司都热衷于在更大程度上支持这些组件而不是他们的品牌产品。
也就是说，在我看来，与 "free" 品牌产品相比，应用程序开发人员是否有可能为每家公司带来更多收入或增加更多价值。如果是这样，并且他们认可并重视它，那么扭转局面并通过这些组件引领发展，然后将其传递给他们的品牌产品，将符合他们的最大利益。我相信应用程序开发人员比他们的品牌浏览器带来更多价值，但似乎其他因素（如公司政治、产品投资等）并没有使公司成为现实。或许我只是有错误的数据或错误的看法。
编辑：
关于 "native" 与 "webview" 的一个警告 - 在极少数情况下，本机实现在调整图像和本机组件的大小和缩放方面做得很差，理论上，容器可以进行预处理即，当传递给本机框架时，绕过本机框架实现中的次优或其他问题。虽然这是可能的，但在 IMO 看来，这种情况很少见，而且不应作为避免使用本机框架的理由。曾经。