探讨安卓系统开发中的适配方案

安卓系统开发中的适配方案一直是开发者们关注的热点话题之一。在不同的设备尺寸、分辨率、屏幕密度等因素下，如何确保应用程序在各种设备上都能够正常显示并提供良好的用户体验，是开发过程中不可忽视的重要环节。本文将围绕安卓系统开发中的适配方案展开详细分析。

安卓系统的适配方案可以从布局适配、资源适配和代码适配三个方面来进行讨论。

布局适配是指在不同屏幕尺寸上保持界面布局的稳定性和美观性。在安卓开发中，通常使用像素密度无关像素（dp）来进行布局设计，同时结合线性布局、相对布局等布局管理器来实现界面的动态适配。还可以使用ConstraintLayout等新型布局管理器来更灵活地适配不同尺寸的屏幕。

资源适配是指根据设备的不同特征加载不同的资源文件。在values文件夹下可以创建不同的dimens.xml、colors.xml等资源文件，根据不同的尺寸、密度等条件来加载对应的资源文件。还可以通过drawable-hdpi、drawable-xhdpi等文件夹来加载不同分辨率的图片资源，确保图片显示的清晰度和流畅度。

代码适配是指通过编写灵活的代码逻辑来适配不同设备的特性。例如，可以通过获取屏幕分辨率、像素密度等参数来动态计算控件的大小和位置，从而实现不同设备上的统一显示效果。同时，还可以针对不同设备特性编写条件判断语句，实现特定适配逻辑。

除了上述的适配方案，还有一些常用的第三方库和工具可以帮助开发者更高效地进行安卓系统适配：

1.

ScreenAdaptation

：一个专门用于屏幕适配的开源库，提供了多种屏幕适配方案和工具，可以快速实现屏幕适配。

2.

AutoLayout

：另一个优秀的屏幕适配库，支持各种单位之间的转换，能够在不同屏幕上实现完美适配效果。

3.

DimenTool

：一个用于生成dimens.xml文件的工具，可以根据设备不同特征生成对应的dimens值，方便资源适配时的调用。

对于不同的应用场景和需求，开发者可以根据具体情况选择适合自己项目的适配方案和工具，以达到最佳的适配效果。

安卓系统开发中的适配方案是一个复杂而又关键的环节，需要开发者充分理解不同设备的特性和适配原理，结合合适的适配方案和工具来进行开发。只有通过精心的设计和不断的优化，才能确保应用程序在各种设备上都能够提供出色的用户体验。

开发安卓APP如何考虑机型适配问题？

开发安卓app考虑机型适配，主要从以下三个方面考虑适配：

Android屏幕适配-应用篇

Android屏幕适配-基础篇 Android屏幕适配-应用篇

从两个大方面阐述一下Android的屏幕适配：

Android推荐使用dp作为尺寸单位来适配UI ，通过dp加上自适应布局和weight比例布局可以基本解决不同手机上适配的问题，这基本是最原始的Android适配方案。 缺点 ： （1）这种方案只能保证我们写出来的界面适配绝大部分手机，部分手机仍然需要单独适配，但dpi的不同，还是会存在差异。 （2）一般的设计稿都是以px为单位的，所以我们在写layout文件的时候需要将px转为dp，影响开发效率。

为了高效的实现UI开发，出现了新的适配方案，我把它称作宽高限定符适配。简单说，就是穷举市面上所有的Android手机的宽高像素值，设定一个基准的分辨率，其他分辨率都根据这个基准分辨率来计算，在不同的尺寸文件夹内部，根据该尺寸编写对应的dimens文件:

鸿洋大神的作品 ，使用也超级简单，核心功能就是在绘制的时候在onMeasure里面做变换，重新计算px。 缺点 ：我们自定义的控件可能会被影响或限制，可能有些特定的控件（框架没有做适配的控件），需要单独适配。

小结：上述几种适配方案都是实际开发中用过的方案，但随着技术不断的更新，出现了更好的适配方案。

