崩潰bug日志總結3

import. 發布于2019-08-16 13:29 / 3212人閱讀

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

目錄介紹

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導致崩潰

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導致空指針異常

好消息

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

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

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

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

A.詳細崩潰日志信息

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

B.查看崩潰類信息

C.項目中異常分析

D.引發崩潰日志的流程分析

這是因為Handler對象與其調用者在同一線程中，如果在Handler中設置了延時操作，則調用線程也會堵塞。每個Handler對象都會綁定一個Looper對象，每個Looper對象對應一個消息隊列（MessageQueue）。如果在創建Handler時不指定與其綁定的Looper對象，系統默認會將當前線程的Looper綁定到該Handler上。

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

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

F.解決辦法

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

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

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

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

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

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

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

G.其他延申

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

A.詳細崩潰日志信息

B.查看崩潰類信息

C.項目中異常分析

adb啟動失敗，端口被占用

D.引發崩潰日志的流程分析

F.解決辦法

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

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

1.關閉xx莢進程
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.詳細崩潰日志信息

非法參數，開始讀取時應該是{}括號，所以需要處理String字符串，它有可能不是標準的json數據

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

B.查看崩潰類信息

C.項目中異常分析

Gson解析數據出現問題，原因服務器返回數據不嚴謹

D.引發崩潰日志的流程分析

可能的錯誤：

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

服務器訪問得到的字符串不是純json前面有空格和回車等字符（難發現）。

如果訪問的json字符串不是utf-8編碼時，用Gson解析會出這種問題，在日志中打印會發現json的{}前面有亂碼字符，也需要注意一下。這是因為不同的編碼的原因導致的，因此必須訪問utf-8的json字符串，才會減少這種問題。

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

最重要原因的我們網絡請求后結果是字符串，而不是json，因此需要處理。

F.解決辦法

/**

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

/**
* 判斷是否是json結構
*/
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.其他延申，補充說明

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

真正的問題是我的數據結構有問題

例如下面Json字符串：

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

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

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

就是說如果你的實體預計是獲取String的變量，但是關鍵字后面對應的卻出現了“{”或“[”，那么這個轉換將被認為是錯誤的，拋出異常。

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

A.詳細崩潰日志信息

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

B.查看崩潰類信息

當調用{@link Context#startActivity}或其變體之一失敗時，會引發此異常，因為無法找到執行給定意圖的活動。

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

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

C.項目中異常分析

D.引發崩潰日志的流程分析

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();
}

第二種辦法：判斷是否有應用寶客戶端

//避免安裝了應用寶的用戶點擊其他外部鏈接走此方法導致崩潰
//判斷是否用應用寶客戶端
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導致崩潰

A.詳細崩潰日志信息

出錯代碼位置
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.引發崩潰日志的流程分析

原因分析(Binder造成)

如果一個進程中使用的Binder內容超過了1M，就會crash.

如果Binder的使用超出了一個進程的限制就會拋出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就是同時創建兩個線程來進行Binder調用.
        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();
        }
    }
}

錯誤打印日志

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

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

1.6 IllegalArgumentException View添加窗口錯誤

A.詳細崩潰日志信息

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已經不存在了，建議不要在非UI線程操作對話框。

D.引發崩潰日志的流程分析

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

F.解決辦法

可以參考崩潰bug日志總結1中的1.7

G.其他延申，建議

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

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

如果是在fragment中發起異步網絡的回調中進行dialog的操作，那么在操作之前，需要判斷 isAdd( )，避免fragment被回收了但是還要求dialog去dismiss

在Activity onDestroy中對Dialog提前進行關閉

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

A.詳細崩潰日志信息

 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.解決辦法

G.其他延申

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

A.詳細崩潰日志信息

B.查看崩潰類信息

C.項目中異常分析

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

D.引發崩潰日志的流程分析

問題所在是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()方法執行了兩個操作，第一個是獲取當前的FragmentManager，并且執行退棧操作，第二個是在退棧完成之后，執行finish方法。繼續查看源碼，關鍵是FragmentManager實現類的popBackStackImmediate方法

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

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

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，在調用super.onBackPressed的時候，我們需要判斷當前Activity是否正在執行銷毀操作。

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

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

G.其他延申

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

A.詳細崩潰日志信息

B.查看崩潰類信息

C.項目中異常分析

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

遇過出現getActivity()出現null的時候導致程序報出空指針異常。其實原因可以歸結于因為我們在

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

系統內存不足

橫豎屏幕切換的時候

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

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

D.引發崩潰日志的流程分析

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

1.是不是放在了第三方的回調中

2.是不是在其他進程中調用了（其實第一點就是在其他進程中調用了）

3.是不是調用時不在指定生命周期范圍內（onAttach與onDetach之間）

F.解決辦法

在Fragment中直接調用
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);
    }
    ……
}

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

@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();
}

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

1、在前面提到的幾種情況下系統回收了MyActivity

2、通過onSaveInstanceState保存MyFragment的狀態

3、用戶再次點擊進入app

4、由于MyActivity被回收，系統會重啟MyActivity，根據之前保存的MyFragment的狀態恢復fragment

5、MyActivity的代碼邏輯中，會再次創建新的MyFragment

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

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

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

2、重建時清除已經保存的fragment的狀態：在恢復Fragment之前把Bundle里面的fragment狀態數據給清除。方法如下：

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

關于其他內容介紹 01.關于博客匯總鏈接

1.技術博客匯總

2.開源項目匯總

3.生活博客匯總

4.喜馬拉雅音頻匯總

5.其他匯總

02.關于我的博客

我的個人站點：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...

泡在網上的日子：http://www.jcodecraeer.com/me...

郵箱：yangchong211@163.com

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

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

GPU云服務器云服務器 linux 崩潰日志查看服務器崩潰日志崩潰日志上傳到服務器權限崩潰

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/71841.html

崩潰bug日志總結1

摘要：項目中異常分析引發崩潰日志的流程分析解決辦法常見的出現場景狀態異常非法線程操作。引發崩潰日志的流程分析解釋如下所示，釋放與此位圖關聯的本機對象，并清除對像素數據的引用。目錄介紹 1.1 java.lang.UnsatisfiedLinkError找不到so庫異常 1.2 java.lang.IllegalStateException非法狀態異常 1.3 android.conten...

Scott 2019-08-16 13:29 評論0 收藏0
崩潰bug日志總結2

摘要：出現錯誤引發崩潰日志的流程分析這個錯誤是應用的方法總數限制造成的。目錄介紹 1.1 java.lang.ClassNotFoundException類找不到異常 1.2 java.util.concurrent.TimeoutException連接超時崩潰 1.3 java.lang.NumberFormatException格式轉化錯誤 1.4 java.lang.Illegal...

sutaking 2019-08-16 13:29 評論0 收藏0
Android實際開發bug大總結

摘要：換句話說，環境或應用程序沒有處于請求操作的適當狀態。項目中異常分析引發崩潰日志的流程分析解決辦法常見的出現場景狀態異常非法線程操作。導致的方法出來顯示消息位于該消息之后，遲遲沒有執行。這時候，的超時檢測結束，刪除了服務中的記錄。目錄介紹 1.1 java.lang.UnsatisfiedLinkError找不到so庫異常 1.2 java.lang.IllegalStateExce...

peixn 2019-08-19 10:23 評論0 收藏0