有没有更好的Android WebView？谷歌自己的文档提到不要依赖WebView对象。
但是对于使用webkit，与其他使用类似硬件的移动设备上使用的webkit浏览器相比，它似乎非常有限。
这在jquery mobile实现中很明显，或者类似于sencha touch实现的Web应用程序中也是如此。 Android版本遇到了减速、渲染问题和劣质用户体验，而其他移动设备——例如iPhone——则可以良好运行。它们都使用webkit。而在应用程序之外，实际的Android浏览器运行得非常好。
有没有一种方法可以从更低的层面真正解决Android的问题？是否有人为Android制作了更全面的Web对象？
感谢任何见解。
CQM，
我知道你同意 Commonswares 提供的回答中所述的几乎所有内容。然而，问题似乎暗示你有一个问题（可能是在理解或概念上），并希望找到/开发更适合你需求的解决方案。
回答这个问题和你可能会收到的回复：
我认为 Commonswares 的有效批评是因为你没有说明提供的平台对象不令人满意的原因或如何，也没有说明你为什么或何时认为 Google 说过该对象不可靠。如果你想要更好的反馈，请适当编辑你的问题以传达这一点，那么在这里就会遇到更少的问题。
此外，在下面的进一步说明中，你暗示这是 Android 平台的问题（事实上，几乎直接陈述了这一点），但事实并非如此。在广泛的网络浏览范围内，有太多的考虑因素无法通过一个简单的控件（如 WebView）完全解决。90年代时，微软也面临着嵌入式 IE COM 对象的同样问题。这是一个大问题，不属于任何一个群体。
回答隐含的问题：
WebView对象基本上是一个迷你浏览器，利用高度灵活的渲染代码，这些代码完全基于与专用浏览器不同的参数。这包括从简单的渲染到甚至可交互（即“sp？”）的对象，如此页面所使用的链接。这个过程很难以（缺乏更好的词汇）使其迷你化，以便在各种具有不同布局结构和参数的应用程序中嵌入，并且能够达到统一的功能。实际上，即使针对专用浏览引擎进行编程，这样的引擎也很难统一，这导致了当前主要浏览器之间的许多差异。
WebView并非旨在提供专用浏览器的全部功能，而是展示由应用程序提供的最有用的Web内容方面。特别是当考虑到添加JavaScript功能或从所述内容交付的客户端处理的安全性影响时，这一点尤其正确。此外，每个设备都有可能具有不同的呈现引擎或相同呈现引擎的不同版本，就像不同设备使用SQLite（例如Foreign Key support）的能力不同一样。
因此，WebView提供了一种解决方案，以显示Web交付的内容，但不能保证其可扩展性或可用性，除非您纯粹使用它来查看（并可能反应）受信任和符合标准的HTML代码。一旦您进入实际的真实网站实践中，您会意识到HTML之所以如此灵活，是因为每个标准都由不同的开发人员在不同层次上遵循。由于HTML的主要信条是它可以工作（显示内容），尽管存在潜在的歧义，因此开发完全综合的嵌入式面向对象解决方案变得更加困难。
… 其他移动设备（如iPhone）会很好地运行它
这取决于内容。此外，Apple设备的开发哲学与Android完全不同。苹果只有少数几个设备，因此他们可以保证设备之间的一致性，并选择何时添加其他功能。例如，第一代iPhone没有本地支持Flash。根据您的问题的影响，我认为这未通过“全面”的测试。
相比之下，Android具有更广泛的设备库。 Android的代码由这些设备的制造商进行调整和修改，以允许他们为其特定设备需求制作更合适的可支持解决方案。 Google无法保证任何给定设备将保留任何或所有代码的任何部分。这创造了进一步的限制，但也创造了其他非常棒的自由。
… 它们都使用WebKit。
Chrome和Safari也都使用WebKit。许多开发人员一直被它们如何以不同的方式利用它而困扰。
......在应用程序之外，Android浏览器实际上运行得很好。
这个问题已经在上面得到解答了。
是否有一种更低级别的方法来真正解决Android的问题？
同样，这并不是Android的问题。如果您对当前实现有特定问题，则可以自由编写单独的解决方案。此外，Web内容是为在浏览器中查看而制作的，并提供了该浏览器。最佳做法是定义您需要它具体执行的操作。您是否需要WebView查看任何网页？还是只有你的？您对其当前呈现有什么问题？您是否需要客户端脚本？
每个工具都是根据特定需求制作的。这甚至适用于所谓的“更好”的列表视图。这些视图是为了解决可能需要多个开发人员的特定需求而制作的。在编程世界中（尤其是OOP），真的几乎没有全面性。如果有的话，我们就不必首先扩展对象了。在查看此类工具时，请考虑它是尝试解决哪个需求。
是否有人为Android创建了更全面的Web对象？
是的。它们通常体现在您可以下载到设备上的其他专用浏览器中。至于它们是否可访问：就我个人而言，我不知道也不想查找。
最终声明
您提出的问题并不具体，因此无法提供真正的解决方案。由于措辞不当，它似乎采取了对抗性立场。如果您的问题既没有得到CommonsWare的答案也没有得到我的答案，请考虑编辑您的问题以添加更具体的需求。话虽如此，我希望我们两个的答案都能为您提供一些见解。
希望有所帮助，
FuzzicalLogic
我很惊讶没有人提到CocoonJS。
它有一个标准WebView的重新实现(Webview+)；一个打包的Webview，因此您的应用程序将在设备上稳定运行(尽管仅限于Android 4+和iOS 8+)。
还有一个名为Canvas+的环境，用于WebGL，但它与WebView+完全独立。这意味着您需要在Canvas+上覆盖WebView+以同时显示DOM和画布。它们不共享相同的JS环境，但有一个消息系统用于在两者之间发送消息。
CocoonJS似乎不是一个很好的生产级解决方案，因为受到了有限的操作系统支持，但也许将来会改善。
还有Crosswalk。它适用于Android 4+和Tizen。
这几乎是一个与主题无关的，发泄情绪请到其他地方的“问题”。
有没有更好的Android Webview？
如果您所说的“Webview”是可嵌入式Web渲染引擎，那可能没有更好的了，因为编写此类引擎很难。您可以查看Firefox Mobile的衍生版本是否可用。或者，您可以使用AOSP版本作为起点，自己制作将WebKit移植到Android上的版本。请注意，这两种方法都可能会大幅增加应用程序的大小。
Google自己的文档提到不要依赖于webview对象。
请提供引用。
有人为Android制作了更全面的Web对象吗？
这将取决于对“更全面的Web对象”的定义。值得注意的是，您忽略了为该短语提供任何定义。
WebView 本身就坐落在大量的本地代码之上，这限制了我们进行更改的灵活性。你提到的其他所有内容都是纯粹由 Java 实现的。 - CommonsWare