中國的行動網路環境複雜,為了帶給使用者更好存取體驗,開發者希望能了解使用者目前的連網方式,然後給使用者一個符合目前網路環境的請求結果。
W3C的規範中給出了一個方法來獲得現在的網絡狀態navigator.connection;根據Working Draft 29 November 2012協議規範我們可以從接口中獲得bandwidth(帶寬,M/s)和metered兩個參數的值;也提供了一個監聽方法,來時刻監聽接入環境的變化。現實中我們發現很多瀏覽器並沒有回傳bandwidth值,而且遵守了Working Draft 07 June 2011的協定回傳給我們type(類型,wifi/2g/3g/4g)。
我們接下來就來看看各家的支援狀況
Android 2.3 Browser | UC | Dolphin | QQ浏览器 | Baidu | Firefox | Chrome | Opera Mini | Maxthon |
Yes | No* | Yes | Yes* | Yes | Yes(New) | No | No | Yes |
說明下在iPhone中任何瀏覽器都無法得到相關資訊。
透過上面的說明,我們發現還是可以透過這個參數來了解很大一部分用戶的聯網情況的,並且為他們提供更優質的體驗。
接下來我們重點說說各瀏覽器的回傳情況。
大部分瀏覽器會回傳一個int型的類型,其中的特例是QQ瀏覽器,傳回的就是型別名稱,對應關係如下
返回值 | QQ返回值 | 类型 |
0 | unknown | UNKNOWN |
1 | ethernet | ETHERNET |
2 | wifi | WIFI |
3 | 2g | CELL_2G |
4 | 3g | CELL_3G |
5 | 4g | CELL_4G(中国现在也会出现这个值,是hspa ) |
? | none | NONE |
接下去是一個更大的特例,這就是firefox,他使用了新版規範,所以返回的是bandwidth;不過很奇怪的是只要是wifi或3G他就返回20,如果是2G返回的就是0.1953125 ;每次都一樣不管現在網路狀態到底是多少。這個問題還會繼續跟進。
提供一個demo位址給大家:http://demo.jb51.net/js/2015/net.html
Demo中對不支援connection的瀏覽器直接返回了{type:0},這樣就很便利解決了某些瀏覽器不支援的問題;對於不支援又能上網的瀏覽器處理為「unknown」當然也是合乎情理的。
很多工程師覺得這個功能支援還不好,還是先不使用的好;但是我覺得只要錯誤能被處理,風險能被把控,為什麼不給那些先天優秀的客戶提供更友善的體驗呢。
今天同學說到讓後端判斷速度,這個可能有點難;不過確實可以透過每次的非同步請求去得到使用者大概的速度(載入的時間和檔案大小其實前端都能得到),然後在選擇性的提供某些服務,之後也準備往這個方向多思考下。