现在 PC 和移动端正在细分, 并且越走越远, 建议小伙伴们坚定自己的方向, 让专业更专业;
最近面试了一些新人, 总感觉很浮躁; 接触的是很多, 太多依赖框架; 去除框架完全分不清东西南北, 这样不好;
因为前端本身就是繁杂, 不过繁杂的背后一直都是稳固的基础有了基础, 你可以写一套为别人服务的框架; 反之则不然;
移动端布局方案还是要清晰的了解一下的; 老前端更系统, 新前端有个正确的认识;
##### 一百分比布局 (不多介绍)
缺点:
宽度可以随屏幕适应, 但高度不能, 宽屏下会被拉伸, 具体表现为, iphone 4 中看到的是正方形, 而到了 iphone 6s 中看到的是长方形
需要手动计算子元素在父元素下的百分比, 计算麻烦
百分比的大小往往需要精确到小数位 6 到 8 位
##### 二媒体查询布局 (不多介绍)
缺点:
无法完全适配 Android 设备各种屏幕, 无法保证显示的一致性, 如: 定义了一个模块的高度在 321 至 375 下是 40px, 那么一个模块在这个范围的屏幕中显示就是 40px, 而不能随屏幕大小而变化
##### 三 flex 布局
类似于百分比布局, 无需计算百分比, 可以很好的适配所有屏幕
手机天猫 典型的 flex 布局, flex 做了很好的兼容处理, 高度写死, 可查看顶部搜索栏源码
缺点:
有着和百分比布局一样的缺点, 高度不便调整
有几种不同的 flex 标准, 在低端 ios 和安卓中有着各种各样的兼容性问题; UC 支持比较差 (亲测);
##### 四使用 rem 单位
和上面的几种布局方案结合使用, 主要做高度调整, 保证布局一致
视口缩放使用 rem
设计稿为 750 的设计稿
- 320 dpr=1 font-size=32px
- 320 dpr=2 font-size=64px
- 375 dpr=2 font-size=75px
- 414 dpr=3 font-size=124.2px
换算规则:(屏幕宽度 * dpr )/10 (除以 10 是为了将屏幕平分 10 份, 为了将来替换成 vm 或 vh 单位)
屏幕根据 dpr 的值进行了相应的缩放
很好的还原了 1px 在高清屏真实度
图片使用了 750 下的两倍图, 并没有做按 dpr 的值加载不同的图片
px 转 rem 需要使用工具转换
##### 五使用框架提供的解决方案
缺点:
不过一般公司自有项目都不借助框架的, 局限性太强;
还有一个更好的, Github 里的, 正在研究... 尚未测试
9. 移动 H5 长按复制 / 禁止长按复制 (不借助框架)
这个是个小问题, 不过项目一旦要求挺蛋疼的不如学会喽;
去除就禁止了, 移动端支持率比较良好~
来源: http://www.qdfuns.com/article/20813/b7fc1c28fedce4eeeb2a90ecf38a4c0a.html