移动前端开发和 Web 前端开发的区别

pc，咱们须要考虑什么呢？有点开发经验的同窗都知道，ie6-11，firefox，chrome，safari都得兼容的吧。哪一个都够你吃一壶的，不管是css仍是js。
mobile的网页开发，咱们须要考虑什么呢？
就目前来讲，咱们只须要考虑webkit内核的浏览器和chrome，uc，qq，小米手机浏览器

ok，单纯说pc和移动端开发的区别，其实也就是这个，能够简单的归纳来讲，mobile端的网页开发比pc端的网页开发，更简单一些。【页面小了啊，装的东西少了，css和html写的少了吧】交互简单一些【滑动，触屏，手势，平时看看手机你还能有啥特殊操做？】

做者：小爝
连接：https://www.zhihu.com/question/20269059/answer/60767669
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

移动端web app开发与套壳开发区别。

移动端web app，移动端网页，Hybrid开发【我喜欢叫套壳开发工程师……】，无所谓叫什么，移动端开发无疑就是这3种了。下面一一解释下个人理解。

移动端web app是什么呢？简单理解就是页面头部加入了下面这一句话的东西：

<meta name="apple-mobile-web-app-capable" content="yes">

这个meta的做用是让普通移动网页被添加到主屏幕后，拥有一些类native的功能，不少同窗应该都很熟悉了。就是相似隐藏ios的上下状态栏，实现全屏，禁止弹性拖拽，全屏，修改顶部颜色等。

我理解这种模式的网页为web app，固然还有一种类型就是你们平时都访问的那些网站，好比手机taobao，手机美团，手机微博的网页版，你们打开的时候，不是全屏的，可是用起来，开发者把它们假装的很像这种web app的交互体验而已。

以上2种我以为能够总结为web app。而不是普通的移动端网页，若是想看移动端网页，能够参考手机新浪网，手机网页，手机腾讯新闻，手机凤凰，是很好的对比。

以后我来讲下套壳的吧。这部分若是没有开发过phonegap或者相似和native连调过webview的同窗，可能以为很陌生，其实不是，这种套壳开发和开发普通的网页没什么区别，只不过资源大部分是file开头的，本地资源，网络资源分为使用js异步接口获取和native获取，再和js的接口交互，相似ios中，能够直接在oc或者swift能够直接在webview中执行js，android同理，可是js想调用native功能怎么办呢？

咱们这边的作法是有一个负责通信的iframe，咱们经过修改这个iframe的url，来让native来监控一系列特殊的url地址请求，再在native中调用对应的功能，好比摄像头，特殊交互，呼起，或者提供接口数据。数据的提供方式相似jsonp的原理，在执行函数的参数中传回来。

理解了这块，其实作套壳的比作普通web app和网页都简单，由于在native的webview中是能够指定是什么版本的webview，用什么内核，拥有什么等级的安全权限等等，ios和android作法不同，可是原理一致，对于前端开发工程师来讲是无差的。

并且套壳开发还有个好处就是，由于资源是本地化的，因此可使用比较重的框架，如angular，react，一些三方框架，由于最终都是经过和native代码捆绑发布的。

套壳native的静态前端部分的更新，咱们可使用远程下载静态资源包的方法实现，不发布大版本而修改webview中逻辑的需求，这一点也是大部分公司选择一半native一半h5来开发的缘由。都知道ios审核发版很慢。

这些就是我知道的一些很通俗的区别了，技术细节就不说了，太多。你们有个概念就好啦。

3，对js和css的使用选择。

这部分我提早预警，这是我本身的见解，不必定是正确的，你们互相讨论。

个人想法是不使用目前那些主流的移动端框架，选择手写。我会说为何。
好比jq mobile，zepto，backbone，angular，还有相似工具集，underscore，一些动画框架，还有小型的游戏框架，通通实际上是不太须要的。

我并非说他们很差，而是这些对于新手来讲，只能是阵痛药，而不是万能药。为何呢，移动端的优化很大的一个瓶颈就是网络加载速度不一致，有wifi，有3g，有4g，还有2g。代码量在移动端开发是很大的一个考察点。

咱们反观这些框架：zepto最早说，你用它作什么？动画？选择器？事件委派？基于zepto的插件？可能大部分人就是用个选择器吧。可是移动端的原生选择器方法应有尽用，原生的彻底够用，包括事件和委派，一共写起来不超过10几行的东西，引入一个框架不值得。再说mvc的框架，若是不使用离线存储，我是反正不敢想没wifi的状况下体验如何，外加移动端真的是否须要分层这种处理不说，主要仍是看业务场景。

套壳的那种上面说了，框架随便用，由于足够复杂，可是普通移动端开发，我我的是不推荐使用的，能够直接上原生的来写，最多来一个模块化工具。我下面就说说本身是怎么作的吧。

手机端对ES5的特性已经所有都支持的很好了，参考：
xiaojue/ES-shim · GitHub
这里的api特性，只实现了一部分，可是其实平时对数据的处理，对象的处理，已经彻底足够。我不说优缺点，我只说，移动端这些都是纯自然的而已。

