为什么在Web视图中渲染组件速度较慢？
根据对这个问题过于宽泛的反馈，我正在缩小这个问题的范围，并将原始问题保留在结论中，以保留下面Jim的答案的含义，这是非常有用的和内容丰富的。
这是一个更具体的问题版本：
执行诸如渲染图像，文本或UI元素或从web视图容器（用于Android的WebView和iOS的UIWebView / WKWebView）发送web服务请求（使用AJAX）的任务比通过其他本地组件。 这是为什么？ Web视图容器本身的初始加载是缓慢还是有其他技术原因？ 我认为最终，在较低的层次上，相同的本地代码正在执行这些function。 为什么使用Web视图时会有性能损失？
人们经常指出，在Web视图中呈现的混合移动应用程序比原生应用程序慢。 我很好奇，对于一个简单的电子商务types的应用程序来说，无论如何通常从服务器加载产品数据并且应用程序具有简单的用户界面。
具体来说，我感兴趣的是为什么在Web视图组件中比起native来说下面的东西会慢一些：
-
用户界面：如果用户界面是使用HTML5组件和简单的JavaScript开发的，并且在应用程序安装时保存在文件系统上，那么呈现它们会比呈现本地用户界面组件慢吗？ 如果答案是肯定的，我很好奇为什么。 为什么在iOS应用程序中加载button的速度会更快，但是iOS应用程序中embedded的Web视图的加载速度会更慢？
-
图像：如果与HTML页面相关的图像存储在本地文件系统中，渲染它们会比与本机应用程序相关的图像慢吗？ 如果是这样，我会很惊讶，真的想知道原因。
-
从服务器加载的数据：从服务器加载的数据（json，XML等）如果加载使用AJAX与本机应用程序使用的任何方法加载速度较慢？ 怎么样从服务器加载的图像？ 我想networking速度会成为限制因素，但我可能是错的。
是否有一个简单的电子商务应用程序的其他部分，我失去了一个本地应用程序将有一个清晰的性能优势比Web视图应用程序？
此外，Facebook和LinkedIn从网页浏览型应用程序切换到本地网站所获得的巨大优势是什么？ 我看到它的方式，他们的应用程序具有简单的用户界面（与游戏相比），大多数数据在访问时通过networking加载。 我错过了什么吗？
最后，本地平台所有者（苹果和谷歌）是否有利于有意拖慢Web视图types应用程序，推动其平台向前发展？ （我很难相信谷歌会这样做，但是你永远不知道苹果）。
编辑：我的问题可能太长和广泛。 问题的要点是：做一些简单的事情，比如从文件系统中显示一个图像，或者在Web视图中花费更长的时间比使用另一个本地组件更长时间？ 如果是这样，为什么？
你的问题是非常广泛的，并受到意见和猜测。 为尽量减less意见和猜测，我会尽力解决这个问题。 同时也试图指出一路上的投机/自信的方面。
-
要使用button示例，button的本地实现不需要加载
WebView以呈现button。 它也不需要第二个框架（WebView框架），以便在屏幕上放置对象。 基于Web的渲染速度较慢是不足为奇的，因为Web容器必须执行确定渲染的任务，然后通过本机框架来实际执行显示。 从本质上讲，与“一步到位”相比，这是一个“两步走”的过程。 本机实现可以比任何组件都更容易利用硬件级别的优化。 充其量，组件（如WebView）可以识别本机系统，以类似的方式检测优化并将其对渲染的影响降至最低。 但是这个问题很多，在大多数情况下可能不会发生。 -
答案与第一个问题类似。 渲染图像需要本地框架。 除了原生框架以外，其他任何东西（比如
WebView容器）都会自己处理。 充其量，这将是一个“通过”，但仍然有这个负担。 也就是说，即使用户无法察觉，也需要更长的时间。 -
在容器中实现的AJAX（
WebView）受限于容器的限制和优化。 本地应用程序可以根据开发人员适应特定服务 – 包括使用快捷方式或通过容器不可用的连接，或不针对特定应用程序进行优化。 有问题的特定应用程序可能或可能能够绕过或实施更大的优化，但很可能是这样。 开发人员的便利性在这个方面是被忽视的（换句话说，实现本地应用程序可能会更困难，但这绝对不会使其达到最佳状态）。
为了回答你的一系列问题，简单的答案是“是的，本地人几乎总是会胜过一个容器”。 您可以更好地控制caching，只要您喜欢就可以使用非HTML请求/响应，您可以自定义标记数据，自定义encryption，自定义压缩等。
用户界面也获得了显着的优势，因为您不限于容器的限制。 例如，HTML渲染有其局限性，根据定义，最好与本机框架相同。 在最坏的情况下，本地框架强加了容器必须考虑的额外限制。 通常，这个限制远远大于原生框架的限制。 在容器中，屏幕元素在大小，行为和交互方面有更多的限制，仅举几例。 他们不可能有更强的能力 – 框架不会支持它。 Facebook等切换的具体原因可能与这些核心问题有关，但是您可以自行阅读和理解。
最后，谷歌或苹果的动机不公开。 这里的任何答案都是猜测。 也就是说，这个或那个可能与Facebook这样的公司一致，试图获得优势。 然而，Facebook不太可能享受这样的协调。 任何一家公司在确保其品牌浏览器（Chrome或Safari）相对于通用本机组件都具有优势的情况下更有可能获得优势。 换句话说，本地组件似乎不太可能具有比那些公司的品牌产品更多的function和支持，因此这些组件在任何时候都可能是非最优的。 虽然这是猜测，但我希望看到任何证据表明任何一家公司都热衷于支持这些组件比他们的品牌产品更大的程度。
也就是说，在我看来，应用程序开发者有可能为每个公司带来更多的收入或增加更多的价值，而不是他们的“免费”品牌产品。 如果是这样，他们认识到并重视，那么扭转局面，通过这些组成部分来引导发展，然后把它们传递给他们的品牌产品将是最有利的。 我认为应用程序开发人员比其品牌浏览器带来更多的价值，但似乎其他因素（如企业政策，产品投资等）并没有使这些公司成为现实。 或者，也许我只是有不好的数据或误导的看法。
编辑：
关于“本地”与“networking视图”的一个警告 – 在本机实现大小和缩放图像和本地组件的情况下，容器可能在理论上做预处理，当传递到本机框架时，在本地框架实现中的旁路次优或其他问题。 虽然这是可能的，但是IMO并不罕见，也不应该依赖作为避免本地框架的理由。 永远。