Why is rendering components inside web views slower? [closed]

问题

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

Based on feedback regarding the question being too broad, I am narrowing the scope of the question and keeping the original question in strike-through to preserve the meaning of Jim's answer below, which is extremely useful and informative.

Here is a more specific version of the question:

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?

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.

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

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?

2. 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.

3. 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.

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?

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?

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).

Edit: 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?

回答1:

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. 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.

2. 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.

3. 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).

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.

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.

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.

EDIT:

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.

来源：https://stackoverflow.com/questions/28788850/why-is-rendering-components-inside-web-views-slower