摘要：詳細(xì)崩潰日志信息查看崩潰類信息當(dāng)調(diào)用或其變體之一失敗時，會引發(fā)此異常，因為無法找到執(zhí)行給定意圖的活動。引發(fā)崩潰日志的流程分析問題所在是方法。

1.1 OnErrorNotImplementedException【 Can"t create handler inside thread that has not called Looper.prepare()】

1.2 adb.exe,start-server" failed -- run manually if necessary

1.3 java.lang.IllegalStateException: ExpectedBEGIN_OBJECT but was STRING at line 1 column 1 path $

1.4 android.content.ActivityNotFoundException: No Activity found to handle Intent

1.5 Package manager has died導(dǎo)致崩潰

1.6 IllegalArgumentException View添加窗口錯誤

1.7 IllegalStateException: Not allowed to start service Intent異常崩潰

1.8 java.lang.IllegalStateException：Can not perform this action after onSaveInstanceState

1.9 在Fragment中通過getActivity找不到上下文，報null導(dǎo)致空指針異常

博客筆記大匯總【16年3月到至今】，包括Java基礎(chǔ)及深入知識點，Android技術(shù)博客，Python學(xué)習(xí)筆記等等，還包括平時開發(fā)中遇到的bug匯總，當(dāng)然也在工作之余收集了大量的面試題，長期更新維護并且修正，持續(xù)完善……開源的文件是markdown格式的！同時也開源了生活博客，從12年起，積累共計47篇[近20萬字]，轉(zhuǎn)載請注明出處，謝謝！

鏈接地址：https://github.com/yangchong2...

如果覺得好，可以star一下，謝謝！當(dāng)然也歡迎提出建議，萬事起于忽微，量變引起質(zhì)變！

A.詳細(xì)崩潰日志信息

Can"t create handler inside thread that has not called Looper.prepare()

B.查看崩潰類信息

C.項目中異常分析

D.引發(fā)崩潰日志的流程分析

這是因為Handler對象與其調(diào)用者在同一線程中，如果在Handler中設(shè)置了延時操作，則調(diào)用線程也會堵塞。每個Handler對象都會綁定一個Looper對象，每個Looper對象對應(yīng)一個消息隊列（MessageQueue）。如果在創(chuàng)建Handler時不指定與其綁定的Looper對象，系統(tǒng)默認(rèn)會將當(dāng)前線程的Looper綁定到該Handler上。

在主線程中，可以直接使用new Handler()創(chuàng)建Handler對象，其將自動與主線程的Looper對象綁定；在非主線程中直接這樣創(chuàng)建Handler則會報錯，因為Android系統(tǒng)默認(rèn)情況下非主線程中沒有開啟Looper，而Handler對象必須綁定Looper對象。

如果在主線程中創(chuàng)建handler時，系統(tǒng)會自動創(chuàng)建Looper,但是在子線程中創(chuàng)建handler時，是不會自動創(chuàng)建Looper的，此時如果不手動創(chuàng)建Looper，系統(tǒng)就會崩潰

F.解決辦法

不要在子線程中做UI操作，比如更改界面，吐司等等……

方法1：需先在該線程中手動開啟Looper（Looper.prepare()-->Looper.loop()），然后將其綁定到Handler對象上；

final Runnable runnable = new Runnable() {
　　@Override
　　public void run() {
　　　　//執(zhí)行耗時操作
　　　　try {

　　　　　　Log.e("bm", "runnable線程： " + Thread.currentThread().getId()+ " name:" + Thread.currentThread().getName());

　　　　　　Thread.sleep(2000);
　　　　　　Log.e("bm", "執(zhí)行完耗時操作了~");
　　　　} catch (InterruptedException e) {
　　　　e.printStackTrace();
　　　　}
　　}
};
new Thread() {
　　public void run() {
　　　　Looper.prepare();
　　　　new Handler().post(runnable);//在子線程中直接去new 一個handler
　　　　Looper.loop();　　　　//這種情況下，Runnable對象是運行在子線程中的，可以進(jìn)行聯(lián)網(wǎng)操作，但是不能更新UI
　　}
}.start();

