2. 程式人生 > >【騰訊Bugly乾貨分享】WKWebView 那些坑

【騰訊Bugly乾貨分享】WKWebView 那些坑

阿新 • • 發佈：2019-01-09

導語

WKWebView 是蘋果在 WWDC 2014 上推出的新一代 webView 元件，用以替代 UIKit 中笨重難用、記憶體洩漏的 UIWebView, 擁有60fps滾動重新整理率、和 safari 相同的 JavaScript 引擎。簡單的適配方法就不細說了，本文主要講述適配 WKWebView 過程中填過的坑以及善待解決的技術難題。

1、WKWebView 白屏問題

WKWebView 自詡擁有更快的載入速度，更低的記憶體佔用，但實際上 WKWebView 是一個多程序元件，Network Loading 以及 UI Rendering 在其它程序中執行。初次適配 WKWebView 的時候，我們也驚訝於開啟 WKWebView 後，App 程序記憶體消耗反而大幅下降，但是仔細觀察會發現，Other Process 的記憶體佔用會增加。在一些用 webGL 渲染的複雜頁面，使用 WKWebView 總體的記憶體佔用（App Process Memory + Other Process Memory）不見得比 UIWebView 少很多。

在 UIWebView 上當記憶體佔用太大的時候，App Process 會 crash；而在 WKWebView 上當總體的記憶體佔用比較大的時候，WebContent Process 會 crash，從而出現白屏現象。在 WKWebView 中載入下面的測試連結可以穩定重現白屏現象: 

這個時候 WKWebView.URL 會變為 nil, 簡單的 reload 重新整理操作已經失效，對於一些長駐的H5頁面影響比較大。

我們最後的解決方案是：

A、藉助 WKNavigtionDelegate

iOS 9以後 WKNavigtionDelegate 新增了一個回撥函式： 

- (void)webViewWebContentProcessDidTerminate:(WKWebView *)webView API_AVAILABLE(macosx(10.11), ios(9.0));