实现原理 ：Android会识别屏幕可用高度和宽度的最小尺寸的dp值（ 其实就是手机的宽度值 ），然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。  sw限定符适配和 宽高限定符适配 类似，区别在于，前者有很好的容错机制，如果没有value-sw360dp文件夹，系统会向下寻找，比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件。这个特性就完美的解决了上文提到的宽高限定符的容错问题。  优点: 1.非常稳定，极低概率出现意外 2.不会有任何性能的损耗 3.适配范围可自由控制，不会影响其他三方库  缺点 ：就是多个dimens文件可能导致apk变大，几百k。

附件：生成sw文件的工具

实现原理 ： 修改系统的density值 （核心） 今日头条适配是以设计图的宽或高进行适配的，适配最终是改变系统density实现的。  过程：

AndroidAutoSize 是基于今日头条适配方案，该开源库已经很大程度上解决了今日头条适配方案的两个缺点，可以对activity，fragment进行取消适配。也是目前我的项目中所使用的适配方案。 使用也非常简单只需两步： （1）引入：

（2）在 AndroidManifest 中填写全局设计图尺寸 (单位 dp)，如果使用副单位，则可以直接填写像素尺寸，不需要再将像素转化为 dp，详情请查看demo-subunits

Android 10（29）适配方案简要说明

Android 10（29）适配方案简要说明 1、根据Google官方文档说明，Android10引入了大量变更 官方文档：1.1、Android 10 中的隐私权变更 1.1.1重大隐私权变更 分区存储 针对外部存储的过滤视图，可提供对特定于应用的文件和媒体集合的访问权限 访问和共享外部存储中的文件的应用 使用特定于应用的目录和媒体集合目录增强了用户对位置权限的控制力 仅限前台权限，可让用户更好地控制应用对设备位置信息的访问权限 在后台时请求访问用户位置信息的应用 确保在没有后台位置信息更新的情况下优雅降级 使用 Android 10 中引入的权限在后台获取位置信息系统执行后台 Activity 针对从后台启动 Activity 实施了限制 不需要用户互动就启动 Activity 的应用 使用通知触发的 Activity不可重置的硬件标识符 针对访问设备序列号和 IMEI 实施了限制 访问设备序列号或 IMEI 的应用 使用用户可以重置的标识符无线扫描权限 访问某些 WLAN、WLAN 感知和蓝牙扫描方法需要获得精确位置权限 使用 WLAN API 和蓝牙 API 的应用 针对相关使用场景请求ACCESS_FINE_LOCATION权限1.1.2更多隐私权变更 标识符和数据： 针对硬件标识符（如 IMEI、序列号、MAC 和类似数据）实施了新限制。

移除了联系人亲密程度信息 随机分配 MAC 地址 对 /proc/net 文件系统的访问权限实施了限制 对不可重置的设备标识符实施了限制 限制了对剪贴板数据的访问权限 保护 USB 设备序列号摄像头和连接性：针对摄像头元数据和连接 API 提供了更强大的保护措施。

对访问摄像头详情和元数据的权限实施了限制 对启用和停用 WLAN 实施了限制 对直接访问已配置的 WLAN 网络实施了限制 一些电话 API、蓝牙 API 和 WLAN API 需要精确位置权限权限 ： 针对权限模型和要求的一些变更。

限制对屏幕内容的访问 面向用户的权限检查（针对旧版应用） 身体活动识别 从界面中移除了权限组1.2影响应用的行为变更 文档：限制非 SDK 接口：为了帮助确保应用的稳定性和兼容性，Android 平台开始限制应用在 Android 9（API 级别 28）中使用非 SDK 接口。

Android 10 包含更新后的受限制非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。

我们的目标是在限制使用非 SDK 接口之前确保有可用的公开替代方案。

手势导航：从 Android 10 开始，用户可以在设备中启用手势导航。

用户启用后，手势导航会影响设备上的所有应用，无论应用是否以 API 级别 29 为目标平台。

例如，如果用户从屏幕边缘向内滑动，系统会将该手势解读为“返回”导航，除非应用针对屏幕的相应部分明确替换该手势。