方法2：通過Looper.getMainLooper()，獲得主線程的Looper，將其綁定到此Handler對象上。

final Runnable runnable = new Runnable() {
　　@Override
　　public void run() {
　　　　//執(zhí)行耗時操作
　　　　try {
　　　　　　Log.e("bm", "runnable線程： " + Thread.currentThread().getId()+ " name:" + Thread.currentThread().getName());
　　　　　　Thread.sleep(2000);
　　　　　　Log.e("bm", "執(zhí)行完耗時操作了~");
　　　　} catch (InterruptedException e) {
　　　　e.printStackTrace();
　　　　}
　　}
};
new Thread() {
　　public void run() {
　　    //在子線程中直接去new 一個handler
　　　　new Handler(Looper.getMainLooper()).post(runnable);
　　　　//這種情況下，Runnable對象是運行在主線程中的，不可以進(jìn)行聯(lián)網(wǎng)操作，但是可以更新UI
　　}
}.start();

G.其他延申

A.詳細(xì)崩潰日志信息

B.查看崩潰類信息

C.項目中異常分析

adb啟動失敗，端口被占用

D.引發(fā)崩潰日志的流程分析

F.解決辦法

百度google大家多說的是任務(wù)管理器 kill掉adb 或者重啟adb server，但我任務(wù)管理器就沒有adb ,猜測是某個程序占用了adb端口。于是按此思路查找。
5037為adb默認(rèn)端口 查看該端口情況如下：
netstat -aon|findstr "5037"
TCP 127.0.0.1:5037 0.0.0.0:0 LISTENING 6540
發(fā)現(xiàn)6540占用了 5037端口，繼續(xù)查看6540的task，發(fā)現(xiàn)是wandoujia .如下所示
tasklist|findstr "6540"
wandoujia_daemon.exe 6540 Console 1 4,276 K

接下來問題就好解決了，在任務(wù)管理器kill掉wandoujia_daemon.exe ，運行android程序，ok .

1.關(guān)閉xx莢進(jìn)程
2.adb kill-server
3.adb start-server

G.其他延申

A.詳細(xì)崩潰日志信息

非法參數(shù)，開始讀取時應(yīng)該是{}括號，所以需要處理String字符串，它有可能不是標(biāo)準(zhǔn)的json數(shù)據(jù)

java.lang.IllegalStateException: ExpectedBEGIN_OBJECT but was STRING at line 1 column 1 path $

B.查看崩潰類信息

C.項目中異常分析

Gson解析數(shù)據(jù)出現(xiàn)問題，原因服務(wù)器返回數(shù)據(jù)不嚴(yán)謹(jǐn)

D.引發(fā)崩潰日志的流程分析

可能的錯誤：

bean類字段類型和字段名稱不一致。

服務(wù)器訪問得到的字符串不是純json前面有空格和回車等字符（難發(fā)現(xiàn)）。

如果訪問的json字符串不是utf-8編碼時，用Gson解析會出這種問題，在日志中打印會發(fā)現(xiàn)json的{}前面有亂碼字符，也需要注意一下。這是因為不同的編碼的原因?qū)е碌模虼吮仨氃L問utf-8的json字符串，才會減少這種問題。

問題可能是：字符串并不是純json字符串，開頭可能會帶有空字符或者回車符，這屬于服務(wù)器問題，但我們也可以解決。

最重要原因的我們網(wǎng)絡(luò)請求后結(jié)果是字符串，而不是json，因此需要處理。

F.解決辦法

/**

*/
public static boolean isJson(String value) {
    try {
        new JSONObject(value);
    } catch (JSONException e) {
        return false;
    }
    return true;
}

