我的理解webview是嵌在APP的H5页面。
APP分为三种形式:web
webview就是在混合应用中存在的H5页面。一个用来展现网页的view组件,使用webkit渲染引擎来展现(iOS)。一款webkit内核浏览器,含有前进后退,没有地址栏。浏览器
webview初始化
浏览器:
刚打开APP模拟不初始化webview,须要打开webview页面的时候,建立webview实例,这个过程须要耗时,这也是打开原生页面很快,打开webview页面要等待一小会,这也是打开慢的其中一个缘由。
iOS的webview有两种,UIWebview和WKWebview,不一样类型的webview和iOS的交互方法也不一样。优化
UIWebviewbview | WKWebview |
拦截url | 拦截url |
jsCore | 不支持 |
思考:目前项目中交互方式是使用哪一种方式。this
这里有一个jsBridge的概念,jsBridge用来webview页面和native通信的。url
什么是jsBridge?
翻译成“桥”,一端连接web,一端连接native,经过jsBridge能够调用native提供出来的方法。
调用客户端提供的方法,也便是jsBridge方法。在调用以前要保证jsBridge已注入成功
在APP里面打开H5页面时,native会注入jsBridge,们调用native方法前,判断一下挂在window下面的这个对象是否已经存在了。spa
waitForJSBridge() { return new Promise((resolve) => { if (!window.StockJSBridge) { document.addEventListener('StockJSBridgeReady', resolve); } else { resolve(); } }); }
调用native提供的拉起分享框方法openShareView翻译
openShareView(config: SdkShareConfig): Promise<any> { return this.waitForJSBridge().then(() => { window.StockJSBridge.invoke('openShareView', { to: config.platform || ['wx', 'pyq', 'qq', 'qzone'], type: config.type, params: { title: config.title, summary: config.description, url: config.link, image: config.image, iconUrl: config.image, }, }); }); }
打开webview页面很明显比native页面慢,其中一个缘由是webview初始化须要时间,为了更快打开webview页面,在打开APP时,提早初始化webview,等须要的时候就派上场了。这个作法的弊端:会让APP的内存增长。衡量利弊,控制初始化的webview数量以及作好webview内存的释放code