移動端h5開發相關內容總結（四）

前言：

看了下博客的更新時間，發現9月份一篇也沒有更新。一直想着都要抽時間寫一篇的，否則今年的更新記錄就會斷在了9月份。可是仍是應爲各類各樣的事情給耽擱了。當心裏忽然涌起一股必須寫點什麼的時候，忽然發現本身把寫博客的「套路」都忘了。(●´ω｀●)φ

一直認爲本身仍是一個比較熱愛思考的人。最近一直在思考兩個問題：

1. 本身作技術的初衷；

2. 本身的技術成長之路；

固然這兩篇文章本身也在潤色之中，相信很快會跟你們見面。

廢話很少說。來正菜。

1.背景色與透明度相關知識

好吧。至從本身到了新的工做環境之後，開發環境又從只須要兼容 IE8 以上回到了必須兼容 IE6 瀏覽器上來。因此在第一次作項目的時候，仍是遇到一些兼容低版本IE瀏覽器的問題。

首先來看一個背景透明的問題，背景透明有三種解決方案：

1. IE6-7使用濾鏡；

2. opcity；

3. rgba；

可是他們也有些細微的差異總結以下：

示例效果以下（若是能夠的話，本身能夠寫一個簡單的demo看下效果）：

第一個是opcity和rgab的區別

第二張是在ie6中的效果：

當咱們在兼容低版本瀏覽器的時候可能下面的寫法能夠知足咱們的需求（兩個屬性都寫上，瀏覽器識別的屬性直接覆蓋前者的屬性）：

.item1{
    opacity:0.1;//IE8以上瀏覽器識別
    filter: progid:DXImageTransform.Microsoft.Alpha(opacity=70);//濾鏡低版本IE7-8支持
}

2. html5標籤呼起系統發件箱

作html5開發的過程當中，咱們可能會有這樣的需求：

點擊按鈕，呼起系統的發送短信的窗口，而且自動填充發送到的號碼和內容；

網絡上能夠很容易的找到這方面的demo ，而且也能夠找到在安卓上和ios上是有卻別的：

<!-- ios-->
<a href="sms:10086&body=發送的內容">點擊我發送短信</a>
<!-- android-->
<a href="sms:10086?body=發送的內容">點擊我發送短信</a>

可是在實際的開發過程當中卻遇到了不少坑。主要緣由是：
除了安卓和IOS系統的寫法不一樣外，ios不一樣系統版本寫法也不一樣。並且在不一樣的app中也有不一樣。

上面的緣由是在生產環境遇到的問題。剛開始由於找不到相關能夠查閱的文檔只能不作兼容。偶然一次在 stackoverflow 發現了問題的緣由。

原文內容以下：

翻譯後總結以下：

因此，若是在生產環境中有呼起系統發件箱而且填充號碼和內容的請注意以上的區別。

3.input標籤選擇系統文件的問題

在html5中 input標籤提供給了開發者訪問系統文件的能力。說實話若是僅僅在移動端的系統瀏覽器中使用input控件真的沒有發現什麼問題。可是在app的**webview**中卻到處是坑。如下是總結出的一些經驗。

<input type="file">在webview中訪問系統文件遇到的一些問題：

1. 觸發input後，頁面「閃退」（現象就是，文件選擇框出現後又立馬關閉）；當初遇到這個問題是在貼吧的客戶端中，聽貼吧的兄弟說，他們後來作了兼容。

2. 華爲手機中能夠正常的呼起系統選擇文件的窗口，可是沒法正常讀取系統文件（最後跟客戶端的同窗肯定，若是h5在webview中讀取系統文件，是須要權限的，也就是說須要客戶端支持）；

