此篇接上一篇：

移動端H5混合開發(fā)，Touch觸控，拖拽，長按, 滑屏 實現(xiàn)方案
https://www.cnblogs.com/buoge/p/9346699.html

app 場布設(shè)置已經(jīng)上線了，用戶可以通過手機端嵌入的h5網(wǎng)頁進行場布設(shè)置，原來只能在pc端瀏覽器，還得帶上個筆記本電腦很是不方便，這個功能很好的解決了目前設(shè)置不順暢的問題。上線后得到大家的認可，提升了業(yè)務(wù)效率，這一個多月的辛苦開發(fā)還是值得的，接下來是對自己這一段時間開發(fā)過程的一個總結(jié)。

整體開發(fā)基于H5+Css3+Jquery,前端這個組合略顯過時，不過我就這個用的熟悉，先做完再說

前后端開發(fā)混合開發(fā)

功能前端和后端是一起開發(fā)的，好處是自己靈活定制不需要溝通成本，但是缺點也有前后端切換需要切換大腦思維的上下文，一會再寫JS一會回去寫Java不利于思維發(fā)揮和深入思考

后端開發(fā)過程中還好有現(xiàn)成的方法可以調(diào)用，所以并沒有耗費太多時間，大部分時間在前端開發(fā)上，假如后端也要做那才真是入水兩腿泥

總結(jié)：后續(xù)在有類似開發(fā)，不要大包大欖，專注一端去做，這樣高效省心，專注前端和專注后臺分工開發(fā)速度快了，效率高了，遇到難題有時間和情景去深入思考，所以盡可能把任務(wù)分開下

android iOS 與h5 互相調(diào)用的問題

H5調(diào)用相機圖片方向有問題：拍照是豎屏，展示成橫屏，上傳上去展示也是橫屏
這兩個帖子講的很清楚，我就不展開了，思路就是利用 exif.js 判斷方向，然后用CanvasApi從新生成base64
格式的圖片

• H5拍照應(yīng)用開發(fā)經(jīng)歷的那些坑兒
  http://www.yuuuuc.me/problems-with-html5-file-api-while-uploading-images/

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

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

相冊調(diào)用去攝像頭，圖片大小限制

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

• iOS 沒法直接去除，只能通過環(huán)境判斷，動態(tài)觸發(fā)自定義函數(shù)，直接跳轉(zhuǎn)到相冊，選擇完成后返回base64數(shù)據(jù)
  客戶端直接使用base64類型的數(shù)據(jù)判斷文件大小，展示，最終上傳到服務(wù)端也是base64方式的

// 前端 function selectDeviceImg(){console.log('selectDeviceImg');if (window.webkit) { // iOSwindow.webkit.messageHandlers.Photo.postMessage(null);} else { // Android and others$("#file_head").trigger("click");}}// 服務(wù)端是這樣子的@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注入到頁面，頁面調(diào)用AndroidObjec
• iOS 實現(xiàn)機制類似，也是在UIWebView里面創(chuàng)建了一個對象，頁面上直接給這個對象發(fā)送消息

// 假如在iOS中 if (window.webkit) {// iOS post message 的方式window.webkit.messageHandlers.Signature.postMessage(null);} else if (typeof AndroidJSObj != "undefined") { // AndroidObjec 方式 AndroidJSObj.getSignature();}

• URL攔截的實現(xiàn)思路：Android和iOS的webview都在監(jiān)聽url的調(diào)轉(zhuǎn)事件，攔截到后，不做跳轉(zhuǎn)，
  直接執(zhí)行本地的邏輯，在實現(xiàn)語音播放的時候用到這個技巧，這個技巧本來是做頁面跳轉(zhuǎn)時使用的，
  客戶端攔截到url跳轉(zhuǎn)到對應(yīng)的 Controller或是Activity,如果是瀏覽器h5直接跳轉(zhuǎn)到對應(yīng)的html頁面

• 另外一種WebViewJavascriptBridge的庫: https://github.com/marcuswestin/WebViewJavascriptBridge 1萬多個start經(jīng)過實戰(zhàn)考研，后續(xù)項目中可以使用這個提升效率

瀏覽器返回問題：history

頁面中有一個功能就是上傳圖片，這個功能會覆蓋現(xiàn)有頁面的背景，上傳頁面是一個html,完事后直接location.href跳轉(zhuǎn)到了另一個，現(xiàn)在整個頁面嵌入在app里面有返回按鈕，但現(xiàn)在不想讓頁面返回到上傳頁面，
試了 location.replace 也不管用，這個方法在移動端不好用，而且還存在另一個問題就是在iOS需要點擊兩次返回按鈕才能退出webview。

這個功能上也調(diào)試了好久，最后也是讓客戶端處理了，監(jiān)聽頁面返回在指定頁面點擊返回鍵直接推出

總結(jié)：嵌套h5的時候盡量使用單頁面的布局方式，方便管理，或是用react,vue這種都有對應(yīng)的路由插件，這里也暴露了前端技能二把刀，遇到這種叼酸的bug就搞不定

屏幕像素與真實像素轉(zhuǎn)換

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