NDK 方面的变更 共享对象不得包含文本重定位 Bionic 库和动态链接器路径变更 系统二进制文件/库会映射到只执行内存安全方面的变更 TLS 1.3 默认处于启用状态 TLS 不信任使用 SHA-1 签名的证书 KeyChain 行为变更和改进 其他 TLS 和加密更改WLAN 直连广播 在 Android 10 中，以下与 WLAN 直连相关的广播不具有粘性： WIFI_P2P_CONNECTION_CHANGED_ACTION WIFI_P2P_THIS_DEVICE_CHANGED_ACTION 如果的应用依赖于在注册时接收这些广播（因为其之前一直具有粘性），请在初始化时使用适当的 get() 方法获取信息。

WLAN 感知功能 Android 10 扩大了支持范围，现在可以使用 WLAN 感知数据路径轻松创建 TCP/UDP 套接字。

要创建连接到 ServerSocket 的 TCP/UDP 套接字，客户端设备需要知道服务器的 IPv6 地址和端口。

这在之前需要通过频外方式进行通信（例如使用 BT 或 WLAN 感知第 2 层消息传递），或者使用其他协议（例如 mDNS）通过频内方式发现。

而借助 Android 10，可以将此类消息作为网络设置的一部分进行传递。

Go 设备上的 SYSTEM_ALERT_WINDOW 在 Android 10（Go 版本）设备上运行的应用无法获得 SYSTEM_ALERT_WINDOW 权限。

这是因为绘制叠加层窗口会使用过多的内存，这对低内存 Android 设备的性能十分有害。

如果在搭载 Android 9 或更低版本的 Go 版设备上运行的应用获得了 SYSTEM_ALERT_WINDOW 权限，则即使设备升级到 Android 10，也会保留此权限。

不过，尚不具有此权限的应用在设备升级后便无法获得此权限了。

如果 Go 设备上的应用发送具有 ACTION_MANAGE_OVERLAY_PERMISSION 操作的 intent，则系统会自动拒绝此请求，并将用户转到设置屏幕，上面会显示不允许授予此权限，原因是它会减慢设备的运行速度。

如果 Go 设备上的应用调用 ()，则此方法始终返回 false。

同样，这些限制不适用于在设备升级到 Android 10 之前便已收到 SYSTEM_ALERT_WINDOW 权限的应用。

关于以旧版 Android 系统为目标平台的应用的警告 在搭载 Android 10 或更高版本的设备上，如果用户首次运行以 Android 5.1（API 级别 22）或更低版本为目标平台的应用，则会看到警告。

如果此应用要求用户授予权限，则系统会先向用户提供调整应用权限的机会，然后才会允许此应用首次运行。

由于 Google Play 的目标 API 方面的要求，用户只有在运行最近未更新的应用时才会看到这些警告。

对于通过其他商店分发的应用，我们也将于 2019 年引入类似的目标 API 方面的要求。

如需详细了解这些要求，请参阅在 2019 年扩展目标 API 级别方面的要求。

移除了 SHA-2 CBC 加密套件 以下 SHA-2 CBC 加密套件已从平台中移除： TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 这些加密套件不如使用 GCM 的类似加密套件安全，并且大多数服务器要么同时支持这些加密套件的 GCM 变体和 CBC 变体，要么二者均不支持。

应用使用情况的变更 UsageStats 应用使用情况方面的改进 – 当在分屏或画中画模式下使用应用时，Android 10 现在能够使用 UsageStats 准确地跟踪应用使用情况。

此外，Android 10 可以正确地跟踪免安装应用的使用情况。

按应用开启灰度模式 – Android 10 可针对各个应用设置灰度显示模式。

按应用开启干扰模式 – Android 10 可以选择性地将应用设置为“干扰模式”，此时系统会禁止显示其通知，并且不会将其显示为推荐的应用。

暂停和播放 – 在 Android 10 中，暂停的应用无法播放音频。

