不保证100%准确性，但是欢迎探讨。
, R- \# H( ^: `1 D# k' I' l2 l2 ?* }# p. J
此文主要针对于没有移动端经验的前端设计师，所以会尽量写的浅显易懂简单粗暴，技术型的**座勿喷~~~3 ^1 k5 J) Q- S3 {5 B4 o
以下讨论暂时不涉及响应式开发。' b: q; ?! A0 f6 m
q. n. `" l7 ^6 D( i伸手党以及没耐心的请直接下翻至懒人部分。
2 u" a! p9 k T% S2 ?, L X& r+ X8 i3 D8 F
------------------------------------------------------我是华丽的分割线------------------------------------------------------------& D& N" S) ?8 Q' p% P' J" x
! i6 ?! Q* R( ~' E/ a) u- P1 ?2 H, N
前端或美工在设计时通常会在psd里设定美工稿的画布尺寸。以pc端的网站为例，美工的psd的设计稿的宽度通常为1002px或者1200px。设定这个宽度的原因很简单，因为对于大部分的pc端用户而言，1440*900是主流台式机的分辨率（1440是宽度），1366*768是主流的笔记本电脑分辨率（1366是宽度）。
' Z+ Z; m, e' c5 `7 A- M0 v! Z' R$ K& P- R那么psd即使是1200px的宽度，也不会在1440和1366的主流电脑上产生横向滚动条，并且网站居中后还会左右留白，视觉效果非常好。' x* p+ f9 z3 D9 F" k9 \
& `' S9 ^/ S; e. n* M一句话总结，1002或者1200的psd宽度，将会在绝大部分的主流台式机和笔记本电脑上完美兼容。, q, m) p f2 V
4 Z' e$ L0 V' @5 K& I. \( Y8 v
以上道理非常简单，相信大部分技术人员也都明白，那么接下来进行一个小小的扫盲，就是1200px的画布尺寸究竟在pc端是如何被解析的，单纯的是因为显示器大小不一样吗？还是显示器的分辨率不一样？其实都不是，根本原因是在于浏览器会对于你的画布尺寸进行二次解析，而pc端浏览器解析的其中一个重要依据就是你的显示器的分辨率，而显示器默认的分辨率通常又和你的显示器的尺寸大小有关。& }: @! B( ^. P/ q }
（显示器尺寸决定显示器默认分辨率，显示器分辨率决定浏览器解析像素）。
$ W. P9 Y& w: q) n- ]& N" R3 T. u/ u, R* A! \4 D
那么理清了这个思路后我们可以得出一个结论，就是pc端的画布尺寸将会在浏览器根据你的显示器分辨率进行1:1的等比解析。
1 f' u0 k/ |! K& X& S8 J
+ ^9 a6 ]; f: Q' |" K
- T% }) |3 X; A. z$ J) }-------------------------------------------------------我是华丽的分割线------------------------------------------------------5 U1 g' c9 O' \# B
_' I# M. e! j% t
; I) h# s* ~3 P6 k1 P, Z* t9 I1 S
8 c5 a4 h0 c9 \% D6 \/ }: N
废话说完理清思路之后，我们来说一说移动端。
8 I' m7 A- \, @* |/ W0 H) p) p8 K
$ m2 Y% ?; k' K1 z- U' o. [移动端和pc端的本质区别就是pc端的浏览器解析宽度是和web端的画布宽度进行1:1的解析的。 但是移动端却不是1:1解析的，具体这个比例是多少牵涉到移动端一个独有的参数：像素密度。
% b. P2 l0 I' ?, C; s$ `3 ]- a7 @, Q+ u
大家在买手机的时候都会看到这样一个英文单词：PPI ，这个单词相信很多人都见过，就是指的像素密度。
" x8 n, @1 V/ ~, c' }! `8 A为防止概念过于抽象，我们仍旧举例说明，以iphone5的参数为例，ip5主屏分辨率：1136x640像素（640是宽度），主屏尺寸：4.0英寸，像素密度：320ppi。具体计算公式为：
0 j% k5 o& T' Z" d. d
" `3 P7 z; @7 d& ^8 x% C: G0 N" V! h# q
7 u6 ]0 S9 g) T8 k5 O$ ^当像ppi为320ppi的时候移动端浏览器是如何解析宽度的呢？已经不是pc端1:1的等比解析了，而是1:2的比例解析（为什么是1:2随后再说）。1200像素宽度的画布将会在320ppi的手机上自动被放大2倍，成为2400像素的宽度。但是ip5的宽度却只有640而已，所以1200像素的画布将会在手机上出现巨长的滚动条。（请再次理清一个思路，这个像素或者分辨率是最后是通过浏览器进行二次解析的，所以手机上640的像素的实际宽度是不等同于pc端640的像素的实际宽度，两者都被各自平台的浏览器进行了二次解析，所以跨平台进行横向对比是没有意义的）。具体多少ppi会放大多少倍数的计算公式如下：! \% b" K: r9 |$ b, y! @6 F
/ h+ U$ W- Y/ W
5 b5 {3 x8 e% @
% ]# l2 D# Q/ T; |0 ^以下是苹果常见机型和安卓旗舰机型： 2 W( {6 c6 l8 O7 E
% x7 x- m* J+ ]) A6 j {- B
( K6 w# b. } O$ g& I' C" h大家可以比较明了的看出来，320的宽度乘以放大倍数之后基本正好等于主屏宽度或者略小于主屏宽度。) ?1 \. x/ u( d. W" v
9 n3 R) q% A h/ m# q }/ Q8 z在ios平台之上，苹果把ppi稳定在了326左右，同样也意味着苹果把手机端的放大倍数给稳定在了2倍上下，而这个326ppi就是苹果声称的“视网膜屏”。换句话说，开发者在ios平台进行开发的话，ios平台本身的规范性为开发者规避了很多兼容性的风险。' ?3 N4 w. i- ?# }' i
而反之安卓呢？各种百花齐放，各种分辨率、各种ppi参差不齐，开发者想在安卓平台上面做到完美兼容？恐怕只有一个解决方案了：“呵呵~”
% ]* Z2 @9 t- t5 ^9 m$ f" [以上只是从前端的一个小小的角度衡量ios和安卓平台在于开发者的本质区别，接下来我们进入正题。
( Q1 x1 W" r1 H+ f9 F& n
: _+ y9 Z, D' H/ t5 }" u) n* x V" X3 u
5 m$ Q! s) D! C% w0 x
而反之安卓呢？各种百花齐放，各种分辨率、各种ppi参差不齐，开发者想在安卓平台上面做到完美兼容？恐怕只有一个解决方案了：“呵呵~”3 h+ z% W b" R+ D6 h2 T. f6 ~
以上只是从前端的一个小小的角度衡量ios和安卓平台在于开发者的本质区别，接下来我们进入正题。
( b3 j: v: M9 a" k6 p* Y2 v3 |$ M* ]
+ u/ v0 F K+ w* Z
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓懒人直接看这里↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
% a6 f+ z# {" U% D
( x( o, U* R- d: o! R) i) M
4 D6 q4 k+ }( M8 K, ]# `$ Y9 r, i有没有一种移动端的web前端尺寸能够比较简单粗暴的解决问题呢？其实还是有的，那就是大家看到了我上面的表格有写到“320像素”。这个320像素的尺寸一方面能够满足所有ios手机端的web展示，另一方面在安卓端展示时，被放大后虽然左右会有留白（针对于高ppi），但是整体来说不会影响大体的展示效果，不会出现滚动条等及其恶劣的影响用户体验的情况（至少我可以接收左右留白）。
% l& d4 c3 G9 a* W) Q1 ?3 S4 ?# m. t4 ?% q* s
一句话概括：320的宽度的画布在苹果手机上完美兼容；在安卓手机上大部分兼容，越是好的安卓手机，ppi越高，左右留白可能越多。, J% i: r; z, l1 ?/ w& e
3 d' |& w, o' T" s
320宽度的好处：简单粗暴，一套前端方案解决所有问题，虽然并不那么完美，但是属于可接受范围之内。
2 `- M1 b" K& Q320宽度的坏处：所有的图片都会被强行扩放到2倍以上，导致图片失真，ppi越大，失真越严重；且个别安卓机型展示时左右留白可能会比较大。
8 w) {2 h4 ?# S9 V3 y+ |0 G1 ^& f9 f/ ]2 m' \9 i1 W
不过图片失真我个人真不觉得一定是个坏事，就目前而言国内大部分用户流量还是以2g和3g网络为主，4g根本没有普及，wifi也基本仅限于家里。所以大部分用户的流量和加载速度是个大问题，当你真的把普通图片换成高清大图，换来的代价可能是用户加载时间需要再多个三五秒，你可以想象一下，有几个人会盯着一个loading看5秒还不退出？别那么看得起互联网用户的耐心。 I5 B+ ~) L1 y
反之高清图片和普通图片被压缩在一个5寸的手机屏幕上进行展示的时候可能只有一平方厘米那么大，除非你仔细看，否则高清图片和普通图片在5寸屏幕上实际显示的差异恐怕还真不是一眼就能看的出来的。
- |3 `8 L8 c. o# E) E: g1 w, _8 i p6 Z2 Q2 Z
--------------------------------------------------------响应式开发---------------------------------------------------------5 h# s. T- f. v
纯百分比做不是不行，而是局限性太大，另外一种思路就比较暴力了：. J0 }9 f; N- A. M
; q+ Y( J% W* C/ |4 q1 l4 O* I
当检测到是ios平台时，执行paln a，& c% t' Z: y9 P+ {- \$ @' f
当检测到是小米4时，执行paln b，$ X! x. `# w( K# u
当检测到是魅族4时，执行paln c，$ |5 ~' i# M! [5 A% n1 i+ U
当检测到是note4时，执行paln d，
- [% H! _7 a% A" u4 q- {+ t以此类推......
3 @ [9 w- ]! P s) |( o3 m% V大体上有个四五种方案基本上安卓上面常见的情况也就都被概况了，但是工程量就得增加四五倍了。而且即使增加了四五倍的工作量，你仍然无法完美解决所有情况，所以**座的开发者看到安卓请绕行，真爱生命，远离安卓。不要忘了，这才是项目初期做个前端而已，中后期时候安卓的弊端才会真的让你欲哭无泪。6 w# P+ G% A9 e
2 Y$ i1 F, c- p; [* O8 g5 ?/ k
3 H/ p# R& Y7 F$ c/ f7 ~-----------------------------------------------------------补充一下----------------------------------------------------------9 B$ p' J5 o1 X$ {
, [9 Q2 B8 s6 a" L. U$ {/ ~
移动端浏览器很给力，各种css3和html5大胆的用就行，ie6系的问题将一去不复返~~
- Y n( K6 e- q
/ {) p* ^! e; M* i( J% E3 e原文地址：http://qf100站长论坛/news/297 转载请注明出处。 ( ]4 Y+ k. v4 R) m6 g; ~/ ~
]$ k9 g* _+ f7 c4 {搜外论坛原创作者：青峰在线
5 r* z. y9 ]. H& ?' B9 u& x8 |
! v; h* n7 Q' N$ J日期：2015-01-28
|
/ k! F# X! N F7 S4 |! `( h& j
: G1 a) ~* b' U4 k
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
