微信 Android 大陆版为什么不用 Chrome WebView 而用 QQ 浏览器?

[iugo]

iOS 上, 微信没得选.

Android 上可以有多种选择:

1. 可以跟随系统使用系统的 WebView. 弊端可能是国内环境乱象, 系统的 WebView 大多不是 Chrome, 可能更坑.
2. 目前微信的做法, 使用自己的 WebView, 但根据 UA, 是 QQ 浏览器.
3. 既然内置了, 为什么不使用 Chrome?

作为 Web 开发者, 在乎更先进的语法和 Web API.
微信既然想吸引开发者, 就应该在乎开发者的需求, 减少开发者的负担, 比如在适配上的工作量, Chrome 版, Safari 版, 再来个 MQQBrowser 版, 好累呦.

对我比较重要的几个东西:

• fetch
• execCommand

还有样式上的一些奇怪的问题. 许多组件都不能重用, 只好针对微信再重新开发.

[sagnitude]

1. Chrome Webview 不是可以一个安卓项目可以“直接打包在 apk ”里面的东西，能用的只是“ Android Webview ”
2. Android Webview 在不同安卓版本是 **几乎完全不同** 的，在 Android <4.4 上， webview 不是 Chrome ；随着安卓版本的变化，内置 webview 所实现的技术标准差别太大，根本无法控制一个微信 web 页面在不同系统 webview 上的表现
3. Android Webview 在不同厂商的 ROM 上，实现也是天差地别，同第二点，无法控制产品的表现，而使用同一个内置的浏览器内核可以控制
4. QQ 内核是集团内部的东西，举个具体的例子，在当前 WebBluetooth 还在草案阶段， WebBluetooth API 目前只有 Android 6.0 及以上才能使用，而微信已经能在页面上使用蓝牙信息（只要有蓝牙和有微信），请问如何在系统 webview 上使用蓝牙接口？
5. 自定义 url scheme 是一个很重要的功能，系统 webview 能提供的自定义是受限的，如果使用自己的产品，可以无限制地自定义和使用，微信的交互很多，基于一个简单的系统 webview 开发如此复杂的功能，听起来像是一场噩梦


补充：
WebBluetooth 接口实现情况： https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/implementation-status.md

[sagnitude]

使用系统 webview ，就像楼主你自己说的，只会增加适配的工作量，不会减少开发者的负担

开发一个页面，只有部分用户能看见，其他人只能看见一个报错信息，听起来不是一个好主意

比如 WebBluetooth ，比如 WebGL （没错，之前安卓微信不能在所有平台上使用 webgl ）

[sagnitude]

@iugo 没有用户需求，就不需要开发者，开发者不是和用户对等的

[sagnitude]

顺便说下 fetch ，参见兼容表格：

https://developer.mozilla.org/zh-CN/docs/Web/API/Fetch_API#Browser_compatibility

Safari webkit 不能用，老的 Android webview 不能用，楼主你就不该用 fetch ，这个组件本身就不应该被用作移动端开发

[sagnitude]

补充：
http://caniuse.com/#feat=fetch

Android Browser 需求 Android >= 5.0

并且华为 P8 虽然是 Android 5.1.0 ，但是内置 webview 不是基于 Chrome 的，之前我们开发 WebGL 的时候就差点撞死在 P8 上，最后改成 canvas 了

[ahtsiu]

像 crosswalk 这样直接使用没有经过裁剪的 chromium 作为内核的话，这个“内核”本身就二三十 M 咯。
裁剪的话，就是 X5 啦

[learnshare]

为了增加自己的 API

[smithtel]

感觉楼主真是萌萌哒。

[iugo]

@sagnitude

您说的第一点和第四点可能是题解. 我没做过 Android 开发, 如果开发中集成 Chrome WebView 难度大, 那这的确是很可信的一个理由.

关于第二, 第三点. 要不要用系统的 WebView, 我觉得没必要再说了吧, 再次引用主题帖中我已经说过的:

> 可以跟随系统使用系统的 WebView. 弊端可能是国内环境乱象, 系统的 WebView 大多不是 Chrome, 可能更坑.

