为什么在Web视图中渲染组件的速度变慢? [英] Why is rendering components inside web views slower?

问题描述

基于有关该问题过于广泛的反馈，我正在缩小问题的范围，并将原始问题保留在删除线中，以保留以下Jim答案的含义，这非常有用且有益.

以下是该问题的更具体版本:

Here is a more specific version of the question:

从Web视图容器(Android的WebView和iOS的UIWebView/WKWebView)内部执行渲染图像，文本或UI元素或发送Web服务请求(使用AJAX)之类的任务，效率不如同一件事通过其他本机组件.这是为什么? Web视图容器本身的初始加载是否缓慢或是否有其他技术原因?我会假设，最终，在较低级别上，相同的本机代码正在执行这些功能.为什么使用网络视图会导致性能下降?

Performing tasks such as rendering an image, text or UI elements or sending a web service request (using AJAX) from inside a web view container (WebView for Android and UIWebView/WKWebView for iOS) is less efficient than doing the same thing through other native components. Why is that? Is the initial loading of the web view container itself that is slow or are there other technical reasons? I would assume that eventually, at a lower level, the same native code is performing these functions. Why are there performance penalties associated with using a web view?

经常有人说，在Web视图中呈现的混合移动应用程序比本机应用程序慢.我很好奇这是否适用于简单的电子商务类型的应用程序，该应用程序通常无论如何都从服务器加载产品数据，并且该应用程序具有简单的用户界面.

It is often stated that hybrid mobile applications rendering in web views are slower than native apps. I am curious whether that is true for a simple e-commerce type app where product data is normally loaded from the server anyway and the app has a simple user interface.

特别是，我感兴趣的是为什么Web视图组件中的以下内容比本机中的以下内容要慢:

Specifically, I am interested in why the following would be slower in a web view component vs. native:

1. 用户界面:如果用户界面是使用HTML5组件和简单的JavaScript开发的，并且在应用安装时保存在文件系统上，那么渲染它们会比呈现本机用户界面组件慢吗?如果答案是肯定的，我会对原因感到好奇.为什么按钮在iOS应用程序中加载得更快，但在iOS应用程序中嵌入的Web视图中加载得慢?

1. User interface: If the user interface is developed with HTML5 components and simple JavaScript and saved on the file system at the app installation time, would rendering them be slower than rendering native user interface components? If the answer is yes, I am curious as to why. Why would a button load faster in an iOS app but slower in a web view embedded in an iOS app?

图像:如果与HTML页面关联的图像存储在本地文件系统中，渲染它们会比与本机应用程序关联的图像慢吗?如果是这种情况，我会感到惊讶，并且真的想知道原因.

Images: If images associated with an HTML page are stored in the local file system, would rendering them be slower than images associated with a native app? I would be surprised if this is the case and would really want to know the reason.

从服务器加载的数据:从服务器加载的数据(json，XML等)与使用本机应用程序使用的任何方法相比，如果使用AJAX加载，其加载速度会更慢吗?从服务器加载的图像呢?我认为网络速度将是这里的限制因素，但我可能是错的.

Data loaded from the server: Would data (json, XML, etc.) loaded from the server load slower if it is being loaded using AJAX versus whatever method the native app uses? What about images loaded from the server? I would think that the network speed would be the limiting factor here, but I could be wrong.

我是否缺少简单的电子商务应用程序的其他部分，其中本机应用程序比Web视图应用程序具有明显的性能优势?

Are there other parts of a simple e-commerce application that I am missing where a native app would have a clear performance advantage over a web view app?

此外，通过从Web视图类型的应用程序转换为本地应用程序，Facebook和LinkedIn获得了哪些最大的优势?以我的看法，他们的应用程序具有简单的UI(与游戏相比)，并且大多数数据是在访问时通过网络加载的.我想念什么吗?

Also, what were the big advantages Facebook and LinkedIn gained by switching from web view type applications to native? The way I see it, their applications have simple UIs (compared to games) and most of the data is loaded over the network at access time. Am I missing something?

