从零搭建移动H5开发项目实战

时间 2019-11-07

标签搭建移动 h5 开发项目实战栏目无线繁體版

原文原文链接

从零搭建移动H5开发项目实战

前端H5的前世今身

在Pc的时代，前端技术无疑统治了大多数用户的交互界面！而在移动为王的今天，NA开发在早期占领了大多数用户的交互界面，后来逐渐的前端H5开发找到了本身的技术优点，慢慢的后来居上。css

前端H5的优点有：

轻松的热更新，（无需等待用户漫长的更新时间）html
code once，run anyway，（极大缩短产品的开发时间）前端
丰富的社区、成熟的技术栈和人才储备web

与此同时也面临了许多难题，好比：

性能问题（在低端机型上不够流畅，点击延迟等）chrome
兼容性问题（不只要适配各类各样的屏幕，还要面对各种厂商对系统浏览器进行篡改引起的兼容性问题）bootstrap
加载时间浏览器

平起平坐

至此前端H5和NA开发造成了一种互补的关系，各有本身的适用场景和本身的优劣之处：微信

H5适合作活动页，运营页，简单的展现页。（支持浏览器的地方就能展现，就能使用）架构
H5适合作产品最小原型，开发效率快（一份代码跑两个平台）iphone
H5适合还不成熟须要频繁迭代的产品

移动开发之荡

移动h5开发和桌面web开发有许多不一样的地方，一个传统的桌面web开发工程师，若是没有通过必定的学习和尝试没法开发出适应移动web的应用。
那移动开发相较于传统web开发有哪些避无可避的难点呢?接下来我将结合在BANFF项目中的实践来分别介绍这些移动h5开发中的难点以及如何解决这些难点。

难题一：浏览器默认样式

不一样系统+不一样品牌+不一样版本的浏览器都会有各类各样本身的默认样式，不少时候若是忽视浏览器的默认样式会致使显示样式上出现兼容性问题，有的时候可能在某些机型上看上去很好，可是换了一个机型却显示又不正常。

在桌面web时代

前端要适配的浏览器有限（有IE，火狐，chrome，360等）。这个时候咱们能够不考虑这些默认的样式，毕竟不一致的地方较少。这个时候能够采用常规的css normall，将各个浏览器的css显示差别控制在必定范围内，这样既能保留平台的特点UI展现，又能避免出现兼容性问题。

移动h5时代

在移动h5上状况就不同了，手机系统多种多样，浏览器平台数不胜数。若是不严格控制住浏览器的默认样式，显示的兼容性问题就比较严重了。

在BANFF项目中咱们对比了 css normal 和 css reset 两种方案，最终采用了css reset 技术，由于在测试过程当中咱们发现，采用css normal方案去开发移动h5，总会遇到有一些机型的样式没法贴合UE图的效果，因此咱们采用css reset将各个平台的css显示差别都抹平，这样就无需考虑浏览器的默认样式了。虽然方法简单粗暴，可是对移动h5开发来讲却很是管用。

css reset方案的核心代码
IE下不一样版本的默认样式摘要

难题二：屏幕适配

如何适配数不清的屏幕尺寸，曾经是困扰前端开发人员的一大难题。

浏览器占比：
主流的屏幕类型：

看了以上的浏览器占比和主流的屏幕类型就知道屏幕适配对前端开发来讲是一个多大的问题了。

在屏幕适配这个问题上，曾今出现了许多优秀的解决方案：

最开始的基于media技术的响应式布局

bootstrap样式库采用了这套适配方案，这套方案的核心思想是将屏幕分为三种类型，搭配上栅格系统，咱们可以写出同时兼容移动端小屏幕和pc大屏幕的页面。

移动端适配方案分为几个派别：

固定高度，宽度自适应

这是目前使用较多的方法，垂直方向用定值，水平方向用百分比、定值、flex都行。腾讯、亚马逊、搜狐的首页都是使用的这种方法。
这种方法使用了完美视口：

<meta name="viewport" content="width=device-width,initial-scale=1">

固定宽度，viewport缩放

这种方案：设计图、页面宽度、viewport width使用一个宽度，浏览器帮咱们完成缩放。单位使用px便可。

原理是根据屏幕宽度来动态生成viewport，生成的 viewport 基本是这样：

<meta name="viewport" content="width=640,initial-scale=0.5,maximum-scale=0.5,minimum-scale=0.5,user-scalable=no">

rem作宽度，viewport缩放