顺便说下 fetch, Safari 的确不支持, iOS 7 连 Promise 都不支持. 这些通过 polyfill 都能解决. 但这不是拒绝的理由吧? 因为一些东西不支持, 就不该用?

这已经是个世界观的问题了:
- 一些国内浏览器不支持 HTTP/2, 运维人员就能在优化服务让能用 HTTP/2 的人用上?
- 浏览器对 ES6 支持有待提升, 开发者就不该用 ES6 语法做开发?
- 不考虑什么新功能, 那就不会有以前 io.js 的分裂和现在浏览器版本号的比赛.

再说另外一个产品观的问题:

> 没有用户需求，就不需要开发者，开发者不是和用户对等的

微信可以不考虑开发者, 没问题. 只不过在我个人看来, 微信是希望吸引开发者依赖微信开发更多所有 "轻应用" 的. 当然, 也可能我错了, 微信才不管开发者, 微信有用户, 如果开发者想要用户, 要巴结着微信.

[Biwood]

微信在学 Apple 没看出来么，设计风格都是跟着 iOS 走，试图建立一个封闭的生态圈，这样才能更好的圈钱

[morethansean]

@iugo 可以明确地告诉你，最主要的原因就是 2 ， 3 点。

[P0P]

@kikyous 这是怎么发现的。科科，关闭了之后微信看文章速度起飞了

[iugo]

@morethansean 重点在 2, 3 点的话. 我只能说, 请看清原文再继续讨论, 否则风马牛是互相浪费时间.

[wzxjohn]

@iugo 实话说我不是很明白，您既然知道国内原生 WebView 这么烂，为啥还说用原生的不需要解释？这点让我很费解。在我看来您的做法就是明知道某个东西又贵又不好用，有更便宜好用的方法，可是你就是要选贵且不好用的，还不说为啥。。。我理解可能您是看到了这个又贵又不好用的东西的某些有点，可是您不说我们怎么理解。。。

[fyooo]

没有做过 android 开发的同学提的技术问题，@sagnitude 同学辛苦的作出详细的技术回复，然后得到的不是感谢，而是#29 一堆「产品观」，「世界观」的废话，醉了...

[jhdxr]

1. 原生的 webview 很糟糕，国内由于各种定制这个问题更严重。但接入原生的 webview 是门槛最低的方案，所以还是有很多产品会这么选择
2. 排除了原生 webview 之后，如果要自制一个内核是养一大个团队的，微信不可能直接养这么一个团队（反过来说如果有这么大一个团队也不会寄居在微信之下），所以一般是要找一个现有的接入
3. 既然要接入，一个是自家的浏览器，如 @just4test 所言，要啥给啥；另外一个是 chrome ，虽然知名度很高，看上去也很好用，但是变化不受自己掌控，解决问题神马都太麻烦。更重要的一点是，内置 chrome 会不会有各种授权的问题？直接用自家的完全不用担心这点，而且还有助于双方的 KPI


上面这个问题是以客户端开发的角度去看的（利益相关：曾在 BAT 中某公司直接负责 web 容器的团队干过）
最后 LZ 提这个问题是以前端开发的角度去看的，而且是以外部开发者的角度去看的。然而说实话，谁在乎你？以微信的这种体量，别说只是用了一个也许不是这么好用的内核，哪怕它抛弃了 html ，自己重头做一个轮子都会有一大堆人去贴上去。与上面提到的 3 点相比，方便外部开发者根本无足轻重。

以上回答在 LZ 看来也许依然只是一些所谓的产品观之类的差异，然而你要知道绝大多数时候起决定性作用的都**不**是技术因素。

[raptor]

用 QQ 浏览器不是问题，问题是 QQ 浏览器太烂，简直不能忍

[also24]

讲真，光是冲着能解决 Android 4.4 上 input 标签的问题，我就想用 X5 内核……

[BOYPT]

想必楼主不大了解 android 上 webview 的坑吧。

[jimmyye]

只有我的微信内置 X5 浏览器可能被劫持了吗？访问 ipip.net 显示的是外地 ip 。
https://v2ex.com/t/251005