1.activity
生命周期如图所示
activity的生命周期
onCreate方法在一个生命周期中只执行一次，并且还在activity创建之初执行的，适合在方法里面进行一些只需要一次的初始化工作，如布局资源的初始化。
onStart方法会在activity每次启动的时候调用，经实践发现，即使是activty重启，调用了onRestart，也会再次调用onStart。onStart调用了，一定会调用onRestart，反过来则不一定，因为onRestart只有在activity重启的这个时机才会调用。由于，这两个方法在调用的时候，activity仍然处于不可见状态，通常我们可以在这两个方法里进行一些资源的准备或者是初始化，例如一些视频资源，音频资源。
onResume方法在activity位于前台时（即可见时）调用。要注意的是，这个调用是指从后台（不可见）切换为前台时调用一次，并不是指activity在前台就一直循环调用，我以前是误解了，后面在实践中发现的。onResume这个方法是比较实用的，很多情况下都会在里面重写一些逻辑，重新调起一些服务，或者发起一些请求以刷新数据。
onPause与onStop往往是成对出现的，都是在activity切换到后台时调用。但也有区别，onPause是在activity失去焦点时也会调用，例如在一个activity上再弹出一个activity的弹窗，这是虽然能够见到底层的activity，但是它失去了焦点，变成了非活动状态，调用了onPause。在onPause里，我们通常会用来提交一些还没来得及保存的数据，停止动画和一些会消耗cup的东西，如果里面的工作是比较耗时的，会影响到下一个activity的出现。
onStop是要在activity位于后台，即activity不可见时调用。在onStop方法里，我们往往需要进行一些资源的回收和销毁的工作。
onDestroy方法在activity的生命周期里的调用时机不是十分确定，如果系统资源充足，activity往往不会马上销毁与回收资源，即不会马上调用onDestroy方法，就会造成系统资源的占用，从而导致内存的溢出，甚至是泄漏，使app崩溃闪退。这就是建议资源回收和销毁在onstop方法里执行的原因。
activity生命周期在切换横竖屏会有一些有趣的变化：
a.不设置activity的android：configChanges时，切换横屏，activity的生命周期会重新调用一次，但是切换竖屏时，生命周期会重新调用两次。
b.当设置activity的android：configChanges=“orientation”时，切换横竖屏都会重新调用各生命周期一次。
c.当设置activity的android：configChanges=“orientation|keyboardHidden”(大于api13时，需要设为“orientation|screenSize”)时，切换横竖屏不会重新调用各生命周期，只会调用onConfigurationChanged方法。
因此在项目中，当需要切换横竖屏时，一般我们会将activty设置为2或者3
2.activity的四种启动模式
standard模式：每次启动从新创建activity实例，默认方式。
singleTop模式：如果该activity位于栈顶，启动时，重新使用该实例；如果不在栈顶，重新创建一个实例，放在栈顶。
singleTask模式：在同一个任务栈中，如果该activity位于栈顶，启动时，重新使用该实例；如果不在栈顶，将位于该activity栈上方的activity全部出栈，以便让该activity位于栈顶；如果整个栈都没有该实例，新创建一个栈，位于栈顶。
singleInstance模式：与singleTask模式类似，但是系统全局只用、共用一个实例，并且是位于一个独立的栈中，栈中也只有该activity实例。
通常我们会将主activity设为singleInstance模式，有时候也会将一些activity设为singleTask模式。
3.关于Fragment
fragment是一种依附于activity，又相对独立的控件，作用基本与activity一致，是为了解决大屏幕配适而出现的控件，也能在一定程度上提高应用的性能。
生命周期
activity与fragment生命周期
一般，fragment的生命周期关注onCreate、onStart、onResume、onPause、onStop这几个就够了，可以与activity类比。还用一个onActivityCreated方法有时候也会使用。要注意的是不要在依附的activity创建前，在onCreate里调用activity的ui或者其他相关的东西，但是可以在onActivityCreated里调用。
activity与fragment之间还有一套通信机制，但是坑比较多，容易出问题，而且有些是源码的bug，出问题不容易修复，因此现在大多数人都是用eventbus来进行activity与fragment之间的通信，也强烈建议使用此种方式实现。
2.Service
由于android5.0之后，权限管理变得严厉，后台的进程也不能再像以前那么流氓，大多都会被杀死，因此service也用得少了，基本上是使用一些异步线程，建一个任务，或者定时器来完成一些服务，在activity销毁之前选取适当的时机回收掉资源。
但是有时候，还是会使用到service的，比如一些音乐或者视频的进程，或者真有某些想要常驻的重要服务。
生命周期：onCreate，onStartCommand，onDestroy比较简单，一般我们在onStartCommand里重写我们的服务逻辑。
service跟activity一样需要先在AndroidManifest.xml文件中注册，使用context的startService（Intent intent）或者bindService启动服务，值得注意的是无论调用多少次startService，都只会创建一个服务实例。stopSelf，当服务完成所有工作之后，停止该服务，而stopService是会立即停止服务。
有一种特殊的服务intentService，适合进行短时间的服务，只需覆写onHandleIntent，在此方法中执行耗时操作即可，任务执行完时会自行销毁，很方便。
3.broadcast
广播的注册有两种方式，在AndroidManifest中静态注册和在代码中动态注册，但是android8.0和一些国内的订制的rom系统，出于电量的考虑，会偏向于让静态注册的广播失效，因此建议广播的注册使用动态注册。
广播有几种类型：普通广播、有序广播、粘性广播、本地广播。一般出于应用的安全性考虑，项目中建议使用本地广播。
4.contentProvider
这个在通信录一类的软件可能会用得比较多，对于android的组件化建设有一定帮助。目前基本没怎么接触，就有时候通过系统的uri获取一些通信录什么的。
网友评论