PPI = Pixels per inch，每英寸上的像素数,即 “像素密度”

• xhdpi: 2.0
• hdpi: 1.5
• mdpi: 1.0 (baseline)
• ldpi: 0.75

drawable-ldpi、drawable-mdpi、drawable-hdpi 精度分别为低、中（android默认）、高。
对应的图片大小为：36×36、48×48、72×72。

xxhdpi: 144*144
xhdpi:96*96
hdpi:72*72
mdpi:48*48
ldpi:36*36

dp是虚拟像素，在不同的像素密度的设备上会自动适配，比如:
在320×480分辨率，像素密度为160,1dp=1px
在480×800分辨率，像素密度为240,1dp=1.5px
计算公式:1dp*像素密度/160 = 实际像素数

drawable- hdpi、drawable- mdpi、drawable-ldpi的区别：
(1)drawable-hdpi里面存放高分辨率的图片,如WVGA (480×800),FWVGA (480×854)
(2)drawable-mdpi里面存放中等分辨率的图片,如HVGA (320×480)
(3)drawable-ldpi里面存放低分辨率的图片,如QVGA (240×320)
系统会根据机器的分辨率来分别到这几个文件夹里面去找对应的图片。

ppi的运算方式是：

PPI = √（长度像素数? + 宽度像素数?） / 屏幕对角线英寸数

dp：Density-independent pixels，以160PPI屏幕为标准，则1dp=1px，

dp和px的换算公式 ：
dp*ppi/160 = px。比如1dp x 320ppi/160 = 2px。

sp：Scale-independent pixels，它是安卓的字体单位，以160PPI屏幕为标准，当字体大小为 100%时， 1sp=1px。

sp 与 px 的换算公式：sp*ppi/160 = px

总结得出：

px = dp*ppi/160
dp = px / (ppi /?160)

px = sp*ppi/160
sp?= px / (ppi /?160)

dp = sp?

参考：

[无线手册-4] dp、sp、px傻傻分不清楚[完整]
http://zhuanlan.zhihu.com/zhezhexiong/19565895

Supporting Different Screens | Android Developers
http://developer.android.com/training/basics/supporting-devices/screens.html#create-bitmaps

Iconography | Android Developers
http://developer.android.com/design/style/iconography.html

Devices and Displays | Android Developers
http://developer.android.com/design/style/devices-displays.html

看过几篇关于android中像素点的帖子，觉得这篇文章写得还不错，

原文地址：http://www.cnblogs.com/bluestorm/p/3640786.html

原文地址：http://blog.csdn.net/arui319/article/details/7040980#

==============================================================================

首先要说的是，用户可能把这种做法视为流氓软件。大部分时候，程序员也不想把软件做成流氓软件，没办法，领导说了算。

我们在使用某些Android应用的时候，可能会发现安装了某应用以后，会有一些服务也会随之运行。而且，这些服务每次都会随着手机开机而启动。有的服务做的更绝，当用户停止该服务器以后，过了一段时间，服务又自动运行了。虽然，从用户的角度来说，这种方式比较流氓。但是，从程序员的角度来说，这是如何做到的呢？经过研究，我发现有一种方式是可以实现的。下面就和大家分享。

先简单介绍，一会儿会贴上全部代码。

如何做到开机启动？

这个比较简单，网上的资料够多，只要实现一个BroadcastReceiver，监听手机启动完成的事件ACTION_BOOT_COMPLETED即可。需要注意的是，好像不能用模拟器，要用手机测试。

那如何做到启动一个Service，并且在用户关闭后能自动又启动了呢？

一般的，都会在上面说到的BroadcastReceiver的实现里面，监听手机启动完成后，启动一个Service，这是一般的做法。问题是，用户可以关闭掉该Service。那么怎样才能使它被关闭掉以后，再次启动呢？聪明的你一定立即就想到了，如果不直接启动Service，而是启动一个timmer，或者alarmManager，然后每隔一段时间去启动Service，就可以了。

