移動端H5混合開發設置覆盤與總結

此篇接上一篇:css

移動端H5混合開發,Touch觸控,拖拽,長按, 滑屏 實現方案
https://www.cnblogs.com/buoge/p/9346699.htmlhtml

app 場佈設置已經上線了,用戶能夠經過手機端嵌入的h5網頁進行場佈設置,原來只能在pc端瀏覽器,還得帶上個筆記本電腦非常不方便,這個功能很好的解決了目前設置不暢的問題。上線後獲得你們的承認,提高了業務效率,這一個多月的辛苦開發仍是值得的,接下來是對本身這一段時間開發過程的一個總結。前端

總體開發基於H5+Css3+Jquery,前端這個組合略顯過期,不過我就這個用的熟悉,先作完再說vue

先後端開發混合開發

功能前端和後端是一塊兒開發的,好處是本身靈活定製不須要溝通成本,可是缺點也有先後端切換須要切換大腦思惟的上下文,一會再寫JS一會回去寫Java不利於思惟發揮和深刻思考html5

後端開發過程當中還好有現成的方法能夠調用,因此並無耗費太多時間,大部分時間在前端開發上,假如後端也要作那才真是入水兩腿泥react

總結:後續在有相似開發,不要大包大欖,專一一端去作,這樣高效省心,專一前端和專一後臺分工開發速度快了,效率高了,遇到難題有時間和情景去深刻思考,因此儘量把任務分開下jquery

android iOS 與h5 互相調用的問題

H5調用相機圖片方向有問題:拍照是豎屏,展現成橫屏,上傳上去展現也是橫屏
這兩個帖子講的很清楚,我就不展開了,思路就是利用 exif.js 判斷方向,而後用CanvasApi重新生成base64
格式的圖片android

  • H5拍照應用開發經歷的那些坑兒
    http://www.yuuuuc.me/problems-with-html5-file-api-while-uploading-images/ios

  • 利用exif.js解決ios手機上傳豎拍照片旋轉90度問題
    https://blog.csdn.net/linlzk/article/details/48652635css3

源碼放在了這裏:
https://github.com/buoge/gist/blob/master/FrontEnd/FixH5Oritention.html

相冊調用去攝像頭,圖片大小限制

  • Android 有api去除攝像頭相機拍照的選項

  • iOS 無法直接去除,只能經過環境判斷,動態觸發自定義函數,直接跳轉到相冊,選擇完成後返回base64數據
    客戶端直接使用base64類型的數據判斷文件大小,展現,最終上傳到服務端也是base64方式的

// 前端    
        function selectDeviceImg(){
            console.log('selectDeviceImg');
            if (window.webkit) { // iOS
                window.webkit.messageHandlers.Photo.postMessage(null);
            } else { // Android and others
                $("#file_head").trigger("click");
            }
        }
        
        // 服務端是這樣子的
        @ResponseBody
        @RequestMapping(value = "/upload", method = RequestMethod.POST)
        public Result uploadImage(@RequestParam(required = true) String imageBase64,
                                  @RequestParam(required = true) String projectId) {
                                  ...
                                }

h5與native交互方式

  • Android 經過WebView對象自定義的AndroidObjec注入到頁面,頁面調用AndroidObjec
  • iOS 實現機制相似,也是在UIWebView裏面建立了一個對象,頁面上直接給這個對象發送消息
// 假如在iOS中 
  if (window.webkit) {
       // iOS post message 的方式
       window.webkit.messageHandlers.Signature.postMessage(null);
    } else if (typeof AndroidJSObj != "undefined") { 
        // AndroidObjec 方式  
        AndroidJSObj.getSignature();
    }
  • URL攔截的實現思路:Android和iOS的webview都在監聽url的調轉事件,攔截到後,不作跳轉,
    直接執行本地的邏輯,在實現語音播放的時候用到這個技巧,這個技巧原本是作頁面跳轉時使用的,
    客戶端攔截到url跳轉到對應的 Controller或是Activity,若是是瀏覽器h5直接跳轉到對應的html頁面

  • 另一種WebViewJavascriptBridge的庫: https://github.com/marcuswestin/WebViewJavascriptBridge 1萬多個start通過實戰考研,後續項目中可使用這個提高效率

瀏覽器返回問題:history

頁面中有一個功能就是上傳圖片,這個功能會覆蓋現有頁面的背景,上傳頁面是一個html,完過後直接location.href跳轉到了另外一個,如今整個頁面嵌入在app裏面有返回按鈕,但如今不想讓頁面返回到上傳頁面,
試了 location.replace 也無論用,這個方法在移動端很差用,並且還存在另外一個問題就是在iOS須要點擊兩次返回按鈕才能退出webview。

這個功能上也調試了很久,最後也是讓客戶端處理了,監聽頁面返回在指定頁面點擊返回鍵直接推出

總結:嵌套h5的時候儘可能使用單頁面的佈局方式,方便管理,或是用react,vue這種都有對應的路由插件,這裏也暴露了前端技能二把刀,遇到這種叼酸的bug就搞不定

屏幕像素與真實像素轉換

