正確使用Context

一般Context造成的內(nèi)存泄漏，幾乎都是當(dāng)Context銷毀的時(shí)候，卻因?yàn)楸灰脤?dǎo)致銷毀失敗，而Application的Context對(duì)象可以理解為隨著進(jìn)程存在的，所以我們總結(jié)出使用Context的正確姿勢：
1：當(dāng)Application的Context能搞定的情況下，并且生命周期長的對(duì)象，優(yōu)先使用Application的Context。
2：不要讓生命周期長于Activity的對(duì)象持有到Activity的引用。
3：盡量不要在Activity中使用非靜態(tài)內(nèi)部類，因?yàn)榉庆o態(tài)內(nèi)部類會(huì)隱式持有外部類實(shí)例的引用，如果使用靜態(tài)內(nèi)部類，將外部實(shí)例引用作為弱引用持有。

ANR基本分析定位方法

ANR分析主要是Input、Broadcast、Service三種ANR， 對(duì)應(yīng)的時(shí)間主要有以下幾種：其中后臺(tái)時(shí)間相對(duì)長一些，broadcast可以達(dá)到60s，但是前臺(tái)一般最高10s，后臺(tái)service是20s。
類型 前臺(tái) 后臺(tái)
Input 8s 8s
Forground Broadcast 10s 20s
Background Broadcast 10s 60s
Service 10s 20s

定位問題思路是，首先查看anr的進(jìn)程，類型，cpu占用，iowait等指標(biāo)
activity、broadcast、還是service，是前臺(tái)還是后臺(tái)。
cpu占用是否過高，iowait是否正常，是否是由于整機(jī)問題影響

查看線程調(diào)用棧，main主線程是由于什么原因?qū)е碌腶nr， 等鎖lock，是否死鎖？ 是否binder卡住了？ 是否no focus windows可能是由于進(jìn)程被殺，搜索是否有window change查看界面切換的影響？wait和notifiy導(dǎo)致的死鎖，查看相關(guān)代碼？其他卡住的地方File、database、sharepreference可以懷疑文件系統(tǒng)等。

引起ANR問題的根本原因，總的來說可以歸納為兩類：
? 應(yīng)用進(jìn)程自身引起的，例如：
主線程阻塞、掛起、死循環(huán)
應(yīng)用進(jìn)程的其他線程的CPU占用率高，使得主線程無法搶占到CPU時(shí)間片
? 其他進(jìn)程間接引起的，例如：
當(dāng)前應(yīng)用進(jìn)程進(jìn)行進(jìn)程間通信請(qǐng)求其他進(jìn)程，其他進(jìn)程的操作長時(shí)間沒有反饋
其他進(jìn)程的CPU占用率高，使得當(dāng)前應(yīng)用進(jìn)程無法搶占到CPU時(shí)間片
分析ANR問題時(shí)，以上述可能的幾種原因?yàn)榫€索，通過分析各種日志信息，大多數(shù)情況下你就可以很容易找到問題所在了。
http://www.cnblogs.com/zl1991/p/5947157.html

進(jìn)程被殺

• android原聲機(jī)制被殺
  當(dāng)Android系統(tǒng)認(rèn)為當(dāng)時(shí)已經(jīng)沒有足夠的內(nèi)存來運(yùn)行新的進(jìn)程，需要“LowMemory Killer”關(guān)閉一些進(jìn)程來回收內(nèi)存，它是在Linux內(nèi)核中實(shí)現(xiàn)的。
  ActivityManagerService記錄每一個(gè)進(jìn)程的優(yōu)先級(jí)，進(jìn)程的oom_adj值就代表優(yōu)先級(jí)，oom_adj值越高代表該進(jìn)程優(yōu)先級(jí)越低。
  每一個(gè)oom_adj對(duì)應(yīng)一個(gè)內(nèi)存警戒值，當(dāng)系統(tǒng)的可用內(nèi)存低于某個(gè)警戒值時(shí)，就殺掉所有大于該警戒值對(duì)應(yīng)的oom_adj值的進(jìn)程。
• SystemUI recenttask被殺 任務(wù)管理器清理進(jìn)程屬于用戶手動(dòng)清理，使用removetask方式清理任務(wù)管理器列表
• 一鍵清理等被殺。