Android有更好的webview吗？谷歌自己的文件提到不要依赖webview对象。
但是对于使用webkit而言，与具有类似硬件的移动设备上使用的其他webkit浏览器相比，它是如此有限似乎很奇怪。
这在jquery移动实现或web应用程序的类似sencha触摸实现中很明显。 Android版本会遇到速度下降，渲染问题以及糟糕的用户体验，其他移动设备（如iphone）也可以正常运行。他们都使用webkit。在应用程序之外，实际的Android浏览器运行得很好。
有没有办法在较低级别上真正解决android的问题？有人为Android制作了更全面的Web对象吗？
感谢您的任何见解
答案 0 :(得分：14)
CQM，
了解我同意Commonswares以及所提供答案中陈述的几乎所有内容。然而，这个问题似乎意味着你有一个问题（无论是理解还是构思），并希望找到/开发更适合您需求的解决方案。
解决问题以及您可能会收到的回复：
我认为Commonswares 有效批评的原因是你没有声明 为什么 或 如何 提供的平台对象不能令人满意，您也不相信 为什么 或 谷歌已经说过这个对象是不可靠的。如果您想获得更好的反馈，请适当地编辑您的问题以便进行沟通，这样您就会遇到更少的问题。
此外，正如下面进一步解释的那样，你暗示这是Android平台的一个问题（事实上，几乎直接说明它）而事实并非如此。在广泛的Web浏览范围内有太多的考虑因素可以通过简单的控件（如WebView）完全解决。微软在90年代遇到了与嵌入式IE COM对象相同的问题。这是一个不属于任何一个群体的大问题。
解决隐含的问题：
WebView对象基本上是一个迷你浏览器，它使用基于与专用浏览器完全不同的参数的高度灵活的渲染代码。这包括从简单渲染到甚至可交互（sp？）对象的所有内容，例如此类页面将使用的链接。这个过程很难（因为没有更好的词）以这样的方式小型化，即能够均匀地嵌入到每次都可能具有不同布局结构和参数的各种应用中。哎呀，即使使用专用的浏览引擎，这样的引擎也难以统一编程，导致当前主流浏览器之间存在很多差异。
因此，WebView并不意味着提供专用浏览器的全部功能，而是在应用程序中显示Web交付内容的最有用方面，这些内容经常执行其他操作。当您考虑添加从所述内容提供的Javascript功能或基于客户端的处理的安全隐患时尤其如此。除此之外，每个设备都有可能拥有不同的渲染引擎或相同渲染引擎的不同版本，这与不同设备使用SQLite具有不同功能的方式非常相似（即外键支持）。
因此，WebView作为显示Web交付内容的解决方案提供，而不保证其可扩展性或可用性，除非您使用纯粹来查看（并且可能）反应）可信和符合标准的HTML代码。一旦你进入现实世界网站的实际实践，你就会意识到HTML的制作是如此灵活，因为每个标准都由不同的开发人员在不同的层面上加入。由于HTML的主要信条是它可以工作（显示内容），尽管存在潜在的模糊性，开发一个完全全面的应用程序嵌入式面向对象解决方案的问题变得更难开发。
...其他移动设备 - 如iphone - 将运行良好
这取决于内容。此外，Apple设备的开发理念与Android完全不同。 Apple只有少数设备，因此可以保证设备的一致性，并选择添加其他功能的时间和时间。例如，第一部iPhone没有Flash的原生支持。基于你的问题的含义，我认为这不会导致＆＃34;全面的＆＃34;测试
相比之下，Android拥有更广泛的设备。 Android的代码由这些设备的制造商调整和更改，以允许他们为其特定的设备需求提供更适当的可支持解决方案。 Google无法保证任何指定设备都能以任何方式保留其任何或所有代码。这造成了进一步的限制，但创造了其他非常棒的自由。......他们都使用webkit。
Chrome和Safari都使用webkit。许多开发人员一直受到他们以不同方式利用它的方式的微小差异的困扰。
...在应用程序之外，实际的Android浏览器运行得很好。
上面已经解决了这个问题。
有没有办法在较低的级别上真正解决android的问题？
同样，这不是 android＆＃39> 问题。如果您对当前实现存在特定问题，则可以自由编写单独的解决方案。此外，使Web内容在浏览器中查看并提供。最佳实践是定义您需要具体执行的操作。您是否需要WebView查看任何网页？或者只是你的？它目前的渲染有什么问题？您需要客户端脚本吗？
每个工具都考虑到特定需求。对于所谓的“更好”而言，情况更是如此。列表视图。这些观点是为了满足不止一个开发人员可能需要的特定需求。在编程领域（尤其是OOP），实际上很少有全面的东西。如果有的话，我们不必首先扩展我们的对象。在查看这样的工具时，请考虑它特别需要解决的问题。
是否有人为Android制作了更全面的网络对象？
是。它们通常显示在您可以下载到设备的其他专用浏览器中。至于他们是否可以访问：个人而言，我不知道，也不倾向于看。
最终声明
您提出的问题实际上不够具体，无法提供真正的解决方案。由于选择不好，它似乎也采取了对立的立场。如果您的问题未通过CommonsWare的回答或我自己的问题解决，请考虑编辑您的问题以添加我们更具体的需求。也就是说，我希望我们的答案能够为您提供一些见解。
希望这有帮助，
FuzzicalLogic
答案 1 :(得分：7)
我担心这两个答案（Commonsware和Fuzzical Logic）都在逃避现实。
我们为iOS，Android和Windows Phone开发HTML5网络应用程序和后来的PhoneGap应用程序（使用Web视图混合）的两年经验的现实是：
在iOS（Safari和WebView）上运行良好，在Android上的Chrome，Windows 8和IE WebView上的IE都很合理（都有问题，但可以解决）但仍然是在Android WebView中的噩梦即可。
在更新到KitKat并使用Chromium替换它之后，Android中的 WebView已被破坏且仍然存在。它只是在正常的HTML5上崩溃（甚至没有遇到Javascript问题）。你会发现很多的人在网上观察类似的事情。
像“Flash支持”这样的事情与此无关 - Flash不是HTML5。制造商是否想要支持某个插件（或者，在这种情况下，整个中间件）取决于他。我总是理解Apple的决定，而在WebView中它确实更不合理。
所以，问题是Android / Google问题，就像这个平台的支持者想要否认它一样。当然，对于一家总是“开放”的公司来说，尤其令人尴尬的是，经过这么多年后，它无法提供有效的HTML5浏览器组件。
但是你的问题是，如果还有其他人的其他WebView：
好吧，我们很想听到一个。对不起，到目前为止我们也找不到一个，原因可能与上面帖子中提到的完全相同：实现它非常困难，并且它将取决于硬件（硬件加速等）。然而，由于Chrome现在起作用至少是合理的（经过这么多年......）我想知道Chromium WebView中缺乏类似质量是否是谷歌的故意，试图阻止人们制作出色的网络应用程序或混合应用程序。 （与微软正在做的相反。）
答案 2 :(得分：1)
我很惊讶没人提到CocoonJS。
它重新实现了标准的WebView（Webview +）;一个打包的Webview，因此您的应用程序将跨设备一致运行（尽管仅限于Android 4+和iOS 8+）。
还有一个名为Canvas + for WebGL的环境，但它与WebView +完全分开。这意味着您需要在Canvas +上叠加WebView +以同时显示DOM和画布。它们不共享相同的JS环境，但是有一个消息传递系统用于在两者之间发送消息。
由于操作系统支持有限，CocoonJS似乎不是一个好的生产级解决方案，但未来可能也会如此。
还有Crosswalk。它适用于Android 4+和Tizen。
答案 3 :(得分：0)
这是非常接近一个偏离主题的，发送你的咆哮 - 其他地方 - 请点“问题”。
Android有更好的webview吗？
如果“webview”是指可嵌入的Web渲染引擎，可能不是，因为编写此类引擎 hard 。您可以看到一个是否可用作Firefox Mobile的分支。或者，欢迎您使用AOSP版本作为起点，将自己的WebKit端口设置为Android。请注意，两者都可能会大幅增加应用的大小。
Google自己的文档提到不要依赖webview对象。
请引用。
是否有人为Android制作了更全面的网络对象？
这取决于一个人对“更全面的网络对象”的定义。值得注意的是，您忽略了为此短语提供任何类型的定义。