崩潰bug日志總結(jié)3

import. 發(fā)布于2019-08-16 13:29 / 3219人閱讀

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

目錄介紹

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添加窗口錯(cuò)誤

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

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

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

好消息

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

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

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

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

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

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

B.查看崩潰類信息

C.項(xiàng)目中異常分析

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

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

在主線程中，可以直接使用new Handler()創(chuàng)建Handler對(duì)象，其將自動(dòng)與主線程的Looper對(duì)象綁定；在非主線程中直接這樣創(chuàng)建Handler則會(huì)報(bào)錯(cuò)，因?yàn)锳ndroid系統(tǒng)默認(rèn)情況下非主線程中沒(méi)有開(kāi)啟Looper，而Handler對(duì)象必須綁定Looper對(duì)象。

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

F.解決辦法

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

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

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

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

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

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

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

G.其他延申

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

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

B.查看崩潰類信息

C.項(xiàng)目中異常分析

adb啟動(dòng)失敗，端口被占用

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

F.解決辦法

百度google大家多說(shuō)的是任務(wù)管理器 kill掉adb 或者重啟adb server，但我任務(wù)管理器就沒(méi)有adb ,猜測(cè)是某個(gè)程序占用了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

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

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

G.其他延申

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

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

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

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

B.查看崩潰類信息

C.項(xiàng)目中異常分析

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

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

可能的錯(cuò)誤：

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

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

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

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

最重要原因的我們網(wǎng)絡(luò)請(qǐng)求后結(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.其他延申，補(bǔ)充說(shuō)明

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

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

例如下面Json字符串：

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

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

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

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

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

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

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

B.查看崩潰類信息

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

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

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

C.項(xiàng)目中異常分析

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

F.解決辦法

第一種辦法：做一個(gè)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)用寶的用戶點(diǎn)擊其他外部鏈接走此方法導(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);
}

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

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

出錯(cuò)代碼位置
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.項(xiàng)目中異常分析

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

原因分析(Binder造成)

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

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

如果是其他原因造成Binder crash的話就會(huì)拋出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() {
        //這個(gè)Demo就是同時(shí)創(chuàng)建兩個(gè)線程來(lái)進(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();
        }
    }
}

錯(cuò)誤打印日志

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

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

1.6 IllegalArgumentException View添加窗口錯(cuò)誤

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.項(xiàng)目中異常分析

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

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

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

F.解決辦法

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

G.其他延申，建議

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

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

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

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

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

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.項(xiàng)目中異常分析

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

F.解決辦法

G.其他延申

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

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

B.查看崩潰類信息

C.項(xiàng)目中異常分析

通過(guò)下面的源碼分析，我們可以知道，出現(xiàn)以上崩潰日志的原因，是因?yàn)槲覀冊(cè)诎聪马?yè)面返回鍵的時(shí)候，當(dāng)前Activity以及在執(zhí)行銷毀操作（也就是說(shuō)我們以前在其他地方調(diào)用了finish方法）。

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

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

在FragmentActivity中

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

接著再次點(diǎn)擊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í)行了兩個(gè)操作，第一個(gè)是獲取當(dāng)前的FragmentManager，并且執(zhí)行退棧操作，第二個(gè)是在退棧完成之后，執(zhí)行finish方法。繼續(xù)查看源碼，關(guān)鍵是FragmentManager實(shí)現(xiàn)類的popBackStackImmediate方法

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

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

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的時(shí)候，我們需要判斷當(dāng)前Activity是否正在執(zhí)行銷毀操作。

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

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

G.其他延申

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

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

B.查看崩潰類信息

C.項(xiàng)目中異常分析

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

遇過(guò)出現(xiàn)getActivity()出現(xiàn)null的時(shí)候?qū)е鲁绦驁?bào)出空指針異常。其實(shí)原因可以歸結(jié)于因?yàn)槲覀冊(cè)?/p>

切換fragment的時(shí)候，會(huì)頻繁被crash

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

橫豎屏幕切換的時(shí)候

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

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

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

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

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

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

3.是不是調(diào)用時(shí)不在指定生命周期范圍內(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)用里面點(diǎn)擊我們的應(yīng)用，系統(tǒng)會(huì)恢復(fù)之前被回收的Activity，這個(gè)時(shí)候FragmentActivity在oncreate里面也會(huì)做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è)我們的頁(yè)面叫MyActivity（繼承自FragmentActivity），其中用到的Fragment叫MyFragment。出現(xiàn)上面這種情況時(shí)，app發(fā)生的變化如下：

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

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

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

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

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

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

對(duì)于上面的問(wèn)題，可以考慮下面這兩種解決辦法：

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

2、重建時(shí)清除已經(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);
}

關(guān)于其他內(nèi)容介紹 01.關(guān)于博客匯總鏈接

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

2.開(kāi)源項(xiàng)目匯總

3.生活博客匯總

4.喜馬拉雅音頻匯總

5.其他匯總

02.關(guān)于我的博客

我的個(gè)人站點(diǎn)：www.yczbj.org，www.ycbjie.cn

github：https://github.com/yangchong211

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

簡(jiǎn)書(shū)：http://www.jianshu.com/u/b7b2...

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

喜馬拉雅聽(tīng)書(shū)：http://www.ximalaya.com/zhubo...

開(kāi)源中國(guó)：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...

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/71841.html

發(fā)表評(píng)論

登陸后可評(píng)論

0條評(píng)論

import.

男|高級(jí)講師

我要關(guān)注我要私信

TA的文章

2021 Google Developer Summit 中國(guó)開(kāi)發(fā)者大會(huì)

閱讀 2799·2021-11-17 09:33
網(wǎng)站主機(jī)名是什么-網(wǎng)址的主機(jī)名是什么？

閱讀 4479·2021-09-22 15:57
我對(duì)移動(dòng)端適配的了解

閱讀 2877·2019-08-30 14:16
css進(jìn)階

閱讀 3140·2019-08-29 14:07
如何找到所有 HTML select 標(biāo)簽的選中項(xiàng)

閱讀 2419·2019-08-26 11:55
基于 styled-components 的單位 px -> vw 自動(dòng)轉(zhuǎn)換

閱讀 3431·2019-08-23 17:07
4個(gè)令人震撼的CSS3動(dòng)畫(huà)

閱讀 1731·2019-08-23 16:50
前端數(shù)據(jù)收集（pv/uv）

閱讀 2543·2019-08-23 16:08

国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

上云采購(gòu)季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺(tái)、長(zhǎng)期優(yōu)惠，快來(lái)選購(gòu)！

崩潰bug日志總結(jié)3

相關(guān)文章

**崩潰bug日志總結(jié)1**

**崩潰bug日志總結(jié)2**

Android實(shí)際開(kāi)發(fā)bug大總結(jié)

發(fā)表評(píng)論

0條評(píng)論

import.

男|高級(jí)講師

TA的文章

2021 Google Developer Summit 中國(guó)開(kāi)發(fā)者大會(huì)

網(wǎng)站主機(jī)名是什么-網(wǎng)址的主機(jī)名是什么？

我對(duì)移動(dòng)端適配的了解

css進(jìn)階

如何找到所有 HTML select 標(biāo)簽的選中項(xiàng)

基于 styled-components 的單位 px -> vw 自動(dòng)轉(zhuǎn)換

4個(gè)令人震撼的CSS3動(dòng)畫(huà)

前端數(shù)據(jù)收集（pv/uv）

最新活動(dòng)