而后是咱们对手势的处理，zepto中有几个颇有用的事件，swipe，swipeLeft，right，up，down，一类的，还有tap，咱们能够看下zepto的源码：
zepto/touch.js at master · madrobby/zepto · GitHub
咱们真的全部场景都须要全部的功能么，tap，doubletap，有多少人用了。。用到的时候，也是很是好实现的功能。我推荐直接手写，或者本身写一个swipe的基类，也不会比zepto的touch.js多太多，而好处是咱们可让它贯穿咱们的项目，做为一个base类使用，固然我不是喷zepto多余，它不少代码作了兼容处理，可是就目前咱们的业务来讲，咱们只须要考虑webkit，只须要考虑几个特定国产浏览器，由于这是统计数听说了算。

没了框架，咱们就不能写代码了么？移动端开发，我以为更考验的是前端的基本功，只要基本功扎实，其实都是很简单的需求，正由于都是本身一行一行写的，遇到诡异问题就更好解决，而再也不须要纠结于，究竟是我作错了，仍是框架错了这个问题。

我不止一次的修改过iscroll的源码来适应和“知足”咱们的测试。。。好比ios下用了iscroll，a标签没法点击跳转，不少人遇到过吧，不看文档你还真是一时不知道怎么解决，iscroll因为禁止了页面原生的滚动，不少原本很简单得东西复杂化了，而咱们须要的是什么？一个下托刷新？一个惯性滚动特效？开什么玩笑，原生的也没几行啊。。。对于一个写了多年pc端的前端来讲我相信徒手写个下托刷新禁止页面惯性反弹的代码，应该不复杂吧？这里给个思路，好比咱们检测touchmove的位置快到达页面【或者容器】底部的时候，阻止touchmove，作容器或者页面translate移动，再在下部埋一个loading，touchend以后再作缓动回复，应该普通前端都能作到。

再说一个经常使用的移动端框架，swipe.js 作幻灯用的，我相信幻灯片作pc端得前端应该每一个人都写过不下5遍了吧。只是事件换了，固然移动端有移动端本身须要处理的问题，可是我使用swipe框架的经历也是很痛苦的，好比没法很好的设置滚动过的距离，自定义缓动效果，还有没法它本身自己带的一些问题，好比横竖屏的时候复位问题，动态插入子节点重排等，让我第一次用的时候越开发越伤心，后来干脆也是本身实现。

因此其实，1，咱们的需求，那些移动端框架不必定知足咱们。2，太大，太复杂，太难调试。3，需求其实自己不复杂，只是咱们想偷懒了。

有点跑题，这个标题说是js和css的选择，js的立场我足够明确了，若是简单功能，不须要js框架，原生足够，已经作得很好，下面说说css。

首先，作pc咱们都须要一个reset或者common，我共享下咱们的，
https://gist.github.com/xiaojue/8bac56fb488532e7857f
固然里面有一些咱们特殊的颜色字体，我css并非特别好，我简单的重复一下咱们css同窗的一些注意要点，可能不全：

这其中字体的选择是根据平台来作的，咱们平时用控制台模拟开发的时候是没有ios或者android系统字体的，可是你不设置又很丑，因此基本是从电脑支持，到移动端支持这个顺序排列的。

下面截图几个wiki：

还有不少，我只找一些我认为可能知道的人少一些的，咱们的wiki还有不少，我css并不太好，这部截自同事的wiki贡献。

css这个方面的东西，我很差多说，毕竟我认可我css通常，可是有几个原则能够提炼出来的就是：
1，不少坑的形成是对原生属性的掌握程度不熟练或者不知道有这个特性。
2，不少属性极限突破可使用缩放，倾斜这种手段来hack，好比最小字体，好比各类本身画的伪类图标。
3，能css画的不要用图。
4，大小须要自适应的图标作成字体的不要画。
5，能flex布局的不要用浮动，不要用绝对定位（不利于页面布局的扩展）

原本还有几个比较典型得css案例，这个找机会在其余答案里说吧，都是上周css比较屌的同事分享的，我也受益不浅。总说就是移动端的css的写法和pc相差甚远，并且技术含量更高了，可喜的是兼容性问题少了，更多的是如何处理的更好扩展和精简。

4，模块化移动端的常见组件。

我只说咱们非业务方面的，能够抽象出来的，可能和公司业务场景挂钩。
1，touch对应的swipe事件。
2，各类滑动翻页效果。
3，简单的小游戏框架。
4，视频和音频的包装。
5，各类lazyload。
6，各类keyframes效果收集。
7，拉拽刷新。

