在项目中，有这么一个功能点，app进程中，需要实现一个定时任务，只要设备处于开机状态，每隔半个小时，就需要定时向服务器上传一次位置信息，并且只要是有网络和获取到GPS信号，进程不能死，如果进程死掉了，需要自动重启。对该点进行细分梳理，包含如下几个小功能点：

     1.进程能够实现开机启动。

     2.进程需要一直存活，并且能够自动重启。

     3.需要定时（30分钟）一次，向server端上报信息。

      针对以上三个功能点，第1和2点，实现起来，都不难，唯独第三点，在实现时，一般情况，会考虑到多种方式实现。由于没有自己查阅相关资料，在实现定时上传功能时，分别使用了三种方案，导致多花了冤枉时间，吃力不讨好，最终的结果是，定时功能不准，时间跨度越长，误差越大。

       for(;;)

            Tread.sleep 30分钟

      timerTask 30分钟一次

     使用系统级AlarmManager，进行精准定时，与系统闹钟的类似功能点。

     方案一和方案二的定时方案不准，主要原因是sleep和timerTask的内部线程运行的时间。在thread运行时，CPU才开始计算时间，当线程挂起，CPU没有将时间片交给该线程，就没有计算时间。实际使用中，app在后台运行越长，误差就越大。

     由于之前没有使用过AlarmManager功能，对其各个API不熟悉，并且存在如下的一些疑问：

     question 1：进程死掉后，AlarmManager是否还有效果？是否需要使用自动重启的service来重启进程？

     question 2：设备reboot后，设置的AlarmManager是否还有效？

     question 3：重复set相同的alarm，是否会影响AlarmManager的定时机制？

     在多番查阅资料后，发现网上的一片文章，写的还不错。http://blog.csdn.net/vicluo/article/details/8484939 尤其是其讲述到的关机alarm问题，尤为重要。

   文章提到，在设备reboot后，为了确保AlarmManager的setInexactRepeating还有效，必须在设备接收到ACTION_BOOT_COMPLETED事件时，重新进行set alarm。

 实现一个简单的demo，运行效果如下：
                 
   点击“启动定时器”，进行设置arlam，点击“关闭定时器”按钮，取消定时任务。
   代码如下：
   MainActivity.java

	@Override
	public void onClick(View v) {
		// TODO Auto-generated method stub
		int id = v.getId();
		switch(id){
		case R.id.button1:
			ServiceUtil.invokeTimerPOIService(mContext);
			break;
		case R.id.button2:
			ServiceUtil.cancleAlarmManager(mContext);
			break;
		}

  类ServiceUtil.java
 

    public static void invokeTimerPOIService(Context context){
        Log.i("ServiceUtil-AlarmManager", "invokeTimerPOIService wac called.." );
        PendingIntent alarmSender = null;
        Intent startIntent = new Intent(context, UploadPOIService.class);
        startIntent.setAction(Constants.POI_SERVICE_ACTION);
        try {
            alarmSender = PendingIntent.getService(context, 0, startIntent, PendingIntent.FLAG_UPDATE_CURRENT);
        } catch (Exception e) {
            Log.i("ServiceUtil-AlarmManager", "failed to start " + e.toString());
        }
        AlarmManager am = (AlarmManager) context.getSystemService(Activity.ALARM_SERVICE);
        am.setInexactRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(), Constants.ELAPSED_TIME, alarmSender);
    }

    public static void cancleAlarmManager(Context context){
        Log.i("ServiceUtil-AlarmManager", "cancleAlarmManager to start ");
        Intent intent = new Intent(context,UploadPOIService.class);
    	intent.setAction(Constants.POI_SERVICE_ACTION);
        PendingIntent pendingIntent=PendingIntent.getService(context, 0, intent,PendingIntent.FLAG_UPDATE_CURRENT);
        AlarmManager alarm=(AlarmManager)context.getSystemService(Activity.ALARM_SERVICE);
        alarm.cancel(pendingIntent);
    }

   在类UploadPOIService，是一个service，使用Thread.sleep模拟网络HTTP请求。  

	@Override
	public void run() {
		// TODO Auto-generated method stub
		try {
			Log.i(TAG, "UploadPOIService beign to upload POI to server ");
			Thread.sleep(5*1000);
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		stopSelf();
	}

   类BootBroadcastReceiver，注册一个静态Broadcast，接收系统级的ACTION_BOOT_COMPLETED事件，用于开机set alarm。

    @Override
    public void onReceive(Context context, Intent intent) {
        mContext = context;
        if (intent.getAction().equals(Intent.ACTION_BOOT_COMPLETED) ||
                intent.getAction().equals(Intent.ACTION_USER_PRESENT)) {
            Log.i("BootBroadcastReceiver", "BroadcastReceiver onReceive here.... ");
            Handler handler = new Handler(Looper.getMainLooper());
            //after reboot the device,about 2 minutes later,upload the POI info to server
            handler.postDelayed(new Runnable() {
                @Override
                public void run() {
                    if(!ServiceUtil.isServiceRunning(mContext,Constants.POI_SERVICE)){
                        ServiceUtil.invokeTimerPOIService(mContext);
                    }
                }
            }, Constants.BROADCAST_ELAPSED_TIME_DELAY);
        }
    }

  运行后，针对question 1和question 3进行测试。从打印的log分析问题。执行步奏：在控制台，使用adb kill命令杀死进程，观察先前设置的AlarmManager是否还有效果？log如下：

   进程PID“32267”和“1190”属于同一应用，从log发现，进程被kill后，自动重启进程，并且先前设置的alarm同样有效。此log信息，说明系统级的alarm，在进程kill后，会自动重启，并且重启后的定时任务，依旧有效。
   在设备reboot后，重新set alarm，alarm会执行。
   以上内容，仅仅从表像来分析AlarmManager的执行机制，如若要深入分析其原理，还需要研读AlarmManager的源码才行。然而，fucking the code，是一件很痛苦的事情。
   在测试代码时，发现某些设备上，AlarmManager执行效果没有达到预期效果，10秒一次的定时任务，被搞成了5min+一次。例如雷布斯的小米3设备，源码设置的10秒一次，米3上，却是5分钟一次定时任务。后来查询资料，发现时由于Android碎片化的原因，各个厂家进行随意定制，考虑节能省电，一旦系统休眠，不会频繁唤醒系统造成的原因。相关链接如下：
   http://www.miui.com/thread-1241523-1-1.html
  上述功能点，不是很难，然而在真正开发过程中，做好这么一件小事，还是很费神的，也遭受过一些莫名其妙的坑。
  在如今的项目中，此项功能点使用得比较频繁，一般app都会偶push功能，push的精准定时任务，实现的方式，也大同小异。
  源码链接如下：
http://download.csdn.net/detail/coder80/8115751
github地址：
https://github.com/hero-peng/AlarmTimerTask