HTTPS 连接变更 如果在 Android 10 上运行的应用将 null 传递给 setSSLSocketFactory()，则会出现 IllegalArgumentException。

在以前的版本中，将 null 传递给 setSSLSocketFactory() 与传入当前的默认 SSL 套接字工厂效果相同。

库已弃用 从 Android 10 开始，将弃用 库。

开发者应该改为使用 AndroidX preference 库，这是 Android Jetpack 的一部分。

如需获取其他有助于迁移和开发的资源，请查看经过更新的设置指南以及我们的公开示例应用和参考文档。

ZIP 文件实用程序库变更 Android 10 对 软件包（用于处理 ZIP 文件）中的类进行了以下变更。

这些变更会让库的行为在 Android 和使用 的其他平台之间更加一致。

Inflater 在以前的版本中，如果在调用 end() 之后调用 Inflater 类中的某些方法，这些方法会抛出 IllegalStateException。

在 Android 10 中，这些方法会改为抛出 NullPointerException。

ZipFile 在 Android 10 及更高版本中，如果所提供的 ZIP 文件不包含任何文件，则 ZipFile 的构造函数（采用的参数类型为 File、int 和 Charset）不会抛出 ZipException。

ZipOutputStream 在 Android 10 及更高版本中，如果 ZipOutputStream 中的 finish() 方法尝试为不包含任何文件的 ZIP 文件写入输出流，则此方法不会抛出 ZipException。

摄像头变更 很多使用摄像头的应用都会假定如果设备采用纵向配置，则物理设备也会处于纵向，正如摄像头方向中所述。

在过去可以做出这样的假定，但随着可用的设备类型（例如可折叠设备）的扩展，这一情况发生了变化。

针对这些设备做出这样的假定可能导致相机取景器的显示产生错误的旋转和/或缩放。

以 API 级别 24 或更高级别为目标平台的应用应该明确设置 android:resizeableActivity，并提供必要的功能来处理多窗口操作。

电池用量跟踪 从 Android 10 开始，只要在发生重大充电事件之后拔下设备电源插头，SystemHealthManager 就会重置其电池用量统计信息。

一般来说，重大充电事件指的是设备电池已充满，或者设备电量从几乎耗尽变为即将充满。

在 Android 10 之前，无论何时拔下设备电源插头，无论电池电量有多微小的变化，电池用量统计信息都会重置。

Android Beam 已弃用 在 Android 10 中，我们正式弃用了 Android Beam，这是一项旧版功能，可通过近距离无线通信 (NFC) 在多个设备之间启动数据共享。

我们还弃用了一些相关的 NFC API。

Android Beam 仍可供需要的设备制造商合作伙伴使用，但它已不再处于积极的开发阶段。

不过，Android 仍将继续支持其他的 NFC 功能和 API，并且从标签和付款中读取数据等使用场景仍将继续按预期执行。

Android机型适配总结

分辨率对应DPI ldpi QVGA (240×320) mdpi HVGA (320×480) hdpi WVGA (480×800),FWVGA (480×854) xhdpi 720P（1280*720） xxhdpi 1080p（1920*1080 ） xxxhdpi 4K（3840×2160） 机型适配方面常规处理方法： 1、开发之前UI给出不同尺寸标准的多套素材，一般情况下给出：hdpi、xhdpi、xxxhdpi 三种尺寸类型的素材。

2、特殊类型图片使用Android Studio内置draw9path工具进行制作，例如聊天界面中内容背景图片。

3、布局编写时尽量使用 Linearlayout 与 RelativeLayout，LinearLayout内部可以使用weight（权重）属性将子控件的尺寸按比例进行设置。

RelativeLayout 内部可以使用layout_align…(相对于xxx)属性将子控件的尺寸相对于父控件或相对于其他子控件进行设置。

4、设置尺寸的时候长度单位 布局使用 dp 字符使用 sp。

其实字体大小的尺寸使用 dp 也可以，但是sp的情况下 用户使用系统设置字体大小的时候可以改变控件中字体的大小，但是使用dp设置的字体就不会产生变化。

