andorid 小知识点

Activity的生命周期
在一个Activity正常启动的过程中，他们被调用的顺序是 onCreate -> onStart -> onResume, 在Activity被干掉的时候顺序是onPause -> onStop -> onDestroy
如果突然来了电话, 则要中止. 如果中止的时候新出的一个Activity是全屏的那么：onPause->onStop ，恢复的时候onStart->onResume.
如果打断这个应用程序的是一个Theme为Translucent 或者Dialog 的Activity那么只是onPause ,恢复的时候onResume .

onCreate: 在这里创建界面 ，做一些数据 的初始化工作
onStart: 到这一步变成用户可见不可交互 的
onResume: 变成和用户可交互 的，(在activity 栈系统通过栈的方式管理这些个
Activity的最上面，运行完弹出栈，则回到上一个Activity)
onPause: 到这一步是可见但不可交互 的，系统会停止动画 等消耗CPU 的事情从上文的描述已经知道，应该在这里保存你的一些数据,因为这个时候 　你的程序的优先级降低，有可能被系统收回。在这里保存的数据，应该在　onResume里读出来，注意：这个方法里做的事情时间要短，因为下一 个activity不会等到这个方法完成才启动
onstop: 变得不可见 ，被下一个activity覆盖了
onDestroy: 这是activity被干掉前最后一个被调用方法了，可能是外面类调用finish方　法或者是系统为了节省空间将它暂时性的干掉，可以用isFinishing()来判断它，如果你有一个Progress Dialog在线程中转动，请在onDestroy里 把他cancel掉，不然等线程结束的时候，调用Dialog的cancel方法会抛异常的。
onPause，onstop， onDestroy，三种状态 下 activity都有可能被系统干掉
为了保证程序的正确性，你要在onPause()里写上持久层操作的代码，将用户编辑的内容都保存到存储介质上(一般都是数据库 )。实际工作中因为生命周期的变化而带来的问题也很多，比如你的应用程序起了新的线程在跑，这时候中断了，你还要去维护那个线程，是暂停还是杀掉还是数据回滚，是吧?因为Activity可能被杀掉，所以线程中使用的变量和一些界面元素就千万要注意了，一般都是采用Android的消息机制 [Handler,Message]来处理多线程和界面交互的问题。

你后台的Activity被系统回收怎么办：onSaveInstanceState
当你的程序中某一个Activity A 在运行时中，主动或被动地运行另一个新的Activity B 　这个时候A会执行

　　
public void onSaveInstanceState(Bundle outState) {
  super.onSaveInstanceState(outState);
  outState.putLong("id", 1234567890);
}

B 完成以后又会来找A, 这个时候就有两种情况，一种是A被回收，一种是没有被回收，被回收的A就要重新调用onCreate()方法，不同于直接启动的是这回onCreate()里是带上参数 savedInstanceState，没被收回的就还是onResume就好了。
savedInstanceState是一个Bundle对象，你基本上可以把他理解为系统帮你维护的一个Map对象。在onCreate()里你可能会用到它，如果正常启动onCreate就不会有它，所以用的时候要判断一下是否为空。

if(savedInstanceState != null){
  long id = savedInstanceState.getLong("id");
}

就像官方的Notepad教程里的情况，你正在编辑某一个note，突然被中断，那么就把这个note的id记住，再起来的时候就可以根据这个id去把那个note取出来，程序就完整一些。

handler机制的原理
andriod提供了 Handler 和 Looper 来满足线程间的通信。Handler 先进先出原则。Looper类用来管理特定线程内对象之间的消息交换(Message Exchange)。

1. Looper: 一个线程可以产生一个Looper对象，由它来管理此线程里的Message Queue(消息队列)
2. Handler: 你可以构造Handler对象来与Looper沟通，以便push新消息到Message Queue里;或者接收Looper从Message Queue取出)所送来的消息。
3. Message Queue(消息队列):用来存放线程放入的消息。
4. 线程：UI thread 通常就是main thread，而Android启动程序时会替它建立一个Message Queue。

什么是ANR 如何避免它?
答：ANR：Application Not Responding，五秒
在Android中，活动管理器和窗口管理器这两个系统服务负责监视应用程序的响应。当出现下列情况时，Android就会显示ANR对话框了：

1. 对输入事件(如按键、触摸屏事件)的响应超过5秒
2. 意向接受器(intentReceiver)超过10秒钟仍未执行完毕
3. Android应用程序完全运行在一个独立的线程中(例如main)。这就意味着，任何在主线程中运行的，需要消耗大量时间的操作都会引发ANR。因为此时，你的应用程序已经没有机会去响应输入事件和意向广播(Intent broadcast)。

因此，任何运行在主线程中的方法，都要尽可能的只做少量的工作。特别是活动生命周期中的重要方法如onCreate()和 onResume()等更应如此。潜在的比较耗时的操作，如访问网络和数据库;或者是开销很大的计算，比如改变位图的大小，需要在一个单独的子线程中完成 (或者是使用异步请求，如数据库操作)。但这并不意味着你的主线程需要进入阻塞状态已等待子线程结束 -- 也不需要调用Therad.wait()或者Thread.sleep()方法。取而代之的是，主线程为子线程提供一个句柄(Handler)，让子线程在即将结束的时候调用它(xing:可以参看Snake的例子，这种方法与以前我们所接触的有所不同)。使用这种方法涉及你的应用程序，能够保证你的程序对输入保持良好的响应，从而避免因为输入事件超过5秒钟不被处理而产生的ANR。这种实践需要应用到所有显示用户界面的线程，因为他们都面临着同样的超时问题。

横竖屏切换时候activity的生命周期?

1. 不设置Activity的android:configChanges时，切屏会重新调用各个生命周期，切横屏时会执行一次，切竖屏时会执行两次
2. 设置Activity的android:configChanges="orientation"时，切屏还是会重新调用各个生命周期，切横、竖屏时只会执行一次
3. 设置Activity的android:configChanges="orientation|keyboardHidden"时，切屏不会重新调用各个生命周期，只会执行onConfigurationChanged方法

http://hi.baidu.com/wanlixingzhe/blog/item/df22fa4acaf304e883025c3e.html

http://www.limodev.cn/blog/  致力于基于linux的嵌入式系统的学习和研究，包括内核、驱动、GUI、MMI、软件设计和优化等

http://hi.baidu.com/304580500/blog/item/39fd88debdf05e06495403c9.html  Android的线程使用来更新UI----Thread、Handler、Looper、TimerTask 

android 应用程序升级:
http://hi.baidu.com/304580500/blog/item/704b041ab12827c0ac6e752c.html
http://hi.baidu.com/304580500/blog/item/9a7e0206f80ddad87a894707.html
http://hi.baidu.com/luyanlong1/blog/item/5d56af393c3bbdd57c1e71cf.html

Android,UI主线程与子线程
http://hi.baidu.com/jackzjj/blog/item/cd0fda62a16b39cfe6113a5a.html
http://hi.baidu.com/455611934/blog/item/781f18a5085381e59052eebd.html
http://hi.baidu.com/455611934/blog/item/0e54193e297af3fe54e723b9.html
http://hi.baidu.com/455611934/blog/item/0c92a73c2da45912baa16785.html

深入理解Android消息处理系统——Looper、Handler、Thread
http://hi.baidu.com/dragon_eros/blog/item/6eaf600cb4e22f28e824881c.html

Android 核心分析
http://blog.csdn.net/maxleng/archive/2010/06.aspx