&&&&Delphi实现窗体自适应调整尺寸以适应不同屏幕分辩率的显示问题。
&Delphi实现窗体自适应调整尺寸以适应不同屏幕分辩率的显示问题。
实现窗体自适应调整尺寸以适应不同屏幕分辩率的显示问题
若举报审核通过，可奖励20下载分
被举报人：
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：
VIP下载&&免积分60元/年（1200次）
您可能还需要
Q.为什么我点的下载下不了，但积分却被扣了
A. 由于下载人数众多，下载服务器做了并发的限制。若发现下载不了，请稍后再试，多次下载是不会重复扣分的。
Q.我的积分不多了，如何获取积分？
A. 获得积分，详细见。
完成任务获取积分。
论坛可用分兑换下载积分。
第一次绑定手机，将获得5个C币，C币可。
关注并绑定CSDNID，送10个下载分
下载资源意味着您已经同意遵守以下协议
资源的所有权益归上传用户所有
未经权益所有人同意，不得将资源中的内容挪作商业或盈利用途
CSDN下载频道仅提供交流平台，并不能对任何下载资源负责
下载资源中如有侵权或不适当内容，
本站不保证本站提供的资源的准确性，安全性和完整性，同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
开发技术下载排行
您当前C币：0&&&可兑换 0 下载积分
兑换下载分:&
消耗C币:0&
立即兑换&&
兑换成功你当前的下载分为 。前去下载资源
你下载资源过于频繁，请输入验证码
如何快速获得积分？
你已经下载过该资源，再次下载不需要扣除积分
Delphi实现窗体自适应调整尺寸以适应不同屏幕分辩率的显示问题。
所需积分：8
剩余积分：0
扫描微信二维码精彩活动、课程更新抢先知
VIP会员，免积分下载
会员到期时间：日
剩余下载次数：1000
Delphi实现窗体自适应调整尺寸以适应不同屏幕分辩率的显示问题。
剩余次数：&&&&有效期截止到：
你还不是VIP会员VIP会员享免积分 . 专属通道极速下载
VIP下载次数已满VIP会员享免积分 . 专属通道极速下载，请继续开通VIP会员
你的VIP会员已过期VIP会员享免积分 . 专属通道极速下载，请继续开通VIP会员客户端设计:针对不同的屏幕大小如何设计_界面设计_前端技术
您的位置： &
& 详细内容
文章描述：客户端交互设计适配之――屏幕大小.
随着各个手机操作系统的应用平台的上线，几乎所有的互联网应用都在往手机上迁移。然而手机与PC 不一样，PC经过了多年的发展，在设计上形成了很多不成文的规则，如网页的宽度都在960px左右【当然，由于整体的电脑屏幕往大尺寸及高分辨发展，除了背景宽屏自适应外，不少网页也正朝着更宽的方向上发展】。当前的手机种类繁多，手机屏幕的大小、比例各异，并且手机的屏幕本身就小，因此既要考虑应用在不同屏幕大小上的适配，又要保持其一致性，同时还要提高每个手机屏幕的使用效率，这就存在着很多的矛盾点。
在客户端的设计过程中，针对不同的屏幕大小，应该如何来设计？是否每个大小的屏幕尺寸都需要一个新的界面布局，还是所有的屏幕尺寸都使用相同的界面布局？我们将在下面的内容中来探讨这些内容。
一、当前热门手机的屏幕大小&
下图中，我抽取了国内某个网络电器城某周的10大畅销手机排名：
虽然只是2010年中的某一周的手机销售量排名，由此可以看出，当前使用中的手机屏幕差异很大，各种屏幕大小和分辨率都有。如果为了适配更多的用户群体，则需要考虑的手机屏幕大小和分辨率更多。【不过，根据当前的手机发展趋势，及手机客户端的使用行为可以看出，最主要需要用户关注的手机屏幕是2.4家陨希240*320以上的手机屏幕，因为这样的手机使用客户端的频率和用户量都会更多。个人建议更多地是考虑320*480及以上的屏幕。】
二、屏幕大小正确理解
说起屏幕大小的时候，会有两种表达方式，1） &我的屏幕2.4迹愕钠聊3.5肌& 2）&这个屏幕分辨率 240*320，那个屏幕分辨率为320*480。&但在设计过程中，屏幕的分辨率和屏幕的实际尺寸必须同时考虑。
这里首先有几个概念需要再澄清一下：
屏幕物理尺寸：屏幕对角线长的实际尺寸，如2.4迹3.5嫉鹊
屏幕分辨率：屏幕所能显示像素的多少。如，240*320等。
屏幕密度（pixel per inch）：以每英寸的像素数。每英寸的分辨率数，如160ppi。
物理尺寸决定了屏幕的实际尺寸，而分辨率可以表示屏幕上可以呈现的像素点数，屏幕密度决定了屏幕的精细程度。相同的屏幕大小，如果分辨率高，则屏幕元素更精细。一个界面元素在屏幕里的实际尺寸却是与屏幕密度相关，屏幕密度较小的屏上，界面元素的实际尺寸就会大些，反之亦然。
&在进行手机界面布局中，除了元素的像素值外，考虑元素的实际尺寸也非常重要，甚至更为重要（人眼是要靠物体成像在视网膜上的视角大小来进行识别感知，视角是与物体实际大小和距离有关）。
&&&&&&&&&&
在不同屏幕中，不同的图标点阵或者不同的字体及大小的汉字，在人的主观感知上，会有一个最优的结果值。在设计的过程中，我们需要根据这个最优值来进行界面的布局及设计。
也可以看出，这个用户感知最优的取值也与使用手机的人群有关（如年龄大的用户需要物理尺寸更大的界面元素）。
1．确定目标的屏幕大小
屏幕大小由宽度和高度两个因素决定，但是在布局手机客户端的过程中，最关心的是宽度值。宽度确定后，高度可以由滚动或者翻页来显示所有内容；文字可以在适当的位置折行；标题栏可以伸缩适配屏幕宽度等等。但并不是不考虑高度，图标、文字、特殊的组件不仅需要考虑宽度，也需要考虑整个屏幕的布局是否与之适配。
由于不可能对所有的客户端进行单独的开发，因此，需要对手机屏幕的大小的归类。同时，在设计中也不会真的只考虑屏幕大小一个因素，屏幕大小和操作系统、手机类型等还是存在很大的相关性的。
首先，我们先来定义一下手机的屏幕大小的归类档次：
A. 小屏幕：宽度240 px 以下屏幕或者2.4 以下屏幕
一般以非智能机为主，归在这个分类中的手机屏幕，一般是以java版本的客户端为主。
B. 中等屏幕：宽度240~320 px，或者2.4~3.0计聊
智能手机以Symbian或S60 v1,2,3，Windows mobile为主流；或者是非智能手机的客户端以java版本为主。
同时包括240*320的宽屏手机。
C. 大屏幕：宽度320 px以上屏幕或者 3.0家陨系钠聊
&iPhone 手机只有两个版本的适配，屏幕物理尺寸保持一致；
Android 系统手机及衍生平台手机
Win phone 7 系统手机
Nokia S60 v5，symbian 3等
D. 平板屏幕：7技耙陨系钠聊弧究梢圆话谑只校^_^】
由于当前的平板电脑上的应用的开发都是基于手机应用的功能，但是，平板的屏幕物理尺寸大增，使用情景也和手机不一致，在设计上有很多的特殊性，可发挥空间也更大，因此个人建议单独的设计。
其次，根据我们的产品战略，来确定待开发产品的用户群体来确定一款目标手机屏幕。由于对于某个业务的手机客户端都不会只推出其中的某一款（除非是战略上的用户群确定为使用某种手机的特殊业务），而是会对不同的手机平台分别进行适配。因此，确定的目标手机屏幕，应该是在该档次中最主流的手机屏幕大小，在以此为基准向上或向下来适配其他的同档手机。
2．适配原则
1）& 客户端的logo，在各个手机上都应该清晰地显示
2）& 标题或者底部栏必须100%的与手机宽度适配
3）& 文字内容如果显示不下的话，可以自动适配宽度进行折行
4）& 图片可以根据宽度进行自动缩放，屏幕宽度超过图片本身时，显示图片本身的大小
5）& 适配过程中，界面的元素的宽高最小值应该符合用户的主观舒适范围值。
6）& 不能完全使用分辨率的绝对比例来对界面布局进行缩放；
3. 适配思路分析
根据我们前面的分析，
C类大屏幕大小主要以Android、iPhone、win phone 7 和Nokia V5等手机为主，它们都是触屏手机，在适配上可以划为一个档次。
B类中等屏幕大小智能机主要以Symbian 和Windows mobile为主，因此在适配这两个平台时，主要集中在B类屏幕间的适配。
B类中等屏幕大小还有一块是非智能手机，使用Java客户端，同时，A类小屏幕大小主要使用Java客户端，因此，Java类客户端需要适配的范围更广，至少应包括B类和A类的屏幕大小。
（1）Android 与iPhone手机的适配
iPhone 本身就只有两个分辨率及一个屏幕大小尺寸，可以很好的来适配（最多出两套图片即可，系统会自动读取）。
对于android，由于其开放性，导致了各种屏幕的大小及分辨率都有。但Android系统有一个很好的特性，系统会根据屏幕的分辨率密度来进行自适应。但是，当密度差异较大时，自适应后，图标会由于拉伸变得模糊影响效果。这时，必须要通过重新设计新的图标或者加大间距来保持最佳的视觉效果及更便利于用户操作。
Android 手机屏根据屏幕的分辨率密度和物理尺寸，可以分为以下几类：
&注：图中的【】内的值为手机所占的百分比值。Android 开发平台数据，不一定准
Android 提供了如下的机制来对不同大小和密度的屏幕进行适配：
1）& 图片资源的缩放
基于当前屏幕的密度，平台自动加载任何未经缩放的限定尺寸和密度的图片。如果图片不匹配，平台会加载默认资源并且在放大或者缩小之后可以满足当前界面的显示要求。如果没有多套资源，平台会认为默认的资源是中密度的屏幕资源（160dpi）。例如，当前为高密度屏幕，平台会加载高密度资源（如图片），如果没有，平台会将中密度资源缩放至高密度。
2）& 根据分辨率和坐标自动缩放（密度不同的屏幕适配）
如果程序不支持多种密度屏幕，平台会自动缩放绝对像素坐标值和尺寸值等，这样就能保证屏幕元素能和密度160的屏幕上一样能显示出同样物理尺寸的效果。平台会根据密度的比例来缩放实际尺寸的大小。
3）& 兼容更大的屏幕大小（屏幕不同的适配）
当前屏幕超过程序所支持屏幕的上限时，定义supports-screens元素，这样超出显示的基准线时，平台会以屏幕大小的比例来缩放整个屏幕。
由上表格也可知，当前的Android手机主要集中在标准屏的中密度和高密度两个型号上。因此在设计中，主要是设计其中的一种为主，再去适配另一个型号即可。对于在一个档次上的手机，都会根据上述的三个原则，系统自动去适配。个人认为，在进行Android手机设计时，如果只准备一套资源时，应该以高密度的版本为主，这样去适配中密度时，效果更好。
当然，如果屏幕的密度差异较大时，自动适配的效果肯定不会，如果要取得更好的适配效果，必须针对几个不同的屏幕密度进行单独设计屏幕元素，提高视觉满意度。
（2）非Android、iphone的手机适配
对于其他的非Android、iphone手机，则需要更多地考虑其适配规则，这些手机系统不提供自适应的适配。
简单整理规则如下：
1）& 向上适配（标准屏向更大【分辨率高，物理尺寸大】的屏幕适配）
在向更大的屏幕适配时，根据设备分辨率的不同，会分为两种状态。
A．如果两者的屏幕分辨率密度（dip）差不多，物理尺寸更大的屏幕。那可以直接在当前尺寸上拉长、拉宽即可，图标、行距都可以保持不变。
B. 如果屏幕密度要大很多，物理尺寸差不多的。则适配点包括：
设计多套图标，需要有更大分辨率的图标
使用不同的字体，需要更大的字体来适配大设备分辨率的屏幕
增加行间距
自适应放大内容中的图片
Tab页签 需要根据屏幕的大小来确认每屏最多显示的数目。
&考虑一些复杂界面，增大界面中的一些元素的分辨率，会导致许多东西需要重新设计。这种情况需要重新设计该界面。
2）& 向下适配
在向更小的屏幕适配，这种情况较少，那会集中在如下几点：
考虑一些极限点的改进，需要适配到小屏幕的手机中，如标题的最大字数等。
title、bottom栏与小屏幕宽度适配。
考虑到行高（行信息展示）的设计是否适合更小的屏幕高度。
在结构上，需要考虑在小屏幕中，显示是否合适。
根据屏幕密度的比例来设计屏幕元素，需要更小分辨率的屏幕元素
使用小的字体，具体的大小需要根据屏幕的大小来设定。
（3）竖屏横屏适配
横竖屏的适配，在本文中，不过多讨论，这里只是简单的整理一下，我自己的理解。
对于不同功能的应用，都有其特定的页面展现形式，个人并不赞同蛮目对任何应用不加选择的都去适配横屏。
个人观点如下：
1）& 不同的应用，在设计的过程中，对于选择不同的屏幕有不同的选择，如普通list多的应用，竖屏更合适；显示图片更多的界面，或者想更好的展示全景的应用，横屏更合适。
2）& 不必遵循，对任何的应用都可以自动进行横屏竖屏的切换。如果觉得没有必要横屏或者竖屏的应用，就可以不切换。
3）& 由于用户在使用手机的过程中，经常会无意中调整位置，从而导致手机误认为是要进行横竖屏的转化，从而更容易导致操作上的失误，引起用户的反感。
4）& 横竖屏的切换时，允许用户对于同一个界面有不同的展示方式。例如不一定在竖屏时时list方式显示，在横屏时也和竖屏保持一致，这时横屏可以有更好的适应横屏的展示方式，使用户更好的操作。
由于手机系统各异，手机的屏幕尺寸五花八门，屏幕的性能也呈现多样性，还有触摸屏和非触屏的区分，这四个变量结合起来，会有无数种不同的情况，如何能使你的应用完美地展现给用户，适配固然很重要。但是，更重要的是你要在适配之前，确定应用的目标群体。如果你的应用主要是针对高端手机用户的，那你何必去考虑低端的手机呢？毕竟为了很少的用户，使你花了很大的力气，可能会有不值得，这一点绝对值得每一个设计师思考。
===========
&&&&&& 题外话
一般来说，我们在设计一个产品时，首先需要确定产品的用户群体，然后基于用户群体来设计针对该用户群特点和使用行为的界面。但是对于手机客户端，感觉这个过程不能完全适用：
原因是因为，我的客户端设计主要是针对不同的手机平台（Android、ios，Win Phone 7，Palm Pre，Symbian&）来开发的，因此，开发出来的客户端适用于所有的持有该手机的用户。但是这些手机持有者是否都有相同的特质，是否都喜爱使用该客户端，是个很大的未知数。另一方面，如果我在建立用户群时，完全根据用户的需求、使用行为又或者人种学特征来分类，那每一群人中持有的手机各不相同，那又该如何定义每个不同平台下的客户端的功能呢？
当然，有人也会说那就先了解不同的手机平台的用户群特征，然后再研究这群人对本客户端应用的需求和使用行为，以此再来设计客户端，目前来说这是更好的研究思路。
总之，这样深入的讨论，会发现客户端会越想越复杂，有人说手机客户端的设计是最复杂的，是很有道理的，值得大家更多地探讨&
( 04:07:59)
( 14:22:25)
( 11:28:51)
( 17:21:00)
( 19:18:00)
相关排行总榜&&&&Delphi实现窗体自适应调整尺寸以适应不同屏幕分辩率的显示问题。
Delphi实现窗体自适应调整尺寸以适应不同屏幕分辩率的显示问题。
实现窗体自适应调整尺寸以适应不同屏幕分辩率的显示问题
若举报审核通过，可奖励20下载分
被举报人：
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：
VIP下载&&免积分60元/年（1200次）
您可能还需要
开发技术下载排行Android官方提供的支持不同屏幕大小的全部方法
本文将告诉你如何让你的应用程序支持各种不同屏幕大小，主要通过以下几种办法：
让你的布局能充分的自适应屏幕 根据屏幕的配置来加载合适的UI布局 确保正确的布局应用在正确的设备屏幕上 提供可以根据屏幕大小自动伸缩的图片 -
使用 &wrap_content& 和 &match_parent&
为了确保你的布局能够自适应各种不同屏幕大小，你应该在布局的视图中使用&wrap_content&和&match_parent&来确定它的宽和高。如果你使用了&wrap_content&，相应视图的宽和高就会被设定成刚好能够包含视图中内容的最小值。而如果你使用了&match_parent&(在 API 8之前叫作&fill_parent&)，就会让视图的宽和高延伸至充满整个父布局。
通过使用&wrap_content&和&match_parent&来替代硬编码的方式定义视图大小，你的视图要么仅仅使用了需要的那边一点空间，要么就会充满所有可用的空间。例如：
注意上面的例子中是如何使用&wrap_content&和&match_parent&来给控件定义宽高的，这让整个布局可以正确地适应不同屏幕的大小，甚至是横屏。
下图是这个布局分别在竖屏和横屏时显示的结果，注意控件的宽和高是根据屏幕自适应的。
使用RelativeLayout
通过多层嵌套LinearLayout和组合使用&wrap_content&和&match_parent&已经可以构建出足够复杂的布局。但是LinearLayout无法允许你准确地控制子视图之前的位置关系，所有LinearLayout中的子视图只能简单的一个挨着一个地排列。如果你需要让子视图能够有更多的排列方式，而不是简单地排成一行或一列，使用RelativeLayout将会是更好的解决方案。RelativeLayout允许布局的子控件之间使用相对定位的方式控制控件的位置，比如你可以让一个子视图居屏幕左侧对齐，让另一个子视图居屏幕右侧对齐。
下图展示了这个布局在QVGA屏幕上显示的结果。
下图展示了这个布局在一个更大的屏幕上显示的结果。
可以注意到，即使屏幕的大小改变，视图之前的相对位置都没有改变。
使用Size限定符
虽然使用以上几种方式可以解决屏幕适配性的问题，但是那些通过伸缩控件来适应各种不同屏幕大小的布局，未必就是提供了最好的用户体验。你的应用程序应该不仅仅实现了可自适应的布局，还应该提供一些方案根据屏幕的配置来加载不同的布局，可以通过配置限定符(configuration qualifiers)来实现。配置限定符允许程序在运行时根据当前设备的配置自动加载合适的资源(比如为不同尺寸屏幕设计不同的布局)。
现在有很多的应用程序为了支持大屏设备，都会实现&two pane&模式(程序会在左侧的面板上展示一个包含子项的List，在右侧面板上展示内容)。平板和电视设备的屏幕都很大，足够同时显示两个面板，而手机屏幕一次只能显示一个面板，两个面板需要分开显示。所以，为了实现这种布局，你可能需要以下文件：
res/layout/main.xml，single-pane(默认)布局：
res/layout-large/main.xml，two-pane布局：
请注意第二个布局的目录名中包含了large限定符，那些被定义为大屏的设备(比如7寸以上的平板)会自动加载此布局，而小屏设备会加载另一个默认的布局。
使用Smallest-width限定符
使用Size限定符有一个问题会让很多程序员感到头疼，large到底是指多大呢？很多应用程序都希望能够更自由地为不同屏幕设备加载不同的布局，不管它们是不是被认定为&large&。这就是Android为什么在3.2以后引入了&Smallest-width&限定符。
Smallest-width限定符允许你设定一个具体的最小值(以dp为单位)来指定屏幕。例如，7寸的平板最小宽度是600dp，所以如果你想让你的UI在这种屏幕上显示two pane，在更小的屏幕上显示single pane，你可以使用sw600dp来表示你想在600dp以上宽度的屏幕上使用two pane模式。
res/layout/main.xml，single-pane(默认)布局：
res/layout-sw600dp/main.xml，two-pane布局：
这意味着，那些最小屏幕宽度大于600dp的设备会选择layout-sw600dp/main.xml(two-pane)布局，而更小屏幕的设备将会选择layout/main.xml(single-pane)布局。
然而，使用早于Android 3.2系统的设备将无法识别sw600dp这个限定符，所以你还是同时需要使用large限定符。这样你就需要在res/layout-large和res/layout-sw600dp目录下都添加一个相同的main.xml。下节你将会看到如何避免重复定义这种布局的技巧。
使用布局别名
Smallest-width限定符仅在Android 3.2及之后的系统中有效。因而，你也需要同时使用Size限定符(small, normal, large和xlarge)来兼容更早的系统。例如，你想手机上显示single-pane界面，而在7寸平板和更大屏的设备上显示multi-pane界面，你需要提供以下文件：
res/layout/main.xml: single-pane布局
res/layout-large: multi-pane布局
res/layout-sw600dp: multi-pane布局
最后的两个文件是完全相同的，为了要解决这种重复，你需要使用别名技巧。例如，你可以定义以下布局：
res/layout/main.xml, single-pane布局
res/layout/main_twopanes.xml, two-pane布局
加入以下两个文件：
res/values-large/layout.xml:
@layout/main_twopanes
res/values-sw600dp/layout.xml:
@layout/main_twopanes
最后两个文件有着相同的内容，但是它们并没有真正去定义布局，它们仅仅只是给main定义了一个别名main_twopanes。这样两个layout.xml都只是引用了@layout/main_twopanes，就避免了重复定义布局文件的情况。
使用Orientation限定符
有些布局会在横屏和竖屏的情况下都显示的很好，但是多数情况下这些布局都可以再调整的。在News Reader示例程序中，布局在不同屏幕尺寸和不同屏幕方向中是这样显示的：
小屏幕, 竖屏: 单面板, 显示logo
小屏幕, 横屏: 单面板, 显示logo
7寸平板, 竖屏: 单面板, 显示action bar
7寸平板, 横屏: 双面板, 宽, 显示action bar
10寸平板, 竖屏: 双面板, 窄, 显示action bar
10寸平板, 横屏: 双面板, 宽, 显示action bar
电视, 横屏: 双面板, 宽, 显示action bar
所有这些布局都是定义在 res/layout/ 这个目录下，为了要让设备根据屏幕配置来加载正确的布局，程序需要使用布局别名来实现。
res/layout/onepane.xml:
res/layout/onepane_with_bar.xml:
res/layout/twopanes.xml:
res/layout/twopanes_narrow.xml:
现在所有需要的布局都已经定义好了，剩下的只要使用限定符来让各个设备根据屏幕配置加载正确的布局了。你现在就可以使用布局别名技术：
res/values/layouts.xml:
@layout/onepane_with_bar
res/values-sw600dp-land/layouts.xml:
@layout/twopanes
res/values-sw600dp-port/layouts.xml:
@layout/onepane
res/values-large-land/layouts.xml:
@layout/twopanes
res/values-large-port/layouts.xml:
@layout/twopanes_narrow
使用Nine-Patch图片
支持不同屏幕大小通常情况下也意味着，你的图片资源也需要有自适应的能力。例如，一个按钮的背景图片必须能够随着按钮大小的改变而改变。
如果你想使用普通的图片来实现上述功能，你很快就会发现结果是令人失望的，因为运行时会均匀地拉伸或压缩你的图片。解决方案是使用nine-patch图片，它是一种被特殊处理过的PNG图片，你可以指定哪些区域可以拉伸而哪些区域不可以。
因而，当你设计需要在不同大小的控件中使用的图片时，最好的方法就是用nine-patch图片。为了将图片转换成nine-patch图片，你可以从一张普通的图片开始：
然后通过SDK中带有的draw9patch工具打开这张图片(工具位置在SDK的tools目录下)，你可以在图片的左边框和上边框绘制来标记哪些区域可以被拉伸。你也可以在图片的右边框和下边框绘制来标记内容需要放置在哪个区域。结果如下图所示：
注意图片边框上的黑色像素，在上边框和左边框的部分表示当图片需要拉伸时就拉伸黑点标记的位置。在下边框和右边框的部分表示内容将会被放置的区域。
同时需要注意，这张图片的后缀名是 .9.png。你必须要使用这个后缀名，因为系统就是根据这个来区别nine-patch图片和普通的PNG图片的。
当你需要在一个控件中使用nine-patch图片时(如android:background=&@drawable/button&)，系统就会根据控件的大小自动地拉伸你想要拉伸的部分，效果如下图所示：
(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: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'26944人阅读
Android开发（45）
有必要了解的 Android中常见的单位 dip, dp, px, sp之间的区别：
dip: device independent pixels(设备独立像素). 不同设备有不同的显示效果,这个和设备硬件有关，一般我们为了支持WVGA、HVGA和QVGA 推荐使用这个，不依赖像素。
px: pixels(像素). 不同设备显示效果相同，一般我们HVGA代表320x480像素，这个用的比较多。
pt: point，是一个标准的长度单位，1pt＝1/72英寸，用于印刷业，非常简单易用；
sp: scaled pixels(放大像素). 主要用于字体显示best for textsize，根据 google 的建议，TextView 的字号最好使用 sp 做单位，
Android支持下列所有单位：
px（像素）：屏幕上的点。
in（英寸）：长度单位。
mm（毫米）：长度单位。
pt（磅）：1/72英寸。
dp（与密度无关的像素）：一种基于屏幕密度的抽象单位。在每英寸160点的显示器上，1dp = 1px。
dip：与dp相同，多用于Android/ophone示例中。
sp（与刻度无关的像素）：与dp类似，但是可以根据用户的字体大小首选项进行缩放。
=================================================================================
这些术语都是指屏幕的分辨率。
VGA：Video Graphics Array，即：显示绘图矩阵，相当于640×480 像素；
HVGA：Half-size VGA；即：VGA的一半，分辨率为480×320；
QVGA：Quarter VGA；即：VGA的四分之一，分辨率为320×240；
WVGA：Wide Video Graphics Array；即：扩大的VGA，分辨率为800×480像素；
WQVGA：Wide Quarter VGA；即：扩大的QVGA，分辨率比QVGA高，比VGA低，一般是：400×240，480×272；
在设计之初，Android系统就被设计为一个可以在多种不同分辨率的设备上运行的操作系统。对于应用程序来说，系统平台向它们提供的是一个稳定的，跨平台的运行环境，而关于如何将程序以正确的方式显示到它所运行的平台上所需要的大部分技术细节，都由系统本身进行了处理，无需程序的干预。当然，系统本身也为程序提供了一系列API，所以在目标平台的分辨率是可以完全确定的情况下，程序也可以精确的控制自身在目标平台上的界面显示方式。
这个文档会说明系统平台究竟提供了哪些分辨率支持特性，与它们如何在程序中使用的信息。如果你遵循文档中列出的方法，就很容易让你的程序在所有支持的分辨率下都能完美显示。这样你就可以用一个单独的.apk文件，将你的程序发布到所有的平台上。
如果你已经发布过针对Android 1.5或更早版本平台的程序，你应该仔细阅读这篇文档，然后考虑一下到底如何让自己的老程序可以在拥有各种不同分辨率，并且运行着Android 1.6或更新平台上正常显示。在绝大部分情况下，只需要对程序作出小小的修改就可以达到目的，但你仍然需要尽可能地在各种分辨率的平台上进行测试。
特别的，如果你有一个已经完成的程序，又想让它可以在超低分辨率的设备（比如320×240）上正确运行，你需要阅读“老程序的更新策略”，那篇文档会告诉你应该怎么做。
术语和概念
屏幕的物理尺寸，以屏幕的对角线长度作为依据（比如2.8寸，3.5寸）。
简而言之，Android把所有的屏幕尺寸简化为三大类：大，正常，和小。
程序可以针对这三种尺寸的屏幕提供三种不同的布局方案，然后系统会负责把你的布局方案以合适的方式渲染到对应的屏幕上，这个过程是不需要程序员用代码来干预的。
屏幕长宽比
屏幕的物理长度与物理宽度的比例。程序可以为制定长宽比的屏幕提供制定的素材，只需要用系统提供的资源分类符long和notlong。
屏幕上拥有的像素的总数。注意，虽然大部分情况下分辨率都被表示为“宽度×长度”，但分辨率并不意味着屏幕长宽比。在Android系统中，程序一般并不直接处理分辨率。
以屏幕分辨率为基础，沿屏幕长宽方向排列的像素。
密度较低的屏幕，在长和宽方向都只有比较少的像素，而高密度的屏幕通常则会有很多——甚至会非常非常多——像素排列在同一区域。屏幕的密度是非常重要的，举个例子，长宽以像素为单位定义的界面元素（比如一个按钮），在低密度的屏幕上会显得很大，但在高密度的屏幕上则会显得很小。
密度无关的像素（DIP）
指一个抽象意义上的像素，程序用它来定义界面元素。它作为一个与实际密度无关的单位，帮助程序员构建一个布局方案（界面元素的宽度，高度，位置）。
一个与密度无关的像素，在逻辑尺寸上，与一个位于像素密度为160DPI的屏幕上的像素是一致的，这也是Android平台所假定的默认显示设备。在运行的时候，平台会以目标屏幕的密度作为基准，“透明地”处理所有需要的DIP缩放操作。要把密度无关像素转换为屏幕像素，可以用这样一个简单的公式：pixels = dips * (density / 160)。举个例子，在DPI为240的屏幕上，1个DIP等于1.5个物理像素。我们强烈推荐你用DIP来定义你程序的界面布局，因为这样可以保证你的UI在各种分辨率的屏幕上都可以正常显示。
支持的屏幕分辨率范围
1.5及更早版本的Android系统，在设计的时候假定系统只会运行在一种分辨率的设备上——HVGA（320×480）分辨率，尺寸为3.2寸。由于系统只能工作在一种屏幕上，开发人员就可以针对那个屏幕来编写自己的程序，而无需去考虑程序在其他屏幕上的显示问题。
但自从Android 1.6以来，系统引入了对多种尺寸、多种分辨率屏幕的支持，以此满足拥有各种配置的新平台的运行需求。这就意味着开发人员在针对Android 1.6或更新版系统开发程序的时候，需要为自己的程序在多种分辨率的屏幕上良好显示作出额外的设计。
为了简化程序员面在对各种分辨率时的困扰，也为了具备各种分辨率的平台都可以直接运行这些程序，Android平台将所有的屏幕以密度和分辨率为分类方式，各自分成了三类：
·三种主要的尺寸：大，正常，小；
·三种不同的密度：高（hdpi），中（mdpi）和低（ldpi）。
如果需要的话，程序可以为各种尺寸的屏幕提供不同的资源（主要是布局），也可以为各种密度的屏幕提供不同的资源（主要是位图）。除此以外，程序不需要针对屏幕的尺寸或者密度作出任何额外的处理。在执行的时候，平台会根据屏幕本身的尺寸与密度特性，自动载入对应的资源，并把它们从逻辑像素（DIP，用于定义界面布局）转换成屏幕上的物理像素。
下表列出了Android平台支持的屏幕中一些比较常用的型号，并显示了系统是如何把它们分类到不同的屏幕配置里的。有些屏幕分辨率并不在下面的列表上，但系统仍会把它们归入下列的某一个类型中。
低密度（120），ldpi
中密度（160），mdpi
高密度（240），hdpi
·QVGA（240×320），2.6～3.0寸
·WQVGA（240×400），3.2～3.5寸
·FWQVGA（240×432），3.5～3.8寸
·HVGA（320×480），3.0～3.5寸
·WVGA（480×800），3.3～4.0寸
·FWVGA（480×854），3.5～4.0寸
·WVGA（480×800），4.8～5.5寸
·FWVGA（480×854），5.0～5.8寸
首先，一块屏幕有几个参数，屏幕的物理尺寸，分辨率，像素密度(Density, DPI)。
物理尺寸，就是所说的几寸的屏幕，代表屏幕对角线的长度，比如3.5寸、3.7寸、4寸、7寸等。分辨率，是屏幕总共能显示的像素数，通常我们都说几百×几百，比如240*320，320*480，480*800等，我们一般直接说乘后的结果。像素密度(DPI)，DPI的全称是dots per inch，每英寸点数，还有个词是PPI，是每英寸像素数，其实PPI感觉更准确一些，这两个比较纠结，很多时候混用，这里就不明确区分了。（本文的意思都是“每英寸像素数”）
这三个参数，任两个确定后，第三个量就是确定了。公式为：分辨率（总像素数）= 物理尺寸 × 像素密度。
比如一个3寸的屏幕，分辨率为240×320，那么密度为 开方(480x800/3.5) 约等于为160。再比如一个3.5寸的屏幕，分辨率为480×800，那么密度为 开方(480x800/3.5) 约等于为331。在比如一个3.5寸的屏幕，分辨率为960x640，那么密度为 开方(960x640/3.5) 约等于418。再比如一个4寸的屏幕，分辨率为480x800,那么密度为 开方(480x800/4) 约等于309。
面对种类旁杂的屏幕，开发人员该怎么办，人工针对不同屏幕做相应调整，No！
让机器调整！开发人员是天生懒惰的！
那么要调整什么，目的该是让界面元素的物理大小在所有设备上保持一致（但是屏大的似乎天然可以显示的大一点，小屏的可以小一点。）
过去，开发人员通常以像素为单位设计计算机用户界面。例如，定义一个宽度为300像素的表单字段，列之间的间距为5个像素，图标大小为16×16像素等。这样处理的问题在于，如果在一个每英寸点数（dpi）更高的新显示器上运行该程序，则用户界面会显得很小。在有些情况下，用户界面可能会小到难以看清内容。
针对屏幕的三个参数，分析如下：
同样物理尺寸,分辨率不同,那么如果按照像素设计,就会产生,分辨率大的那个,图像很小.物理尺寸就会很小.同样分辨率,不同物理尺寸,如果按钮找像素设计,实际看起来的物理比例是一样的.看起来物理尺寸一样,不同分辨率,分辨率大的,屏幕尺寸就要大.看起来物理尺寸一样,不同屏幕尺寸,大尺寸的,就要像素多.
那么Android框架为自动调整尺寸做了什么呢？
就是密度无关像素，原文如下
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen.
是说，以160dpi为标准，在一个160dpi的屏幕上的1个物理像素作为设备无关像素的1个像素，也就是Android最佳实践中推荐的dip/dp（以下这两个单位表示同样含义，dip常见于Google官方示例中）这个单位。
针对于字体，Android设计了sp这个单位，这个于dp的不同在于，字体大小在dp的基础上，可以根据用户的偏好设置，相应调整字体大小，所以是scale的。
Android的做法不是根据160dpi这个标准值和设备实际的dpi的比值进行缩放！而是设定了一套标准化尺寸和密度：
标准化物理尺寸: small, normal, large, and xlarge标准化屏幕密度: ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high)
Each generalized size or density spans a range of actual screen sizes or density. For example, two devices that both report a screen size of normal might have actual screen sizes and aspect ratios that are slightly different when measured by hand. Similarly,
two devices that report a screen density of hdpi might have real pixel densities that are slightly different. Android makes these differences abstract to applications, so you can provide UI designed for the generalized sizes and densities and let the system
handle any final adjustments as necessary. Figure 1 illustrates how different sizes and densities are roughly categorized into the different size and density groups.（摘自官方文档）
（我曾经以为，Android会根据实际dpi进行缩放，这也是我迷惑很久，之前写就在这个卡住了）
为了证明Android确实不是不是根据实际dpi进行缩放，我查阅了相关的源代码。
我们知道当显卡绘制一个图像的时候，是根据物理像素绘制的。所以，当开发人员设定dp这种单位的时候，需要一个转化过程，将sp转化为px。
如果按我之前所想，计算公式该是：实际dpi / mdpi（也就是160dpi）然后乘上sp的数值，这样就得到了在不同设备上物理大小完全一样的的界面元素。
但是Android不是这样设计的，正如前文所说，是根据那套标准化的密度来进行转换的。通过如下代码(这个是Android将dp转化为px值的过程)。
public static float applyDimension(int unit, float value, DisplayMetrics metrics) { switch (unit) { case COMPLEX_UNIT_PX: case COMPLEX_UNIT_DIP:
return value * metrics. case COMPLEX_UNIT_SP: return value * metrics.scaledD case COMPLEX_UNIT_PT: return value * metrics.xdpi * (1.0f/72); case COMPLEX_UNIT_IN: return value * metrics. case COMPLEX_UNIT_MM: return value * metrics.xdpi
* (1.0f/25.4f); } return 0; }
可以看到，如果单位是dip(dp)，那么返回值则是dip的value * metrics.density。
这里的density是
The logical density of the display. This is a scaling factor for the Density Independent Pixel unit, where one DIP is one pixel on an approximately 160 dpi screen (for example a 240x320, 1.5&x2& screen), providing the baseline of the system's display. Thus
on a 160dpi screen this density value will be 1; on a 120 dpi screen it would be .75; etc.
This value does not exactly follow the real screen size (as given by xdpi and ydpi, but rather is used to scale the size of the overall UI in steps based on gross changes in the display dpi. For example, a 240x320 screen will have a density of 1 even if its
width is 1.8&, 1.3&, etc. However, if the screen resolution is increased to 320x480 but the screen size remained 1.5&x2& then the density would be increased (probably to 1.5).
（摘自Google官方文档，懒得翻译了，当然也是怕翻译坏了原来的味道，这段还是相当重要的）
重点是This value does not exactly follow the real screen size。这也解释我之前的疑惑。
这个density值Displaymetrics记录的，如果你想看看实际情况，可以获取Displaymetrics，通过代码：
DisplayMetrics metrics = new DisplayMetrics(); getWindowManager().getDefaultDisplay().getMetrics(metrics);
然后就能得到metrics的值。
这类还有xdpi和ydpi这两个值，官方文档上说：The exact physical pixels per inch of the screen in the X(Y) dimension.
然而，当我试图获取某些机器的这两个值的时候却与我手动计算所得到的值完全不同！
后来翻阅StackOverflow，看到也有人遇到类似问题，
作者获得了几个设备的dip值，如下：
HTC Desire Z: 480x800, density : HIGH, xdpi: 254.0, ydpi: 254.0Motorola Defy: 480x854, density : HIGH, xdpi: 96.0, ydpi: 96.0Samsung Galaxy S2: 480x800, density : HIGH, xdpi: 217.71428, ydpi: 218.49463LG Optimus 2X: 480x800, density : HIGH, xdpi: 160.0, ydpi: 160.0
（原文地址：&/questions/6224900/android-incorrect-size-for-views-with-mm-or-inch-dimensions）
可以看到对于Moto和LG的dpi是明显错误的。
再回想刚才Android转换单位的函数里面这段代码：
case COMPLEX_UNIT_PT: return value * metrics.xdpi * (1.0f/72); case COMPLEX_UNIT_IN: return value * metrics. case COMPLEX_UNIT_MM: return value
* metrics.xdpi * (1.0f/25.4f);
对于这几个单位的处理都用到了xdpi，所以很可能转换后是错误的值，
（这里应该仍然算是个疑问，难道真的没有办法得到正确的值吗？我们都知道是不推荐用pt,in,mm这种单位的，这是否也是一个方面）
至此关于屏幕的问题大体说完，然后就是提供的资源问题，当我们设置了一个界面元素的的大小后，对于不是标准dpi的机器上就要进行缩放，那么对于绘制的矢量元素，自然是不用管，而对于图像这种位图，缩放后会导致模糊等问题，所以就要对标准化dpi的几个大小，提供相应的替换版本，Android会根据实际屏幕规格，进行相应替换，并且有相应的查找资源的规则，看Android源码，可以知道，Android的框架的默认ui使用了大量nine-patch图片。这里就不详细说了。
好吧，这次就到这里了。
=======================================================================================
（一）、尺寸
现有的Android手机主要屏幕尺寸有：2.8、3.1、3.2、3.7、4、4.2、4.3、5.0(单位/英寸)
屏幕为2.8英寸的机型主要由HTC Tattoo(也就是我们常说的G4)、摩托罗拉FLIPOUT(行货名称为MB511)等机型，这个尺寸的Android手机通常为入门级机型，价格通常在1000元上下。
&屏幕尺寸3.1-3.5英寸的机型主要为中端机型，代表机型有HTC Hero(G3)，摩托罗拉ME600(后空翻)、三星i7500等，价格在2000元上下。
&新上市的屏幕尺寸3.7英寸以上机型通常为Android高端手机，代表机型有HTC Desire S、HTC Sensation、摩托罗拉Droid X(天翼定制型号为ME811)、摩托罗拉Atrix 4G(行货型号为ME860)、三星Nexus S、三星Galaxy S2等，价格通常在3000元以上。
&&&&屏幕尺寸越大，可视范围就越大，由于所有Android手机均为可触摸操作屏幕，所以操作区域也更大。在用手机玩游戏，观看视频方面，大尺寸手机优势明显。
&&&另外，手机尺寸越大，携带起来也越不方面。我使用过的最大的Android手机是Dell Mini 5(7英寸Galaxy Tab不在手机之列)，这部手机屏幕尺寸超过5英寸，几乎无法塞进裤子的口袋。
（二）、分辨率
Android手机分辨率主要有240X320、320X480、480X800、480X854几种。
分辨率一词在港台地区称之为解析度(个人认为解析度一词表达的更为精确)，也就是屏幕图像的精密度。分辨率越大的显示屏越清晰。
&&&&分辨率为240X320、320X480的机型通常为Android中低端机型，价格通常在元。
&&&&分辨率480X800、480X854的机型通常为中高端机型，价格从不等。
目前大部分软件开发大多以兼容分辨率480X800和480X854的手机为标准，所有有一些软件早一些分辨率的手机会被告知无法运行。
2. &&&&&手机尺寸分布情况（/resources/dashboard/screens.html）
目前主要是以分辨率为800*480和854*480的手机用户居多
Data collected during a 7-day period ending on August 1, 2011
ldpi mdpi hdpi xhdpi
small 3.4%
normal 0.9% 16.9% 74.5%
large 3.1%
xlarge 1.2%
2、术语解释
术语 说明 备注
Screen size（屏幕尺寸) 指的是手机实际的物理尺寸，比如常用的2.8英寸，3.2英寸，3.5英寸，3.7英寸摩托罗拉milestone手机是3.7英寸
Aspect Ratio(宽高比率) 指的是实际的物理尺寸宽高比率,分为long和nolong Milestone是16：9,属于long
Resolution(分辨率) 和电脑的分辨率概念一样，指手机屏幕纵、横方向像素个数 Milestone是854*480
DPI(dot per inch) 每英寸像素数，如120dpi,160dpi等,假设QVGA(320*240)分辨率的屏幕物理尺寸是（2英寸*1.5英寸），dpi=160 可以反映屏幕的清晰度，用于缩放UI的
Density(密度) 屏幕里像素值浓度，resolution/Screen size可以反映出手机密度 &
Density-independent pixel (dip) 指的是逻辑密度计算单位,dip和具体像素值的对应公式是dip/pixel=dpi &表示每英寸有多少个显示点
3、手机屏幕分类和像素密度的对应关系
VGA &：Video Graphics Array，即：显示绘图矩阵，相当于640×480 像素；
HVGA ：Half-size VGA；即：VGA的一半，分辨率为480×320； density=160
QVGA ：Quarter VGA；即：VGA的四分之一，分辨率为320×240； density=120
WVGA：Wide Video Graphics Array；即：扩大的VGA，分辨率为800×480像素；density=240
WQVGA：Wide Quarter VGA；即：扩大的QVGA，分辨率比QVGA高，比VGA低，一般是：400×240，480×272；density=120
apk的资源包中，当屏幕density=240时使用hdpi标签的资源
当屏density=160时使用mdpi标签的资源
当屏幕density=120时使用ldpi标签的资源。
不加任何标签的资源是各种分辨率情况共用的
屏幕(Type) 宽度(Pixels) 高度(Pixels) 尺寸Range (inches) 大小Size 密度Group
QVGA 240 320 2.6 - 3.0 Small screen Low density (120) &ldpi
WQVGA 240 400 3.2 - 3.5 Normal screen Low density (120) &ldpi
FWQVGA 240 432 3.5 - 3.8 Normal screen Low density (120) &ldpi
HVGA 320 480 3.0 - 3.5 Normal screen Mediumdensity(160)mdpi
WVGA 480 800 3.3 - 4.0 Normal screen High density (240), hdpi
FWVGA 480 854 3.5 - 4.0 Normalscreen High density (240), hdpi
WVGA 480 800 4.8 - 5.5 Large screen Medium density(160) mdpi
FWVGA 480 854 5.0 - 5.8 Large screen Medium density(160) mdpi
开发角度讲，应用程序会根据 3 类 A ndroid 手机屏幕提供3 套UI 布局文件，但是相应界面图标也需要提供3 套
con Type Standard Asset Sizes (in Pixels), for Generalized Screen Densities
&&Lowdensityscreen(ldpi) Mediumdensityscreen(mdpi) Highdensityscreen(hdpi)
Launcher 36 x 36 px 48 x 48 px 72 x 72 px
Menu 36 x 36 px 48 x 48 px 72 x 72 px
StatusBar 24 x 24 px 32 x 32 px 48 x 48 px
Tab 24 x 24 px 32 x 32 px 48 x 48 px
Dialog 24 x 24 px 32 x 32 px 48 x 48 px
List View 24 x 24 px 32 x 32 px 48 x 48 px
========================================================================================
各种Android操作系统的手机简直就是琳琅满目，屏幕分辨率的差异可想而知。目前比较主流的有WVGA=800x480，HVGA=480x320，另外的还有QVGA=320x240。当然还有魅族M9的DVGA=960x640，还有蛋疼的摩托罗拉的FWVGA=854x480。
其实，在你layout的xml文件中，编写的时候是不是用了许多的padding呢？如果是，那你就蛋疼了。因为这样的布局永远是无法适应所有手机屏幕的。
正确的做法应该是使用的是weight属性。将你控件的layout中的width、height设置为fill-parent，不要使用wrap——content。因为wrap-content的大小是不固定的。而weight（权重）这个属性很好的解决了这个问题。
当包裹在控件外面的Layout的width、height属性都设置为fill-parent时，可以利用weight的反比特性。即如果控件A设置weight为5，控件B设置weight为7，那么A所占的空间为5/（5+7），B所占的空间为7/（5+7）。这样的反比属性对任何分辨率下的手机都是合适的。
当然，字体就不行了。那怎么保证字体能够跟布局一样能够自适应呢？
呵呵，很简单，就是在你的res文件夹中创建一个文件夹，叫做values-320x240。其中320x240是你手机屏幕的分辨率，根据你手机屏幕的情况做不同的命名，例如values- 800x480。在该文件夹下创建一个dimens.xml文件，定义各种字体的大小。那么系统就会自动根据你手机屏幕的分辨率去调用响应的文件夹。
&&& 另外，值得提醒的是，记得在你默认的values文件下的dimens.xml文件中也要写上相应的字体大小哦，因为当系统无法认识你手机屏幕大小的时候，它会自动去找你默认文件中的
东西，没有写的话程序会崩溃。
************************************************************分割线************************************************************
在看下面内容之前首先请看你SDK文档中以下这篇文章
其实google在分辨率适应性的东西已经写的很清楚了，只是我们很多人没去看而已
以下是结论：
屏幕分辨率：
density：1（160）
文件夹：values-mdpi-
屏幕分辨率：
density：1.5（240）
文件夹：values-hdpi-683x400&&由&&600/1.5得到，需要四舍五入。
屏幕分辨率：800x480
density：1（160）
文件夹：values-mdpi-800x480
屏幕分辨率：800x480
density：1.5（240）
文件夹：values-hdpi-533x320&&由800/1.5&&480/1.5得到，需要四舍五入。
以此类推
一般情况下需要创建出values 、values-mdpi 、 values-hdpi文件夹，以备在一些没有规定的尺寸屏幕上找不到资源的情况。
然后在里面使用不同的dimens文件，Layout中不要使用显示的数字，所有的尺寸定义全都援引dimens里面的内容。
这样能够保证深度UI定制的情况
另外在工程的default.properties中如果split.density=false，则分辨率适配的时候文件夹命名不需要与scale相除
屏幕分辨率：800x480
density：1.5（240）
文件夹：values-hdpi-800x480
************************************************************分割线************************************************************
关于dimens&
位置：res\values
单位：px&&&Pixel 以画面的像素为单位；
&&&&&&& &in&&&&&Inches以画面的多少英寸为单位；
&&&&&&&& mm&&Millimeter以画面的多少毫米为单位；
&&&&&&&& pt&&&&&Points 一点为1/72英寸；
&&&&&&&& dp或dip&&Density-indepentdent 为160dpi屏幕的一个
&&&&&&&& ap Scale-independent Pixels 随屏幕尺寸改变的一个
1.drawable: 存放不同分辨率对应图片
&&&&&&在2.1版本中有drawable-mdpi、drawable-ldpi、drawable-hdpi三个，这三个主要是为了支持多分辨率。
drawable- hdpi、drawable- mdpi、drawable-ldpi的区别：
(1)drawable-hdpi里面存放高分辨率的图片,如WVGA (480x800),FWVGA (480x854)
(2)drawable-mdpi里面存放中等分辨率的图片,如HVGA (320x480)
(3)drawable-ldpi里面存放低分辨率的图片,如QVGA (240x320)
系统会根据机器的分辨率来分别到这几个文件夹里面去找对应的图片。
&&&&&&在2.1之前的版本可以通过drawable-800x480, drawable-480x320 等方式实现。
2:layout:放置对应不同分辨率的布局
&&&&&&创建不同的layout文件夹， layout-800x480,layout-480x320, 系统会根据屏幕的大小自己选择合适的layout进行使用。
&&&&&&另外：可以在res目录下建立layout-port和layout-land两个目录，里面分别放置竖屏和横屏两种布局文件。
下面列出主流的android机型有：
240x320低端，国产入门级采用，例如HTC G4，G8
320x480中端，大部分基于此分辨率，例如HTC G1,G2,G3,G6, MOTO ME600, SAMSUNG I7500
480x800中高端，大部分基于此分辨率，例如HTC G5,G7, MOTO MT810
480x854MOTO特有的，例如Droid, Milestone, XT800
960x640, 魅族M9
更为详细的见下图：
参考了以下资料：
&========================================================================
1、屏幕相关概念
是指屏幕上有横竖各有多少个像素
1.2屏幕尺寸
指的是手机实际的物理尺寸，比如常用的2.8英寸，3.2英寸，3.5英寸，3.7英寸
android将屏幕大小分为四个级别（small，normal，large，and extra large）。
1.3屏幕密度
每英寸像素数
手机可以有相同的分辨率，但屏幕尺寸可以不相同，
Diagonal pixel表示对角线的像素值（=），DPI=933/3.7=252
android将实际的屏幕密度分为四个通用尺寸（low，medium，high，and extra high）
一般情况下的普通屏幕：ldpi是120dpi，mdpi是160dpi，hdpi是240dpi，xhdpi是320dpi
对于屏幕来说，dpi越大，屏幕的精细度越高，屏幕看起来就越清楚
1.4密度无关的像素（Density-independent pixel——dip）
dip是一种虚拟的像素单位
dip和具体像素值的对应公式是dip/pixel=dpi,也就是px = dp * (dpi / 160)
当你定义应用的布局的UI时应该使用dp单位，确保UI在不同的屏幕上正确显示。
手机屏幕分类和像素密度的对应关系如表1所示
手机尺寸分布情况（/resources/dashboard/screens.html）如图所示，
目前主要是以分辨率为800*480和854*480的手机用户居多
从以上的屏幕尺寸分布情况上看，其实手机只要考虑3-4.5寸之间密度为1和1.5的手机
2、android多屏幕支持机制
Android的支持多屏幕机制即用为当前设备屏幕提供一种合适的方式来共同管理并解析应用资源。
Android平台中支持一系列你所提供的指定大小（size-specific）,指定密度（density-specific）的合适资源。
指定大小（size-specific）的合适资源是指small, normal, large, and xlarge。
指定密度（density-specific）的合适资源，是指ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high).
Android有个自动匹配机制去选择对应的布局和图片资源
1）界面布局方面
根据物理尺寸的大小准备5套布局:
layout(放一些通用布局xml文件，比如界面顶部和底部的布局，不会随着屏幕大小变化，类似windos窗口的title bar),
layout-small(屏幕尺寸小于3英寸左右的布局），
layout-normal(屏幕尺寸小于4.5英寸左右），
layout-large(4英寸-7英寸之间），
layout-xlarge(7-10英寸之间）
2）图片资源方面
需要根据dpi值准备5套图片资源:
drawable：主要放置xml配置文件或者对分辨率要求较低的图片
drawalbe-ldpi:低分辨率的图片,如QVGA (240x320)
drawable-mdpi:中等分辨率的图片,如HVGA (320x480)
drawable-hdpi:高分辨率的图片,如WVGA (480x800),FWVGA (480x854)
drawable-xhdpi：至少960dp x 720dp
Android有个自动匹配机制去选择对应的布局和图片资源。
系统会根据机器的分辨率来分别到这几个文件夹里面去找对应的图片。
在开发程序时为了兼容不同平台不同屏幕，建议各自文件夹根据需求均存放不同版本图片。
3、AndroidManifest.xml 配置
android从1.6和更高，Google为了方便开发者对于各种分辨率机型的移植而增加了自动适配的功能
&supports-screens
android:largeScreens=&true&
android:normalScreens=&true&
android:smallScreens=&true&
android:anyDensity=&true&/&
3.1是否支持多种不同密度的屏幕
android:anyDensity=[&true& | &false&]
如果android:anyDensity=&true&
指应用程序支持不同密度，会根据屏幕的分辨率自动去匹配。
如果android:anyDensity=&false&
应用程序支持不同密度，系统自动缩放图片尺寸和这个图片的坐标。具体解释一下系统是如何自动缩放资源的。
例如我们在hdpi,mdpi,ldpi文件夹下拥有同一种资源，那么应用也不会自动地去相应文件夹下寻找资源，这种情况都是出现在高密度，以及低密度的手机上，比如说一部240×320像素的手机，
如果设置android:anyDensity=&false&，Android系统会将240 x 320(低密度)转换为 320×480(中密度)，这样的话，应用就会在小密度手机上加载mdpi文件中的资源。
3.2是否支持大屏幕
android:largeScreens=[&true& | &false&]
如果在声明不支持的大屏幕，而这个屏幕尺寸是larger的话，系统使用尺寸为(&normal&)和密度为(&medium)显示，
不过会出现一层黑色的背景。
3.3是否支持小屏幕
android:smallScreens=[&true& | &false&]
如果在声明不支持的小屏幕，而当前屏幕尺寸是smaller的话，系统也使用尺寸为(&normal&)和密度为(&medium)显示
如果应用程序能在小屏幕上正确缩放(最低是small尺寸或最小宽度320dp)，那就不需要用到本属性。否则，就应该为最小屏幕宽度标识符设置本属性
来匹配应用程序所需的最小尺寸。
4、Android提供3种方式处理屏幕自适应
4.1预缩放的资源(基于尺寸和密度去寻找图片)
1）如果找到相应的尺寸和密度，则利用这些图片进行无缩放显示。
2）如果没法找到相应的尺寸，而找到密度，则认为该图片尺寸为 &medium&，利用缩放显示这个图片。
3）如果都无法匹配，则使用默认图片进行缩放显示。默认图片默认标配 &medium& (160)。
4.2自动缩放的像素尺寸和坐标(密度兼容)
1）如果应用程序不支持不同密度android:anyDensity=&false&,系统自动缩放图片尺寸和这个图片的坐标。
2）对于预缩放的资源，当android:anyDensity=&false&，也不生效。
3）android:anyDensity=&false&，只对密度兼容起作用，尺寸兼容没效果
4.3兼容更大的屏幕和尺寸(尺寸兼容)
1）对于你在声明不支持的大屏幕，而这个屏幕尺寸是normal的话，系统使用尺寸为 (&normal&)和密度为(&medium)显示。
2.）对于你在声明不支持的大屏幕，而这个屏幕尺寸是larger的话，系统同样使用尺寸为(&normal&)和密度为(&medium)显示，
不过会出现一层黑色的背景。
5、Android系统自动适配技巧
Android系统采用下面两种方法来实现应用的自动适配：
1）布局文件中定义长度的时候，最好使用wrap_content,fill_parent, 或者dp 进行描述，这样可以保证在屏幕上面展示的时候有合适的大小
2）为不同屏幕密度的手机，提供不同的位图资源，可以使得界面清晰无缩放。
对应bitmap 资源来说，自动的缩放有时会造成放大缩小后的图像变得模糊不清，这是就需要应用为不同屏幕密度配置提供不同的资源：为高密度的屏幕提供高清晰度的图像等。
3）不要使用AbsoluteLayout
4）像素单位都使用DIP，文本单位使用SP
6、在代码中获取屏幕像素、屏幕密度
DisplayMetrics metric = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(metric);
int width = metric.widthP // 屏幕宽度（像素）
int height = metric.heightP // 屏幕高度（像素）
float density = metric. // 屏幕密度（0.75 / 1.0 / 1.5）
int densityDpi = metric.densityD // 屏幕密度DPI（120 / 160 / 240）
7、 一般多分辨率处理方法及其缺点
7.1 图片缩放
基于当前屏幕的精度，平台自动加载任何未经缩放的限定尺寸和精度的图片。如果图片不匹配，平台会加载默认资源并且在放大或者缩小之后可以满足当前界面的显示要求。例如，当前为高精度屏幕，平台会加载高精度资源（如HelloAndroid中drawable-hdpi 中的位图资源），如果没有，平台会将中精度资源缩放至高精度，导致图片显示不清晰。
7.2 自动定义像素尺寸和位置
如果程序不支持多种精度屏幕，平台会自动定义像素绝对位置和尺寸值等，这样就能保证元素能和精度160 的屏幕上一样能显示出同样尺寸的效果。例如，要让WVGA 高精度屏幕和传统的HVGA 屏幕一样显示同样尺寸的图片，当程序不支持时，系统会对程序慌称屏幕分辨率为320×480,在（10,10）到（100,100）的区域内绘制图形完成之后，系统会将图形放大到（15,15）到（150,150）的屏幕显示区域。
7.3 兼容更大尺寸的屏幕
当前屏幕超过程序所支持屏幕的上限时，定义supportsscreens元素，这样超出显示的基准线时，平台在此显示黑色的背景图。例如，WVGA 中精度屏幕上，如程序不支持这样的大屏幕，系统会谎称是一个320×480 的，多余的显示区域会被填充成黑色。
7.4 采用OpenGL 动态绘制图片
Android 底层提供了OpenGL 的接口和方法，可以动态绘制图片，但是这种方式对不熟悉计算机图形学的开发者来讲是一个很大的挑战。一般开发游戏，采用OpenGL 方式。
7.5 多个apk 文件
Symbian 和传统的J2ME 就是采用这种方式，为一款应用提供多个分辨率版本，用户根据自己的需求下载安装相应的可执行文件。针对每一种屏幕单独开发应用程序不失为一种好方法，但是目前Google Market 对一个应用程序多个分辨率版本的支持还不完善，开发者还是需要尽可能使用一个apk 文件适应多个分辨率。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：533536次
积分：5480
积分：5480
排名：第3335名
原创：51篇
转载：184篇
评论：62条
(2)(1)(2)(1)(2)(3)(1)(3)(1)(1)(6)(10)(4)(7)(32)(72)(5)(1)(6)(2)(9)(50)(14)