还是看下面的全部代码吧，不过多解释了。这些代码中还是有不少概念的，不熟悉AlarmManager、PendingIntent、BroadcastReceiver、Service等等这些概念的同学可以百度一下。

package com.arui.framework.android.daemonservice;

import android.app.AlarmManager;
import android.app.PendingIntent;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.os.SystemClock;

public class BootBroadcast extends BroadcastReceiver {

	@Override
	public void onReceive(Context context, Intent mintent) {

		if (Intent.ACTION_BOOT_COMPLETED.equals(mintent.getAction())) {
			// 启动完成
			Intent intent = new Intent(context, Alarmreceiver.class);
			intent.setAction("arui.alarm.action");
			PendingIntent sender = PendingIntent.getBroadcast(context, 0,
					intent, 0);
			long firstime = SystemClock.elapsedRealtime();
			AlarmManager am = (AlarmManager) context
					.getSystemService(Context.ALARM_SERVICE);

			// 10秒一个周期，不停的发送广播
			am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstime,
					10 * 1000, sender);
		}

	}
}

package com.arui.framework.android.daemonservice;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;

public class Alarmreceiver extends BroadcastReceiver {
	@Override
	public void onReceive(Context context, Intent intent) {

		if (intent.getAction().equals("arui.alarm.action")) {
			Intent i = new Intent();
			i.setClass(context, DaemonService.class);
			// 启动service 
			// 多次调用startService并不会启动多个service 而是会多次调用onStart
			context.startService(i);
		}
	}
}

package com.arui.framework.android.daemonservice;

import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;

public class DaemonService extends Service {

	@Override
	public IBinder onBind(Intent intent) {
		return null;
	}

    @Override
    public void onCreate() {
    	super.onCreate();
    	Log.v("=========", "***** DaemonService *****: onCreate");
    }

    @Override
    public void onStart(Intent intent, int startId) {
    	Log.v("=========", "***** DaemonService *****: onStart");
    	// 这里可以做Service该做的事
    }
}

下面是manifest文件的代码。

		<receiver 
			android:name="com.arui.framework.android.daemonservice.BootBroadcast"
			android:permission="android.permission.RECEIVE_BOOT_COMPLETED">
			<intent-filter>
				<action android:name="android.intent.action.BOOT_COMPLETED" />
			</intent-filter>
		</receiver>
		<receiver 
			android:name="com.arui.framework.android.daemonservice.Alarmreceiver" >
			<intent-filter>
				<action android:name="arui.alarm.action" />
			</intent-filter>
		</receiver>
        <service
            android:name="com.arui.framework.android.daemonservice.DaemonService" >
        </service>

继续讨论这个问题。

如果用户停止整个应用（在管理应用程序中停止应用，或者第三方软件停止整个应用），此时整个进程被杀死，所有的服务自然也被杀死了，timmer，或者alarmManager也就停止了。此时就不会再定期启动服务了。

那么，怎么才能做到，用户或者第三方软件无法停止整个应用呢。我们可以再注册一个系统级别的监听（BroadcastReceiver），来监听系统级别的消息，再次启动timmer，或者alarmManager。这样，即使应用被杀死了，隔一段时间，应用还会自动启动。具体的，就不在这里展开了。

自从知道了android中Timer在手机锁屏的时候不会正常倒计时后，就寻找到了另外一种全局的计时器AlarmManager,它是android中提供的一个系统服务，即使手机在锁屏的情况下也能倒计时。短时间的计时是没问题的，长时间的倒计时正在进行测试。

下面先了解下AlarmManager的一些方法和属性：

AlarmManager 包含的主要方法：

// 取消已经注册的与参数匹配的定时器
void cancel(PendingIntent operation)
//注册一个新的延迟定时器
void set(int type, long triggerAtTime, PendingIntent operation)
//注册一个重复类型的定时器
void setRepeating(int type, long triggerAtTime, long interval, PendingIntent operation)
//注册一个非精密的重复类型定时器
void setInexactRepeating (int type, long triggerAtTime, long interval, PendingIntent operation)
//设置时区
void setTimeZone(String timeZone)

定时器主要类型：

