目錄介紹

• 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/yangchong211/YCBlogs
• 如果覺得好，可以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-tools\adb.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.解決辦法

  /**
  * 判斷是否是json結構。這種判斷不是很嚴謹
  */
  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<PackageInfo> 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/yang-chong-69-24/pins/posts
• 簡書：http://www.jianshu.com/u/b7b2c6ed9284
• csdn：http://my.csdn.net/m0_37700275
• 喜馬拉雅聽書：http://www.ximalaya.com/zhubo/71989305/
• 開源中國：https://my.oschina.net/zbj1618/blog
• 泡在網上的日子：http://www.jcodecraeer.com/member/content_list.php?channelid=1
• 郵箱：[email protected]
• 阿裏雲博客：https://yq.aliyun.com/users/article?spm=5176.100- 239.headeruserinfo.3.dT4bcV
• segmentfault頭條：https://segmentfault.com/u/xiangjianyu/articles

崩潰bug日誌總結3