Android 时间相关的坑

SystemcurrentTimeMillis

我们经常用这个接口来统计时间，比如

final long startTime = System.currentTimeMillis();
...
final long endTime = System.currentTimeMillis();
duration = endTime - startTime;

这端代码正常情况下是没有什么问题的，但是如果是在线上，用户量极大，且startTime和startTime的调用点不在一个地方，或者这个duration比较长时间，比如统计用户停留耗时，这个代码可能会收集到垃圾数据。因为currentTimeMillis本质上和日历时间一样，用户是可以修改的，比如在startTime和endTime中间用户将日历时间调回去了，那么得到的duration是负值。当然对于后台来说，可以过滤这些垃圾数据。但是为了更好的统计时间推荐使用elapsedRealtime。

elapsedRealtime

返回的是系统从启动到当前时间，所以这个时间做耗时duration统计是比较准确的，且不受用户调整日期行为影响。

timer问题

我们有时通过timer来执行一些定时任务

TimerTask timerTask = new TimerTask(){
	@Override
	public void run() {
		runOnUiThread(new Runnable() {
			@Override
			public void run() {
				System.out.println("Timer call");
			}
		});
	}
};
mTimer.schedule(timerTask,1000, 60*000);

上面代码是正常情况下每隔60s运行一次。
但是如果用户手工更改了本地时间，是可能导致该周期性任务失败。这是因为Timer本身是通过currentTimeMillis接口获取时间的

解决方案

使用handler.postDelay这种方式。

这个uptimeMillis和elapsedRealtime类似，都是一个相对时间，用户没法直接修改的。

/**************************************************
* 本文来自CSDN博主"一点码客"，喜欢请顶部点击关注
* 转载请标明出处:http://blog.csdn.net/itchosen
***************************************************/

如需实时查看更多更新文章，请关注公众号"一点码客"，一起探索技术