public static final int ELAPSED_REALTIME
// 当系统进入睡眠状态时，这种类型的闹铃不会唤醒系统。直到系统下次被唤醒才传递它，该闹铃所用的时间是相对时间，是从系统启动后开始计时的,包括睡眠时 间，可以通过调用SystemClock.elapsedRealtime()获得。系统值是3 (0x00000003)。

public static final int ELAPSED_REALTIME_WAKEUP
//能唤醒系统，用法同ELAPSED_REALTIME，系统值是2 (0x00000002) 。

public static final int RTC
//当系统进入睡眠状态时，这种类型的闹铃不会唤醒系统。直到系统下次被唤醒才传递它，该闹铃所用的时间是绝对时间，所用时间是UTC时间，可以通过调用 System.currentTimeMillis()获得。系统值是1 (0x00000001) 。

public static final int RTC_WAKEUP
//能唤醒系统，用法同RTC类型，系统值为 0 (0x00000000) 。

Public static final int POWER_OFF_WAKEUP
//能唤醒系统，它是一种关机闹铃，就是说设备在关机状态下也可以唤醒系统，所以我们把它称之为关机闹铃。使用方法同RTC类型，系统值为4(0x00000004)。

当你的应用不在运行，而此时你仍然需要你的应用去执行一些操作（比如，短信拦截），只有这种时候才使用AlarmManager, 其他正常情况下的，推荐使用Handler。

AlarmManager 生命周期：

repeating AlarmManager一旦启动就会一直在后台运行(除非执行cancel方法)，可以在“应用管理”中看到这个应用状态是正在运行。 “强行停止”可以让Alarmmanager停掉。

尝试了几种任务管理器， 都只能重置计数器（确实释放内存了），但都无法关闭定时器，只有系统自带的“强行停止”奏效。

如果某个AlarmManager已经启动， 程序又再次去启动它，只要PendingIntent是一样，那么之前那个AlarmManager会被release掉。

如何使用AlarmManager？

使用AlarmManager共有三种方式， 都是通过PendingIntent。

getActivity(Context, int, Intent, int)

getBroadcast(Context, int, Intent, int)

getService(Context, int, Intent, int)

==========================代码示例===========================================

package com.aibb.alarmmanagertest;

import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.io.Writer;
import java.text.SimpleDateFormat;
import java.util.Date;

import android.app.AlarmManager;
import android.app.PendingIntent;
import android.app.Service;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.content.IntentFilter;
import android.os.Environment;
import android.os.IBinder;
import android.os.SystemClock;
import android.util.Log;

public class AlarmManagerService extends Service{

private class AlarmOnBroadcastReciver extends BroadcastReceiver{

@Override
public void onReceive(Context context, Intent intent) {
if(intent.getAction().equals(“com.aibb.alarmamanger.start”)){
logTimeMsg(“alarm manager end:”);
}
}

}

@Override
public void onCreate() {
super.onCreate();
//一定要注册reveicer
AlarmOnBroadcastReciver reve = new AlarmOnBroadcastReciver();
IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction(“com.aibb.alarmamanger.start”);
this.registerReceiver(reve, intentFilter);

startAlarmManager();
}

@Override
public IBinder onBind(Intent arg0) {
// TODO Auto-generated method stub
return null;
}

private void startAlarmManager() {
Intent intent =new Intent(“com.aibb.alarmamanger.start”);
PendingIntent sender=PendingIntent
.getBroadcast(this, 0, intent, 0);
//开始时间
long firstime=SystemClock.elapsedRealtime();//System.currentTimeMillis();//SystemClock.elapsedRealtime();
long currenttime = System.currentTimeMillis();
firstime+=1000;
AlarmManager am=(AlarmManager)getSystemService(ALARM_SERVICE);

//如果是周期性的执行，就需要使用SystemClock.elapsedRealtime() time since boot
/*am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP
, firstime, 5*1000, sender);*/
// am.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstime+180*1000, sender);
am.set(AlarmManager.RTC_WAKEUP, currenttime+1800*1000, sender);
logTimeMsg(“alarm manager start:”);
}

private static final String TAG = AlarmManagerActivity.class.getSimpleName();

private Writer logWriter;

private File logFile;

/**
* 记录Timer的执行时间
* @param location
*/
public void logTimeMsg(String prefixStr) {
if (null == logFile) {
logFile = new File(Environment.getExternalStorageDirectory(),”AlarmManagerTime.txt”);
}
if (null == logWriter) {
try {
logWriter = new FileWriter(logFile, true);
} catch (Exception e) {
Log.e(“EnvironmentChangeReceiver”, e.getMessage(), e);
}
}
try {
String jsonString = prefixStr;
Date date = new Date();
SimpleDateFormat sdf = new SimpleDateFormat(“yyyy-MM-dd HH:mm:ss”);
String time = sdf.format(date);;
logWriter.write(jsonString+”:” +time+ “\r\n”);
logWriter.flush();
} catch (IOException e) {
e.printStackTrace();
}
}

}