當 WKWebView 總體記憶體佔用過大，頁面即將白屏的時候，系統會呼叫上面的回撥函式，我們在該函式裡執行[webView reload](這個時候 webView.URL 取值尚不為 nil）解決白屏問題。在一些高記憶體消耗的頁面可能會頻繁重新整理當前頁面，H5側也要做相應的適配操作。

B、檢測 webView.title 是否為空

並不是所有H5頁面白屏的時候都會呼叫上面的回撥函式，比如，最近遇到在一個高記憶體消耗的H5頁面上 present 系統相機，拍照完畢後返回原來頁面的時候出現白屏現象（拍照過程消耗了大量記憶體，導致記憶體緊張，WebContent Process 被系統掛起），但上面的回撥函式並沒有被呼叫。在WKWebView白屏的時候，另一種現象是 webView.titile 會被置空, 因此，可以在 viewWillAppear 的時候檢測 webView.title 是否為空來 reload 頁面。

綜合以上兩種方法可以解決絕大多數的白屏問題。

Cookie 問題是目前 WKWebView 的一大短板

2.1、WKWebView Cookie儲存

業界普遍認為 WKWebView 擁有自己的私有儲存，不會將 Cookie 存入到標準的 Cookie 容器 NSHTTPCookieStorage 中。

實踐發現 WKWebView 例項其實也會將 Cookie 儲存於 NSHTTPCookieStorage 中，但儲存時機有延遲，在iOS 8上，當頁面跳轉的時候，當前頁面的 Cookie 會寫入 NSHTTPCookieStorage 中，而在 iOS 10 上，JS 執行 document.cookie 或伺服器 set-cookie 注入的 Cookie 會很快同步到 NSHTTPCookieStorage 中，FireFox 工程師曾建議通過 reset WKProcessPool 來觸發 Cookie 同步到 NSHTTPCookieStorage 中，實踐發現不起作用，並可能會引發當前頁面 session cookie 丟失等問題。

WKWebView Cookie 問題在於 WKWebView 發起的請求不會自動帶上儲存於 NSHTTPCookieStorage 容器中的 Cookie。

比如，NSHTTPCookieStorage 中儲存了一個 Cookie: 

name=Nicholas;value=test;domain=y.qq.com;expires=Sat, 02 May 2019 23:38:25 GMT；

通過 UIWebView 發起請求http://y.qq.com， 則請求頭會自動帶上 cookie: Nicholas=test；
而通過 WKWebView發起請求http://y.qq.com， 請求頭不會自動帶上 cookie: Nicholas=test。

2.2、WKProcessPool

蘋果開發者文件對 WKProcessPool 的定義是：A WKProcessPool object represents a pool of Web Content process. 通過讓所有 WKWebView 共享同一個 WKProcessPool 例項，可以實現多個 WKWebView 之間共享 Cookie（session Cookie and persistent Cookie）資料。不過 WKWebView WKProcessPool 例項在 app 殺程序重啟後會被重置，導致 WKProcessPool 中的 Cookie、session Cookie 資料丟失，目前也無法實現 WKProcessPool 例項本地化儲存。

2.3、Workaround

由於許多 H5 業務都依賴於 Cookie 作登入態校驗，而 WKWebView 上請求不會自動攜帶 Cookie, 目前的主要解決方案是： 

WKWebView * webView = [WKWebView new]; 
NSMutableURLRequest * request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://h5.qzone.qq.com/mqzone/index"]]; 
[request addValue:@"skey=skeyValue" forHTTPHeaderField:@"Cookie"]; 
[webView loadRequest:request];

注意：document.cookie()無法跨域設定 cookie

WKUserContentController* userContentController = [WKUserContentController new]; 
WKUserScript * cookieScript = [[WKUserScript alloc] initWithSource: @"document.cookie = 'skey=skeyValue';" injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:NO]; 
[userContentController addUserScript:cookieScript];

這種方案無法解決302請求的 Cookie 問題，比如，第一個請求是 www.a.com，我們通過在 request header 裡帶上 Cookie 解決該請求的 Cookie 問題，接著頁面302跳轉到 www.b.com，這個時候 www.b.com 這個請求就可能因為沒有攜帶 cookie 而無法訪問。當然，由於每一次頁面跳轉前都會呼叫回撥函式： 

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;

可以在該回調函式裡攔截302請求，copy request，在 request header 中帶上 cookie 並重新 loadRequest。不過這種方法依然解決不了頁面 iframe 跨域請求的 Cookie 問題，畢竟-[WKWebView loadRequest:]只適合載入 mainFrame 請求。

3、WKWebView NSURLProtocol問題

WKWebView 在獨立於 app 程序之外的程序中執行網路請求，請求資料不經過主程序，因此，在 WKWebView 上直接使用 NSURLProtocol 無法攔截請求。蘋果開源的 webKit2 原始碼暴露了私有API： 

+ [WKBrowsingContextController registerSchemeForCustomProtocol:]

通過註冊 http(s) scheme 後 WKWebView 將可以使用 NSURLProtocol 攔截 http(s) 請求： 

Class cls = NSClassFromString(@"WKBrowsingContextController”); 
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:"); 
if ([(id)cls respondsToSelector:sel]) { 
           // 註冊http(s) scheme, 把 http和https請求交給 NSURLProtocol處理 
           [(id)cls performSelector:sel withObject:@"http"]; 
           [(id)cls performSelector:sel withObject:@"https"]; 
}

但是這種方案目前存在兩個嚴重缺陷：

a、post 請求 body 資料被清空

因此，如果通過 registerSchemeForCustomProtocol 註冊了 http(s) scheme, 那麼由 WKWebView 發起的所有 http(s)請求都會通過 IPC 傳給主程序 NSURLProtocol 處理，導致 post 請求 body 被清空；

b、對ATS支援不足

測試發現一旦開啟ATS開關：Allow Arbitrary Loads 選項設定為NO，同時通過 registerSchemeForCustomProtocol 註冊了 http(s) scheme，WKWebView 發起的所有 http 網路請求將被阻塞（即便將Allow Arbitrary Loads in Web Content 選項設定為YES）；

WKWebView 可以註冊 customScheme, 比如 dynamic://, 因此希望使用離線功能又不使用 post 方式的請求可以通過 customScheme 發起請求，比如 dynamic://www.dynamicalbumlocalimage.com/，然後在 app 程序 NSURLProtocol 攔截這個請求並載入離線資料。不足：使用 post 方式的請求該方案依然不適用，同時需要 H5 側修改請求 scheme 以及 CSP 規則；

4、WKWebView loadRequest 問題

在 WKWebView 上通過 loadRequest 發起的 post 請求 body 資料會丟失：

//同樣是由於程序間通訊效能問題，HTTPBody欄位被丟棄
[request setHTTPMethod:@"POST"];
[request setHTTPBody:[@"bodyData" dataUsingEncoding:NSUTF8StringEncoding]];
[wkwebview loadRequest: request];

workaround:

假如想通過-[WKWebView loadRequest:]載入 post 請求 request1: ,可以通過以下步驟實現：

  1. 替換請求 scheme，生成新的 post 請求 request2: post://h5.qzone.qq.com/mqzone/index, 同時將 request1 的 body 欄位複製到 request2 的 header 中（WebKit 不會丟棄 header 欄位）;
  2. 通過-[WKWebView loadRequest:]載入新的 post 請求 request2;
  3. 通過 +[WKBrowsingContextController registerSchemeForCustomProtocol:]註冊 scheme: post://;
  4. 註冊 NSURLProtocol 攔截請求post://h5.qzone.qq.com/mqzone/index ,替換請求 scheme, 生成新的請求 request3: ，將 request2 header的body 欄位複製到 request3 的 body 中，並使用 NSURLConnection 載入 request3，最後通過 NSURLProtocolClient 將載入結果返回 WKWebView;

5、WKWebView 頁面樣式問題

在 WKWebView 適配過程中，我們發現部分H5頁面元素位置向下偏移或被拉伸變形，追蹤後發現主要是H5頁面高度值異常導致：

a. 空間H5頁面有透明導航、透明導航下拉重新整理、全屏等需求，因此之前 webView 整個是從（0, 0）開始佈局，通過調整webView.scrollView.contentInset 來適配特殊導航欄需求。而在 WKWebView 上對 contentInset 的調整會反饋到webView.scrollView.contentSize.height的變化上，比如設定 webView.scrollView.contentInset.top = a，那麼contentSize.height的值會增加a,導致H5頁面長度增加，頁面元素位置向下偏移；

解決方案是：調整WKWebView佈局方式，避免調整webView.scrollView.contentInset。實際上，即便在 UIWebView 上也不建議直接調整webView.scrollView.contentInset的值，這確實會帶來一些奇怪的問題。如果某些特殊情況下非得調整 contentInset 不可的話，可以通過下面方式讓H5頁面恢復正常顯示： 

/**設定contentInset值後通過調整webView.frame讓頁面恢復正常顯示 
 *參考：http://km.oa.com/articles/show/277372
 */ 
webView.scrollView.contentInset = UIEdgeInsetsMake(a, 0, 0, 0); 
webView.frame = CGRectMake(webView.frame.origin.x, webView.frame.origin.y, webView.frame.size.width, webView.frame.size.height - a);

b. 在接入 now 直播的時候，我們發現在 iOS 9 上 WKWebView 會出現頁面被拉伸變形的情況，最後發現是window.innerHeight值不準確導致（在WKWebView上返回了一個非常大的值），而H5同學通過獲取window.innerHeight來設定頁面高度，導致頁面整體被拉伸。通過查閱相關資料發現，這個bug只在 iOS 9 的幾個系統版本上出現，蘋果後來fix了這個bug。我們最後的解決方案是：延遲呼叫window.innerHeight

setTimeout(function(){height = window.innerHeight},0);

or 

Use shrink-to-fit meta-tag 
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no, maximum-scale=1, shrink-to-fit=no">

6、WKWebView 截圖問題

空間玩吧H5小遊戲有截圖分享的功能，WKWebView 下通過 -[CALayer renderInContext:]實現截圖的方式失效，需要通過以下方式實現截圖功能： 

@implementation UIView (ImageSnapshot) 
- (UIImage*)imageSnapshot { 
    UIGraphicsBeginImageContextWithOptions(self.bounds.size,YES,self.contentScaleFactor); 
    [self drawViewHierarchyInRect:self.bounds afterScreenUpdates:YES]; 
    UIImage* newImage = UIGraphicsGetImageFromCurrentImageContext(); 
    UIGraphicsEndImageContext(); 
    return newImage; 
} 
@end

然而這種方式依然解決不了 webGL 頁面的截圖問題，筆者已經翻遍蘋果文件，研究過 webKit2 原始碼裡的截圖私有API，依然沒有找到合適的解決方案，同時發現 Safari 以及 Chrome 這兩個全量切換到 WKWebView 的瀏覽器也存在同樣的問題：對webGL 頁面的截圖結果不是空白就是純黑圖片。無奈之下，我們只能約定一個JS介面，讓遊戲開發商實現該介面，具體是通過 canvas getImageData()方法取得圖片資料後返回 base64 格式的資料，客戶端在需要截圖的時候，呼叫這個JS介面獲取 base64 String 並轉換成 UIImage。

7、WKWebView crash問題

WKWebView 放量後，外網新增了一些 crash, 其中一類 crash 的主要堆疊如下： 

... 
28 UIKit 0x0000000190513360 UIApplicationMain + 208 
29 Qzone 0x0000000101380570 main (main.m:181) 
30 libdyld.dylib 0x00000001895205b8 _dyld_process_info_notify_release + 36 
Completion handler passed to -[QZWebController webView:runJavaScriptAlertPanelWithMessage:initiatedByFrame:completionHandler:] was not called

主要是JS呼叫window.alert()函式引起的，從 crash 堆疊可以看出是 WKWebView 回撥函式: 

+ (void) presentAlertOnController:(nonnull UIViewController*)parentController title:(nullable NSString*)title message:(nullable NSString *)message handler:(nonnull void (^)())completionHandler;

completionHandler 沒有被呼叫導致的。在適配 WKWebView 的時候，我們需要自己實現該回調函式，window.alert()才能調起 alert 框，我們最初的實現是這樣的： 

- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler 
{ 
    UIAlertController *alertController = [UIAlertController alertControllerWithTitle:@"" message:message preferredStyle:UIAlertControllerStyleAlert]; 
    [alertController addAction:[UIAlertAction actionWithTitle:@"確認" style:UIAlertActionStyleCancel handler:^(UIAlertAction *action) { completionHandler(); }]]; 
    [self presentViewController:alertController animated:YES completion:^{}]; 
}

如果 WKWebView 退出的時候，JS剛好執行了window.alert(), alert 框可能彈不出來，completionHandler 最後沒有被執行，導致 crash；另一種情況是在 WKWebView 一開啟，JS就執行window.alert()，這個時候由於 WKWebView 所在的 UIViewController 出現（push或present）的動畫尚未結束，alert 框可能彈不出來，completionHandler 最後沒有被執行，導致 crash。我們最終的實現大致是這樣的： 

- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler 
{ 
    if (/*UIViewController of WKWebView has finish push or present animation*/) { 
        completionHandler(); 
        return; 
    } 
    UIAlertController *alertController = [UIAlertController alertControllerWithTitle:@"" message:message preferredStyle:UIAlertControllerStyleAlert]; 
    [alertController addAction:[UIAlertAction actionWithTitle:@"確認" style:UIAlertActionStyleCancel handler:^(UIAlertAction *action) { completionHandler(); }]]; 
    if (/*UIViewController of WKWebView is visible*/) 
     [self presentViewController:alertController animated:YES completion:^{}]; 
    else 
        completionHandler(); 
}

確保上面兩種情況下 completionHandler 都能被執行，消除了 WKWebView 下彈 alert 框的 crash，WKWebView 下彈 confirm 框的 crash 的原因與解決方式與 alert 類似。

另一個 crash 發生在 WKWebView 退出前呼叫：

 -[WKWebView evaluateJavaScript: completionHandler:]

執行JS程式碼的情況下。WKWebView 退出並被釋放後導致completionHandler變成野指標，而此時 javaScript Core 還在執行JS程式碼，待 javaScript Core 執行完畢後會呼叫completionHandler()，導致 crash。這個 crash 只發生在 iOS 8 系統上，參考Apple Open Source，在iOS9及以後系統蘋果已經修復了這個bug，主要是對completionHandler block做了copy（refer: https://trac.webkit.org/changeset/179160）；對於iOS 8系統，可以通過在 completionHandler 裡 retain WKWebView 防止 completionHandler 被過早釋放。我們最後用 methodSwizzle hook 了這個系統方法： 

+ (void) load 
{ 
    [self jr_swizzleMethod:NSSelectorFromString(@"evaluateJavaScript:completionHandler:") withMethod:@selector(altEvaluateJavaScript:completionHandler:) error:nil]; 
} 
/* 
 * fix: WKWebView crashes on deallocation if it has pending JavaScript evaluation 
 */ 
- (void)altEvaluateJavaScript:(NSString *)javaScriptString completionHandler:(void (^)(id, NSError *))completionHandler 
{ 
    id strongSelf = self; 
    [self altEvaluateJavaScript:javaScriptString completionHandler:^(id r, NSError *e) { 
        [strongSelf title]; 
        if (completionHandler) { 
            completionHandler(r, e); 
        } 
    }]; 
}

8、其它問題

8.1、視訊自動播放

WKWebView 需要通過WKWebViewConfiguration.mediaPlaybackRequiresUserAction設定是否允許自動播放，但一定要在 WKWebView 初始化之前設定，在 WKWebView 初始化之後設定無效。

8.2、goBack API問題

WKWebView 上呼叫 -[WKWebView goBack], 回退到上一個頁面後不會觸發window.onload()函式、不會執行JS。

8.3、頁面滾動速率

WKWebView 需要通過scrollView delegate調整滾動速率：

- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView {
     scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
}

9、結語

本文總結了在 WKWebView 上踩過的一些坑。雖然 WKWebView 坑比較多，但是相對 UIWebView 在記憶體消耗、穩定性方面還是有很大的優勢。儘管蘋果對 WKWebView 的開發進度過於緩慢，但相信 WKWebView 才是未來。

更多精彩內容歡迎關注騰訊 Bugly的微信公眾賬號：

騰訊 Bugly是一款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智慧合併功能幫助開發同學把每天上報的數千條 Crash 根據根因合併分類，每日日報會列出影響使用者數最多的崩潰，精準定位功能幫助開發同學定位到出問題的程式碼行，實時上報可以在釋出後快速的瞭解應用的質量情況，適配最新的 iOS, Android 官方作業系統，鵝廠的工程師都在使用，快來加入我們吧！

相關推薦

【騰訊Bugly乾貨分享】WKWebView 那些坑

導語 WKWebView 是蘋果在 WWDC 2014 上推出的新一代 webView 元件，用以替代 UIKit 中笨重難用、記憶體洩漏的 UIWebView, 擁有60fps滾動重新整理率、和 safari 相同的 JavaScript 引擎。簡單

【騰訊Bugly乾貨分享】Android程序保活招式大全

【騰訊Bugly乾貨分享】Android程序保活招式大全 本文來自於騰訊bugly開發者社群，非經作者同意，請勿轉載，原文地址：http://dev.qq.com/topic/57ac4a0ea374c75371c08ce8 作者：騰訊——張興華 目前市面上的應用，貌似除了微信和手Q都會

【騰訊Bugly乾貨分享】移動網際網路測試到質量的轉變

Dev Club 是一個交流移動開發技術，結交朋友，擴充套件人脈的社群，成員都是經過稽核的移動開發工程師。每週都會舉行嘉賓分享，話題討論等活動。 本期，我們邀請了 TesterHome 測試技術社群聯合創始人“陳曄”，為大家分享《移動網際網路測試到質量的轉

【騰訊Bugly乾貨分享】聊聊蘋果的Bug

作者：張三華 導語 精神哥最近發現， 很多開發者在 iOS10 上遇到了一類堆疊為nano_free字樣的Crash，也有很多人向我們Bugly客服反饋遇到了這類問題，但並沒有好的解決方案。正當大家都束手無策的時候，微信強大的技術團隊針對這類

【騰訊Bugly乾貨分享】總結一個技術總監的教訓和經驗

導語 2017年來了，新年開篇，就不跟大家聊技術啦，給大家分享一篇鵝廠技術總監在多年工作中總結出的教訓和經驗。 這篇文章自從在騰訊內部論壇發表後，精神哥每年都會拿出來重新研讀一番，每次都有新的感悟和收穫，所以強烈推薦給大家。 正文 資深程式設

【騰訊Bugly乾貨分享】打造“微信小程式”元件化開發框架

作者：Gcaufy 導語 Bugly 之前發了一篇關於微信小程式的開發經驗分享（點選閱讀），小夥伴們在公眾賬號後臺問了很多關於小程式開發方面的問題，精神哥在查閱相關內容的時候，發現了龔澄同學自己寫了一個小程式開發框架，真的怒贊，趕緊安利給大家

【騰訊Bugly乾貨分享】美團大眾點評 Hybrid 化建設

本期 T 沙龍探討了移動端熱更新相關的話題。由於沙龍時間的限制，本期我們選取了美團的 Hybrid 化建設、去哪兒的跨平臺 ListView 效能優化、微博 Android 端熱更新踩過的坑話題。還期待熱更新、熱修復哪些話題？歡迎留言給我們。也歡迎報名參加

【騰訊Bugly乾貨分享】Android減包 － 減少APK大小

本文是對Google官方文件 Reduce APK Size 的翻譯，點選“閱讀原文”可以檢視英文原文。 譯者簡介：damonxia(夏正冬)，天天P圖Android工程師 使用者經常會避免下載看起來體積較大的應用，特別是在不穩定的2G、3G

【騰訊Bugly乾貨分享】跨平臺 ListView 效能優化

導語 精神哥前陣子去參加了好友小青在北京辦的T沙龍，探討移動端熱更新相關的話題。Bugly 曾為大家介紹過不少騰訊內部的熱更新的框架，正好這次看到了美團，去哪兒以及微博同學在應用熱更新方面的實踐。 上週為大家整理了《美團大眾點評 Hybrid 化建設

【騰訊Bugly乾貨分享】Android ListView與RecyclerView對比淺析--快取機制

作者：黃寧源 一，背景 RecyclerView是谷歌官方出的一個用於大量資料展示的新控制元件，可以用來代替傳統的ListView，更加強大和靈活。 最近，自己負責的業務，也遇到這樣的一個問題，關於是否要將ListView替換為Recycl

【騰訊Bugly乾貨分享】Android 新一代多渠道打包神器

關於作者： 李濤，騰訊Android工程師，14年加入騰訊SNG增值產品部，期間主要負責手Q動漫、企鵝電競等專案的功能開發和技術優化。業務時間喜歡折騰新技術，寫一些技術文章，個人技術部落格：www.ltlovezh.com 。 ApkChanne

【騰訊Bugly乾貨分享】你為什麼需要 Kotlin

一、往事 曾經你有段時間研究 Intellij 的外掛開發，企圖編譯 Intellij Idea Community Edition （ICE）的原始碼，結果發現有個奇怪的東西讓你的程式碼無法編譯。。什麼鬼，kt 是什麼玩意兒？ 怎麼又有

【騰訊bugly乾貨分享】精神哥手把手教你如何智鬥ANR

上帝說要有ANR，於是Bugly就有了ANR上報，那麼ANR到底是什麼？ 最近很多童鞋問起精神哥ANR的問題，那麼這次就來聊一下，雞爪怎麼泡才好吃，噢不，是如何快速定位ANR。 ANR是什麼 簡單說，通常就是App執行的時候，duang~卡住了，怎麼搞都動不

【騰訊bugly乾貨分享】解耦---Hybrid H5跨平臺性思考

跨平臺，是H5最重要的能力之一。而 Hybrid H5 因強依賴於具體 app，往往不具有跨平臺性。這時，將強依賴關係解耦，即可恢復 H5 的跨平臺能力。近期本人負責 手Q 紅包打賞專案的前端開發，因專案涉及到多 app 跨平臺相容，對 hybrid H5

【騰訊Bugly乾貨分享】WebSocket 淺析

前言 在WebSocket API尚未被眾多瀏覽器實現和釋出的時期，開發者在開發需要接收來自伺服器的實時通知應用程式時，不得不求助於一些“hacks”來模擬實時連線以實現實時通訊，最流行的一種方式是長輪詢 。 長輪詢主要是發出一個HTTP請求到伺服器，

【騰訊Bugly乾貨分享】基於RxJava的一種MVP實現

Dev Club 是一個交流移動開發技術，結交朋友，擴充套件人脈的社群，成員都是經過稽核的移動開發工程師。每週都會舉行嘉賓分享，話題討論等活動。 本期，我們邀請了騰訊IEG Android 開發工程師——戴俊，為大家分享《基於RxJava的一種MVP實現》

【騰訊Bugly乾貨分享】RecyclerView 必知必會

導語 RecyclerView是Android 5.0提出的新UI控制元件，可以用來代替傳統的ListView。 Bugly之前也發過一篇相關文章，講解了 RecyclerView 與 ListView 在快取機制上的一些區別： 今天精神哥來給

【騰訊Bugly乾貨分享】深入理解 ButterKnife，讓你的程式學會寫程式碼

0、引子 話說我們做程式設計師的，都應該多少是個懶人，我們總是想辦法驅使我們的電腦幫我們幹活，所以我們學會了各式各樣的語言來告訴電腦該做什麼——儘管，他們有時候也會誤會我們的意思。 突然有一天，我覺得有些程式碼其實，可以按照某種規則生成，但你又不能不

【騰訊Bugly乾貨分享】Android 程序保活招式大全

本文來自於騰訊bugly開發者社群， ，原文地址：https://segmentfault.com/a/1190000006251859作者：騰訊——張興華目前市面上的應用，貌似除了微信和手Q都會比較擔心被使用者或者系統（廠商）殺死問題。本文對 Android 程序拉活進行一

【騰訊Bugly乾貨分享】WebVR如此近-three.js的WebVR示例解析

作者：蘇晏燁 關於WebVR 最近VR的發展十分吸引人們的眼球，很多同學應該也心癢癢的想體驗VR裝置，然而現在的專業硬體價格還比較高，入手一個估計就要吃土了。但是，對於我們前端開發者來說，我們不僅可以簡單地在手機上進行視覺上的VR體驗，還可以