此篇接上一篇:
移动端 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 (Windows.webkit) { // iOS
- Windows.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 (Windows.webkit) {
- // iOS post message 的方式
- Windows.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://Stack Overflow.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
下面是几个播放音频比较好的库个人十分推荐 howler.JS 后续有类似需求也会直接使用这个库
- https://GitHub.com/goldfire/howler.JS#examples
- https://GitHub.com/mediaelement/mediaelement
- https://GitHub.com/CreateJS/SoundJS
上线时间点
本来说是 8 月 15 号上线, 延期到 8 月底上线, 但是由于我弄了两天发布脚本, 研究了一天的部署环境, 没有尽早提测, 但是感觉主要是没有沟通到位, 我从其他处得知这次功能要在月底一次发版, 我就没在意, 没有继续推进这个事, 又在打磨一些细节, 一个是调试音视频播放, 一个是调试 Windows.hostory 接口尝试解决页面返回的问题, 最后没解决和客户端协商解决, 因此耽误了时间, 下次在商谈好时间节点后要尽量按照时间节点来进行活动安排, 时间点关键点要多沟通, 上还是不能上, 还是延期上都要有个明确的结论.
来源: https://www.cnblogs.com/buoge/p/9691573.html