这种方案是目前业界比较承认的一种方案，也是吸收了其余方案的长处再进行改良的一种方案
原理有如下三点：

动态的生成 viewport；
屏幕宽度设置 rem的大小，即给<html>设置font-size；
根据设备像素比（window.devicePixelRatio）给<html>设置data-dpr

rem 适配效果

经过fekey转换来避免手写rem

在BANFF项目中咱们比较了以上的几种适配方案

首先响应式布局的解决方案没法实现真正的移动适配，它的适配只能解决pc大屏幕到手机小屏幕的问题，可是手机屏幕任然有不少种，这个时候基于响应式布局的来写页面会发如今Iphone6下看上去和UE效果图一致，但到了iphone5s下按钮之间的间距和UE效果图就差不少，更不用说Iphone4s和其余一众Android机型了

而rem方案可以解决小屏幕的适配问题，由于它的显示单位rem是随着屏幕大小，rem方案比（固定宽度，viewport缩放）来讲有优点的地方是可使用两种不一样的单位，想让元素适配的时候就用rem，想让文字不缩放的时候就用px。好比1px的线rem就能轻松搞定，而其余方案不行。好比一些文字咱们并不但愿它适配，由于部分字体适配后会显示出毛边，这个时候用px能实现不适配的效果。rem的不足之处是咱们在书写样式的时候要手动将UE的标注转化成rem。

最终咱们采用了wmflex 基于（rem作宽度，viewport缩放）的解决方案，很好的实现了适配各种屏幕。同时采用了fekey（px To rem）来解决书写rem不方便的问题，这样咱们在写样式的时候只要和按照UE标准的
750px来就好了，fekey会自动帮助咱们转为rem。通过测试在低端的Android机上或者是dpr等于2的IPhone6s和dpr等于3的IPhone6s plus都能很好的按照交互图来展现。

能够说基于rem适配原理的这一套解决方案，咱们已经可以轻松适配各类类型、各类大小的屏幕。

难题三：点击延迟

web开发对鼠标有一套完整的事件支持，可是对移动系统上的点击，触控，滑动的事件支持并不完善。就拿最多见的点击来讲，h5就有过很长一段时间的很差体验。

点击延迟，对于早期的h5开发能够说是致命的，相较于native的流畅来讲，h5的300毫秒的点击延迟几乎是不可接受的。

业界经常使用的方法是采用将touch事件来进行一系列封装，进而得出一套触控Api来。

fastclick就是通过大量优化的去除点击延迟解决方案。原理是hook了浏览器的touch事件来模拟click事件，让前端开发人员以熟悉的click来书写代码

除了点击事件，滚动、滑动、多点触控，这些浏览器不原生提供的能力都须要咱们用代码去模拟出来。

在BANFF项目中采用较常规的解决方案fastclick来去除点击延迟，在之后的项目中若是遇到更复杂的交互需求，会采用更具扩展性的hammerjs来处理各类各样的触碰需求。好比滑动、旋转、多点触碰。

难题四：mock与调试

H5页面运行环境多样，若是仅仅是经过报错后弹出alert框这种形式去调试的话，开发效率会下降不少。

首先H5页面确定是能运行在Pc Chrome上的，借用Chrome的成熟调试体系效率会提升不少；可是咱们要考虑到NA内嵌的webview，其中js代码的运行时机要依赖websdk的加载。没法简单的将h5应用拿到chrome上调试。而且除了经常使用的waimaiApp端，还要考虑微信端，或者是Banff端。因此咱们要有一套mock机制，在Pc端上走Mock的代码，在NA端或者微信端上走端对应的代码。

一种较好的代码架构思路是咱们提供一个Adapter层，Adapter层对业务代码提供一致的接口，而后Adapter根据不一样的使用场景对接不一样的端代码

有了Adapter层后咱们根据什么来判断当前代码运行在什么端呢？比较常见的方法是经过浏览器的ua来进行判端。若是担忧代码的体积问题，咱们也能经过fekey或其余打包工具，在打包阶段，打包出不一样端对应的代码。这样能减小代码的加载时间和体积。

总结和展望

移动h5开发有许多难点，这些难点若是传统web开发人员不去学习和了解就会踩坑。对于一个从零开始的移动端h5项目，我总结了以上这些移动开发难点，但愿以后的人能少踩点坑，站在个人肩膀上提升项目开发的效率和质量。以后咱们会结合fekey在项目初始化阶段把这些问题解决，产出一份移动开发的项目模板，替新人将这些坑踩平。