1、null問題
當物件（基本資料型別、定義的Class物件）只宣告未實體化時，其為null.
如：
Date a; //此時給a在堆疊中分配一個空間保存a變數，a為null。
a=new Date(); //此時在堆中開辟Date物件的資料空間，并把該空間的首地址賦值給a。
Date b=a; //b參考a，將a保存的地址賦給b。在單執行緒中，a,b的改變同步。即此時改變b中的資料，a中資料同步改變。
在除錯中，經常拋出null參考問題。
其原因是：當物件為null時，無法執行任何方法，常見的是執行String.clear()、String.add()等。
解決方法：當有null資料需要進行操作時，先進行if陳述句的判斷。
2、Fragment增刪動態更新問題。
當用ViewPage+(FragmentList-FragmentAdapter)時，存在Fragment動態更新問題。造成原因是FragmentPagerAdapter的原始碼當中的instantiateItem()方法，其根據tag查找對應的Fragment, 如果找到，那么就通過當前的Transaction進行attach操作，這個fragment就會顯示了，如果沒有找到，就用getItem()從你的Fragment串列中獲取一個然后Transaction進行add操作。（自己看一下FragmentAdapter的原始碼就知道怎么回事了，很清晰簡單），如果比較懶的話可參考分析：https://blog.csdn.net/lyabc123456/article/details/79797552
網上教程是通過Transaction洗掉fragment，但該方法存在問題或沒有解釋完整。通過除錯發現其洗掉fragment的邏輯如下圖所示，其洗掉了fragment，但該位置仍然存在，Fragment重排序后存在一個空fragment。
如此導致當再增加一個Fragment后，第三個位置將直接attach一個空Fragment。新增的Fragment無效。
解決方法：對于洗掉Fragment后有再增加Fragment的需求，再洗掉操作中應直接通過Transaction洗掉所有記憶體中的Fragment，重新實體化FragmentAdapter物件重繪記憶體，可避免空Fragment的存在。
對于Fragment內容更新，則直接獲取FragmentList中的Fragment，利用Handle將其在主執行緒中修改內容即可更新UI。
3、==判斷
在對String進行相等條件判斷是，誤用“==”進行相等判斷出現bug。
問題原因：“==”比教的是兩個非null物件的地址。使用==判斷的情況一般用于基本資料型別及物件為null。對兩個String物件進行判斷時應使用String.equals()方法。equals()方法比較的是兩個物件的內容值。
導致后果：不會出現程式例外，當會導致邏輯錯誤。
解決方法：使用equals()方法比較是否相等。
4、非UI執行緒更改UI組件
UI界面的創建與修改都是在UI執行緒中，界面創建后，各種事件（如點擊事件）的處理方法是在UI執行緒中的，故此時可修改UI組件。但當需要在其他執行緒中修改UI組件的情境中，如新建網路請求執行緒，獲取資料后更新UI組件顯示，此時對UI組件的修改需要通過handle運行在主執行緒中。
在weather模塊中遇到兩處網路請求執行緒中更新UI組件操作，第一是請求城市，用回傳的城市串列資料更新RecycleAdapter，第二處是請求天氣，用回傳的天氣資料更新Fragment。由于部分更新操作未放到UI執行緒中出錯。
解決方法：在主執行緒中創建Handle，用handle.post() 或handle.handleMessage()將在其他執行緒中更新UI組件的操作放到UI執行緒中，handle的兩種使用方法見：https://blog.csdn.net/mountain_hua/article/details/81291677
關于對UI組件的更改包括常見的（1）UI組件內容修改；（2）UI組件的增刪及visible屬性設定；（3）notifydatasetchanged(); 對于像Adapter中list的修改（weather中的recycleAdatper），之后呼叫notifydatasetchanged();都應放到主執行緒中，否則會出錯,實際程序中遇到了網路請求執行緒結束后UI界面有時改變有時不改變，好像是執行緒的時序問題。
總之所有在非UI執行緒中涉及的對UI界面的任何修改都應放到主執行緒中。
5、多執行緒共享資料的同步
<本段僅作為個人專案問題小節，估計只有自己能看懂寫的啥>
<總之有資料共享時，多執行緒條件下務必保持資料“可見性”，這是由于java記憶體機制的原理導致的，具體說明可直接看給出的參考鏈接>
在weather模塊中，為了獲得界面顯示的所有天氣資訊，需要請求多個url，多次更新特定位置上一個Fragment上不同位置的內容，且網路請求的回應速度不同，對界面的更新順序無法保證，為保證代碼的共用性，對Fragment上的不同位置的更新使用同一個更新方法，且使用相同的共享資料型別。如此便在多個執行緒中使用同一個物件WeatherBean,因此必須保證共享資料的可見性。否則會產生錯誤。
問題原因：程式中的資料存盤在主記憶體中，每個執行緒有自己的作業記憶體，當執行緒需要使用共享資料時，會將主記憶體中的資料拷貝至自己的作業記憶體中，之后的操作會使用拷貝的資料，而不會使用主記憶體中的資料。如：
共享資料WeatherBean為：share={tmp=null,air=null};
執行緒1與執行緒2同時獲取share， 兩個執行緒分別讀取share，并且把share存到了各自的作業記憶體中，然后執行緒1獲取了tmp資料為10，賦值給share的tmp，此時執行緒1中share={tmp=10,air=null}，并且把tmp的值寫回到主存中。但是執行緒2中作業記憶體的share={tmp=null,air=null}，當執行緒2獲取了air資料為“晴”，其share={tmp=null,air=“晴”}，執行緒1獲取資料后進行Fragment.update(share)，此時fragment中tmp顯示10，air顯示空，執行緒2獲取資料后進行Fragment.update(share),此時fragment中tmp顯示空，air顯示“晴”，所以導致fragment無法正確更新。
解決方法：使用volatile修飾需要共享的資料，保證資料的“可見性”，關于volatile的用法可見：
https://www.cnblogs.com/kubidemanong/p/9505944.html
https://blog.csdn.net/mccand1234/article/details/91345168
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/62712.html
標籤：Android
下一篇：寵物app開發技術難題