移动端网站如何开发(电脑端网站到手机端网站我们需要在html代码中添加哪个meta标签)

一、总结

一句话总结：

添加viewport标签：meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0"

添加viewport标签

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" />

详细属性：

width ---- viewport的宽度（width=device-width意思是：宽度等于设备宽度）height ------ viewport的高度（height=device-height意思是：高度等于设备宽度）initial-scale ----- 初始的缩放比例minimum-scale ----- 允许用户缩放到的最小比例maximum-scale ----- 允许用户缩放到的最大比例user-scalable ----- 用户是否可以手动缩放

1、移动端web app,移动端网页,Hybrid开发的区别？

移动端web app：加meta name="apple-mobile-web-app-capable" content="yes"，这个meta的作用是让普通移动网页被添加到主屏幕后，拥有一些类native的功能。就是类似隐藏ios的上下状态栏，实现全屏，禁止弹性拖拽，全屏，修改顶部颜色等。

移动端网页：普通的移动端网页，可以参考手机新浪网，手机腾讯新闻等等

Hybrid开发：和开发普通的网页没什么区别，只不过资源大部分是file开头的，本地资源，网络资源分为使用js异步接口获取和native获取，再和js的接口交互

2、Hybrid开发中js想调用native功能怎么办？

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

3、为什么说Hybrid开发(套壳)比做普通web app和网页都简单？

需要考虑的更少：在native的webview中是可以指定是什么版本的webview，用什么内核，拥有什么等级的安全权限等等

可用重框架：因为资源是本地化的，所以可以使用比较重的框架，如angular，react，一些三方框架，因为最终都是通过和native代码捆绑发布的

二、移动前端开发和 Web 前端开发的区别是什么？（转自知乎）

转自：移动前端开发和 Web 前端开发的区别是什么？ - 知乎

/question/20269059

我转了快2个月了，准备 谈谈感想。晚上回家吃完饭开更。

---------

看到这么多赞，不填坑对不起大家，但是本人水平有限，内容又太多太杂，今天先更新一部分，这几天较忙。之后慢慢补，谢谢大家支持和点赞。

有交流尽管留言，时间允许我会和你讨论，并列入本回答。

0827，9：49

---------

1，普通pc端开发与移动端开发区别。

先说背景，我大言不惭的说一下，我pc端的前端开发干了有快4年多，不算大牛，也算一个标准的前端开发工程师吧，可怜的是我之前做过的移动端项目不超过1个。。所以几乎经验为零。我对这个神秘又被炒的火热的名字迷惑了很久，移动前端开发工程师，h5前端开发工程师，native前端开发工程师，Hybrid前端开发工程师，卧槽感觉屌屌的有木有啊。。

所以我在决定弃坑了（pc的代码实在写腻歪了。。），投身到专属的移动开发中，业余时间也做过phonegap，也知道和了解过一些h5+native开发的方式，下面就慢慢给大家【科普】一下。。说错了别喷。

普通pc端开发，我理解就是你拿电脑打开的网页都算【这不是废话么】。

那么移动端前端开发工程师，说白了就很好理解了，做手机网页的前端开发工程师。

这么一比，是不是感觉，移动端开发简单多了？

没错，我转了之后发现还真是呢。。。【还有点小激动】

pc，我们需要考虑什么呢？有点开发经验的同学都知道，ie6-11，firefox，chrome，safari都得兼容的吧。哪个都够你吃一壶的，无论是css还是js。

mobile的网页开发，我们需要考虑什么呢？

就目前来说，我们只需要考虑webkit内核的浏览器和chrome，uc，qq，小米手机浏览器就好了。。。【后面特意会说这几只国产浏览器哪里屌了】

相比较而言，除了经验是0以外，需要兼容的东西还是少了，少了，少了呢。

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

so，别被这玩意吓坏了，根据我的经验来看，pc端的前端开发程序员，转mobile开发，一点问题没有，而且上手会很快。

够直白的解释了。

2，移动端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，我共享下我们的，

/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在移动端布局的一个用法：）（1013更新）

