android Process.killProcess 和 System.exit(0) 区别
2015-07-01 10:40
447 查看
1 Process.killProcess 和 System.exit(0) 两个都会 kill 掉当前进程。
你可以打开 DDMS 查看进程号,或 adb shell 进入 shell 然后 ps 一下,进程确实被 kill 掉了。
2 如果是在第一个 Activity 调用 Process.killProcess 或 System.exit(0) 都会 kill 掉当前进程。
但是如果不是在第一个 Activity 中调用,如 ActivityA 启动 ActivityB ,你在 ActivityB 中调用
Process.killProcess 或 System.exit(0) 当前进程确实也被 kill 掉了,但 app 会重新启动,
又创建了一个新的进程。(这是我同事发现的)
这点还不是很明白,我估计 android os 认为 app 是被意外终止的(如内存不足),os 底层有监听服务,
app 被意外终止会自动重启。
3 在测试极光推送的时候,发现退出 app 后就收不到推送了。后来发现是调用了 System.exit(0) 的原因。
首先 service 也是在进程中的,在主线程中,所以 service 中如果有耗时操作也要开启另外的线程来处理。
当调用 System.exit(0) 或 Process.killProcess 的时候进程被 kill 掉了,进程里的所有东西当然包括 service 肯定
也没了。由于极光推送 pushservice 被 kill 掉了,所以退出 app 后就收不到推送了。
4 还没完,戏剧性的事情发生了,刚退出 app 由于 kill 掉了进程,服务没了,所以收不到推送。但是过了大约1分钟左右居然又能推过来了。
原来是和 service 的 onStartCommand 的返回值有关
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
Log.i(“lelsie”, “service onStartCommand”);
return START_STICKY;
//return START_NOT_STICKY;
}
如果返回 START_STICKY 是说服务应该一直运行除非我们手动停止它。极光 pushservice 返回的肯定是 START_STICKY。
所以1分钟之内系统又重启了服务,当然会先为 app 创建一个新的进程,也就是重启了 app, 同样你可以在 DDMM 中查看进程的杀死与新进程的重建。
我在手机上截了 2 张图
![](https://img-blog.csdn.net/20150701103915296)
![](https://img-blog.csdn.net/20150701103940379)
![](https://img-blog.csdn.net/20150701103952571)
第一个图是在调用了 Process.killProcess 或 System.exit(0) 之后的图,可以看到进程已不存在了,服务当然也不在了。显示正在重新启动。
第二个图是服务重启以后的正常状态,所以 1-2分钟后又能接收到推送了。
第三个图是 DDMS 截图
5 其实 Process.killProcess 或 System.exit(0) 都不应该直接调用, 进程是由 os 底层进行管理的,android 系统会自己进行处理回收进程。
退出应用你就直接 finish 掉 activity 就行了。
正常情况下 back 键退出应用以后 os 就会回收 app 进程, 但当 app 中有推送服务等需要长时间运行的服务时 os 就不会 kill 掉进程,也就是说应用将一直在线。 即使你手动 kill 掉进程, 进程也会自动重启。
本人水平有限,有问题大家再多讨论。。。。
你可以打开 DDMS 查看进程号,或 adb shell 进入 shell 然后 ps 一下,进程确实被 kill 掉了。
2 如果是在第一个 Activity 调用 Process.killProcess 或 System.exit(0) 都会 kill 掉当前进程。
但是如果不是在第一个 Activity 中调用,如 ActivityA 启动 ActivityB ,你在 ActivityB 中调用
Process.killProcess 或 System.exit(0) 当前进程确实也被 kill 掉了,但 app 会重新启动,
又创建了一个新的进程。(这是我同事发现的)
这点还不是很明白,我估计 android os 认为 app 是被意外终止的(如内存不足),os 底层有监听服务,
app 被意外终止会自动重启。
3 在测试极光推送的时候,发现退出 app 后就收不到推送了。后来发现是调用了 System.exit(0) 的原因。
首先 service 也是在进程中的,在主线程中,所以 service 中如果有耗时操作也要开启另外的线程来处理。
当调用 System.exit(0) 或 Process.killProcess 的时候进程被 kill 掉了,进程里的所有东西当然包括 service 肯定
也没了。由于极光推送 pushservice 被 kill 掉了,所以退出 app 后就收不到推送了。
4 还没完,戏剧性的事情发生了,刚退出 app 由于 kill 掉了进程,服务没了,所以收不到推送。但是过了大约1分钟左右居然又能推过来了。
原来是和 service 的 onStartCommand 的返回值有关
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
Log.i(“lelsie”, “service onStartCommand”);
return START_STICKY;
//return START_NOT_STICKY;
}
如果返回 START_STICKY 是说服务应该一直运行除非我们手动停止它。极光 pushservice 返回的肯定是 START_STICKY。
所以1分钟之内系统又重启了服务,当然会先为 app 创建一个新的进程,也就是重启了 app, 同样你可以在 DDMM 中查看进程的杀死与新进程的重建。
我在手机上截了 2 张图
第一个图是在调用了 Process.killProcess 或 System.exit(0) 之后的图,可以看到进程已不存在了,服务当然也不在了。显示正在重新启动。
第二个图是服务重启以后的正常状态,所以 1-2分钟后又能接收到推送了。
第三个图是 DDMS 截图
5 其实 Process.killProcess 或 System.exit(0) 都不应该直接调用, 进程是由 os 底层进行管理的,android 系统会自己进行处理回收进程。
退出应用你就直接 finish 掉 activity 就行了。
正常情况下 back 键退出应用以后 os 就会回收 app 进程, 但当 app 中有推送服务等需要长时间运行的服务时 os 就不会 kill 掉进程,也就是说应用将一直在线。 即使你手动 kill 掉进程, 进程也会自动重启。
本人水平有限,有问题大家再多讨论。。。。
相关文章推荐
- 使用C++实现JNI接口需要注意的事项
- Android IPC进程间通讯机制
- Android Manifest 用法
- [转载]Activity中ConfigChanges属性的用法
- Android之获取手机上的图片和视频缩略图thumbnails
- Android之使用Http协议实现文件上传功能
- Android学习笔记(二九):嵌入浏览器
- android string.xml文件中的整型和string型代替
- i-jetty环境搭配与编译
- android之定时器AlarmManager
- android wifi 无线调试
- Android Native 绘图方法
- Android java 与 javascript互访(相互调用)的方法例子
- android 代码实现控件之间的间距
- android FragmentPagerAdapter的“标准”配置
- Android"解决"onTouch和onClick的冲突问题
- android:installLocation简析
- android searchView的关闭事件
- SourceProvider.getJniDirectories