其实不少pc要有的mobile端也都有，好比浮层，tip，气泡，分享，添加主屏一类，可能和业务关联太多，就不一一列举了。这部分的组件其实市面上也没有太多开源的比较简易的，大部分都是又支持pc，又支持mobile，致使了不少冗余，或者质量和需求，api不过关，致使很难扩展，各家都是本身写。好比在微信的webview里分享和在qq的webview分享，和在普通页面的分享，在微博的webview里分享，提示和实现的方法都不同，可是其实彻底都是能够抽象成一个公共的东西的，个人团队也在作这方面积累。

这个再安利一下，我作的一个作划屏活动页的组件：
xiaojue/EasySlide · GitHub
慢慢我也会开源咱们内部抽象好的移动端组件出来的。

5，移动端的性能优化和统计。
性能优化必须创建在统计的基础上，不然都是耍流氓，因此先说统计。

目前个人作法和pc差很少，监控一些前端关注的时间点，首屏，doc ready，window ready，css ready，实现统计方法和pc也都同样，应该各个公司都有，我简单说下前端实现首屏统计如何作：

个人思路是，首屏的图加载完，即首屏完成，首屏无图，最接近首屏的dom节点ready的时间点为首屏时间，咱们能够在load的时候和document ready的过程之间检测这几个临界，来收集首屏的完成时间，固然很不许啦，可是也是有一些参考价值的。。。

有了数据，我说一下移动端的统计极值问题，举个例子，咱们手机打开一个网页，尚未load完成，切到了后台，这个时候脚本是不会执行的了，过了几小时，几天再回来的数据，咱们都能收集到，这部分属于垃圾数据，是须要算平均值的时候去除的。这点和pc不太同样。

而后是性能优化创建在均值性能指标上的，咱们尽快的提高首屏和win load的时间便可，原则和作法和pc一致，固然，移动端不是资源越合成一个越好，咱们的实践是分散成不一样的几个资源下载，总时间比较快，好比活动页面，h5小游戏页都是这样。能够统一把资源图拆开加载，而后增长loading便可。

----我还在奋力思考和编写中-----今天先到这里了。。。。【这里还有一个点，我想讨论一下是mobile的cache的利用率问题，这个明天我详细说，决定找些权威的数据或者本身作下测试再开始写】

6，移动端网页布局方法与pc的差别。

主要是css方面，外加如何作到同一url，不一样客户端展示不一致的作法，俗称pc和mobile都兼容。还有会说一下rem的相关用法和一段比较经典的rem.js

今天有空来更新一下这个rem在移动端布局的一个用法：）（20151013更新）

首先，em和rem的概念我简要说一下，em是父元素fontsize的倍数表示，rem则是root即为html的fontsize的倍数表示。好比我html.style.fontSize = 12px;那么1rem则为12px，0.5rem为6px；

好了，概念有了，那么作布局的时候咱们怎么用呢，你们应该用过的都知道，移动端的字体默认为16px，那么1rem我想表示为10px的话，咱们就须要 10 % 16 = 0.625 即为62.5%，这样就能够比较方便的把设计稿里的px转换成rem单位来作到自适应了。这样不管用户如何设置电脑或者手机的默认字体大小，设置为rem的单位的长度都会随比例变化。

这是一种常规作法，其实换个角度咱们还能够这样用：

咱们想象一个设计稿宽度为640，800，1200px等尺寸时，咱们如何来快速完成响应式的布局呢？
百分比？flex？这些仍是有些复杂的。

后来发现，栅格等比缩放整个设计稿看起来是个更简单粗暴的方法。并且正好能够利用rem这个比例变化单位。

看下这段js：
https://gist.github.com/xiaojue/0615797dd6a7160177bd

比较好理解，咱们首先根据psd的设计稿宽度设置一个基值，而后咱们js获取到当前窗口的宽度值，而后把这个设计稿宽度除以100栅格化一下，得到一份的宽度数，以后再用真实窗口的宽度除以这个一份的宽度，拿到就是咱们须要给html设置的fontsize的px值。

这样咱们只须要把对应psd里的px单位除以100，就获得了任何宽度环境下的rem值。固然实际发现有些浏览器这个rem单位是存在bug的，好比比例值不许，那么咱们就须要得到这个不许的比例再转换成准的再赋值html的fontsize，可见calcTestDom函数，以后再处理一下旋转屏幕时候的状况，resize时候的状况就行了。

这样咱们在作一些活动专题页面时，只须要引入这段js，在页头设置一个设计稿宽，而后对着设计稿一顿疯狂的px除100来定位就行了。。比设置成62.5%的方式要更好（1，修复了浏览器bug，2，转换单位更方便直观，px/100便可）

7，常见js组件与pc端组件差别。

这部分还在想怎么说比较通俗易懂，哪些组件是很是典型得，须要我回去慢慢想一想，找几个实际的对比例子。

8，一些常见的坑。

分享一下内部wiki的经典移动端坑和解决办法。（不会太多，别抱太大期待了。。）

9，适配【机型，浏览器】的方法和选择。
1，统计说话。
2，调试方法。

10，测试技巧与pc的差异。

做者：小爝 连接：https://www.zhihu.com/question/20269059/answer/60767669 来源：知乎 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。