Android中屏幕密度和图片大小的关系分析

转发:http://blog.csdn.net/singwhatiwanna/article/details/19139013

前言

Android中支持许多资源,包括图片(Bitmap),对应于bitmap的文件夹是drawable,除了drawable,还有drawable-ldpi、drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi等,同一张图片放到上面不同的文件夹中是有区别的,比如一张100 * 100像素大小的图片,分别放在上述各个文件夹中,然后将其设置为ImageView(假设宽高都是wrap_content)的图片,那么这个ImageView的大小是多少呢,或者说图片的大小是多少呢?本文主要和大家阐述这个问题。当然,还有一个问题,如果在上述各个文件夹中都放置一张相同的图片(内容相同,尺寸不同),那么系统会选择加载哪一张图片呢?这个问题,系统有内部的选择机制,简单来说:系统会选择最接近手机屏幕密度的图片,由于这个问题和本文主题关系不是很大,所以暂时不讨论此类问题。

概念

先介绍一些概念:

屏幕密度:单位英寸面积上的像素点数

ldpi:   屏幕密度为120的手机设备

mdpi: 屏幕密度为160的手机设备(此为baseline,其他均以此为基准,在此设备上,1dp = 1px)

hdpi:  屏幕密度为240的手机设备

xhdpi: 屏幕密度为320的手机设备

xxhdpi:屏幕密度为480的手机设备

图片大小以及dp和px关系一览表

说明:根据上表,我们应该很容易算出一张图片在不同手机上的宽和高是多少。

结论

从上表可以得出如下结论

1. 图片放在drawable中,等同于放在drawable-mdpi中,原因为:drawable目录不具有屏幕密度特性,所以采用基准值,即mdpi

2. 图片放在某个特定drawable中,比如drawable-hdpi,如果设备的屏幕密度高于当前drawable目录所代表的密度,则图片会被放大,否则会被缩小

  放大或缩小比例 = 设备屏幕密度 / drawable目录所代表的屏幕密度

3. 为了更全面的适配所有设备,我们应该提供一套针对主流屏幕密度的图片(目前为hdpi或xhdpi),其他密度通过系统自动缩放得到图片

时间: 2024-11-19 04:57:34

Android中屏幕密度和图片大小的关系分析的相关文章

Android中使用SoftReference缓存图片对象

Java中的SoftReference即对象的软引用.如果一个对象具有软引用,内存空间足够,垃圾回收器就不会回收它:如果内存空间不足了, 就会回收这些对象的内存.只要垃圾回收器没有回收它,该对象就可以被程序使用.软引用可用来实现内存敏感的高速缓存.使用软引用能防止内存泄露,增强程序的健壮性.   SoftReference的特点是它的一个实例保存对一个Java对象的软引用,该软引用的存在不妨碍垃圾收集线程对该 Java对象的回收.也就是说,一旦SoftReference保存了对一个Java对象的

Android 多屏幕适配 dp和px的关系

一直以来别人经常问我,android的多屏幕适配到底是怎么弄,我也不知道如何讲解清楚,或许自己也是挺迷糊. 以下得出的结论主要是结合官方文档进行分析的https://developer.android.com/guide/practices/screens_support.html android由于碎片化太严重,而导致市面上出现非常多的种类尺寸手机设备,当然也包括非常奇葩的分辨率手机.所以我们在布局的时候使用px作为单位显然不能很好的做到多屏幕的适配.其实在官方文档中有介绍一种解决多屏幕适配的

android中使用jni对字符串加解密实现分析

android中使用jni对字符串加解密实现分析 最近项目有个需求,就是要对用户的敏感信息进行加密处理,比如用户的账户密码,手机号等私密信息.在java中,就对字符串的加解密我们可以使用AES算法加密字符串,使用它的好处就不必多说了,但我们又知道android的源代码是可以被反编译的,所以使用纯Java方式的AES加密是不安全的,所以想到了使用android中的jni来对字符串加解密处理,它会产生一个.so文件,更重要的是它通过C/C++代码实现,所以安全行比较高,它可以被反编译成机器码,但几乎

Android中Preference的使用以及监听事件分析

> 在Android系统源码中,绝大多数应用程序的UI布局采用了Preference的布局结构,而不是我们平时在模拟器中构建应用程序时使用的View布局结构,例如,Setting模块中布局.当然,凡事都有例外,FMRadio应用程序中则使用了View布局结构(可能是该应用程序是marvel公司提供的,如果由google公司做,那可说不准).归根到底,Preference布局结构和View的布局结构本质上还是大同小异,Preference的优点在于布局界面的可控性和高效率以及可存储值的简洁性(每个

Android中高效的显示图片之三——缓存图片

加载一张图片到UI相对比较简单,如果一次要加载一组图片,就会变得麻烦很多.像ListView,GridView,ViewPager等控件,需要显示的图片和将要显示的图片数量可能会很大. 为了减少内存使用,这类控件都重复利用移出屏幕的子视图,如果你没有持用引用,垃圾回收器也会回收你加载过的图片.这种做法很好,但是如果想要图片加载快速流畅且不想当控件拖回来时重新运算获取加载过的图片,通常会使用内存和磁盘缓存.这节主要介绍当加载多张图片时利用内存缓存和磁盘缓存使加载图片时更快. 一.使用内存缓存 内存

Android中高效的显示图片之一 ——加载大图

在网上看了不少文章,发现还是官方文档介绍最详细,把重要的东西简单摘要出来.详细可看官方文档地址 ( http://www.bangchui.org/read.php?tid=9 ) . 在应用中显示图片,如果不多加小心,很容易就会使应用因为异常“java.lang.OutofMemoryError:bitmap size exceeds VM budget”而导致crash.在android中加载图片需要一定的技巧性,主要是因为: 1.通常设备资源有限,安卓设备给每个应用只分配16M的空间.当然

Android中使用ImageViewSwitcher实现图片切换轮播导航效果

前面写过了使用ViewFlipper和ViewPager实现屏幕中视图切换的效果(未实现轮播)附链接: Android中使用ViewFlipper实现屏幕切换 Android中使用ViewPager实现屏幕页面切换和页面切换效果 今天我们在换一种实现方式ImageViewSwitcher. ImageSwitcher是Android中控制图片展示效果的一个控件,如:幻灯片效果 ImageSwitcher粗略的理解就是ImageView的选择器. ImageSwitcher的原理:ImageSwi

Android中高效的显示图片之二——在非UI线程中处理图片

在“加载大图”文章中提到的BitmapFactory.decode*方法,如果源数据是在磁盘.网络或其它任何不是在内存中的位置,那么它都不应该在UI线程中执行.因为它的加载时间不可预测且依赖于一系列因素(磁盘读写速度.图片大小.CPU频率等).如果在主线程中执行这个操作,一旦它阻塞了主线程,就会导致系统ANR.本节介绍使用AsyncTask在后台处理图片和演示怎么处理并发问题. 一.使用一个AsyncTask AsyncTask类提供一个简易的方法在后台线程中执行一些任务并把结果发布到UI线程.

Android中简单实现选择图片并裁剪

在android中选择图片是一个很常见的功能,图片的来源通常情况下是从相机获取和从相册获取两种. 先来写一个简单的选择按钮和一个能显示图片的ImageView <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent&qu