5、针对每一个屏幕的尺寸生成一套px与dp的转换方案，详情见博客： Android机型适配方案 。

6、google推出了一个百分比布局库，可以使用百分比的方式进行布局尺寸的设置，详情见博客： Android百分比布局库（percent-support-lib）解析与扩展 7、利用自定义View的方式去解决，其实原理也是，在绘制View的时候，获取屏幕的尺寸然后按照一定的比例去设置控件的尺寸 还有一些琐碎知识点需要了解并记住： 1. px (pixels)像素 ： 一个像素通常被视为图像的最小的完整采样，这个用的比较多,特别是web开发,页面基本都是使用像素作为单位的： 这个是最常用但也最难理解的尺寸单位。

它与“像素密度”密切相关，所以首先我们解释一下什么是像素密度。

假设有一部手机，屏幕的物理尺寸为1.5英寸x2英寸，屏幕分辨率为240×320，则我们可以计算出在这部手机的屏幕上，每英寸包含的像素点的数量为240/1.5=160dpi（横向）或320/2=160dpi（纵向），160dpi就是这部手机的像素密度，像素密度的单位dpi是Dots Per Inch的缩写，即每英寸像素数量。

横向和纵向的这个值都是相同的，原因是大部分手机屏幕使用正方形的像素点。

不同的手机/平板可能具有不同的像素密度，例如同为4寸手机，有480×320分辨率的也有800×480分辨率的，前者的像素密度就比较低。

Android系统定义了四种像素密度：低（120dpi）、中（160dpi）、高（240dpi）和超高（320dpi），它们对应的dp到px的系数分别为0.75、1、1.5和2，这个系数乘以dp长度就是像素数。

例如界面上有一个长度为“80dp”的图片，那么它在240dpi的手机上实际显示为80×1.5=120px，在320dpi的手机上实际显示为80×2=160px。

如果你拿这两部手机放在一起对比，会发现这个图片的物理尺寸“差不多”。

： 与dp完全相同，只是名字不同而已。

在早期的Android版本里多使用dip，后来为了与sp统一就建议使用dp这个名字了。

： 与缩放无关的抽象像素（Scale-independent Pixel）。

sp和dp很类似但唯一的区别是，Android系统允许用户自定义文字尺寸大小（小、正常、大、超大等等），当文字尺寸是“正常”时1sp=1dp=0.英寸，而当文字尺寸是“大”或“超大”时，1sp>1dp=0.英寸。

类似我们在windows里调整字体尺寸以后的效果——窗口大小不变，只有文字大小改变。

还有一些详细的情况需要了解，都在这个博客里： 点击进入

Android-屏幕适配全攻略（绝对详细）（一）

关键字： 屏幕适配 px dp dpi sp large限定符

前言： 这篇文章依然是我在 [慕课网 ][h]学习凯子哥的同名视频Android-屏幕适配全攻略，所记录下来的笔记—凯子哥讲得真的超详细。 [h]:MOOC

从上图可以看出，主流的分辨率是前六种：1280×720、1920×1080、800×480、854×480、960×540、1184×720，不过我们有解决方案。看完这篇文章，想必你就可以解决常见的屏幕适配问题。

接下来正式进入正题。

介绍几个在Android屏幕适配上非常重要的名词：

屏幕尺寸 是指屏幕对角线的长度。单位是英寸，1英寸=2.54厘米 屏幕分辨率 是指在横纵向上的像素点数，单位是px，1px=1像素点，一般是纵向像素横向像素，如1280×720 屏幕像素密度 是指每英寸上的像素点数，单位是dpi，即“dot per inch”的缩写，像素密度和屏幕尺寸和屏幕分辨率有关

dip： Density Independent Pixels（密度无关像素）的缩写。以160dpi 为基准，1dp=1px dp： 同dip dpi： 屏幕像素密度的单位，“dot per inch”的缩写

px： 像素，物理上的绝对单位