/**
* 判斷是否是json結(jié)構(gòu)
*/
public static boolean isGoodJson(String json) {
    try {
        new JsonParser().parse(json);
        return true;
    } catch (JsonParseException e) {
        System.out.println("bad json: " + json);
        return false;
    }
}
```

G.其他延申，補充說明

解決辦法：后臺輸出穩(wěn)定的Gson格式。此方法工程量太大

真正的問題是我的數(shù)據(jù)結(jié)構(gòu)有問題

例如下面Json字符串：

{"code":1,"info":"success","results":{"id":"1","name":"hehe"}}

results對應(yīng)的應(yīng)該是一個實體類，如果這個時候想把他解析為String或者List就會出現(xiàn)異常

如果參考使用GsonForm處理后的數(shù)據(jù)模型，幾乎不會出現(xiàn)問題；加入result后面的內(nèi)容可能在請求時會因為某些原因會存在格式上的變化，這個時候就有出現(xiàn)該異常的風(fēng)險。Gson中，關(guān)鍵字后面出現(xiàn)""引起來的內(nèi)容將會被只認(rèn)為是STRING，“{}”只被認(rèn)為是類，“[]”只被認(rèn)為是List，這個幾乎是強制性的。

就是說如果你的實體預(yù)計是獲取String的變量，但是關(guān)鍵字后面對應(yīng)的卻出現(xiàn)了“{”或“[”，那么這個轉(zhuǎn)換將被認(rèn)為是錯誤的，拋出異常。

A.詳細(xì)崩潰日志信息

android.content.ActivityNotFoundException: No Activity found to handle Intent

B.查看崩潰類信息

當(dāng)調(diào)用{@link Context#startActivity}或其變體之一失敗時，會引發(fā)此異常，因為無法找到執(zhí)行給定意圖的活動。

public class ActivityNotFoundException extends RuntimeException
{
    public ActivityNotFoundException()
    {
    }

    public ActivityNotFoundException(String name)
    {
        super(name);
    }
};

C.項目中異常分析

D.引發(fā)崩潰日志的流程分析

F.解決辦法

第一種辦法：做一個try catch

Intent intent = new Intent(Intent.ACTION_SENDTO,url);
try {
    context.startActivity(intent);
} catch(ActivityNotFoundException exception) {
    Toast.makeText(this, "no activity", Toast.LENGTH_SHORT).show();
}

第二種辦法：判斷是否有應(yīng)用寶客戶端

//避免安裝了應(yīng)用寶的用戶點擊其他外部鏈接走此方法導(dǎo)致崩潰
//判斷是否用應(yīng)用寶客戶端
if(AppUtils.isPkgInstalled(AdDetailActivity.this,"com.tencent.android.qqdownloader")){
    Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url));
    startActivity( intent);
}

A.詳細(xì)崩潰日志信息

出錯代碼位置
public static String softVersionName(Context context) {
    PackageInfo info = null;
    try {
        info = context.getPackageManager().getPackageInfo( context.getPackageName(), 0);     //在這里
    } catch (NameNotFoundException e) {
        e.printStackTrace();
    }
    return info.versionName;
}

B.查看崩潰類信息

C.項目中異常分析

D.引發(fā)崩潰日志的流程分析

原因分析(Binder造成)

如果一個進(jìn)程中使用的Binder內(nèi)容超過了1M，就會crash.

如果Binder的使用超出了一個進(jìn)程的限制就會拋出TransactionTooLargeException這個異常。

如果是其他原因造成Binder crash的話就會拋出RuntimeException。

F.解決辦法

public static String softVersionName(Context context) {
    PackageInfo info = null;
    try {//增加同步塊
        synchronized (context) {
            info =context.getPackageManager().getPackageInfo(context.getPackageName(), 0);
        }
        return info.versionName;
    } catch (Exception e) {
        e.printStackTrace();
        return "";
    }
}

G.其他延申

private void test() {
        //這個Demo就是同時創(chuàng)建兩個線程來進(jìn)行Binder調(diào)用.
        for (int i = 0; i < 2; i++) {
            new Thread() {
                @Override
                public void run() {
                    int count = 0;
                    List list = getPackageManager().getInstalledPackages(0);
                    for (PackageInfo info : list) {
                        if(count >=1000){
                            break;
                        }
                        try {
                            PackageInfo pi = getPackageManager().getPackageInfo(info.packageName, PackageManager.GET_ACTIVITIES);
                        } catch (PackageManager.NameNotFoundException e) {

                        }
                    }
                }
            }.start();
        }
    }
}

錯誤打印日志

解決方式：其實只要避免多個線程同時來調(diào)用Binder就可以了，畢竟一個線程用了會釋放，所以理論上是很難發(fā)生的。

synchronized(MainActivity.class){ 
    PackageInfo pi = getPackageManager() .getPackageInfo(info.packageName, PackageManager.GET_ACTIVITIES); 
} 

A.詳細(xì)崩潰日志信息

View=com.android.internal.policy.impl.PhoneWindow$DecorView{22a4fb16 V.E..... R.....ID 0,0-1080,1020} not attached to window manager
com.flyco.dialog.widget.base.BaseDialog.superDismiss(BaseDialog.java)

B.查看崩潰類信息

C.項目中異常分析

該異常表示view沒有添加到窗口管理器，通常是我們dismiss對話框的時候，activity已經(jīng)不存在了，建議不要在非UI線程操作對話框。

D.引發(fā)崩潰日志的流程分析

常發(fā)生這類Exception的情形都是，有一個費時的線程操作，需要顯示一個Dialog，在任務(wù)開始的時候顯示一個對話框，然后當(dāng)任務(wù)完成了在Dismiss對話框，如果在此期間如果Activity因為某種原因被殺掉且又重新啟動了，那么當(dāng)dialog調(diào)用dismiss的時候WindowManager檢查發(fā)現(xiàn)Dialog所屬的Activity已經(jīng)不存在，所以會報錯。要避免此類Exception，就要正確的使用對話框，也要正確的使用線程

F.解決辦法

可以參考崩潰bug日志總結(jié)1中的1.7

G.其他延申，建議

不要在非UI線程中使用對話框創(chuàng)建，顯示和取消對話框；

盡量少用多帶帶線程，出發(fā)是真正的耗時操作采用線程，線程也不要直接用Java式的匿名線程，除非是那種單純的操作，操作完成不需要做其他事情的。

如果是在fragment中發(fā)起異步網(wǎng)絡(luò)的回調(diào)中進(jìn)行dialog的操作，那么在操作之前，需要判斷 isAdd( )，避免fragment被回收了但是還要求dialog去dismiss

在Activity onDestroy中對Dialog提前進(jìn)行關(guān)閉

A.詳細(xì)崩潰日志信息

 Caused by: java.lang.IllegalStateException: Not allowed to start service Intent { act=initApplication cmp=com.paidian.hwmc/.service.InitializeService }: app is in background uid UidRecord{a37d28d u0a386 TRNB bg:+5m30s482ms idle procs:3 seq(0,0,0)}

B.查看崩潰類信息

C.項目中異常分析

D.引發(fā)崩潰日志的流程分析

F.解決辦法

G.其他延申

A.詳細(xì)崩潰日志信息

B.查看崩潰類信息

C.項目中異常分析

通過下面的源碼分析，我們可以知道，出現(xiàn)以上崩潰日志的原因，是因為我們在按下頁面返回鍵的時候，當(dāng)前Activity以及在執(zhí)行銷毀操作（也就是說我們以前在其他地方調(diào)用了finish方法）。

D.引發(fā)崩潰日志的流程分析

問題所在是Activity#onBackPressed()方法。查看源代碼：點擊onBackPressed方法中的super

在FragmentActivity中

@Override
public void onBackPressed() {
    if (!mFragments.getSupportFragmentManager().popBackStackImmediate()) {
        super.onBackPressed();
    }
}

接著再次點擊super，在Activity中

public void onBackPressed() {
    if (mActionBar != null && mActionBar.collapseActionView()) {
        return;
    }

    if (!mFragments.getFragmentManager().popBackStackImmediate()) {
        finishAfterTransition();
    }
}
public void finishAfterTransition() {
    if (!mActivityTransitionState.startExitBackTransition(this)) {
        finish();
    }
}

我們看到onBackPressed()方法執(zhí)行了兩個操作，第一個是獲取當(dāng)前的FragmentManager，并且執(zhí)行退棧操作，第二個是在退棧完成之后，執(zhí)行finish方法。繼續(xù)查看源碼，關(guān)鍵是FragmentManager實現(xiàn)類的popBackStackImmediate方法

@Override
public boolean popBackStackImmediate() {
    checkStateLoss();
    executePendingTransactions();
    return popBackStackState(mHost.getHandler(), null, -1, 0);
}

我們看到，在執(zhí)行退棧動作之前，這里還有一步檢查操作

private void checkStateLoss() {
    if (mStateSaved) {
        throw new IllegalStateException(
                "Can not perform this action after onSaveInstanceState");
    }
    if (mNoTransactionsBecause != null) {
        throw new IllegalStateException(
                "Can not perform this action inside of " + mNoTransactionsBecause);
    }
}

從這里，我們終于找到了崩潰日志上的異常文案：Can not perform this action after onSaveInstanceState

F.解決辦法

方案1，在調(diào)用super.onBackPressed的時候，我們需要判斷當(dāng)前Activity是否正在執(zhí)行銷毀操作。

if (!isFinishing()) {
    super.onBackPressed();
}

方案2，通過上面的源碼分析，我們也知道了，super.onBackPressed最后也是調(diào)用finish()方法，因此我們可以重寫onBackPressed，直接調(diào)用finish方法。

G.其他延申

A.詳細(xì)崩潰日志信息

B.查看崩潰類信息

C.項目中異常分析

使用ViewPager+Fragment進(jìn)行視圖滑動，在某些部分邏輯也許我們需要利用上下文Context（例如基本的Toast），但是由于Fragment只是衣服在Activity容器的一個試圖，如果需要拿到當(dāng)前的Activity的上下文Context就必須通過getActivity()獲取。

遇過出現(xiàn)getActivity()出現(xiàn)null的時候?qū)е鲁绦驁蟪隹罩羔槷惓！Ｆ鋵嵲蚩梢詺w結(jié)于因為我們在

切換fragment的時候，會頻繁被crash

系統(tǒng)內(nèi)存不足

橫豎屏幕切換的時候

以上情況都會導(dǎo)致Activity被系統(tǒng)回收，但是由于fragment的生命周期不會隨著Actiivty被回收而被回收，因此才會導(dǎo)致getActivity()出現(xiàn)null的問題。

很多人都曾被這個問題所困擾，如果app長時間在后臺運行，再次進(jìn)入app的時候可能會出現(xiàn)crash，而且fragment會有重疊現(xiàn)象。如果系統(tǒng)內(nèi)存不足、切換橫豎屏、app長時間在后臺運行，Activity都可能會被系統(tǒng)回收然后重建，但Fragment并不會隨著Activity的回收而被回收，創(chuàng)建的所有Fragment會被保存到Bundle里面，從而導(dǎo)致Fragment丟失對應(yīng)的Activity。

D.引發(fā)崩潰日志的流程分析

當(dāng)遇到getActivity()為null，或getContext()時，先冷靜想想以下3點：

1.是不是放在了第三方的回調(diào)中

2.是不是在其他進(jìn)程中調(diào)用了（其實第一點就是在其他進(jìn)程中調(diào)用了）

3.是不是調(diào)用時不在指定生命周期范圍內(nèi)（onAttach與onDetach之間）

F.解決辦法

在Fragment中直接調(diào)用
private MActivity mActivity; 
@Override 
public void onAttach(Activity activity) { 
    super.onAttach(activity); 
    mActivity = (MActivity) activity; 
}
@Override
public void onDetach() {
    super.onDetach();
    mActivity = null;
}

G.其他延申

源碼解讀：在FragmentActivity中

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    Parcelable p = mFragments.saveAllState();
    if (p != null) {
        outState.putParcelable(FRAGMENTS_TAG, p);
    }
    ……
}

如果從最近使用的應(yīng)用里面點擊我們的應(yīng)用，系統(tǒng)會恢復(fù)之前被回收的Activity，這個時候FragmentActivity在oncreate里面也會做Fragment的恢復(fù)

@SuppressWarnings("deprecation")
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    mFragments.attachHost(null /*parent*/);
    super.onCreate(savedInstanceState);
    NonConfigurationInstances nc = (NonConfigurationInstances) getLastNonConfigurationInstance();
    if (nc != null) {
        mFragments.restoreLoaderNonConfig(nc.loaders);
    }
    if (savedInstanceState != null) {
        Parcelable p = savedInstanceState.getParcelable(FRAGMENTS_TAG);
        mFragments.restoreAllState(p, nc != null ? nc.fragments : null);
  ……
    }
    if (mPendingFragmentActivityResults == null) {
        mPendingFragmentActivityResults = new SparseArrayCompat<>();
        mNextCandidateRequestIndex = 0;
    }
    mFragments.dispatchCreate();
}

假設(shè)我們的頁面叫MyActivity（繼承自FragmentActivity），其中用到的Fragment叫MyFragment。出現(xiàn)上面這種情況時，app發(fā)生的變化如下：

1、在前面提到的幾種情況下系統(tǒng)回收了MyActivity

2、通過onSaveInstanceState保存MyFragment的狀態(tài)

3、用戶再次點擊進(jìn)入app

4、由于MyActivity被回收，系統(tǒng)會重啟MyActivity，根據(jù)之前保存的MyFragment的狀態(tài)恢復(fù)fragment

5、MyActivity的代碼邏輯中，會再次創(chuàng)建新的MyFragment

6、頁面出現(xiàn)混亂，覆蓋了兩層的fragment。假如恢復(fù)的MyFragment使用到了getActivity()方法，會報空指針異常

對于上面的問題，可以考慮下面這兩種解決辦法：

1、不保存fragment的狀態(tài)：在MyActivity中重寫onSaveInstanceState方法，將super.onSaveInstanceState(outState);注釋掉，讓其不再保存Fragment的狀態(tài)，達(dá)到fragment隨MyActivity一起銷毀的目的。

2、重建時清除已經(jīng)保存的fragment的狀態(tài)：在恢復(fù)Fragment之前把Bundle里面的fragment狀態(tài)數(shù)據(jù)給清除。方法如下：

if(savedInstanceState!= null){
    String FRAGMENTS_TAG =  "Android:support:fragments";
    savedInstanceState.remove(FRAGMENTS_TAG);
}

1.技術(shù)博客匯總

2.開源項目匯總

3.生活博客匯總

4.喜馬拉雅音頻匯總

5.其他匯總

我的個人站點：www.yczbj.org，www.ycbjie.cn

github：https://github.com/yangchong211

知乎：https://www.zhihu.com/people/...

簡書：http://www.jianshu.com/u/b7b2...

csdn：http://my.csdn.net/m0_37700275

喜馬拉雅聽書：http://www.ximalaya.com/zhubo...

開源中國：https://my.oschina.net/zbj161...

泡在網(wǎng)上的日子：http://www.jcodecraeer.com/me...

郵箱：yangchong211@163.com

阿里云博客：https://yq.aliyun.com/users/a... 239.headeruserinfo.3.dT4bcV

segmentfault頭條：https://segmentfault.com/u/xi...