基于对问题过于宽泛的反馈，我正在缩小问题的范围，并将原始问题保留在罢工中以保留下面Jim的答案的含义，这非常有用且信息丰富。 / em>
以下是该问题的更具体版本：
执行诸如渲染图像，文本或UI元素或从Web视图容器（WebView for Android和UIWebView / WKWebView for iOS）内部发送Web服务请求（使用AJAX）等任务的效率低于执行相同的操作通过其他本机组件。这是为什么？ Web视图容器本身的初始加载是否缓慢或是否存在其他技术原因？我认为最终，在较低级别，相同的本机代码正在执行这些功能。为什么使用网络视图会导致性能下降？
通常声称在Web视图中呈现的混合移动应用程序比本机应用程序慢。我很好奇是否适用于简单的电子商务类型应用程序，其中产品数据通常从服务器加载并且应用程序具有简单的用户界面。
具体来说，我感兴趣的是为什么以下网页视图组件与本机组件相比会更慢：
用户界面：如果使用HTML5组件和简单的JavaScript开发用户界面并在应用程序安装时保存在文件系统上，那么渲染它们会比渲染本机用户界面组件慢吗？如果答案是肯定的，我很好奇为什么。为什么iOS应用程序中的按钮加载速度会更快，而iOS应用程序中嵌入的Web视图会更慢？
图像：如果与HTML页面关联的图像存储在本地文件系统中，是否会使它们比与本机应用程序关联的图像慢？如果是这种情况我会感到惊讶，并且真的想知道原因。
从服务器加载的数据：如果使用AJAX加载的数据（json，XML等）加载速度较慢，那么本机应用程序使用的方法是什么？从服务器加载的图像怎么样？我认为网络速度将是这里的限制因素，但我可能是错的。
在本地应用程序比Web视图应用程序具有明显的性能优势的情况下，我是否缺少简单电子商务应用程序的其他部分？
此外，Facebook和LinkedIn通过从Web视图类型应用程序切换到本机获得的巨大优势是什么？我看到它的方式，他们的应用程序具有简单的UI（与游戏相比），并且大多数数据在访问时通过网络加载。我错过了什么吗？
最后，原生平台所有者（Apple和Google）是否有利于有意减慢Web视图类型应用程序以推动其平台向前发展？ （我很难相信谷歌会这样做，但你永远不会知道苹果）。
编辑：我的问题可能太长而且广泛。问题的关键在于：与其他本机组件相比，在Web视图中显示文件系统中的图像或进行Web服务调用等简单操作需要更长的时间吗？如果是这样，为什么？
答案 0 :(得分：2)
您的问题非常广泛，受到意见和猜测的影响。为了尽量减少意见和猜测，我将尝试解决它。并且还试图指出沿途的投机/舆论方面。
要使用按钮示例，按钮的本机实现不需要加载WebView以呈现按钮。它也不需要第二个框架（WebView框架）来在屏幕上放置对象。基于Web的渲染速度较慢也不足为奇，因为Web容器必须完成确定渲染的工作，然后通过本机框架来实际执行显示。从本质上讲，它是一个＆＃34;两步过程＆＃34;与一步过程相比。＆＃34;本机实现可以比任何组件更容易地利用硬件级优化。最好的情况是，组件（如WebView）可以识别本机系统，以类似的方式检测优化并最大限度地减少它对渲染的影响。但这有很多问题，而且在大多数情况下可能不会发生。
答案与第一个问题类似。渲染图像需要本机框架。除了原生框架之外，其他任何东西（如WebView容器）都会自己处理。充其量，它将是一个＆＃34;通过＆＃34;但仍然有这样的负担。也就是说，即使用户无法察觉，也需要更长的时间。
在容器中实现的AJAX（再次像WebView一样）受容器的限制和优化的约束。本机应用程序可以根据开发人员适应特定服务 - 包括使用通过容器不可用的快捷方式或连接，或者不针对特定应用程序进行优化。所讨论的特定应用可能或可能能够通过更大的优化来规避或实施，但它可能是可能的。开发人员的便利性在此被忽略（换句话说，实现本机应用程序可能更难，但这绝对不能使其最佳化。）
要回答您的非编号系列问题，简单的答案是＆＃34;是的，本机将几乎总是赢得一个容器＆＃34;。您可以更好地控制缓存，您可以随时使用非HTML请求/响应，您可以自定义标记数据，自定义加密，自定义压缩等。
UI也具有显着的优势，因为您不仅限于容器的限制。例如，HTML呈现有其局限性，根据定义，它们最多与本机框架相同。在最坏的情况下，本机框架会产生容器必须考虑的额外限制。通常，限制远远大于本机框架的限制。在容器中，屏幕元素对大小调整，行为和交互有更多限制，仅举几例。他们不可能拥有更大的能力 - 框架不会支持它。 Facebook等转换的具体原因可能与这些核心问题有关，但您可以自己阅读和解释。
最后，Google或Apple的动机并未公开。这里的任何答案都是猜测。也就是说，有可能一个或另一个与Facebook等公司保持一致，试图获得优势。然而，Facebook不太可能享受这种一致性。这两家公司更有可能确保其品牌浏览器（Chrome或Safari）优于通用原生组件。换句话说，本机组件似乎不太可能具有比那些公司更多的功能和支持。品牌产品，因此这些组件在任何给定时间都可能不是最佳的。虽然这是猜测，但我希望看到任何证据表明两家公司都希望在更大程度上支持这些组件而不是品牌产品。
也就是说，在我看来，应用程序开发人员可能会为每个公司带来更多收入或增加更多价值，而不是他们的＆＃34;免费＆＃34;品牌产品。如果是这种情况，并且他们认识并重视它，那么通过这些组件扭转局面并引导开发符合他们的最佳利益，然后将其传递给他们的品牌产品。我相信应用程序开发人员比其品牌浏览器带来更多价值，但似乎其他因素（如公司政治，产品投资等）并未使这些公司成为现实。或许我只是有不好的数据或错误的看法。
编辑：
关于＆＃34;本地人＆＃34; vs.＆＃34; webview＆＃34; - 在极少数情况下，本机实现在调整和扩展图像和本机组件方面做得很差，理论上，容器可以进行预处理，当传递给本机框架时，可以绕过次优或其他问题。本机框架实现。虽然这是可能的，但IMO很少见，而且不应该依赖它作为避免本机框架的理由。如初。