android第三周小结

1. 系统自带的通讯录应用，联系人名单保存在data/data/com.android.providers.contacts/databases/contats2.db，通过select * from contacts可以查询

2. 系统中的每个AppWidget都有一个数字标识

3. android系统中的每个application跑在单独的Process中

4. activity、service、ContentProvider必须在manifest中声明，但是BroadcastReceiver可以在代码中动态注册

5. activity的back stack是一个Last In First Out模型

6. activity最重要的生命周期方法是onCreate()和onPause()，前者需要完成activity的初始化工作，后者需要完成重要数据的持久化

7. 在屏幕横竖屏切换的时候，activity会被destroy，然后recreate

8. 从android3.0之后，引入了fragment和loader机制，之前的平台是没有的

9. android系统有多任务机制，设备的HOME页面是大多数任务的开始页面。有多个task，也就有多个back stack

10. 在back stack中的activity永远不会重新排列，所以如果一个activity被多次引用，将会创建多个实例

11. 当由于系统释放资源，而destroy掉activity之后，系统依然会记得activity在back stack中有一席之地。当重新显示该activity时，需要recreate，而不是resume

12. 可以在manifest中配置task管理机制，但一般推荐使用默认机制

13. 通过startService()方法启动的service，生命周期长于启动它的component。通过bound方式绑定的service，生命周期和绑定它的component相同

14. service是跑在所属application的主thread中，不会默认新开thread，所以需要编码创建新thread

15. service如果绑定到一个前台activity，则不太可能被kill。如果一个service被kill之后，会在系统获得足够的资源之后restart

16. 如果不需要同时处理多个请求，也不需要绑定到activity，可以继承IntentService，比直接继承Service方便一些

17. 用startService()方法启动的service的生命周期是onCreate()->onStartCommand()->onDestroy()。用bind()方法启动的service的生命周期是onCreate()->onBind()->onUnbind()->onDestory()

18. android自带的ContentProvider在android.provider包中声明了

19. 使用Cursor抛出了CursorIndexOutOfBoundsException，是因为没有先调用cursor.moveToFirst()方法

20. 所谓Intent的late run-time binding，其实是指的implicit intent，如果是explicit intent，就没有延迟绑定

21. implicit intent的action和data通常是成对出现的

22. activity如果要接受implicit intent的话，其intent-filter一定要加上DEFAULT CATEGORY。因为如果使用了implicit intent，android会自动调用intent.addCategory()方法，加上DEFAULT CATEGORY。而且every category in the Intent object must match a category in the IntentFilter。所以如果没有在intent-filter里加上DEFAULT CATEGORY，则implicit intent无法匹配通过

23. Intent匹配过程总结：如果是explicit intent，则直接找到指定的组件，如果没有找到，则抛出异常。如果是implicit intent，则android系统会把所有的组件都列出来，然后和intent设置的action、category、data逐一匹配。如果只有一个匹配结果，则直接调用，如果没有匹配结果，就抛出异常，如果有多个匹配结果，则让用户选择使用哪个组件来响应intent

支持下 。。。