android稳定性程序,Android-稳定性问题

正确使用Context

一般Context造成的内存泄漏，几乎都是当Context销毁的时候，却因为被引用导致销毁失败，而Application的Context对象可以理解为随着进程存在的，所以我们总结出使用Context的正确姿势：

1：当Application的Context能搞定的情况下，并且生命周期长的对象，优先使用Application的Context。

2：不要让生命周期长于Activity的对象持有到Activity的引用。

3：尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。

ANR基本分析定位方法

ANR分析主要是Input、Broadcast、Service三种ANR， 对应的时间主要有以下几种：其中后台时间相对长一些，broadcast可以达到60s，但是前台一般最高10s，后台service是20s。

类型 前台 后台

Input 8s 8s

Forground Broadcast 10s 20s

Background Broadcast 10s 60s

Service 10s 20s

定位问题思路是，首先查看anr的进程，类型，cpu占用，iowait等指标

activity、broadcast、还是service，是前台还是后台。

cpu占用是否过高，iowait是否正常，是否是由于整机问题影响

查看线程调用栈，main主线程是由于什么原因导致的anr， 等锁lock，是否死锁？ 是否binder卡住了？ 是否no focus windows可能是由于进程被杀，搜索是否有window change查看界面切换的影响？wait和notifiy导致的死锁，查看相关代码？其他卡住的地方File、database、sharepreference可以怀疑文件系统等。

引起ANR问题的根本原因，总的来说可以归纳为两类：

• 应用进程自身引起的，例如：

主线程阻塞、挂起、死循环

应用进程的其他线程的CPU占用率高，使得主线程无法抢占到CPU时间片

• 其他进程间接引起的，例如：

当前应用进程进行进程间通信请求其他进程，其他进程的操作长时间没有反馈

其他进程的CPU占用率高，使得当前应用进程无法抢占到CPU时间片

分析ANR问题时，以上述可能的几种原因为线索，通过分析各种日志信息，大多数情况下你就可以很容易找到问题所在了。

http://www.cnblogs.com/zl1991/p/5947157.html

进程被杀

android原声机制被杀

当Android系统认为当时已经没有足够的内存来运行新的进程，需要“LowMemory Killer”关闭一些进程来回收内存，它是在Linux内核中实现的。

ActivityManagerService记录每一个进程的优先级，进程的oom_adj值就代表优先级，oom_adj值越高代表该进程优先级越低。

每一个oom_adj对应一个内存警戒值，当系统的可用内存低于某个警戒值时，就杀掉所有大于该警戒值对应的oom_adj值的进程。

SystemUI recenttask被杀 任务管理器清理进程属于用户手动清理，使用removetask方式清理任务管理器列表

一键清理等被杀。