3. 在ios的webview中也會出現問題。若是有興趣的同窗能夠參考這篇蘋果的開發者文檔(點擊訪問）

詳細的能夠參考這篇文章一塊兒閱讀：《h5端呼起攝像頭掃描二維碼並解析》

4.傳遞參數的解決方案

在開發過程曾經遇到過這樣的問題：

不少個頁面，好比說a-z。當我在a頁面的時候，瀏覽器中的url會帶有某些參數，當我在作完一系列的操做到達z頁面。
某天有個需求，用戶在頁面a的時候會帶上一個參數，決定用戶在z頁面作完操做後頁面最終跳向哪裏。那麼這個參數該怎麼傳遞到z頁面呢？

第一種解決方案：

從a頁面到z頁面跳轉的過程當中，經過 GET 的方式在url中帶上這個參數；

這種方案是比較常規，也是比較不錯的解決方案。可是須要在頁面中的邏輯跳都加上須要的參數。這樣工做量比較大，並且容易出現遺漏。不建議使用。

第二種解決方案：

使用html5新特性sessionStorage來解決問題。在a頁面的時候，把新添加的須要傳給z頁面的參數放在sessionStorage中。在z頁面直接從sessionStorage中取須要獲取的參數值，而後決定頁面最終的跳轉。

這樣解決問題不只減小了很大的工做量，也解決了工做量大會遺漏的問題。

sessionStorage的優勢：

由於數據是存儲在內存中，當會話結束，頁面關閉之後這些數據就會被銷燬。

html5移動端存儲的一些坑：

固然在移動端瀏覽器中使用localStorage和sessionStorage是沒有任何問題的。可是在安卓webview中卻出現了localStorage沒法向移動的磁盤寫數據的問題。最後經過網絡搜索發現。在安卓上webview是默認不開啓localStorage想磁盤寫文件的權限的。因此若是須要使用localStorage的同窗須要找客戶端支持。詳細信息以下：

5.pc端js生成二維碼

作過一個JavaScript生成二維碼的需求。當時調研了兩個方案：

1. 使用qrcodejs

2. 使用jquery.qrcide

在使用的過程當中仍是遇到一些坑，總結以下：

因此在前端有需求作生成二維碼需求的時候，能夠參考以上的兩個點，肯定本身選擇哪一個開源庫更適合本身的項目。

6.本地存儲js字符串

當看到題目的時候，可能會「一臉蒙逼」爲何要在本地存儲js字符串啊。好吧，有時候業務場景的需求確實是比較變態，且看我描述的一個業務場景。

業務場景：
由於歷史的緣由，咱們的html5頁面是跑在客戶端的webview中，可是客戶端的titlebar上的那個返回按鈕倒是調用了前端js的back方法進行頁面返回的。這個時候就會出現一個問題，若是在咱們的h5頁面中跳出了咱們本身的頁面，到了第三方的頁面。第三方頁面的js確定是沒有咱們客戶端返回按鈕須要的js返回方法的。

可能有人會說，「臥槽，爲何要這麼搞，當初誰這麼設計的。。。」或者是「讓客戶端同窗發版，用客戶端本身的返回不就解決問題了麼」。

好吧，都說了是歷史緣由了其它的都不要說，並且找客戶端同窗發版也不太現實的狀況下只能想其它的解決方案了。

以前已經聊到過html5的客戶端存儲技術sessionStorage。固然我要作的就是把那段前端的back方法存到sessionStorage中。當加載第三方的頁面的時候直接從sessionStorage中讀取back方法的字符串，轉化爲js代碼，而且賦值給客戶端調用的方法。

其實這裏的難點是怎麼把js字符串轉化爲可執行的js代碼。

1. 使用eval執行js代碼語句，看下面簡單的示例：

由上面的代碼能夠知道，eval能夠把簡單的js字符串轉化爲js代碼而且執行它。可是當咱們的js字符串比較複雜呢？好比下面這樣：

function aaa(){
    console.log(1);
}

那麼使用eval函數還行不行呢？看下面的示例：

由上面的執行結果能夠知道，無論怎麼執行都得不到咱們的預期的結果，可是有沒有辦法獲得咱們預期的結果呢？答案是：有。

1. JavaScript中new 關鍵字的使用

在JavaScript中一切皆是對象。當咱們建立一個函數的時候除了函數聲明和函數表達式外，還能夠經過new Function的方式來建立函數（這種方式並不經常使用，可是特殊的場景仍是頗有用的）。

那麼使用new Function怎麼解決上面的問題呢？請看示例代碼：

由上面的示例代碼和c的執行結果我想不少人已經知道怎麼作了，其實只須要對b的字符串函數作一下簡單的修改便可，看代碼：

上面的代碼執行結果的b()就是咱們我想要的保存的函數體。

7.絕對定位的「坑」

來看一個比較常見的佈局

上面的這個佈局 由於footer是相對於頁面底部絕對定位的，因此當屏幕過小的時候會有一個問題footer區域覆蓋了內容區域，以下圖：

那咱們怎麼解決這個問題呢？我看到在咱們項目的源代碼中是經過js給footer和內容區域所在的父容器設置一個最小的高度來解決這個爲題的，這樣作很差。除了會增長複雜的判斷也會形成頁面的重繪：

var webViewHeight = window.innerHeight;
var iosCampatibleValue = 64;
if(webViewHeight<500){
    webViewHeight =500;
}
$('#pageWrapper').css('height', webViewHeight);

很明顯上面的代碼會形成頁面的重繪（固然這個對系統性能消耗並非那麼容易感知）。可是用css可不能夠解決這個問題呢？

固然是能夠的，就是爲內容容器設置一個padding-bottom它的值就是底部footer的高度,以下圖：

當移動端的屏幕比較低的時候就會是下面的這種狀況：

padding-bottom和footer重合。可是footer永遠不會覆蓋內容區域的內容。這時頁面會出現滾動條。可能咱們最初的設計是爲了用戶體驗不讓用戶的屏幕出現滾動條，可是仍是那句話沒有十全十美的程序，在一些小衆機型上爲了保證頁面的正常顯示保證用戶正常瀏覽咱們只能犧牲一下這樣的用戶體驗了。

8.鍵盤被呼起模擬滾動

如今大多數的安卓系統和ios系統，當輸入框獲取焦點呼起系統鍵盤的時候，系統鍵盤都會將input輸入框給推上鍵盤的上方，方便用戶的輸入。可是不外乎例外，特別是在某些app中，這個自己是系統的操做並不生效，這個時候若是須要達到完美的用戶體驗就須要人爲的參與進來。

解決辦法：

思路很簡單，就是檢測輸入框的focus事件，當輸入框獲取焦點的時候，用js去把頁面滾動一下。最好維護一個系統沒法正常推起輸入框的軟件列表（能夠經過HTTP的UA來獲取軟件的惟一標識）。若是可使用系統默認的滾動就用系統的，若是不能夠再人爲的調用js干預。

function inputScroll(dom){
var tplList=['ss','bb'] ;

var tpl = $.fn.getQueryString(tpl);
    if(tplList.indexOf(tpl)){
        dom.focus(function(){
            var clientHeight = $(window).height();
            var contentHeight = clientHeight + clientHeight/2;
            var smsInputTop= $(this).offset().top;

            content.height(contentHeight);
            window.scrollTo(0,smsInputTop-76);
            });
    }
}

---