以前一個帖子寫過,背景是充滿屏幕的,場布上是有點位的,長按能夠添加點位,點位的定位算法就比較重要:

核心就是:計算點位在原始圖片的left,top位置,在不一樣分辨率上等比展現

設備分辨率: 300600
圖片分辨率: 600
1200

點在屏幕上的位置是(left,top):(30,60)
對應到圖片上原始像素就是(left,top):(60,120)

在另一個設備分辨率是: 200*400的話
圖片上原始像素:(60,120),存在數據庫,前端展現會返回
在此設備上對應的位置就是:(20,40)

我這裏爲了方便演繹參數值通過調整,大概意思就是這樣

網絡異常的處理,loading...,成功失敗

全部Ajax請求剛開始的時候沒有使用一個統一的異常處理,請求開始加loading...,出錯或網絡異常,取消loading,提示業務異常或網絡異常,這塊應該提前規劃,再有相似需求必定注意

網頁認證受權的問題

ajax api 的認證方式是目前考慮到3種:

  • 本身按照必定規則md5計算出來的,根據時間戳算一個不可逆的簽名,客戶端算好,調用h5傳給頁面,發送ajax時放在header裏面(目前是這種)

  • 我以前實現過一種思路是使用md5和base64一塊兒算好以後放在cookie裏面,頁面發送的時候帶上cookie,計算過程任然在客戶端,客戶端計算完成調用h5的js函數,而後在發起ajax請求,由服務器驗證,驗證經過返回json

  • OAuth2 標準不解釋了,這個服務暫時尚未本身搭建過卻是用過別人的,後續也會單獨學習這塊把這個技能點補充上來

關於移動前端開發效率

Jquery 爲主的開發方式還能夠在優化
Jquery 效率比起 mvvm 的vue,react 代碼效率要低,可是比較簡單,目前代碼已經接近2000行功能再要疊加確定是要混亂起來,改很差改,修很差修,除了我每人敢動

css3 與前端工程實踐的積累不足
在瀏覽器返回,手機相冊選取,樣式兼容性展現顯示出不少力不從心的感受,只能是你們一塊兒協做解決,或是workaround 用曲線救國的方式實現,這塊其實沒辦法,主力沒有在前端,只能遇到問題多總結,多去實踐才行

移動端觸控庫選擇

  • hammer.js 作手勢交互和點擊,長按的操做簡直太棒,這個庫1024!
  • 其實回過頭來說,js開發庫不應用jquery應該用 zepto.js,它自己是爲移動端而生,jquery 在移動端點擊事件處理有不少問題,好些時候不能響應,只能用touchstart,touchend來觸發,可是使用touch事件會發生不少誤操做和無觸碰,體驗不是很好

UI 框架和樣式庫的選擇

前面說過css不是很溜,不但願本身花時間在前端樣式上,因此尋找一個合適的UI庫是尤其重要的,這裏我選擇的是mui https://github.com/dcloudio/mui/
Bootstrap4 一些基礎樣式
iconfont 免費的icon

** 模態彈層layui **
使用的 layer.js的移動版很是好用,解決了移動端模態彈層的問題,推薦你們使用:
https://layer.layui.com/mobile/

tmpl
前端模板老組件了,雖然比起mvvm遜色很多,好在夠用

滾動穿透

  • 這裏有一些詳細的解釋,其實在模態彈窗那裏也沒有解決滑動穿透的問題
    https://uedsky.com/2016-06/mobile-modal-scroll/

** 點擊300毫秒延遲問題 **
在iOS端尤其強烈,這裏放兩個連接解釋下,原因,解決方案不少自行搜索

* 爲啥會有300毫秒延遲?
 https://thx.github.io/mobile/300ms-click-delay
 https://stackoverflow.com/questions/12238587/eliminate-300ms-delay-on-click-events-in-mobile-safari

動態播放音頻的問題

H5頁面動態播放音頻,在iOS一直沒有弄好,多是頁面動態添加音視頻的緣故,動態播放一直有問題,從測試結果來看是咱們本身的音頻文件服務器不穩定致使的,沒法動態預覽mp3語音文件,只能經過調用原生app的方法播放聲音

  • 但音頻播放問題
    https://www.ibm.com/developerworks/cn/web/wa-ioshtml5/index.html

  • 下面是幾個播放音頻比較好的庫
    https://github.com/goldfire/howler.js#examples
    https://github.com/mediaelement/mediaelement
    https://github.com/CreateJS/SoundJS

上線時間點

原本說是8月15號上線,延期到8月底上線,可是因爲我弄了兩天發佈腳本,研究了一天的部署環境,沒有儘早提測,可是感受主要是沒有溝通到位,我從其餘處得知此次功能要在月底一次發版,我就沒在乎,沒有繼續推動這個事,又在打磨一些細節,一個是調試音視頻播放,一個是調試window.hostory接口嘗試解決頁面返回的問題,最後沒解決和客戶端協商解決,所以耽誤了時間,下次在商談好時間節點後要儘可能按照時間節點來進行活動安排,時間點關鍵點要多溝通,上仍是不能上,仍是延期上都要有個明確的結論。

是時候升級一下前端技術棧了:VUE

相關文章
相關標籤/搜索