首先，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：

/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的差别。

几个比较经典的调试方法和工具介绍。

慢慢垒，先补提纲，5678910都没写。。。

三、HTML5移动端手机网站开发流程

转自：HTML5移动端手机网站开发流程-段亮个人博客

/learn/web/html5/304.html

最近一直在研究移动手机网站的开发，发现做手机网站没有想象中的那么难。为什么会这么说呢？我们试想下:我们连传统的PC网站都会做，难道连一个小小的手机网站难道都搞不定吗？其实手机网站就是一个微缩版的PC网站罢了！至于为什么觉得难、觉得无从下手。

段亮觉得有以下几点：

一、没有完整的思路和流程

就像做网站的流程一样，如果你能知道它的流程，我相信就不会觉得做手机网站难！真正难的是你没有思路。

二、把html5这门技术想的高深莫测

好像觉得学会用html5+css3做手机网站，就相当于学会了顶尖的绝世武功。其实你错了！不要把html5这玩意想的太高深，其实做手机网站，真正意义上用不到什么的html5的强大功能。(可能对于一些不懂什么技术的小白而言：你的手机网站是用HTML5+CSS3做的啊，简直牛逼呀！能用上目前互联网上最新最前沿的技术。其实明眼人一看，就知道是用什么技术做的。俗话说的好："外行看热闹，内行看门道")

好了扯了这么多，下面就说说怎么来开发移动手机网站吧！

基本上开发手机网站，可大致分为两大类。一类是用框架开发手机网站。一类是自己手写手机网站。

一、框架开发手机网站

一般用现在常用的开发框架有：目前Web前端最火的框架（BootStrap）、Jquery mobile..当然可能还有一些移动端开发的框架，这些我就没具体去研究过。

为什么说BootStrap是目前前端最火热的开发框架呢？

因为bootstrap自带响应式布局（栅格系统），而且能做到移动设备优先的原则。

运用bootstrap来开发网站有什么好处呢？

1.不懂设计也可以做网站

就算不懂设计，你的网页在Bootstrap的帮助下，也能拥有超高颜值。它强大的内置样式库让你的作品变成尤物。

主要体现在：字体文件和bootstrap自带的UI样式。（为广大不会UI设计的程序员，提供了福音）

2.上手快

你可以专心解决问题，冗繁的细节都丢给Bootstrap操心。可以做到一次开发，就可适配所有终端，并且能迅速上手并建出网站原型。还提供很多丰富的插件，就算你不会JS，基本能看懂常见的API，网站上的效果，基本能解决。

缺点：

1.不遵循最佳实践

我们在使用Bootstrap时遇到的最大问题之一是你的DOM元素上将拥挤大量的类。这打破了良好的web设计基本规则之一，HTML不再有语义，而且内容和表示不再分离。前端纯粹主义者会觉得这相当令人讨厌，以为它使可扩展性、重用性和维护性遇到了更大的挑战。

2.Bootstrap 太重

直接点说：就是CSS和JS有点点大。CSS压缩后115k,JS压缩后35k

如果你想要使用Bootstrap的所有功能，你应该好好考虑资源的加载时间。当然，对于一些地方这可能不是问题，但是在新西兰互联网不得不横跨太平洋，这时数据达到那儿将是很缓慢的。因此考虑你的目标市场。

相信任何框架都有它的优点，同时也是有它的缺点的。没有一个产品是很完美的，所以根据自身实际情况进行选择。至于一些其它框架暂时不做过多的解释了，相信只要你肯愿意百度一下，就可以找到你想要的答案。

二、手写手机网站

一般我们自己手动开发手机网站的话，基本可以划分两类来做到。一类是通过在网页头部添加meta标签进行实现（网页指html5的格式来开发）。另一类是通过CSS3的Media标签（媒介查询）来实现。不了解媒介查询的朋友，可以看看这篇文章：响应式布局。

在这里我们详细讲解下,利用添加meta标签来做手机网站。

基本在网页头部我们只需添加四个meta标签就可以实现一个手机网站的框架。我一起来看看是哪些meta标签。

