div+css的四行自适应手机端屏幕布局怎么写？高度、宽度为自适应100%，即为满屏显示

{
    margin:0;
    padding:0;    
}
html,body{
    height:100%;    
}
line1,line4{
    position:absolute;
    width:100%;
    height:50px;
    z-index:5;    
}
line1{
    top:0;    
}
line2{
    position:relative;
    height:50%;
    z-index:1;    
}
line3{
    position:relative;
    height:50%;
    z-index:1;    
}
line4{
    bottom:0;    
}

我想你要表达是是高50吧？不太会表述，还是直接给你上代码吧

基于android的通讯录的设计与实现
一：引言
学了android的开发与设计课后，对计算机软硬件相关知识有了一定的了解；基于此，设计与实现一个在Android系统上运行的手机通讯管理软件，实现手机通讯录的基本功能，包括：添加联系人、查看联系人、修改联系人、删除联系人、拨打电话、发送短信、查询联系人，以及联系人的导入导出功能即联系人的备份。
主要开发基于Android
的手机的通讯管理软件。以Java语言为基础，结合Android移动开发平台，并利用Android提供的SDK，实现在Android平台上运行的手机通讯录，方便广大手机用户更加便捷地对联系人的信息进行管理。该手机通讯录面向所有的Android手机用户，为他们提供更实际便捷的手机服务,具有拨号、通讯记录等基本功能。该通讯录的数据导出功能是该软件的一个特色，可以实现联系人数据导出到文本，实现数据备份。大家生活当中经常遇到手机丢失，出现故障，和其他一些事故。最担心的就是丢失手机里的电话号码。
11 选题目的及意义
随着3G网络的使用，移动终端不再仅是通讯网络的终端，还将成为互联网的终端。因此，移动终端的应用软件和需要的服务将会有很大的发展空间。在Google和Android手机联盟的共同推动下，Android在众多手机 *** 作系统中脱颖而出，受到广大消费者的欢迎。
手机通讯录作为手机的基本功能之一，每天我们都在频繁地使用着。根据手机功能使用调查显示，有八成以上的消费者使用手机通讯录功能。随着手机通讯录功能的不断加强与完善，手机通讯录对于人们的意义，已不仅仅像记事簿一样显示通讯地址，而是向着个性化、人性化的方向发展。通讯录从无到有，从英文到中文，经过了十几年的发展历程，今后的发展趋势就是从通讯录发展为名片夹，也就是在一个人名下，可以存储座机、手机、单位、地
址、电子邮件等内容。这种名片夹在电话薄的基础上，大大丰富了内容，同时结构也发生了革命性变化，而且随着手机的发展，相信更优秀的通讯录会越来越受到社会各层人士的喜爱。
12 项目背景
Android一词的本义指"机器人",同时也是Google在2007年11月5日宣布的基于Linux内核的开源手机系统的名称，中文注册商标"安致",
该平台由 *** 作系统、中间件、用户界面和应用软件组成，是一个为移动终端打造的真正开放和完整的智能手机系统。其早期为Google开发，后由开放手机联盟（ Open
Handset Alliance）开发。它采用了软件堆层（software
stack,又名以软件叠层）的架构，主要分为三部分，底层以Linux内核为基础，由C语言开发，只提供基本功能；中间层包括数据库Library和虚拟机Virtual
Machine，由C++开发；最上层是由各公司自行开发，以Java编写的各种应用软件，如通话程序，短信程序等。 二：功能需求。
根据用户需求总结出来的反映了用户需求的系统逻辑模型转换成可以实施的物理模型，把整个设计划分成单元，主要解决如何去做的问题，要想创建整个通讯录首先要通过增加联系人信息来创建通讯录。整个应用程序应划分为4个模块，分别是程序启动、用户界面、后台服务和数据库适配器，各模块之间的关系如图所示：
从上图中不难看出，后台服务是整个应用程序的核心，主要是“数据获取模块”，负责周期性
的从用户输入的内容中获取信息。
后台服务在程序启动时就由AppWidgetProvider启动，也可由用户界面通过startService(进行启动，启动后的后台服务将一直保持运行状态。同时用户界面从数据获文本信息。一方面可以避免因网络通信不畅造成界面失去响应；另一方面，后台服务可以及时更新数据，以保证数据的准确性。数据库适配器封装了所有对SQLite数据库 *** 作的方法用户界面和后台服务会调用它来实现数据库 *** 作。在完成用户界面设计、数据库设计和模块设计后，至此程序设计阶段基本完成。文本编辑器中不同功能界面之间的切换，用户可以通过点击menu键来切换到不同的功能界面，不同功能界面的切换如图
三:设计思路。
开发的基于Android手机通讯录具有十分重要的意义。可以根据客户需求的实际情况，开发一款实用的手机通讯录软件。
本设计主要是采用Android的View框架编写，部分框架运用Android中的其他组件。
当进入通讯录的增加界面时，调用的是一个用相对布局RelativeLayout的XML布局文件。其中包括了2个Button，分别实现了不同的功能。
第一个Button是保存内容，当输入联系人姓名和号码是点击保存实现此功能。说到保存，不得不说得是保存信息涉及添加新联系人的头像，姓名，手机号码，办公室电话，家庭电话，职务职称，单位名称，地址，邮政编码，Email，其他，备注这些信息。
第二个Button是返回，顾名思义就是从增加界面返回前一界面。
响应menu键的触发事件，设置底部菜单是否可见，并通过对底部菜单选项的监听实现底部菜单中的增加、查找、删除、菜单、退出等功能，其中菜单包括显示所有、删除所有、号码备份功能。
在联系人信息界面时通过点击menu键，会d出通信功能框，通过与发信息、打电话、发邮件功能接口的套用来实现。
四:流程图
一个好的系统设计的步骤决定了程序是否能按照设计者的目的按时完成，是否能在规定的时间内按照设计者的要求高质量的完成程序必要的功能。并且按照标准的设计步骤对程序进行调试，测试，以及后期的优化完善，使程序更加具有健壮性和可用性。通过对通讯录功能、系统模块、用户需求方面进行全方位的分析制定开发流程，开发流程如图4-1所示。
图4-1开发流程图
采用标准的开发流程确定系统具有用户管理功能，联系人增删改功能，通讯功能，查找功能，备份等功能。系统的功能图如4-2所示。
图4-2 系统功能图
通过对系统的功能结构的分析，设计后系统运行流程是系统运行后用户将进入通讯录主界面，可以看到联系人列表。通过点击MENU界面的增加功能选项可以新增联系人

iOS 越来越人性化了，用户可以在设置-通用-辅助功能中动态调整字体大小了。你会发现所有 iOS 自带的APP的字体大小都变了，可惜我们开发的第三方APP依然是以前的字体。在 iOS 7 之后我们可以用 UIFont 的preferredFontForTextStyle: 类方法来指定一个样式，并让字体大小符合用户设定的字体大小。目前可供选择的有六种样式：
UIFontTextStyleHeadline UIFontTextStyleBody UIFontTextStyleSubheadline UIFontTextStyleFootnote UIFontTextStyleCaption1 UIFontTextStyleCaption2
iOS会根据样式的用途来合理调整字体。

问题来了，诸如字体大小这种“动态类型”，我们需要对其进行动态的UI调整，否则总是觉得我们的界面怪怪的：
我们想要让Cell 的高度随着字体大小而作出调整：
总之，还会有其他动态因素导致我们需要修改布局。

解决方案
UITableView
有三种策略可以调节Cell（或者是Header和Footer）的高度：

a调节Height属性
b通过委托方法tableView: heightForRowAtIndexPath:
cCell的“自排列”（self-sizing）

前两种策略都是我们所熟悉的，后面将介绍第三种策略。UITableViewCell 和 UICollectionViewCell 都支持 self-sizing。

在 iOS 7 中，UITableViewDelegate新增了三个方法来满足用户设定Cell、Header和Footer预计高度的方法：
- tableView:estimatedHeightForRowAtIndexPath: - tableView:estimatedHeightForHeaderInSection: - tableView:estimatedHeightForFooterInSection:
当然对应这三个方法 UITableView 也 estimatedRowHeight、estimatedSectionHeaderHeight 和 estimatedSectionFooterHeight 三个属性，局限性在于只能统一定义所有行和节的高度。

以 Cell 为例，iOS 会根据给出的预计高度来创建一个Cell，但等到真正要显示它的时候，iOS 8会在 self-sizing 计算得出新的 Size 并调整 table 的 contentSize 后，将 Cell 绘制显示出来。关键在于如何得出 Cell 新的 Size，iOS提供了两种方法：

自动布局
这个两年前推出的神器虽然在一开始表现不佳，但随着 Xcode 的越来越给力，在iOS7中自动布局俨然成了默认勾选的选项，通过设定一系列约束来使得我们的UI能够适应各种尺寸的屏幕。如果你有使用约束的经验，想必已经有了解决思路：向 Cell 的 contentView 添加约束。iOS 会先调用 UIView 的 systemLayoutSizeFittingSize: 方法来根据约束计算新的Size，如果你没实现约束，systemLayoutSizeFittingSize: 会接着调用sizeThatFits:方法。

人工代码
我们可以重写sizeThatFits:方法来自己定义新的Size，这样我们就不必学习约束相关的知识了。

下面我给出了一个用 Swift 语言写的 Demo-HardChoice ，使用自动布局来调整UITableViewCell的高度。我通过实现一个UITableViewCell的子类DynamicCell来实现自动布局，你可以再GitHub上下载源码：
import UIKit class DynamicCell: UITableViewCell { required init(coder: NSCoder) { superinit(coder: coder) if textLabel != nil { textLabelfont = UIFontpreferredFontForTextStyle(UIFontTextStyleHeadline) textLabelnumberOfLines = 0 } if detailTextLabel != nil { detailTextLabelfont = UIFontpreferredFontForTextStyle(UIFontTextStyleBody) detailTextLabelnumberOfLines = 0 } } override func constraints() -> [AnyObject] { var constraints = [AnyObject]() if textLabel != nil { constraintsextend(constraintsForView(textLabel)) } if detailTextLabel != nil { constraintsextend(constraintsForView(detailTextLabel)) } constraintsappend(NSLayoutConstraint(item: contentView, attribute: NSLayoutAttributeHeight, relatedBy: NSLayoutRelationGreaterThanOrEqual, toItem: contentView, attribute: NSLayoutAttributeHeight, multiplier: 0, constant: 44)) contentViewaddConstraints(constraints) return constraints } func constraintsForView(view:UIView) -> [AnyObject]{ var constraints = [NSLayoutConstraint]() constraintsappend(NSLayoutConstraint(item: view, attribute: NSLayoutAttributeFirstBaseline, relatedBy: NSLayoutRelationEqual, toItem: contentView, attribute: NSLayoutAttributeTop, multiplier: 18, constant: 300)) constraintsappend(NSLayoutConstraint(item: contentView, attribute: NSLayoutAttributeBottom, relatedBy: NSLayoutRelationGreaterThanOrEqual, toItem: view, attribute: NSLayoutAttributeBaseline, multiplier: 13, constant: 8)) return constraints } }
上面的代码需要注意的是，Objective-C中的类在Swift中都可以被当做AnyObject，这在类型兼容问题上很管用。

别忘了在相应的 UITableViewController 中的 viewDidLoad 方法中加上：
selftableViewestimatedRowHeight = 44
自适应效果如下：
UICollectionView
UITableView 和 UICollectionView 都是 data-source 和 delegate 驱动的。UICollectionView 在此之上进行了进一步抽象。它将其子视图的位置，大小和外观的控制权委托给一个单独的布局对象。通过提供一个自定义布局对象，你几乎可以实现任何你能想象到的布局。布局继承自 UICollectionViewLayout 抽象基类。iOS 6 中以 UICollectionViewFlowLayout 类的形式提出了一个具体的布局实现。在 UICollectionViewFlowLayout 中，self-sizing 同样适用：
采用self-sizing后：
UICollectionView 实现 self-sizing 不仅可以通过在 Cell 的 contentView 上加约束和重写 sizeThatFits: 方法，也能在 Cell 层面（以前都是在 contentSize 上进行 self-sizing）上做文章：重写 UICollectionReusableView 的preferredLayoutAttributesFittingAttributes: 方法来在 self-sizing 计算出 Size 之后再修改，这样就达到了对Cell布局属性（UICollectionViewLayoutAttributes）的全面控制。

PS：preferredLayoutAttributesFittingAttributes: 方法默认调整Size属性来适应 self-sizing Cell，所以重写的时候需要先调用父类方法，再在返回的 UICollectionViewLayoutAttributes 对象上做你想要做的修改。

由此我们从最经典的 UICollectionViewLayout 强制计算属性（还记得 UICollectionViewLayoutAttributes 的一系列工厂方法么？）到使用 self-sizing 来根据我们需求调整属性中的Size，再到重写UICollectionReusableView（UICollectionViewCell也是继承于它）的 preferredLayoutAttributesFittingAttributes: 方法来从Cell层面对所有属性进行修改：
下面来说说如何在 UICollectionViewFlowLayout 实现 self-sizing：
首先，UICollectionViewFlowLayout 增加了estimatedItemSize 属性，这与 UITableView 中的 ”estimatedHeight“ 很像（注意我用省略号囊括那三种属性），但毕竟 UICollectionView 中的 Item 都需要约束 Height 和 Width的，所以它是个 CGSIze，除了这点它与 UITableView 中的”estimatedHeight“用法没区别。
其没有其次，在 UICollectionView 中实现 self-sizing，只需给 estimatedItemSize 属性赋值（不能是 CGSizeZero ），一行代码足矣。

InvalidationContext
假如设备屏幕旋转，或者需要展示一些其妙的效果（比如 CoverFlow ），我们需要将当前的布局失效，并重新计算布局。当然每次计算都有一定的开销，所以我们应该谨慎的仅在我们需要的时候调用 invalidateLayout 方法来让布局失效。

在 iOS 6 时代，有的人会“聪明地”这样做：
- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds { CGRect oldBounds = selfcollectionViewbounds; if (CGRectGetWidth(newBounds) != CGRectGetWidth(oldBounds)) { return YES; } return NO; }
而 iOS 7 新加入的 UICollectionViewLayoutInvalidationContext 类声明了在布局失效时布局的哪些部分需要被更新。当数据源变更时，invalidateEverything 和 invalidateDataSourceCounts 这两个只读 Bool 属性标记了UICollectionView 数据源“全部过期失效”和“Section和Item数量失效”，UICollectionView会将它们自动设定并提供给你。

你可以调用invalidateLayoutWithContext:方法并传入一个UICollectionViewLayoutInvalidationContext对象，这能优化布局的更新效率。

当你自定义一个 UICollectionViewLayout 子类时，你可以调用 invalidationContextClass 方法来返回一个你定义的 UICollectionViewLayoutInvalidationContext 的子类，这样你的 Layout 子类在失效时会使用你自定义的InvalidationContext 子类来优化更新布局。

你还可以重写 invalidationContextForBoundsChange: 方法，在实现自定义 Layout 时通过重写这个方法返回一个 InvalidationContext 对象。

综上所述都是 iOS 7 中新加入的内容，并且还可以应用在 UICollectionViewFlowLayout 中。在 iOS 8 中，UICollectionViewLayoutInvalidationContext 也被用在self-sizing cell上。

iOS8 中 UICollectionViewLayoutInvalidationContext 新加入了三个方法使得我们可以更加细致精密地使某一行某一节Item（Cell）、Supplementary View 或 Decoration View 失效：
invalidateItemsAtIndexPaths: invalidateSupplementaryElementsOfKind:atIndexPaths: invalidateDecorationElementsOfKind:atIndexPaths:
对应着添加了三个只读数组属性来标记上面那三种组件：
invalidatedItemIndexPaths invalidatedSupplementaryIndexPaths invalidatedDecorationIndexPaths
iOS自带的照片应用会将每一节照片的信息（时间、地点）停留显示在最顶部，实现这种将 Header 粘在顶端的功能其实就是将那个 Index 的 Supplementary View 失效，就这么简单。

UICollectionViewLayoutInvalidationContext 新加入的 contentOffsetAdjustment 和 contentSizeAdjustment 属性可以让我们更新 CollectionView 的 content 的位移和尺寸。

此外 UICollectionViewLayout 还加入了一对儿方法来帮助我们使用self-sizing：
shouldInvalidateLayoutForPreferredLayoutAttributes:withOriginalAttributes: invalidationContextForPreferredLayoutAttributes:withOriginalAttributes:
当一个self-sizing Cell发生属性发生变化时，第一个方法会被调用，它询问是否应该更新布局（即原布局失效），默认为NO；而第二个方法更细化的指明了哪些属性应该更新，需要调用父类的方法获得一个InvalidationContext 对象，然后对其做一些你想要的修改，最后返回。

试想，如果在你自定义的布局中，一个Cell的Size因为某种原因发生了变化（比如由于字体大小变化），其他的Cell会由于 self-sizing 而位置发生变化，你需要实现上面两个方法来让指定的Cell更新布局中的部分属性；别忘了整个 CollectionView 的 contentSize 和 contentOffset 因此也会发生变化，你需要给 contentOffsetAdjustment 和 contentSizeAdjustment 属性赋值。

苹果如何设置桌面布局，跟着教程一起看看吧。

1、首先在桌面长按任意图标后，在d出选择中选择编辑主屏幕。

2、这时看到应用晃动后，就可以随意移动手机桌面的图标。

3、在编辑状态下的软件可以随意拖到任何地方，利用是这个功能进行桌面的布局和移动。

4、如果想要清理桌面的图标但是不想删除软件，用户可以把应用拖到另一个应用的上面，这样就会出现一个收藏夹帮助解放桌面空间。

例如：对于DPR=2的Retina屏幕而言1个位图像素对应于4个物理像素，由于单一位图像素不可再分割，所以只能就近取色，从而导致模糊。所以对于清晰度问题，较好的方案是提供两倍图 @x2 。

像素密度表示设备屏幕能够显示的设备独立像素DIP的数量，屏幕显示的像素数量越多画面也就越精细，同时同样屏幕区域能够显示的信息也就越多。

屏幕由像素点组成，每个像素点发出不同颜色的光，进而构成界面。而屏幕的物理尺寸与像素尺寸是不成比例的。不同尺寸的手机屏幕拥有不同的分辨率，分辨率实际上是手机像素的宽高尺寸。

像素密度（pixels per inch,PPI或DPI）表示每英寸长度上排列的设备独立像素点DIP的个数，1英寸等于253厘米。像素密度PPI越高则表示屏幕分辨率越高进而屏幕显示越精细。Retine屏幕比普通屏幕清晰的原因，是因为它的像素密度是普通屏幕的数倍。

例如：35英寸的iPhone手机屏幕

日常所说的屏幕尺寸，实际是指屏幕对角线的长度。计算像素密度首先需要计算设备屏幕对角线等效像素，然后除以对角线长度。例如HTC G7分辨率为480x800，37英寸，计算出像素密度为252PPI。

像素密度PPI = 平方像素宽加平方像素高之和开平方的结果，再除以屏幕对角线的英寸数。

密度决定比例

通过计算像素密度PPI可以得知设备屏幕属于哪个密度区间，因为不同密度区间对应着不同的默认缩放比例。

通俗来说视区 Viewport 就是浏览器上用来显示页面的区域，也就是说，浏览器的实际宽度和手机宽度不一样，无论手机宽度是320px或640px，在手机浏览器内部宽度始终会是浏览器本身的视区。

现代浏览器都会给自身的视区提供一个默认值，大多会以980px或1024px为主。在移动端视区默认一般来说是会大于手机屏幕的，所以当在桌面浏览器正常显示的页面，会以960px设计主区域。放到移动端就会出现横向滚动条，因此会专门会给浏览器设计移动端的页面。

移动端浏览器会将页面放在一个虚拟的窗口 viewport 中，通常这个虚拟的窗口会比屏幕宽，这样就不用将每个页面挤到很小的窗口中，以防止破坏没有针对手机浏览器优化的网页布局，用户可以通过平移或缩放来查看页面中的不同部分。

页面中视区 viewport 是可绘制的区域，虽然视区的可视面积和屏幕尺寸相匹配，但视区页由自己的尺寸，用来确定页面中的像素数量。

在 iPhone 和 Android 平台中 WebKit 内核的历览器使用980像素宽的视见区或逻辑尺寸，相当于viewport中的width=980px。当页面加载后，页面内容通常被完全缩放以便整个页面都可见，尽管内容会被缩放的非常小且不可读。

在Web页面中，可通过JS动态获取相关参数。

根据目前市场主流移动终端，统计设备独立像素后，移动端H5设计稿推荐尺寸为640 x 1136、750 x 1334。

除去浏览器全屏显示，几乎所有情况下均会存在顶部状态栏和导航栏。根据iPhone标准，状态栏和导航栏的独立像素高度分别为40px和88px。Android平台可以更改状态和导航栏高度可取默认值48px和100px为准。在网页中就会将页面内容向下挤入盲区，根据不同的布局方式可能会挤出视口，也就是可视区域之下。因此取两个平台的最大值148。因此设计稿要尽量保证单页下没有重要内容。如果要在所有屏幕上将重要内容显示完全，需要注意市面上存在的小尺寸屏幕，绝对部分智能机分辨率在640 x 960之上，因此只要重要内容放在盲区之上即可。计算出的最安全高度为812 = 960 - 148。

简单来说视区 Viewport 是严格等于浏览器的窗口，在桌面浏览器中视区就是浏览器窗口的宽高，但在移动设备上由于视区太窄，为了更好的为 CSS 布局服务，所以提供了两个视区，分别是可见视区 Visual Viewport 和布局视区 Layout Viewport 。

如果将移动设备浏览器的可视区域设置为Viewport，某些网站会因为Viewport太窄而显示错乱，所以浏览器会默认将Viewport设置为一个较宽的值，比如980px，使得为桌面浏览器设计的网站也能在移动设备浏览器上正常显示。这个浏览器默认的Viewport也就是Layout Viewport布局视区。布局视区的宽度可以使用JavaScript的 documentdocumentElementclientWidth 获取。移动设备中默认的视区就是Layout Viewport。

布局视区的宽度是大于浏览器可视区域的宽度的，因此需要一个Viewport来表示浏览器可视区域大小，这个Viewport也就是可见视区Visual Viewport，可见视区可使用JavaScript的 documentdocumentElementinnerWidth 获取。

Ideal Viewport是一个能完美适配移动设备的Viewport，首先无需缩放和横向滚动条就能正常查看页面所有内容，其次显示的文字、大小合适。比如14px的文本不会因为一个高密度像素的屏幕而显示的太小或无法看清。无论在何种密度屏幕、何种分辨率下，显示出来的大小都差不多，这个Viewport也就是Ideal Viewport。

Ideal Viewport并没有一个固定的尺寸，不同的设备拥有不同的尺寸。比如在IPhone设备中Ideal Viewport宽度是320px，无论屏幕宽度是320还是640的。Ideal Viewport的意义在于，无论在何种分辨率下，针对Ideal Viewport而设计的页面无需缩放和横向滚动条都可以完美地呈现给用户。

移动设备中默认的视区是Layout Viewport，在进行移动设备页面开发时则需要Ideal Viewport。要得到完美视区，需设置 meta 标签。

该 meta 标签的作用是让当前视区宽度等于设备宽度，同时不允许用户手动缩放。 minimum-scale=10 与 maximum-scale=10 并不是必需的。但 width = device-width 则是必须的，以保证不会出现横向滚动条。

width 能够控制默认布局视区Layout Viewport的宽度，若不指定则默认会是980px或1024px，这个值会由设备自身所决定。当把布局视区宽度设置为移动设备宽度 width = device-width 时，此时布局视区将会变成完美视区。

其实要将当前视区宽度设置为完美视区宽度，既可以设置 width = device-width 也可以设置 initial-scale = 10 ，但是单单设置 width = device-width 会导致iPhone、iPad设备中横竖屏不分，单单设置 initial-scale = 10 则会导致IE中横竖屏不分。所以都以竖屏的完美视口宽度为标准，最完美的写法时两则都写上去， width = device-width 解决iPhone、iPad缺陷， initial-scale = 10 则解决IE的缺陷。

CSS3新增视区单位vm和vh，在移动端iOS8+和Android44+获得支持。

设备像素比定义了物理像素与设备独立像素之间的对应关系，计算公式为：设备像素比 = 物理像素 / 设备独立像素。

在CSS中可通过以下方式进行媒体查询，针对不同DPR设备做出样式适配。

在JavaScript中可通过 windowdevicePixelRatio 获取当前设备的DPR。

在Ratina高清设备屏幕中一个CSS像素对应4个物理像素

Web页面设置视口后，页面与屏幕是1:1显示，移动设备都具有设备像素比 DPR ，当DPR=2时移动设备上的一个CSS像素由4个物理像素点组成。

安卓客户端限制了 viewport 设置的缩放属性，让客户端放开限制就行，但是由于市场上的app版本还是不支持，所以需要做兼容性处理。

iPhone6 上有1px 的滚动条，最后处理方案是通过 viewport 中的 maximum-scale 的值加了01，由于设置了user-scalable=no，maximum-scale 的值加01并不会有什么影响。

通过JS动态获取移动设备的设备像素比，通过设备像素比来计算并设备Web页面中 html 标签的字体大小 font-size 以及缩放比例。

例如：动态设置 html 的font-size, 同时根据设备DPR调整页面的缩放值，进而达到高清效果。

rem 全称 font size of the root element 是指相对于根元素的字体大小的相对单位，计算规则依赖于根元素。

rem 是通过根元素进行适配的，web中根元素是指 html ，所以通过设置 html 的字体大小即可控制 rem 的大小。

REM布局的核心是设置好根 html 元素的字体大小 font-size ，为了防止在高清屏下像素不够用而导致模糊，当拿到移动设计稿时，移动设计稿一般会以iPhone5设备宽320px或iPhone6设备宽375px为基准，制作出两倍宽的设计稿，即640px或750px。

例如：设置 html 标签的 font-size:10px ，6rem即610px。

rem 适用于WebApp，出于兼容性考虑，WebApp下使用 rem 更加能凸价值和功能。

使用CSS的媒体查询控制

移动UI设计稿会采用iPhone宽度作为标准

使用JS控制Web页面文字大小使其自适应屏幕

使用 rem 布局的本质是等比缩放，一般是基于宽度。

将屏幕宽度均分100份，每一份的宽度使用x表示，即x=屏幕宽度/100，如果将x作为单位，x前面的数值代表屏幕宽度的百分比。想要屏幕元素随着屏幕宽度等比缩放，只需要确定x单位，可通过CSS3中的 rem 来实现。可通过JS设置HTML字体大小等于屏幕宽度的百分之一。

若UE设计稿宽度尺寸为640px，设计稿中某元素宽度为100px，则可以计算出100 / 640px 100px = 15625。

最佳实践：px2rem移动端自适应方案 >