此篇接上一篇:
移動端H5混合開發,Touch觸控,拖拽,長按, 滑屏 實現方案
https://www.cnblogs.com/buoge/p/9346699.html
app 場佈設定已經上線了,使用者可以通過手機端嵌入的h5網頁進行場佈設定,原來只能在pc端瀏覽器,還得帶上個膝上型電腦很是不方便,這個功能很好的解決了目前設定不順暢的問題。上線後得到大家的認可,提升了業務效率,這一個多月的辛苦開發還是值得的,接下來是對自己這一段時間開發過程的一個總結。
整體開發基於H5+Css3+Jquery,前端這個組合略顯過時,不過我就這個用的熟悉,先做完再說
前後端開發混合開發
功能前端和後端是一起開發的,好處是自己靈活定製不需要溝通成本,但是缺點也有前後端切換需要切換大腦思維的上下文,一會再寫JS一會回去寫Java不利於思維發揮和深入思考
後端開發過程中還好有現成的方法可以呼叫,所以並沒有耗費太多時間,大部分時間在前端開發上,假如後端也要做那才真是入水兩腿泥
總結:後續在有類似開發,不要大包大欖,專注一端去做,這樣高效省心,專注前端和專注後臺分工開發速度快了,效率高了,遇到難題有時間和情景去深入思考,所以儘可能把任務分開下
android iOS 與h5 互相呼叫的問題
H5呼叫相機圖片方向有問題:拍照是豎屏,展示成橫屏,上傳上去展示也是橫屏
這兩個帖子講的很清楚,我就不展開了,思路就是利用 exif.js 判斷方向,然後用CanvasApi從新生成base64
格式的圖片
-
H5拍照應用開發經歷的那些坑兒
http://www.yuuuuc.me/problems-with-html5-file-api-while-uploading-images/ -
利用exif.js解決ios手機上傳豎拍照片旋轉90度問題
https://blog.csdn.net/linlzk/article/details/48652635
原始碼放在了這裡:
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
圖片解析度: 6001200
點在螢幕上的位置是(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