这里我们先附一张整体的思维图，其中每个分支都可以作为一个专题来说，后续我们逐步展开。 

 

前言

WebView的定位：对于任何一个应用，根据业务的不同类型，webview的重要性也不一样，如音乐类、视频类应用，其h5相关的业务很少，只用于简单的广告引流等场景；但是对于电商等应用，各种促销活动需要灵活高效的支持，h5往往会扮演重要角色。这里，本文对webview的定位更趋向于后者，其服务对象与服务范围为：PV、UV均为千万级+，业务数量1000+。

WebView与WebViewVC

一般情况下，WebView都会对外提供View和VC两个控件，供业务按需使用。所以，大部分情况下，由WebView开发提供的View和VC都会被冠以基础控件的名号。但是，根据我们的经验，更准确的定位应该是：View为基础控件，VC为半基础半业务控件，VC的子类为业务控件。

关于View和VC各自应该扮演的角色，在开发中，我们需要把握的原则为：

第一、与系统相关的行为需要在View层完成。更具体的：WebView自身与UI无关的缺陷逻辑在View层完成，如对window.open指令的支持，WKWebView的UIDelegate的实现；与UI相关的缺陷在View层完成，但是可以提供BOOL 控制，由业务自身决定是否启用，如我们在另一篇文章中提到的状态栏被隐藏的bug（https://blog.****.net/u012413955/article/details/82778856）；

第二、基于WebView自身的能力提供可拓展功能的接口在View层完成，如提供js注入的能力；

第三、WebView可选属性设置能力在View层完成，如是否支持audio自动播放等；

第四、如果存在UIWebView和WKWebView双内核的情况，在View层将二者统一，并将两者公共的API和代理统一封装，提供出去；

第五、将当前View所持有的真正的WebView作为属性暴露出去（主要是防止控件层的能力不足的问题，方便业务直接拓展）；