最后，本机平台所有者(Apple和Google)在故意放慢Web视图类型应用程序以推动其平台前进方面是否具有优势? (我很难相信Google会做到这一点，但您对Apple却一无所知).

Finally, do the native platform owners (Apple and Google) have an advantage in purposely slowing down web view type applications to push their platforms forward? (It's hard for me to believe Google would do that, but you never know with Apple).

我的问题可能太长太宽泛.问题的要旨是:与其他本地组件相比，诸如显示文件系统中的图像或进行Web服务调用之类的简单事情在Web视图中花费的时间更长吗?如果是这样，为什么?

My question may be too long and broad. The gist of the question is this: Do simple things like displaying an image from the file system or making a web service call take longer inside a web view compared to another native component? If so, why?

推荐答案

您的问题范围很广，可能会引起舆论和猜测.为了尽量减少意见和猜测，我将尝试解决它.并且还尝试指出在此过程中的投机/专制方面.

Your question is very broad, and subject to opinion and speculation. In attempt to minimize opinion and speculation, I will try to address it. And also try to point out the speculative/opinionated aspects along the way.

1. 要使用您的按钮示例，按钮的本机实现不需要加载WebView即可呈现按钮.它还不需要第二个框架(WebView框架)就可以在屏幕上放置对象.基于Web的渲染速度较慢也就不足为奇了，因为Web容器必须完成确定渲染然后通过本机框架实际执行显示的工作.本质上，与一步过程"相比，这是一个两步过程".本机实现可以比任何组件更轻松地利用硬件级优化.充其量，该组件(如WebView)可以识别本机系统，以类似的方式检测优化，并将其对渲染的影响降至最低.但这是一个很大的问题，在大多数情况下可能不会发生.

1. To use your button example, a native implementation of a button does not require loading a WebView in order to render the button. It also does not require a second framework (the WebView framework) in order to place objects on the screen. It should not be surprising that a web-based rendering is slower because the web container has to do it's job of determining rendering and then go through the native framework to actually perform the display. Essentially, it's a "two step process" compared to a "one step process." Native implementations can take advantage of hardware level optimizations far more easily than any component can. At best, the component (like a WebView) can recognize the native system, detect optimizations in a similar manner and minimize it's impact on rendering. But that's a lot to ask and probably does not happen in most cases.

对此的答案类似于第一个问题.渲染图像需要本机框架.除本机框架外，其他任何事情(如WebView容器)也将由它自己处理.充其量，这将是一次通行证"，但仍然有重担.也就是说，即使用户无法感知，也会花费更长的时间.

The answer to this is similar to the first question. Rendering an image requires the native framework. Anything else (like a WebView container) will do it's own processing in addition to the native framework. At best, it will be a "pass through" but still have the burden of being just that. That is, it will take longer, even if it not perceptible by the user.

AJAX受该容器的限制和优化的约束.根据开发人员的要求，本机应用程序可以适应特定的服务-包括使用无法通过容器获得或未针对特定应用程序进行优化的快捷方式或连接.所讨论的特定应用程序可能会或可能能够绕过或通过更大的优化来实现，但很可能是这样.在这方面，开发人员的便利性被忽略了(换句话说，对您而言，实施本机应用程序可能会比较困难，但这绝对不能使其达到最佳状态.)

AJAX that is implemented in a container (again, like a WebView) is subject to that container's limitations and optimization. A native application can adapt to a particular service according to the developer - including using shortcuts or connections not available through a container or not optimized for the particular application. The particular application in question may or may be able to circumvent or be implemented with greater optimization, but it's likely that it can be. The convenience of a developer is disregarded in this (in other words, it might be harder on your to implement a native app, but that definitely does not make it optimal).

要回答您未编号的一系列问题，简单的答案是是的，本地人几乎总是会赢得一个容器".您可以更好地控制缓存，可以随时使用非HTML请求/响应，还可以自定义标签数据，自定义加密，自定义压缩等.

To answer your non-numbered series of questions, the simple answer is "yes, native will almost always win over a container". You have better control over caching, you can use non-HTML requests/responses whenever you like, you can custom tag data, custom encrypt, custom compress, etc.

由于您不仅限于容器的限制，因此UI也获得了显着的优势.例如，HTML渲染有其局限性，根据定义，它最多与本机框架相同.最糟糕的是，本机框架施加了容器必须考虑的其他限制.通常，限制远大于本机框架的限制.在容器中，屏幕元素在大小，行为和交互方面有更多限制，仅举几例.他们不可能拥有更大的功能-该框架将不支持它. Facebook等转换的具体原因可能与这些核心问题有关，但是您可以自己阅读和解释.

The UI also gains significant advantages because you are not limited to the restrictions of a container. For example, HTML rendering has its limitations, which by definition are, at best, the same as the native framework. At worst, the native framework imposes additional limitations that the container must account for. Usually, the limitations are far greater than those of the native framework. In a container, screen elements have more restrictions on sizing, behavior and interaction, to name a few. It is impossible for them to have greater capabilites - the framework would not support it. The specific reasons for Facebook, etc. switching probably have to do with these core issues, but you can read and interpret that on your own.

最后，Google或Apple的动机尚未公开.这里的任何答案都是猜测.也就是说，一个或另一个可能与Facebook等公司结盟，以试图获得优势.但是，Facebook不太可能会享受这种统一.两家公司都更有可能在确保其品牌浏览器(Chrome或Safari)比通用本机组件方面更具优势.换句话说，与这些公司的品牌产品相比，本机组件似乎不太可能具有更多的功能和支持，因此这些组件在任何给定时间都可能不是最佳的.尽管这只是猜测，但我想看到任何证据表明，两家公司都比其品牌产品更热衷于支持这些组件.

Last, the motives of Google or Apple are not publicly known. Any answer here is speculation. That said, it is possible that one or another is aligned with companies like Facebook to try to gain an advantage. It is unlikely, however, that Facebook would enjoy such an alignment. It is more likely that either company has an advantage in assuring that their branded browser (Chrome or Safari) has an advantage over generic native components. In other words, it seems very unlikely that native components will have more features and support than those companies' branded products, and therefore those components are likely to be non-optimal at any given time. While that is speculation, I would like to see any evidence that either company is keen on supporting those components to a greater extent than their branded products.

也就是说，在我看来，与免费"品牌产品相比，应用程序开发人员有可能为每家公司带来更多的收入或增加更多的价值.如果是这样，并且他们认可并重视它，那么对他们来说，扭转局面并通过这些组件领导开发，然后将其传递给他们的品牌产品，将是他们的最大利益.我相信应用开发人员会比其品牌的浏览器带来更多的价值，但是似乎其他因素(例如公司政策，产品投资等)并未使公司实现这一目标.也许我只是数据不好或误导了.

That said, it seems to me that is it is possible that app developers bring in more revenue or add more value to each company than their "free" branded products. If that is the case, and they recognize and value it, then it would be in their best interest to reverse the situation and lead development through those components, then pass that to their branded products. I believe app developers bring more value than their branded browsers, but it seems that other factors (such as corporate politics, product investment, etc.) do not make this a reality for the companies. Or perhaps I simply have bad data or a misguided perception.

关于本机"与"Webview"的一个警告-在极少数情况下，本机实现在调整图像和本机组件的大小和缩放方面做得不好，容器在理论上可以进行预处理，然后传递给本机框架，绕过次优或本机框架实现中的其他问题.尽管这是可能的，但IMO却很少见，不是避免使用本机框架的理由而不应依靠的东西.曾经.

One caveat about "native" vs. "webview" - in the rare case that a native implementation does a poor job of sizing and scaling images and native components, a container could, theoretically, do preprocessing that, when passed to the native framework, by-pass sub-optimal or other problems in the native framework implementation. While this is possible, IMO it would be rare and not something that should be relied upon as a reason to avoid native frameworks. Ever.

这篇关于为什么在Web视图中渲染组件的速度变慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！