这几天有个APP需要在刷了NFC后一段时间内保持一个状态不改变，比如10min内一直保持一个状态，然后再到了10min时做一个判断，更新其最新状态。当时一想到这个场景，立马就想到了使用android中定时器Timer来实现这个功能，起初也没多想，直到测试的时候才发现这个Timer在运行时有很多问题。比如，Timer在手机锁屏的情况下就会停止运行，当开屏的时候才会继续倒计时，还有就是Timer在锁屏的情况下可能会被回收。

在网上查阅帖子后，找到了一篇测试Timer的文章，写的很好。

原文地址是：http://blog.csdn.net/lzqjfly/article/details/8021551

============================================================================

目标: 希望采用Timer来计时，要求在服务中运行，每10分钟记录一次数据。但是采用timer来做了以后，发现统计的次数没有达到预期的目标。甚至没有运行，以下是在测试情况

1.为了能够看到测试效果，将循环时间设置为2秒

本打算用服务做测试，但为了方便就用activity做测试

结果：

1.将手机与电脑连接测试，改程序正常，能够一直运行。并且按下电源键后仍然能够正常运行，统计的次数也正常

2.手机与电脑断开连接后，然后重新运行改程序，该程序能正常运行。然后按下电源键，手机处于待机状态，过一段时间后在看屏幕上的次数，发现次数没有动，不知道为啥？？？

3.手机与电脑断开连接后，运行程序，然后按home键，在手机没有处于待机的状态下，统计的次数发生变化，能够正常运行。但是如果手机处于待机状态后，程序不在运行。

问题： 手机待机后会让大部分程序不在运行（除电话，短信等）。难道这是系统的保护机制？？？

2.采用线程的Sleep处理；

采用Sleep的处理结果和上面1中的一样，怀疑是不是activity和thread有区别,于是采用线程来处理，并将结果保存到xml中

服务如下：

显示数据的activity

测试结果：：

1.手机和电脑连接，手机处于调试模式，不管是按下电源键让手机处于待机状态还是按下home键，服务都能够正常的统计数据

2.手机与电脑断开连接，不管是手机自动处于待机状态还是主动按下电源键让手机处于待机状态，服务里面的线程都没有正常的记录数据。 求解 ？？？

最终结合网上资料采用AlarmManager 控制计时操作，能够保证系统在sleep的时候发出广播，达到统计的目的

接受广播的类

从网络上总结Intent和PendingInent的区别：

intent英文意思是意图，pending表示即将发生或来临的事情。
PendingIntent这个类用于处理即将发生的事情。比如在通知Notification中用于跳转页面，但不是马上跳转。

Intent 是及时启动，intent 随所在的activity 消失而消失。
PendingIntent 可以看作是对intent的包装，通常通过getActivity,getBroadcast ,getService来得到pendingintent的实例，当前activity并不能马上启动它所包含的intent,而是在外部执行 pendingintent时，调用intent的。正由于pendingintent中 保存有当前App的Context，使它赋予外部App一种能力，使得外部App可以如同当前App一样的执行pendingintent里的 Intent， 就算在执行时当前App已经不存在了，也能通过存在pendingintent里的Context照样执行Intent。另外还可以处理intent执行后的操作。常和alermanger 和notificationmanager一起使用。
Intent一般是用作Activity、Sercvice、BroadcastReceiver之间传递数据，而Pendingintent，一般用在 Notification上，可以理解为延迟执行的intent，PendingIntent是对Intent一个包装。