核心就是：計算點位在原始圖片的left,top位置，在不同分辨率上等比展示

設(shè)備分辨率： 300600
圖片分辨率： 6001200

點在屏幕上的位置是（left,top）：（30,60）
對應(yīng)到圖片上原始像素就是（left,top）：(60,120)

在另外一個設(shè)備分辨率是： 200*400的話
圖片上原始像素：（60，120），存在數(shù)據(jù)庫，前端展示會返回
在此設(shè)備上對應(yīng)的位置就是：（20，40）

我這里為了方便演繹參數(shù)值經(jīng)過調(diào)整，大概意思就是這樣

網(wǎng)絡(luò)異常的處理，loading...,成功失敗

所有Ajax請求剛開始的時候沒有使用一個統(tǒng)一的異常處理，請求開始加loading...,出錯或網(wǎng)絡(luò)異常，取消loading,提示業(yè)務(wù)異常或網(wǎng)絡(luò)異常，這塊應(yīng)該提早規(guī)劃，再有類似需求一定注意

網(wǎng)頁認證授權(quán)的問題

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

• 自己按照一定規(guī)則md5計算出來的，根據(jù)時間戳算一個不可逆的簽名，客戶端算好，調(diào)用h5傳給頁面，發(fā)送ajax時放在header里面（目前是這種）

• 我之前實現(xiàn)過一種思路是使用md5和base64一起算好之后放在cookie里面，頁面發(fā)送的時候帶上cookie,計算過程任然在客戶端，客戶端計算完成調(diào)用h5的js函數(shù)，然后在發(fā)起ajax請求，由服務(wù)器驗證，驗證通過返回json

• OAuth2 標準不解釋了，這個服務(wù)暫時還沒有自己搭建過倒是用過別人的，后續(xù)也會單獨學(xué)習(xí)這塊把這個技能點補充上來

關(guān)于移動前端開發(fā)效率

Jquery 為主的開發(fā)方式還可以在優(yōu)化
Jquery 效率比起 mvvm 的vue,react 代碼效率要低，但是比較簡單，目前代碼已經(jīng)接近2000行功能再要疊加肯定是要混亂起來，改不好改，修不好修，除了我每人敢動

css3 與前端工程實踐的積累不足
在瀏覽器返回，手機相冊選取，樣式兼容性展示顯示出很多力不從心的感覺，只能是大家一起協(xié)作解決，或是workaround 用曲線救國的方式實現(xiàn)，這塊其實沒辦法，主力沒有在前端，只能遇到問題多總結(jié)，多去實踐才行

移動端觸控庫選擇

• hammer.js 做手勢交互和點擊，長按的操作簡直太棒，這個庫1024！
• 其實回過頭來講，js開發(fā)庫不該用jquery應(yīng)該用 zepto.js,它本身是為移動端而生，jquery 在移動端點擊事件處理有很多問題，好些時候不能響應(yīng)，只能用touchstart,touchend來觸發(fā)，但是使用touch事件會發(fā)生很多誤操作和無觸碰，體驗不是很好

UI 框架和樣式庫的選擇

前面說過css不是很溜，不希望自己花時間在前端樣式上，所以尋找一個合適的UI庫是尤為重要的，這里我選擇的是mui https://github.com/dcloudio/mui/
Bootstrap4 一些基礎(chǔ)樣式
iconfont 免費的icon

** 模態(tài)彈層layui **
使用的 layer.js的移動版非常好用，解決了移動端模態(tài)彈層的問題，推薦大家使用：
https://layer.layui.com/mobile/

tmpl
前端模板老組件了，雖然比起mvvm遜色不少，好在夠用

滾動穿透

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

** 點擊300毫秒延遲問題 **
在iOS端尤為強烈，這里放兩個鏈接解釋下，緣由，解決方案很多自行搜索

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

動態(tài)播放音頻的問題

H5頁面動態(tài)播放音頻，在iOS一直沒有弄好，可能是頁面動態(tài)添加音視頻的緣故，動態(tài)播放一直有問題，從測試結(jié)果來看是我們自己的音頻文件服務(wù)器不穩(wěn)定導(dǎo)致的，無法動態(tài)預(yù)覽mp3語音文件，只能通過調(diào)用原生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月底上線，但是由于我弄了兩天發(fā)布腳本，研究了一天的部署環(huán)境，沒有盡早提測，但是感覺主要是沒有溝通到位，我從其他處得知這次功能要在月底一次發(fā)版，我就沒在意，沒有繼續(xù)推進這個事，又在打磨一些細節(jié)，一個是調(diào)試音視頻播放，一個是調(diào)試window.hostory接口嘗試解決頁面返回的問題，最后沒解決和客戶端協(xié)商解決，因此耽誤了時間，下次在商談好時間節(jié)點后要盡量按照時間節(jié)點來進行活動安排，時間點關(guān)鍵點要多溝通，上還是不能上，還是延期上都要有個明確的結(jié)論。

是時候升級一下前端技術(shù)棧了：VUE

轉(zhuǎn)載于:https://www.cnblogs.com/buoge/p/9691573.html

總結(jié)

以上是生活随笔為你收集整理的移动端H5混合开发设置复盘与总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。