1、添加viewport标签

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" />

详细属性：

width ---- viewport的宽度（width=device-width意思是：宽度等于设备宽度）height ------ viewport的高度（height=device-height意思是：高度等于设备宽度）initial-scale ----- 初始的缩放比例minimum-scale ----- 允许用户缩放到的最小比例maximum-scale ----- 允许用户缩放到的最大比例user-scalable ----- 用户是否可以手动缩放

关于viewport的详细原理和知识点，各位就百度吧！在这里我就不做详细的讲解了。

2、禁止将数字变为电话号码

<meta name="format-detection" content="telephone=no" />

一般情况下，IOS和Android系统都会默认某长度内的数字为电话号码，即使不加也是会默认显示为电话的，so，取消这个很有必要！

3、iphone设备中的safari私有meta标签

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

它表示：允许全屏模式浏览，隐藏浏览器导航栏

4、iphone的私有标签

<meta name="apple-mobile-web-app-status-bar-style" content="black">

它指定的iphone中safari顶端的状态条的样式

默认值为default（白色），可以定为black（黑色）和black-translucent（灰色半透明）

另外还有一个个性化的link标签，它支持用户将网页创建快捷方式到桌面时，其图标变为我们自己定义的图标。比如手机腾讯网上的标签：

<link rel="apple-touch-icon-precomposed" href="/wap30/info/info5/img/logo_icon.png">

不过腾讯对这个png图标的命名并不规范，常规我们要求文件名应为 apple-touch-icon.png 或 apple-touch-icon-precomposed.png ，前者的命名iOS会为这个图标自动添加圆角、阴影和高亮覆盖层，后者则不会添加这些效果。

手机网站基本框架代码：

<!doctype html><html><head><meta charset="utf-8"><title>手机网站</title><meta name="keywords" content="" /><meta name="description" content="" /><meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" /><meta name="format-detection" content="telephone=no" /><meta name="apple-mobile-web-app-capable" content="yes" /><meta name="apple-mobile-web-app-status-bar-style" content="black"><meta name="author" content="duanliang, " /><style>body{font-size:62.5%;font-family:"Microsoft YaHei",Arial; overflow-x:hidden; overflow-y:auto;}.viewport{ max-width:640px; min-width:300px; margin:0 auto;}</style></head><body><div>大家好！我是段亮，这是我的第一个手机网页哦！</div></body></html>

下面是我做的基于微信二次开发的手机页面案例：

点击预览

其实在移动端的开发让我纠结的是在字体单位上的选择。

随着CSS3的兴起，有一种叫rem的单位渐渐的出现在我们的视野中。它是一个相对单位，能实现响应式的那种。它是相对于html根元素来设置当前文字大小，或者宽高的。因为它是一个不固定值,不像PX。听说在PX这个单位在PC和移动的解析不同，所以才使用rem的。这点我也不是很清楚，也请教了一些做手机网站的高手，了解了一些信息。

原来大部分的人依旧是使用PX来布局，rem都用的少。目前来说，就移动端的淘宝首页就是采用rem来作为单位来布局的。关于使用rem单位这个问题以及它的好处：还得需要大神来解答这个问题，毕竟我也只是刚接触。

关于手机网站的调试问题

一般我们采用的：在浏览器调试+真机测试，因为浏览器毕竟只是一个模拟工具，实际开发的话，我们还得用真机去测试。

比如：（Android类手机，iPhone5、5s、6、6Plus...）

而在浏览器上测试，可以chrome（谷歌浏览器）的F12调试工具：有个手机样的小图标，点击就能模拟手机测试。

如下图：

或者用火狐的测试工具：按shift+ctrl+M进行查看。

写在最后：其实等你真正熟悉做手机网站这套流程后，你会发现做手机网站没有你想象的那么难，真正难的是不知道如何去下手。对于移动端的JS效果可能和PC端有些不同，因为移动端有移动端的事件，这也是我为什么老是强调学JS，是学原生JS，而不是学Jquery。