作者：xuding 转过来作为记录。

由于历史原因，我们有的APP依然使用webservice进行网络请求，我们为此封装了WebserviceUtils工具类，这个类具有明显的工具类特点——不与界面业务有任何耦合，这本应是个不错的设计。
然而我们长大后确发现，正因为不与界面耦合，WebserviceUtils在请求操作出错时，无法向界面传递消息，起初我们纠结万分，痛苦之中在研究了android Looper类的源码，于是我们自以为掌握了android消息队列的原理，参考：
http://www.cnblogs.com/codingmyworld/archive/2011/09/14/2174255.html
于是有了如下代码：

01.try {

02. // 网络请求

03.} catch (Exception e) {

04. Log.e(TAG, “请求超时”, e);

05. Activity activity = ActivityStackManager.getCurrentActivity();

06. Looper.prepare();

07. SysUtils.closeHint();

08. Toast.makeText(activity, “网络通讯异常，请检查网络…”, Toast.LENGTH_LONG).show();

09. Looper.loop();

10.}
复制代码这样书写终于可以弹出提示了，然而悲剧的是，弹出提示紧接着，界面就失去响应（ANR），曾记否，那一年的冬天，大约也是这个季节，当时客户现场不断传来APP停止响应的呼吼，出错现象如同雪花在面前纷纷扬扬，而我们居然一片都抓不住啊
说正题，此处的问题很经典，需要从后台线程向界面上展示消息，Android展示消息只能在主线程里操作。Android中每个线程都有handler对象，消息框（Toast）、对话框等都是通过主线程的handler操作消息对列来做的。
上述代码中的Looper.prepare()、Looper.loop()是参考Handler.java源码来做的，那么为什么会ANR呢？
关键就是这里的loop()，和其他系统一样，android的消息队列也是通过死循环实现的：

01.for (;;) {

02. Message msg = queue.next(); // might block

03. if (msg == null) {

04. // No message indicates that the message queue is quitting.

05. return;

06. }

07. msg.target.dispatchMessage(msg);

08. // 。。。。。

09. msg.recycle();

10.}
复制代码低版本sdk中是while(){…)，都一样，在后台线程loop()之后，因为这个死循环，该线程就一直处于阻塞状态了，于是这里的消息也就成了APP临终的遗言，紧接着ANR失去响应，然后就没有然后了。。。因为是死循环导致出错，所以APP捕获不到uncaughtException，也就无法输出错误日志了，于是更加让人不明所以，加大了排查错误的难度。
那么问题来了，后台线程究竟有没有办法向前台发消息呢？当然有，其实我们有了上述的知识，离胜利已经很近了：

01.new Handler(Looper.getMainLooper()).post(new Runnable() {

02. @Override

03. public void run() {

04. SysUtils.closeHint();

05. Toast.makeText(activity, “网络通讯异常，请检查网络…”, Toast.LENGTH_LONG).show();

06. }

07.});
复制代码非常优雅的通过Looper.getMainLooper()得到主线程handler，然后post！
非常简单吧！这个故事告诉我们一个道理，凡事一要求甚解，知其然还要知其所以然。我们有时候闭门造车容易将自己蒙蔽，吾尝终日而思，不如须臾之所学也。当我们脚踏实地，蓦然回首，就会发现，原来希望一直都在我们身边，只是我们被雪花迷失了方向。。。
万幸的是，这样的错误，我们以后的APP开发中很难再出现了，我们使用的annotations框架可以很优雅的处理各种对话框，从此Looper.loop()、AnsyncTask、Handler都成为了过往的种种。。。
其实Annotations处理主线程事件，也是通过上面的new Handler(Looper.getMainLooper()).post(…)来做的，欲知Annotations如何，且听下回分解~