中国领先的IT技术网站
51CTO旗下网站
解惑好文：移动端H5页面高清多屏适配方案(3)
我们应该怎么做，才能在开发移动端H5页面时，适配不同分辨率不同屏幕尺寸的手机。
作者：Lovesueee来源：| 12:30
多屏适配布局问题
移动端布局，为了适配各种大屏手机，目前最好用的方案莫过于使用相对单位rem。
基于rem的原理，我们要做的就是: 针对不同手机屏幕尺寸和dpr动态的改变根节点html的font-size大小(基准值)。
这里我们提取了一个公式(rem表示基准值)
rem = document.documentElement.clientWidth * dpr / 10
乘以dpr，是因为页面有可能为了实现1px border页面会缩放(scale) 1/dpr 倍(如果没有，dpr=1)。说明：
除以10，是为了取整，方便计算(理论上可以是任何值)
所以就像下面这样，html的font-size可能会：
iPhone3gs: 320px / 10 = 32px
iPhone4/5: 320px * 2 / 10 = 64px
iPhone6: 375px * 2 / 10 = 75px
对于动态改变根节点html的font-size，我们可以通过css做，也可以通过javascript做。
css方式，可以通过设备宽度来媒体查询来改变html的font-size：
缺点：通过设备宽度范围区间这样的媒体查询来动态改变rem基准值，其实不够精确，比如：宽度为360px 和 宽度为320px的手机，因为屏宽在同一范围区间内(&375px)，所以会被同等对待(rem基准值相同)，而事实上他们的屏幕宽度并不相等，它们的布局也应该有所不同。最终，结论就是：这样的做法，没有做到足够的精确，但是够用。
javascript方式，通过上面的公式，计算出基准值rem，然后写入样式，大概如下(代码参考自kimi的m-base模块)
var&dpr,&rem,&&var&docEl&=&document.documentE&var&fontEl&=&document.createElement('style');&var&metaEl&=&document.querySelector('meta[name=&viewport&]');&scale&=&1&/&&dpr&=&win.devicePixelRatio&||&1;&rem&=&docEl.clientWidth&*&dpr&/&10;&&metaEl.setAttribute('content',&'width='&+&dpr&*&docEl.clientWidth&+&',&&&&&&&&&&&&&&&&&&&&&&initial-scale='&+&scale&+&',maximum-scale='&+&scale&+&',&&&&&&&&&&&&&&&&&&&&&&minimum-scale='&+&scale&+&',user-scalable=no');&&docEl.setAttribute('data-dpr',&dpr);&&docEl.firstElementChild.appendChild(fontEl);&fontEl.innerHTML&=&'html{font-size:'&+&rem&+&'px!}';&&window.rem2px&=&function(v)&{&&&&&v&=&parseFloat(v);&&&&&return&v&*&&};&window.px2rem:&function(v)&{&&&&&v&=&parseFloat(v);&&&&&return&v&/&&};&window.dpr&=&&window.rem&=&&
这种方式，可以精确地算出不同屏幕所应有的rem基准值，缺点就是要加载这么一段js代码，但个人觉得是这是目前最好的方案了。
因为这个方案同时解决了三个问题：
border: 1px问题
图片高清问题
屏幕适配布局问题
说到布局，自然就得回答一下最初的留下的那个问题：如何在css编码中还原视觉稿的真实宽高？
前提条件：
拿到的是一个针对iPhone6的高清视觉稿 750&1334
采用上述的高清方案(js代码)。
如果有一个区块，在psd文件中量出：宽高750&300px的div，那么如何转换成rem单位呢？
公式如下：
rem = px / 基准值;
对于一个iPhone6的视觉稿，它的基准值就是75(之前有提到)；
所以，在确定了视觉稿(即确定了基准值)后，通常我们会用less写一个mixin，像这样：
&.px2rem(@name,&@px){&&&&&@{name}:&@px&/&75&*&1&}&
所以，对于宽高750&300px的div，我们用less就这样写：
.px2rem(width,&750);&.px2rem(height,&300);&
转换成html，就是这样：
width:&10&&height:&4&&
最后因为dpr为2，页面scale了0.5，所以在手机屏幕上显示的真实宽高应该是375&150px，就刚刚好。
倘若页面并没有scale 0.5，我们的代码就得这样：
.px2rem(width,&375);&.px2rem(height,&150);&
这样的宽高，我们往往是这样得来的：
将750&1334的视觉稿转成375&667的大小后，再去量这个区块的大小(感觉好傻)。
在750&1334量得区块宽高是750&300px后，再口算除以2(感觉好麻烦)。
最后给出一张没有布局适配(上图)和用rem布局适配(下图)的对比图：
(上面的手机分别是：iPhone3gs, iPhone5, iPhone6)
很明显可以看出，rem适配的各个区块的宽高都会随着手机屏宽而改变，最最明显的可以看一下图片列表那部分，最后一张图视觉稿要求只出现一点点，rem布局在任何屏幕下都显示的很好。
字体大小问题
既然上面的方案会使得页面缩放(scale)，对于页面区块的宽高，我们可以依赖高清视觉稿，因为视觉稿本来就&2了，我们直接量就可以了，那么对于字体该如何处理呢？
对于字体缩放问题，设计师原本的要求是这样的：任何手机屏幕上字体大小都要统一，所以我们针对不同的分辨率(dpr不同)，会做如下处理：
font-size:&16&[data-dpr=&2&]&input&{&&&font-size:&32&}&
(注意，字体不可以用rem，误差太大了，且不能满足任何屏幕下字体大小相同)
为了方便，我们也会用less写一个mixin：
.px2px(@name,&@px){&&&&&@{name}:&round(@px&/&2)&*&1&&&&&[data-dpr=&2&]&&&{&&&&&&&&&@{name}:&@px&*&1&&&&&}&&&&&&&&&&[data-dpr=&2.5&]&&&{&&&&&&&&&@{name}:&round(@px&*&2.5&/&2)&*&1&&&&&}&&&&&&&&&&[data-dpr=&2.75&]&&&{&&&&&&&&&@{name}:&round(@px&*&2.75&/&2)&*&1&&&&&}&&&&&[data-dpr=&3&]&&&{&&&&&&&&&@{name}:&round(@px&/&2&*&3)&*&1px&&&&&}&&&&&&&&&&[data-dpr=&4&]&&&{&&&&&&&&&@{name}:&@px&*&2&&&&&}&}&
(注意：html的data-dpr属性就是之前js方案里面有提到的，这里就有用处了)
根据经验和测试，还是会出现这些奇奇葩葩的dpr，这里做了统一兼容~
用的时候，就像这样：
.px2px(font-size,&32);&
当然对于其他css属性，如果也要求不同dpr下都保持一致的话，也可以这样操作，如：
.px2px(padding,&20);&.px2px(right,&8);&
上面对移动端H5高清和多屏适配的一些方案总结，和知识讲解，不对的地方，还请指出来。
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条热点头条头条
24H热文一周话题本月最赞
讲师：12人学习过
讲师：13人学习过
讲师：20人学习过
精选博文论坛热帖下载排行
Cisco 640-801
Cisco& Certified Network Associate (CCNA&)
Q&A with explanations
Version 93.0...
订阅51CTO邮刊html5（9）
用CSS判断横屏竖屏问题：
&/pre&&/p&&p&&pre name=&code& class=&html& style=&font-weight:&&
@media (orientation: portrait) { } 横屏
@media (orientation: landscape) { }竖屏
&link rel=&stylesheet& media=&all and (orientation:portrait)& href=&portrait.css&&横屏
&link rel=&stylesheet& media=&all and (orientation:landscape)& href=&landscape.css&&竖屏
用JavaScript判断横屏竖屏问题:
//判断手机横竖屏状态：
function hengshuping(){
if(window.orientation==180||window.orientation==0){
alert(&竖屏状态！&)
if(window.orientation==90||window.orientation==-90){
alert(&横屏状态！&)
window.addEventListener(&onorientationchange& in window ? &orientationchange& : &resize&, hengshuping, false);
//移动端的浏览器一般都支持window.orientation这个参数，通过这个参数可以判断出手机是处在横屏还是竖屏状态。
从而根据实际需求而执行相应的程序。通过添加监听事件onorientationchange，进行执行就可以了。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：40316次
排名：千里之外
原创：41篇
转载：31篇
(3)(2)(2)(2)(5)(2)(2)(3)(8)(8)(2)(3)(5)(4)(2)(5)(3)(6)(3)(3)移动端H5之动态设置html的font-size的横屏BUG修复以及横屏提示
在上一篇 移动端之在不同尺寸大小的手机上展示同一效果解决方案 中,我们考虑的只是默认竖屏的情况.很显然,如果用户手机允许屏幕旋转,那么在横屏的情况下,页面就变得很恶心了.
因此我们需要进行一个处理,来判断是否是横屏,在横屏的情况下,要使用高度值来计算html的font-size.
因为项目引入了jquery,因此下面的代码全部是jquery语法.
function htmlFontSize(){
var win = $(window),
winH = win.height(),
winW = win.width(),
winW & winH ? hfz = winH : hfz = winW;
$(&html&).css('font-size',~~(hfz*)/100000+&px&);
通过上面的代码,就可以在横屏的情况下正确的显示页面的大小了.但是,横屏的情况下,页面会变得比较怪异,应该给用户一个提示.
百度了一下,找到了横屏的事件与解决方法.
function orientationChange() {
if (window.orientation==90 || window.orientation==-90){
alert(&横屏下不能获得最佳体验,建议竖屏浏览网页!&);
横屏提示代码如上.
再然后,就是在正确的时候要执行这些函数了.
$(function(){
htmlFontSize();
$(window).on(&resize&,function(){
htmlFontSize();
orientationChange();
$(window).on(&orientationchange&,function(){
orientationChange();
如上.效果是正确的.但是,好像我用了两个事件有点多余.因此,可以将代码整合到一个事件里面.
$(function(){
htmlFontSize();
orientationChange();
$(window).on(&orientationchange&,function(){
htmlFontSize();
orientationChange();
这里需要提醒的是resize事件在PC上进行调试的时候还是很好用的.
最后,这两个函数完全可以合并到一个函数里面.就不多写了.因为,领导说横屏下我做的效果还不错,就不用提示了:)
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'爱果果-关于滑屏H5开发的9个问题
关于滑屏H5开发的9个问题
编者按：小编最近一直在听《逻辑思维》，其中有一期提到“问题远比答案更重要”。是的，问题给我们一个思考的触发，好多问题并不一定有答案，或者没有唯一答案，思考问题的过程中我们会重新思考、审视或者重构原有的认知接口，所以问题的意义远大于答案本身。这篇文章，腾讯ISUX的同学就给我们一个思考问题的触发，并给出了他们自己关于这9个问题的思考。
滑屏的交互形式自从在 H5 中流行起来，便广泛应用在产品宣传、广告、招聘和活动运营等场景中，作为微信朋友圈广告惯用的形式，其影响力更是得到了强化与放大。如今滑屏H5可谓玲琅满目，数不尽数。
作为一个 工程师，接过很多类似的项目，也曾写过滑屏的插件，在经历了不同的需求的“洗礼”并踩过若干个坑之后，不禁反问自己：应该如何面对每一次类似的需求，在已有的经验下如何做到体验更好？如何节省工作量提高效率？面对性能优秀的 iOS 与性能良莠不齐的 Android 平台，又如何做到体验统一与性能最优？
第一问：拖拽翻屏，还是滑动翻屏？
页面随手势拖拽后翻屏
滑动后（touchend）后翻屏
如上面两个 Gif 图所示，两种方式的差异在于：
拖拽翻屏：页面随手指拖动而移动，手指松开（touchend）后翻页
滑动翻屏：页面不随手指拖动而移动，手指松开（touchend）后翻页
看似差别不大的两种交互，实现复杂度差别巨大，在 Android 中的体验更是不一样。前者需要在每个 touchmove 的时候进行计算与定位，计算量庞大（关注数字变化）：
而后者只需要在松开手指后再进行计算与翻页，性能大幅提升：
而且从第一种方案切换到第二种时，交互上的微妙改变并没有带来直观的影响。所以从性能角度上，滑动翻屏自然是最佳的选择。
第二问：滑屏技术的最佳实现方式是什么？
控制 wrapper 滑动
控制每一屏滑动
如上 Gif 图所示，滑屏可以在 wrapper 上操作，也可以将每一屏作为独立的滑动元素。简单的滑动可能两者并无太大差异，但假如把多样的需求和场景考虑到，可以发现在滑屏上也会细化出很多功能点：
滑动禁用与开启
预加载 / 延时加载
初始化时显示某一页
滚动到某一页、跳过某一页
提供滑动前、滑动中、滑动后的接口
滑动时间、速度、缓动效果自定义
考虑动态增删页数而无差错
考虑页面缩放、横竖屏切换
在上述要求下，前者已显得分身乏术，而后者由于其元素间的自由性，可以满足上述的需求，且效果更佳，虽然实现复杂度会提高。
最关键的是，前者的实现方式在部分安卓上偶尔会出现卡在上一屏与下一屏中间的情况，一开始遇到时做了很多补救都无果，最终才无奈替换了整个滑动方案，采用第二种控制内部元素的方式，可谓血的教训。
什么是卡在上一屏与下一屏中间呢，类似这样：
简单分析下原因，整个页面都通过在 body 上监测 touchmove 时增加 event.preventDefault() 来阻止自然的页面滑动，但唯独安卓有时候在有动画的元素上移动时，body 会捕捉不到 touchmove 事件，页面可以滚动了，便出现上述可以滑动 wrapper 的情况，而方案二控制每一屏滑动，每屏最宽最高就只是屏幕的宽高，也就不会出现页面滑动了。
第三问：首屏需要 Loading 页吗？
需要吗？需要。不需要吗？不需要。
需不需要看需求对 H5 的定位，若是类似微信朋友圈广告的这种品牌运营 H5，有大量素材作为支撑的页面，是需要进入时 loading 页的，这一点希望提前跟产品经理达成共识；但假如页面是系列活动中比较重要的入口，需要多次进入，则不要有 loading 页，力求一进入就能直接看到。
针对有 loading 的情况，还需要考虑：
是否一次性将所有资源 load 完？
no no no，即使有专门的 loading 页，都请分屏加载，否则这里将会流失大量用户。
那资源的体积跟时间之间应该形成一个怎样的认知呢？ 看表（根据 Chrome 开发者工具 Network 换算数据）：
上述是理想数值，实际上根据腾讯云统计到的 2G/3G 的下载速率，远未达到理想的速度：
根据《》可得知：中国移动用户 2G 用户占 41.4%，3G 用户占 31.3%，4G 用户占 27.3%。现状远远没有长期处于 WiFi 环境下的我们想象的那么美好，虽然这些用户并非长期使用 2G/3G，但是页面必须确保在 2/3G 环境下有一个顺畅的浏览体验，避免用户流失。建议首屏资源在 300KB 左右（大概加载时间为 2~3s 左右），并设置缓存。
针对无 loading 的情况，还需要考虑：
假如页面有比较丰富的动画，需要先加载资源才能被正常播放呢？
要么去掉动画，要么用 CSS 或 JS 来实现动画，必须要做出取舍。
既然是无 loading 的页面，自然对速度有要求，还能提高加载速度吗？
可以，请分屏加载。若希望做到体验无缝，请在前一屏加载后一屏的资源。
第四问：内部滚动怎么办？
内部滚动即某屏内部还有滚动（但实际上系统的滚动跟滑屏的滚动是冲突对立的），如果这一屏不涉及复杂的 DOM，我还是觉得可以使用 iScroll，虽然它在安卓上的性能一直被诟病，但经过非常多安卓机的检验，效果还是在可接收范围内的，但别忘了前提：DOM 不复杂（如活动规则页）。
那是否有更好的解决方案呢？不妨回看之前滑屏的最佳实现方式：
可以看到，在每一屏上进行操作，当上一屏或下一屏滑动到当前屏时，之前的那一屏会去掉 translate 属性，回归到最初的状态（被当前屏盖在下面，即 position: left:0; top:0），这个时候，将当前屏的 position: height:100% 去掉，使其回归文档流，那么 body 将会被撑开，页面可以被正常滑动，是不是连 iScroll 都省了？
尝试着写了个 Demo：
正如你体验到的那样，理想很丰满，现实很骨感，在 PC 上的体验是没有问题的（请在 Chrome 下模拟手机滑动），然而因为 iOS 和 Android 中很多浏览器都自带 bounce 回弹效果，而 iOS 和 Android 的大部分浏览器中，页面滚动时是会阻止页面重绘的（JS 的执行也无法立刻生效在页面中），所以Demo 里看到的效果就是回弹后才翻屏。所以目前这个方案页仅限于某些场景使用。
第五问：背景音乐是默认开启或是关闭？
之前在做一个宣传活动 H5 的时候，默认开启过音乐，发现 28w 曝光只有 800 个人主动关闭音乐。所以默认开启还是最优的，在制作音频的时候注意体积最好在 100~200k 范围，并且默认音量不应该太高，收尾渐入渐出，还得注意版权。
然而目前不管是手 Q 或是微信，都存在一个偶现的 bug：在手机中切换页面或者回到主屏幕，H5 的背景音乐依旧在播放，除非杀掉进程。初步猜测为 Webview 未正确得到释放。
第六问：H5 页面需要兼顾 PC 平台吗？
很多 H5 页面都只针对移动设备展示，但如果分享的链接被人在 PC 中打开呢？比如分享到微博或QQ 空间的链接，被正在电脑上浏览的人打开，看到的是一个显示不正常的页面，这样的体验是非常不好的。所以最好的做法就是准备一个 PC 的扫码页面或将内容搬到 PC，打通回路，为 H5 页面引流。
正如之前做过的 QQ 时光机项目：
第七问：动画如何做低版本退化？
移动端对 、Canvas、SVG 动画的支持已经不错了，目前兼容性较差的系统主要有 Android 2.3，它不支持 animtion-fill-mode 属性，这会导致动画播放完后无法保持在最后状态；不支持 before/after 伪元素的动画；不支持 animation-timing-function: steps，所以也无法玩转图片序列帧；所以可以特别针对这个版本进行差异化处理，通过判断 UA 对其展示静态页面。
然而最佳的退化方式不应该是版本检测，而是能力检测，可以通过 Modernizr 这个组件判断设备具备的能力。
第八问：如何做好适配？
适配的核心就是确保内容在不同的屏幕分辨率下显示正常，经常采用的方式有 REM、Media Query 和 JS+CSS，没有一套永恒不变的适配方案，往往需要多种结合。如果是比较简单的展示类H5，可以参考如下的代码：
当然，少不了横竖屏的提示：
不过在 iPhone4/4s 这种小屏幕下，也可以尝试取消分屏滑动，直接用浏览器原生的滚动。
第九问：…
我们也许还会遇到如下情况：
分享到各个社交平台（准备分享引导浮层）
使用自定义字体（、）
图片资源自动合并成雪碧图（Compass）
相信对于大部分
开发来说，写出一个安卓下不卡顿，没有兼容性问题的页面是最美好的愿望，有时候甚至可以针对 iOS 跟 Android 专门写一套代码，看似工作量大，其实可以规避掉很多不必要的麻烦。同时也需要跟产品、设计师们在安卓上的体验退化上达成一致，以免页面做出来后带来预期上的落差。
在追求最佳实践的路上，永远少不了层出不穷的问题。不一而足，无法穷举，滑屏只是一种形式，内容才是 H5 的精华所在，切勿舍本逐末。如今可以看到越来越多的创意融入 H5 中（视频、Canvas、SVG 等），前端世界变得越来越丰富多彩，这对开发者来说是机遇也是挑战，你我共勉！
还觉得不过瘾？
快关注爱果果微信吧！
ISUX的其他文章
发现灵感，找到创意}