sp： Scale-Independent Pixels的缩写，可以根据文字大小首选项自动进行缩放。Google推荐我们使用12sp以上的大小，通常可以使用12sp，14sp，18sp，22sp，最好不要使用奇数和小数。

用于区分不同的像素密度。

在Google官方开发文档中，说明了 **mdpi：hdpi：xhdpi：xxhdpi：xxxhdpi=2：3：4：6：8 ** 的尺寸比例进行缩放。例如，一个图标的大小为48×48dp，表示在mdpi上，实际大小为48×48px，在hdpi像素密度上，实际尺寸为mdpi上的1.5倍，即72×72px，以此类推。

我们可以通过以下几种方式来支持各种屏幕尺寸：

wrap_content： 根据控件的内容设置控件的尺寸 math_parent： 根据父控件的尺寸大小设置控件的尺寸 weight： 权重，在线性布局中可以使用weight属性设置控件所占的比例

例如，我们要实现下图所显示的效果：当屏幕尺寸改变时，new reader控件两边的控件大小不变，new reader控件会占完剩余的空间。

具体布局文件如下：

小插曲： 关于 android:layout_weight 属性

一般情况，我们都是设置要进行比例分配的方向的宽度为0dp，然后再用权重进行分配。如下：

效果为：

效果为：

button1宽度=L+（L-2L）×1/3=2/3L button2宽度=L+（L-2L）×2/3=1/3L

当然，还有其他的方式，都可以运用此公式进行计算。 在实际开发中，我们一般使用0dp的方式，而不使用其他方式。

简单的布局一般都使用 线性布局 ，而略微复杂点的布局，我们使用 相对布局 ，大多数时候，我们都是使用这两种布局的嵌套。

我们使用 相对布局 的原因是， 相对布局 能在各种尺寸的屏幕上保持控件间的相对位置。

res/layout/单面板：

res/layout-large/双面板：

如果这个程序运行在屏幕尺寸大于7inch的设备上，系统就会加载 res/layout-large/而不是 res/layout/ ，在小于7inch的设备上就会加载 res/layout/ 。

需要注意的是，这种通过 large 限定符分辨屏幕尺寸的方法，适用于android3.2之前。在android3.2之后，为了更精确地分辨屏幕尺寸大小，Google推出了最小宽度限定符。

res/layout-sw600dp/ ，双面板布局：Small Width 最小宽度

这种方式是不区分屏幕方向的。这种最小宽度限定符适用于android3.2之后，所以如果要适配android全部的版本，就要使用 large 限定符和 sw600dp 文件同时存在于项目 res 目录下。

这就要求我们维护两个相同功能的文件。为了避免繁琐操作，我们就要使用布局别名。

由于后两个文具文件一样，我们可以用以下两个文件代替上面三个布局文件：

res/layout/单面板布局res/layout/main_双面板布局

然后在 res 下建立res/values/ 、res/values-large/ 、res/values-sw600dp/ 三个文件。

默认布局res/values/ :

Android3.2之前的平板布局res/values-large/ :

Android3.2之后的平板布局res/values-sw600dp/ :

这样就有了 main 为别名的布局。 在activity中 setContentView();

这样，程序在运行时，就会检测手机的屏幕大小，如果是平板设备就会加载 res/layout/main_ ，如果是手机设备，就会加载 res/layout/。我们就解决了只使用一个布局文件来适配android3.2前后的所有平板设备。

如果我们要求给横屏、竖屏显示的布局不一样。就可以使用 屏幕方向限定符 来实现。 例如，要在平板上实现横竖屏显示不用的布局，可以用以下方式实现。res/values-sw600dp-land/ :横屏

res/values-sw600dp-port/ :竖屏

自动拉伸位图，即android下特有的 图片格式。

当我们需要使图片在拉伸后还能保持一定的显示效果，比如，不能使图片中的重要像素拉伸，不能使内容区域受到拉伸的影响，我们就可以使用 图来实现。

要使用 ，必须先得创建 图片，androidSDK给我们提供了的工具就包含 文件的创建和修改工具。双击 SDK安装目录 ，就会打开下图所示的窗口。

