当前位置： >
iOS开发 如何适配iOS10？（整理）
来源：INFOCOOL & 发布时间：
& 作者：网友 &
浏览次数：
摘要: 日，苹果发布iOS 10。日，全新的操作系统iOS 10将正式上线。 作为开发者，如何适配iOS10呢？ 1.Notifica...
日，苹果发布iOS 10。日，全新的操作系统iOS 10将正式上线。
作为开发者，如何适配iOS10呢？
1.Notification(通知)
自从Notification被引入之后，苹果就不断的更新优化，但这些更新优化只是小打小闹，直至现在iOS 10开始真正的进行大改重构，这让开发者也体会到UserNotifications的易用，功能也变得非常强大。
iOS 9 以前的通知 1.在调用方法时，有些方法让人很难区分，容易写错方法，这让开发者有时候很苦恼。 2.应用在运行时和非运行时捕获通知的路径还不一致。 3.应用在前台时，是无法直接显示远程通知，还需要进一步处理。 4.已经发出的通知是不能更新的，内容发出时是不能改变的，并且只有简单文本展示方式，扩展性根本不是很好。
iOS 10 开始的通知 1.所有相关通知被统一到了UserNotifications.framework框架中。 2.增加了撤销、更新、中途还可以修改通知的内容。 3.通知不在是简单的文本了，可以加入视频、图片，自定义通知的展示等等。 4.iOS 10相对之前的通知来说更加好用易于管理，并且进行了大规模优化，对于开发者来说是一件好事。 5.iOS 10开始对于权限问题进行了优化，申请权限就比较简单了(本地与远程通知集成在一个方法中)。
　　 &如果使用了推送，修改如图：
2.ATS的问题
iOS 9中默认非HTTS的网络是被禁止的，当然我们也可以把NSAllowsArbitraryLoads设置为YES禁用ATS。不过iOS 10从日起苹果不允许我们通过这个方法跳过ATS，也就是说强制我们用HTTPS，如果不这样的话提交App可能会被拒绝。但是我们可以通过NSExceptionDomains来针对特定的域名开放HTTP可以容易通过审核。
NSExceptionDomains方式&设置域。可以简单理解成，把不支持https协议的接口设置成http的接口。
具体方法：
1）、在项目的info.plist中添加一个Key：App Transport Security Settings，类型为字典类型。
2）、然后给它添加一个Exception Domains，类型为字典类型；
3）、把需要的支持的域添加給Exception Domains。其中域作为Key，类型为字典类型。
4）、每个域下面需要设置3个属性：NSIncludesSubdomains、NSExceptionRequiresForwardSecrecy、NSExceptionAllowsInsecureHTTPLoads。
细节提示:在iOS9以后的系统中如果使用到网络图片，也要注意网络图片是否是HTTP的哦，如果是，也要把图片的域设置哦！
3.iOS 10 隐私权限设置
iOS 10 开始对隐私权限更加严格，如果你不设置就会直接崩溃，现在很多遇到崩溃问题了，一般解决办法都是在info.plist文件添加对应的Key-Value就可以了。
以上Value值，圈出的红线部分的文字是展示给用户看的，必须添加。
4.Xcode 8 运行一堆没用的logs解决办法
上图我们看到，自己新建的一个工程啥也没干就打印一堆烂七八糟的东西，我觉得这个应该是Xcode 8的问题，
具体也没细研究，解决办法是设置OS_ACTIVITY_MODE : disable如下图:
添加参数：
Name ：OS_ACTIVITY_MODE&
Value : &disable
5.iOS 10 UIStatusBar方法过期:
在我们开发中有可能用到UIStatusBar一些属性，在iOS 10 中这些方法已经过期了，如果你的项目中有用的话就得需要适配。
上面的图片也能发现，如果在iOS 10中你需要使用preferredStatusBar比如这样：
//iOS 10 - (UIStatusBarStyle)preferredStatusBarStyle { & &return UIStatusBarStyleD }
6.iOS 10 UICollectionView 性能优化
随着开发者对UICollectionView的信赖，项目中用的地方也比较多，但是还是存在一些问题，比如有时会卡顿、加载慢等。所以iOS 10 对UICollectionView进一步的优化。
UICollectionView cell pre-fetching预加载机制
UICollectionView and UITableView prefetchDataSource 新增的API
针对self-sizing cells 的改进
Interactive reordering
　　在iOS 10 之前,UICollectionView上面如果有大量cell,当用户活动很快的时候,整个UICollectionView的卡顿会很明显,为什么会造成这样的问题,这里涉及到了iOS 系统的重用机制,当cell准备加载进屏幕的时候,整个cell都已经加载完成,等待在屏幕外面了,也就是整整一行cell都已经加载完毕,这就是造成卡顿的主要原因,专业术语叫做:掉帧.要想让用户感觉不到卡顿,我们的app必须帧率达到60帧/秒,也就是说每帧16毫秒要刷新一次.
　　iOS 10 之前UICollectionViewCell的生命周期是这样的:
1.用户滑动屏幕,屏幕外有一个cell准备加载进来,把cell从reusr队列拿出来,然后调用prepareForReuse方法,在这个方法里面,可以重置cell的状态,加载新的数据;
2.继续滑动,就会调用cellForItemAtIndexPath方法,在这个方法里面给cell赋值模型,然后返回给系统;
3.当cell马上进去屏幕的时候,就会调用willDisplayCell方法,在这个方法里面我们还可以修改cell,为进入屏幕做最后的准备工作;
4.执行完willDisplayCell方法后,cell就进去屏幕了.当cell完全离开屏幕以后,会调用didEndDisplayingCell方法.
　　iOS 10 UICollectionViewCell的生命周期是这样的:
1.用户滑动屏幕,屏幕外有一个cell准备加载进来,把cell从reusr队列拿出来,然后调用prepareForReuse方法,在这里当cell还没有进去屏幕的时候,就已经提前调用这个方法了,对比之前的区别是之前是cell的上边缘马上进去屏幕的时候就会调用该方法,而iOS 10 提前到cell还在屏幕外面的时候就调用;
2.在cellForItemAtIndexPath中创建cell，填充数据，刷新状态等操作,相比于之前也提前了;
3.用户继续滑动的话,当cell马上就需要显示的时候我们再调用willDisplayCell方法,原则就是:何时需要显示,何时再去调用willDisplayCell方法;
4.当cell完全离开屏幕以后,会调用didEndDisplayingCell方法,跟之前一样,cell会进入重用队列.在iOS 10 之前,cell只能从重用队列里面取出,再走一遍生命周期,并调用cellForItemAtIndexPath创建或者生成一个cell.在iOS 10 中,系统会cell保存一段时间,也就是说当用户把cell滑出屏幕以后,如果又滑动回来,cell不用再走一遍生命周期了,只需要调用willDisplayCell方法就可以重新出现在屏幕中了.iOS 10 中,系统是一个一个加载cell的,二以前是一行一行加载的,这样就可以提升很多性能; iOS 10 新增加的Pre-Fetching预加载 这个是为了降低UICollectionViewCell在加载的时候所花费的时间,在 iOS 10 中,除了数据源协议和代理协议外,新增加了一个UICollectionViewDataSourcePrefetching协议,这个协议里面定义了两个方法:
　　- (void)collectionView:(UICollectionView *)collectionView prefetchItemsAtIndexPaths:(NSArray&NSIndexPath *& *)indexPaths NS_AVAILABLE_IOS(10_0); 　　- (void)collectionView:(UICollectionView *)collectionView cancelPrefetchingForItemsAtIndexPaths:(NSArray&NSIndexPath *& *)indexPaths NS_AVAILABLE_IOS(10_0);
　　　在ColletionView prefetchItemsAt indexPaths这个方法是异步预加载数据的,当中的indexPaths数组是有序的,就是item接收数据的顺序;　　　CollectionView cancelPrefetcingForItemsAt indexPaths这个方法是可选的,可以用来处理在滑动中取消或者降低提前加载数据的优先级.　　　注意:这个协议并不能代替之前读取数据的方法,仅仅是辅助加载数据.　　　Pre-Fetching预加载对UITableViewCell同样适用.
7.iOS 10 UIColor 新增方法
以下是官方文档的说明：
Most graphics frameworks throughout the system, including Core Graphics, Core Image, Metal, and AVFoundation, have substantially improved support for extended-range pixel formats and wide-gamut color spaces. By extending this behavior throughout the entire graphics stack, it is easier than ever to support devices with a wide color display. In addition, UIKit standardizes on working in a new extended sRGB color space, making it easy to mix sRGB colors with colors in other, wider color gamuts without a significant performance penalty.
Here are some best practices to adopt as you start working with Wide Color.
In iOS 10, the UIColor class uses the extended sRGB color space and its initializers no longer clamp raw component values to between 0.0 and 1.0. If your app relies on UIKit to clamp component values (whether you’re creating a color or asking a color for its component values), you need to change your app’s behavior when you link against iOS 10.
When performing custom drawing in a UIView on an iPad Pro (9.7 inch), the underlying drawing environment is configured with an extended sRGB color space.
If your app renders custom image objects, use the new UIGraphicsImageRenderer class to control whether the destination bitmap is created using an extended-range or standard-range format.
If you are performing your own image processing on wide-gamut devices using a lower level API, such as Core Graphics or Metal, you should use an extended range color space and a pixel format that supports 16-bit floating-point component values. When clamping of color values is necessary, you should do so explicitly.
Core Graphics, Core Image, and Metal Performance Shaders provide new options for easily converting colors and images between color spaces.
因为之前我们都是用RGB来设置颜色，反正用起来也不是特别多样化，这次新增的方法应该就是一个弥补吧。所以在iOS 10 苹果官方建议我们使用sRGB，因为它性能更好，色彩更丰富。如果你自己为UIColor写了一套分类的话也可尝试替换为sRGB，UIColor类中新增了两个Api如下:
+ (UIColor *)colorWithDisplayP3Red:(CGFloat)displayP3Red green:(CGFloat)green blue:(CGFloat)blue alpha:(CGFloat)alpha NS_AVAILABLE_IOS(10_0); - (UIColor *)initWithDisplayP3Red:(CGFloat)displayP3Red green:(CGFloat)green blue:(CGFloat)blue alpha:(CGFloat)alpha NS_AVAILABLE_IOS(10_0);
8.iOS 10 UITextContentType
// The textContentType property is to provide the keyboard with extra information about the semantic intent of the text document.@property(nonatomic,copy) UITextContentType textContentType NS_AVAILABLE_IOS(10_0); // default is nil
在iOS 10 UITextField添加了textContentType枚举，指示文本输入区域所期望的语义意义。
使用此属性可以给键盘和系统信息，关于用户输入的内容的预期的语义意义。例如，您可以指定一个文本字段，用户填写收到一封电子邮件确认uitextcontenttypeemailaddress。当您提供有关您期望用户在文本输入区域中输入的内容的信息时，系统可以在某些情况下自动选择适当的键盘，并提高键盘修正和主动与其他文本输入机会的整合。
9.iOS 10 字体随着手机系统字体而改变
当我们手机系统字体改变了之后，那我们App的label也会跟着一起变化，这需要我们写很多代码来进一步处理才能实现，但是iOS 10 提供了这样的属性adjustsFontForContentSizeCategory来设置。因为没有真机，具体实际操作还没去实现，如果理解错误帮忙指正。
&UILabel *myLabel = [UILabel new]; & /* & &UIFont 的preferredFontForTextStyle: 意思是指定一个样式，并让字体大小符合用户设定的字体大小。 & */ & &myLabel.font =[UIFont preferredFontForTextStyle: UIFontTextStyleHeadline]; /* Indicates whether the corresponding element should automatically update its font when the device’s UIContentSizeCategory is changed. For this property to take effect, the element’s font must be a font vended using +preferredFontForTextStyle: or +preferredFontForTextStyle:compatibleWithTraitCollection: with a valid UIFontTextStyle. */ & & //是否更新字体的变化 & &myLabel.adjustsFontForContentSizeCategory = YES;
10.iOS 10 UIScrollView新增refreshControl
iOS 10 以后只要是继承UIScrollView那么就支持刷新功能：
@property (nonatomic, strong, nullable) UIRefreshControl *refreshControl NS_AVAILABLE_IOS(10_0) __TVOS_PROHIBITED;
11.iOS 10 判断系统版本正确姿势
判断系统版本是我们经常用到的，尤其是现在大家都有可能需要适配iOS 10，那么问题就出现了，如下图：
我们得到了答案是：
//值为 1 [[[[UIDevice currentDevice] systemVersion] substringToIndex:1] integerValue]//值为10.000000 [[UIDevice currentDevice] systemVersion].floatValue,//值为10.0 [[UIDevice currentDevice] systemVersion]
所以说判断系统方法最好还是用后面的两种方法，哦~我忘记说了[[UIDevice currentDevice] systemVersion].floatValue这个方法也是不靠谱的，好像在8.3版本输出的值是8.2，记不清楚了反正是不靠谱的，所以建议大家用[[UIDevice currentDevice] systemVersion]这个方法！
Swift判断如下：
&if #available(iOS 10.0, *) { & & & & & &// iOS 10.0 & & & & & &print("iOS 10.0"); & & & &} else { }
12.Xcode 8 插件不能用的问题
大家都升级了Xcode 8，但是对于插件依赖的开发者们，一边哭着一边去网上寻找解决办法。那么下面是解决办法：让你的 Xcode8 继续使用插件(http://vongloo.me//Make-Your-Xcode8-Great-Again/?utm_source=tuicool&utm_medium=referral )
但是看到文章最后的解释，我们知道如果用插件的话，可能安全上会有问题、并且提交审核会被拒绝，所以建议大家还是不要用了，解决办法总是有的，比如在Xcode中添加注释的代码块也是很方便的。
13.iOS 10开始项目中有的文字显示不全问题
我用Xcode 8 和Xcode 7.3分别测试了下，如下图：
Xcode7 创建一个Label然后让它自适应大小，字体大小都是17最后输出的宽度是不一样的，我们再看一下，下面的数据就知道为什么升级iOS 10 之后App中有的文字显示不全了：英文字母会不会也有这种问题，我又通过测试，后来发现英文字母没有问题，只有汉字有问题。目前只有一个一个修改控件解决这个问题，暂时没有其他好办法来解决。
14.Xcode 8使用Xib awakeFromNib的警告问题
在Xcode 8之前我们使用Xib初始化- (void)awakeFromNib {}都是这么写也没什么问题，但是在Xcode 8会有如下警告：
官方解释：You must call the super implementation of awakeFromNib to give parent classes the opportunity to perform any additional initialization they require.Although the default implementation of this method does nothing, many UIKit classes provide non-empty implementations. You may call the super implementation at any point during your own awakeFromNib method.你必须调用父类实现awakeFromNib来给父类来执行它们需要的任何额外的初始化的机会。虽然这种方法的默认实现不做任何事情，许多UIKit类提供非空的实现。你可以调用自己的awakeFromNib方法中的任何时候超级实现。
15、推送的时候，开启Remote notifications
You've implemented -[&UIApplicationDelegate& application:didReceiveRemoteNotification:fetchCompletionHandler:],but you still need to add "remote-notification" to the list of your supported UIBackgroundModes in your Info.plist.
解决方案：需要在Xcode 中修改应用的 Capabilities 开启Remote notifications，请参考下图：
16、One of the two will be used. Which one is undefined.”
　　objc[5114]: Class PLBuildVersion is implemented in both /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/PrivateFrameworks/AssetsLibraryServices.framework/AssetsLibraryServices (0x) and /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/PrivateFrameworks/PhotoLibraryServices.framework/PhotoLibraryServices (0x). One of the two will be used. Which one is undefined.
　　在模拟器中、发现“One of the two will be used. Which one is undefined.”日志
　　查找资料发现原因：objc runtime 对所用app使用同一个命名空间(flat namespace)，运行机制如下：
首先二进制映像被加载，检查程序依赖关系
每一个二进制映像被加载的同时，程序的objc classes在objc runtime命名空间中注册
如果具有相同名称的类被再次加载，objc runtime的行为是不可预知的。一种可能的情况是任意一个程序的该类会被加载(这应该也是默认动作)
我来说两句
友情链接：47388人阅读
iphone6适配（2）
from:http://www.xiaoketang.net/iphone-6-6-plus-设计·适配方案.html
treelessing
刘典，架构师 ：使用 Auto Layout，只需要一个 xib 文件都可以应对所有尺寸的 iPhone
陈伟，设计师：最好用 Sketch，输出1倍矢量图（pdf）程序完美适配
刘炜，：Photoshop 支持用矢量（而且应该只用矢量）元素设计界面，只是无法输出矢量资源（可以通过脚本用 AI 输出 SVG，但相对不那么方便）。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1160448次
积分：9613
积分：9613
排名：第1563名
原创：11篇
转载：285篇
评论：117条
(1)(3)(1)(4)(1)(5)(3)(4)(9)(40)(23)(52)(22)(11)(15)(3)(22)(35)(2)(2)(22)(2)(1)(1)(7)(3)(6)(6)(3)(5)(18)(23)(4)(1)移动端开发中，关于适配问题的一点总结(一) - 简书
移动端开发中，关于适配问题的一点总结(一)
我们第一次接触移动web的时候，直观印象样应该是：屏幕比pc小很多，所以对pc端设计的界面，不一定（或者说不完全）能很好的适用到移动端。下面这段代码，做过移动端项目的同学一定不会陌生。
假设你已经见过上面的代码，并有所应用，对响应式设计如何工作有大概的了解，但不一定清楚一些细节。最近在做一个移动端的项目，要求做到精确还原设计稿，像素级。现在我把自己的一些心得分享出来，给大家参考。下面我就关于像素，视口，分辨率，meta视口 相关的内容展开叙述。要实现像素级还原，首先我们要搞清楚什么是像素。#像素像素(pixel) 是网页布局的基础，web开发者，包括设计师，凭直觉去使用它。我们好像对它很熟悉，但依然还有很多关于这个基础构建模块的东西需要我们去学习。例如，一个像素到底是什么。乍一看，这似乎是个非常简单的问题，一个像素就是计算机能够显示一种特定颜色的最小区域。屏幕上像素越多，你就看到的越多。或者说，同样尺寸的设备，像素越多，效果就越细腻。对于开发者来说，给一个元素设置 width : 200会发生什么事情呢？//废话
lol ，就是给它设置宽度200px 呗，stupid question..但要注意的一点是，这里定义的200px 并不是上面提到的设备像素。
像素分为两种：1.CSS像素：为web开发者创造的，在CSS 和JavaScript 中使用的一个抽象的层。2.设备像素： 设备屏幕的物理像素，任何设备的物理像素的数量都是固定的。width : 200 这个声明 表示，这个宽度为200px的元素跨越了200个CSS 像素，200个css像素相当于多少个设备像素取决于屏幕和用户的缩放，比如，在苹果的视网膜设备上，以5s为例，其像素密度是普通屏幕的两倍，那这个元素就跨越了400个设备像素。如果用户放大，那它将跨越更多的设备像素。我们使用的时候，只是去定义它的css像素尺寸就行了，关于它用了多少设备像素，就不是我们去计算了，浏览器会进行计算的。＃视口
我们一直在使用这行代码，但是这样写有什么用 ？
加了这个和不加这个到底有什么区别？要解释这个问题，我们首先要了解一个概念 - 视口在解释视口之前，我们先回顾一下CSS的基础：css中，在没有声明任何宽度时，每个块级元素的默认宽度都是100% 。那这个100% 是相对于什么的100% 呢？ 对了，是它父元素的100% 。 每一个css百分比都是根据它的父元素的宽度来进行计算的，所以宽度为父元素 宽度的100% ，本质是：
这里，div.aside占用了它的父元素 body 宽度的100％，但我们没有给body 定义宽度，因此，它占用了它的父元素，也就是html 宽度的100% 。但，我们同样也没有给它定义宽度。因此，它占用的是它的父元素宽度的100% ;那html 的父元素是谁呢 ？这就是要说的 视口了。在CSS文档中，它叫做 初始包含块。这是百分比计算的根源，它给css布局限制了最大宽度。在pc 浏览器中，视口的宽度 和浏览器窗口的宽度是一致的（先不管margin 和padding）,html ,body 元素的宽度都和浏览器窗口的宽度一致。测试走起：
测试结果表明上面的叙述是对的，这不是什么开创性的发现，只是方便下面的讲述。布局视口小屏幕的移动端设备，主要是手机和部分平板（屏幕特别巨大的除外＝ ＝ ），如果让视口的宽度和浏览器宽度 保持一致的话，会导致一个结果-------页面很丑。手机，平板，浏览器的宽度一般在240-640像素之间，而大...大多数给pc设计的宽度至少为800，一般是960，或者1080。因此，如果用手机去看刚才的那个页面，宽度20%的aside将会非常窄。如图：
一个为桌面设计的网站 在780～ 1260px
的视口中应该会显示的很好，20% 宽度的元素也会大致像设计师希望的那样。如果移动端的浏览器也能展示为pc设计的网站，大家一定会很开心。但是这是有代价的，如上图，如果移动端浏览器遇到了没有为移动端做优化的网站，它会尽可能的缩小网站让用户看到网站的全貌。所以就显得很挤，字体很小，阅读性很差。
这样用户就只有通过放大，去看想看的信息。在手机上，视口与移动端浏览器屏幕宽度不再关联，而是完全独立的了。这个视口，叫布局视口，css布局会根据它来计算，并被它约束。如图：
左图是在chrome 中放大之后的效果，图右是在手机中，放大后的效果，仅为说明两个视口的关系。 视觉视口字面意思，它是用户正在看到的网站的区域。我们可以通过缩放去操作视觉视口，但不会影响布局视口，布局视口仍保持原来的宽度。一般情况下，视觉视口对于开发人员来说并不是那么重要，到那时如果有需要看到用户正在看什么区域的需求，可以用js来获取。##理想视口首先来解释一下这个概念默认情况下，移动设备的布局宽度为768～1024像素，虽然这能让桌面网站不被压扁，但这并不是理想情况，尤其是对于小屏幕的使用者，因为在狭小的屏幕上，更适合狭小的网站。简单的说，就是，布局视口的默认宽度并不是一个理想的宽度。这就是 苹果 和其他效仿苹果的 浏览器厂商 引进理想视口的原因。理想视口，对设备来讲，是最理想的视口尺寸。显示在理想视口中的网站拥有最理想的宽度，不需要缩放。但，只有当网站是手机（或者平板）的时候，才应该使用理想视口。所以，这行代码：
就是告诉浏览器，我要使用理想视口了。让布局视口的宽度和理想视口的宽度一样。哦，对了，只有我们人为添加这段代码，理想视口才会生效，否则，布局视口将会维持默认宽度。
缩放首先，什么是缩放...从技术上讲，缩放就是放大或者缩小css像素的过程。典型的例子就是我在手机上浏览pc端的网站，放大一点，好看清字。但是，这个缩放会影响页面上的所有元素。比如，宽度为200px的元素占用了200个css像素，由于这些像素被放大了，这些像素就跨越了更多的物理像素，缩小则相反。css像素的尺寸缩小了，跨越的设备像素也就少了。所以，缩放会影响视觉视口的尺寸。放大会使视觉视口变得更小，我们看到的内容就越少，因为屏幕上显示的css像素更少了。缩小则会使视觉视口变的更大，使我们看到更多的部分。因为屏幕上css像素更多了。所以，缩放程度和视觉视口的大小是逆相关的：缩放程度越大，视觉视口越小。一个重大区别在手机上，布局视口不会被缩放。但是在pc上会，因为它的布局视口和视觉视口大小是一样的，不可能改变一个的同时，另一个不会变。要注意的是：移动端的缩放虽然不会导致css布局被重新计算，但是频繁的操作会给cpu比较大的负担，耗电快，因此不重新布局对性能有很大好处。##最小缩放 和最大缩放initial-scale=1,maximum-scale=1"如果允许缩放，那用户可以缩放到什么程度呢 ？在手机上是5个因子， 换句话说就是20% － 500%。但是安卓-webkit-不大一样,不管有没有meta指令，它的缩放范围都是4个因子（25%－400%）;我们可以通过:
来禁止用户缩放。分辨率分辨率有两个含义。1.设备每英寸的点的个数。2.CSS 和 JavaScript 中也有分辨率的概念，不过他们并不是一回事。物理分辨率dpi所有的屏幕都有物理分辨率，衡量单位为DPI ,（dots per inch）.DPI 越大，画面越清晰。另外要注意的一点，web开发者不可能知道物理分辨率，因为没法获取这个信息。有些手机通过screen.width暴露设备像素个数，但这在不同浏览器之间是不可靠的。无论如何JavaScript 都无法获取设备的物理尺寸。##设备像素比 dprJavaScript 中，有个属性，window.devicePixelRatio ，CSS也有device-pixel-ratio 和分辨率的媒体查询，但是它们都是和物理分辨率无关的。取而代之的是，他们提供了设备像素个数和理想视口的比，成为设备像素比，device pixel ratio,简称DPR。官方文档的描述如下：
window.devicePixelRatio是设备上物理像素和设备独立像素(device-independent pixels (dips))的比例。公式表示就是：window.devicePixelRatio = 物理像素 / dips。dips:device-independent pixels设备独立像素，就是独立于设备之外的像素，也就是css像素。比如：5s的物理像素为640px, CSS像素为320px,那 pdr = 640/320 = 2.DPR不一定是整数,比如BlackBerry Z10 的宽度是768px 物理像素；CSS像素为342px,因此，它的dpr 大约为 2.25.#meta视口meta 视口标签 存在的目的
主要是 让布局视口的尺寸和理想视口的尺寸匹配。Apple 发明了这个标签，其他的厂商复制了它的大部分内容。meta 标签应该被放在&head&中，并按以下格式书写：&meta name="viewport" content = "name= value,name = value"&每一个名/值 都是一个给浏览器的指令，以逗号分隔，常用的有5个：width设置布局视口的宽度，为一个正整数initial-scale设置页面的初始缩放程度 和布局视口的宽度minimum-scale允许用户的最小缩放程度，为一个数字，可以带小数maximum-scale允许用户的最大缩放值，为一个数字，可以带小数user-scalable是否允许用户进行缩放，值为"no"或"yes", no 代表不允许，yes代表允许完美的meta 视口在safari中，当设置initial-scale= 1 时，理想视口的尺寸会随着屏幕的旋转改变。在竖屏时，布局视口的宽度是320px ,横屏下，是480px 或者568px.但在ie10中却有完全相反的问题：initial-scale = 1
时，在横屏模式下宽度也保持为320px ,但width = device-width 时，它会从320px变为480px.所以为了在所有浏览器上解决类似的问题，我们需要如下写法：
字体和尺寸有了上面的理论基础，我们就能愉快的处理移动端尺寸的问题了。移动端的尺寸，主要是间距，宽高，字体，和图像 的尺寸。由于移动设备千差万别，如何才能保证效果呢？来看一下淘宝：
要注意的有三点：1. html
头部meat标签中的DPR2. width,height 的 rem 3.font-size 的rem：font size of the root element，那么rem是个单位，单位大小由根元素font-size的大小决定。关于动态修改font-size,具体的做法，可以参考 ,这里不再赘述。解决移动端尺寸问题的关键就是根元素的尺寸问题。现在普遍的做法是动态修改根元素的font-size,这样rem 会随着设备的变化有着不同的参考值，那尺寸问题就迎刃而解了。除了使用rem,另一种做法是使用来解决适配问题，这里暂时就不讨论了。还有一个是字体的问题，用一幅图表达就是：
字体的问题说大不大，说小也不小，关乎到用户体验，马虎不得。在字体的设置上，不推荐使用rem。我的做法是根据DPR 设置字体。当然，在开发的时候，我们不用手动去做这件事，可以借助来解决。如果不想用gulp，也可以使用scss 来解决。我简单定义了一下字体的mixin,基本能用，也给大家看看吧，欢迎拍砖。
也可以这样：
可以这样用：
生成的代码：
也可以看看了解webapp 中有关字体的更多信息。ios、android 等是不支持微软雅黑字体，为了满足产品的需要，保证视觉稿的还原度，手机端是如何定义微软雅黑字体呢？大家可能会想到 @font-face 定义为微软雅黑字体并存放到 web 服务器上，在需要使用时被自动下载.
但是这样做有两个比较突出的问题：1.中文字库文件往往很大，一来消耗用户的流量，二来对页面的打开速度造成了延迟。2.虽然可以用字蛛这样的工具去提取用到的字体，但是不方便后期维护。ios 系统默认中文字体是默认英文字体是默认数字字体是HelveticaNeue无微软雅黑字体android 系统默认中文字体是Droidsansfallback默认英文和数字字体是Droid Sans无微软雅黑字体winphone 系统默认中文字体是Dengxian(方正等线体)默认英文和数字字体是Segoe无微软雅黑字体做了个小测试，下图为测试机 iphone 5s、三星 GT-N7000 android 2.3.6、HTC windows Phone 8.0 三种手机中的默认中文字体和英文字体展现：
可以看出三种不同的中文字体和微软雅黑一样是，有无衬线只是一个小原因，而无论页面中使用哪种字体，肉眼很难看出它们的差异，对产品的体验几乎没有影响。有关衬线字体和无衬线字体的差别，参考下图：
使用系统默认的字体所达到的视觉效果跟使用微软雅黑字体没有明显的差别。结论：各个手机系统有自己的默认字体，且都不支持微软雅黑.如无特殊需求，手机端无需定义中文字体，使用系统默认.英文字体和数字字体可使用 Helvetica ，三种系统都支持.body {font-family: "Helvetica Neue", Helvetica, STHeiTi, sans-}
iOS 4.0+ 使用英文字体 Helvetica Neue，之前的iOS版本降级使用 Helvetica。中文字体设置为华文黑体STHeiTi（中文名称叫黑体-简）。设计时候一般用华文黑体来代替，两者差异微小。#结语第一、首先如果不设置meta viewport标签，那么移动设备上浏览器默认的宽度值为800px，980px，1024px等这些，总之是大于屏幕宽度的。这里的宽度所用的单位px都是指css中的px，它跟代表实际屏幕物理像素的px不是一回事。第二、使用 &meta name="viewport" content="width=device-width, initial-scale=1"&来得到一个理想视口。第三、市面上虽然有那么多不同种类不同品牌不同分辨率的手机，但它们的理想viewport宽度归纳起来无非也就 320、360、384、400等几种，都是非常接近的，理想宽度的相近也就意味着我们针对某个设备的理想viewport而做出的网站，在其他设备上的表现也不会相差非常多甚至是表现一样的。第四、使用rem 处理尺寸，使用font-size处理字体。最后的最后，由于本人还是前端路上的小菜鸟，见识有限，才疏学浅，有表述错误的地方，还请指正，以上。附参考资料：推荐：
指尖上的精彩}