我的理解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