下面是一个例子：

Button属性设置：

如果我们选择的内容区域偏差太大，可能就不会显示出text值 BUTTON 。

好了，这篇文章写的有点多了，剩下的内容放在下篇文章 记录吧。 内容提要： 解决方案-支持各种屏幕密度 解决方案-实施自适应用户界面流程

未完待续

Android 开发中 如何做到XML多屏幕适配？

Android上面解决适配不同尺寸(分辨率)和密度的问题，主要是通过以密度分类,再加上分辨率的方式来减化适配不同尺寸屏幕的工作量.一般来讲,屏幕分辨率越高,清晰度也应该越高,也即其密度也应该越大,否则会看起来很不清楚,比如4寸的屏幕只显示100个像素,这就近距离看电影,或者看投影仪一样,非常的粗糙和不清晰.所以,Android主要是以屏幕密度来区分不同的设备:高密度:hdpi (High dots per inch)中等密度:mdpi(Medium dots per inch)低密度:ldpi(Low dots per inch)并且布局中推荐使用密度无关单位dip或dp,来作为长度或者宽度的单位.这样,从理论上来讲,开发者只需要做:1. 为不同的密度屏幕准备图片资源(图片是没办法的,因为图片的长度和宽度是固定的像素值,不能够随密度变化而变化,可以强行拉伸,但图片会失真.当然也有9 Patch图片可以解决随意拉伸的问题.但普通的图片的长度和宽度是固定的.2. 用dip作为单位来指定长度或者宽度就可以适配所有的设备,让布局在所有的屏幕上都得到比较好的显示效果.当然,现实的生活没有这么完美,各种设备千差万别.但是总体仍可分为这三大类,为这三大类准备好图片后,其他的只要与某一类较接近,即使稍有拉伸或失真,也不太明显,是可以接受的.所以,对于一般性的应用程序,写一个布局文件在layout中,为三种密度准备图片drawable-hdpi, drawable-mdpi, drawable-ldpi,就足以应对80%的设备/drawable-hdpi/ic_-mdpi/ic_-ldpi/ic_/(这里可能有点过时了,因为现在多了xdpi,而且很多设备也是xdpi的.)但是光以密度屏幕来分类和处理还不够.随着设备的越来越多,以及屏幕尺寸越来越大,还有就是Tablet的出现,又会出现这样的问题:设备的屏幕密度虽然不高,但其分辨率很高.举个简单的例子:iPad2的分辨率是1024×768,iPhone 4 960×640,但是iPhone 4的密度是326ppi,远大于iPad2.但是,无论密度有多高它的屏幕就那么,最多能显示960×640个像素点,一个1024*768的图片在iPad上可以看到全部,而iPhone上只能看到一大半!这也是为什么用iPad来运行iPhone上的应用程序时,只是以屏幕中间的一部分来模拟显示的原因.对Android来说也是一样的.如此一来,即使相同的dpi,假如其屏幕尺寸非常大,那么为其准备的图片将被拉伸很大或者显示不全元素也会被拉伸很长.这样并不是很好的体验.对于尺寸大的屏幕应该让其显示更多的内容,而不是把一部分元素拉伸很大.所以,很多手机安卓应用如果未经专门适配,在平板上直接使用体验将会是非常差的.为了解决这样的问题,就还必须以屏幕尺寸来区分设备主要有四种屏幕尺寸:small, normal, large and xlarge这主要是配合屏幕密度来一起使用,比如,适配平板的图片:drawable-xlarge-hdpi/ic_这里就要提到了密度,尺寸和分辨率的对应关系了. 屏幕分辨率是随设备变化最明显的一个,上面的二种分类方法仅是对屏幕进行的大致的一个分类.虽然屏幕分辨率与密度没有直接的关系,但是所有的设备都基本上一致的:ldpiQVGA 240*320 0.8mdpiHVGA 320*480 1.0hdpi WVGA480*800 1.5hdpi qHD 540*960 1.5xdpi WXGA720*