findbugs清理總結

findbugs警告26個。主要有以下9類問題。
 
1、Bug: Hard coded reference to an absolute pathname
BUG描述:This code constructs a File object using a hard coded to an absolute pathname(此代碼包含文件對象爲一個絕對路徑名)
 
問題原因:硬編碼指向絕對路徑。
 
File preFile = new File(PREFERENCES_FILE_FULL_PATH);
 
而private static final String PREFERENCES_FILE_FULL_PATH =
 
        "/data/data/com.android.mms/shared_prefs/auto_downLoad.xml";
 
PREFERENCES_FILE_FULL_PATH聲明爲了final型,不可變的。如果後續文件路徑有變更,引用不到了,但路徑又不可更改,就會引入問題。
 
解決方法:去掉final。
 
2、Bug: Pattern: Dead store to local variable
 
BUG描述:This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used. (該指令爲局部變量賦值,但在其後的沒有對她做任何使用。通常,這表明一個錯誤,因爲值從未使用過。)
 
問題原因:鎖屏中提示Dead store to velocityX,分析代碼
 
case MotionEvent.ACTION_POINTER_1_UP語句中定義了局部變量velocityX,並且只在if ((mDirectionFlag && velocityX > 0)||(!mDirectionFlag && velocityX < 0))
 
                    velocityX = -velocityX;中賦值後並未再使用。因此沒有賦值的必要,並且分析代碼不需要該變量,可以去除。
 
解決方法:去掉velocityX變量的定義及賦值。
 
3、BUG: Inconsistent synchronization
BUG描述:The fields of this class appear to be accessed inconsistently with respect to synchronization. (不合理的同步)
 
問題原因:根據描述ConfigLoader文件中mUnlockAppDataMap在46%的時間內都是處於被鎖狀態。分析代碼mUnlockAppDataMap是在checkUnlockAppConfigChange這個函數中被鎖的。而該方法public synchronized boolean checkUnlockAppConfigChange(Context context)沒有地方調用。
 
解決方法:去掉synchronized關鍵字。
 
4、BUG: Incorrect lazy initialization of static field
 
BUG描述:This method contains an unsynchronized lazy initialization of a non-volatile static field. Because the compiler or processor may reorder instructions, threads are not guaranteed to see a completely initialized object, if the method can be called by multiple threads.(這種方法包含了一個不同步延遲初始化的非volatile靜態字段。因爲編譯器或處理器可能會重新排列指令,如果該方法可以被多個線程調用,線程不能保證看到一個完全初始化的對象。)
 
問題原因:sInstance 是static型,clean()方法可能被多個線程調用,在sInstance判斷爲非空後,再清空置null時可能會有問題。
 
解決方法:給clean()加上關鍵字synchronized .public static synchronized void clean()
 
5、BUG: Redundant nullcheck of value known to be non-null
 
BUG描述:This method contains a redundant check of a known non-null value against the constant null.(方法中對不爲空的值進行爲空的判斷。)
 
問題原因:分析findbugs報錯的這段代碼
 
if(mInputStream == null){
 
Log.i(TAG , " mInputStream is null ");
 
return;
 
}
 
mDBuilder = mDBuilderFactory.newDocumentBuilder();
 
if(mInputStream != null) {
 
mDocument = mDBuilder.parse(mInputStream);
 
}else {
 
Log.i(TAG , "mInputStream ==  null");
 
return;
 
}
 
mInputStream若爲null,則直接返回。後面不需要再有if(mInputStream != null)的判斷。
 
解決方法:在mInputStream判空後不再重複判空,將後面if判斷中的mInputStream改爲mDBuilder。
 
6、BUG: Should be a static inner class
 
BUG描述:This class is an inner class, but does not use its embedded reference to the object which created it.  This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.  If possible, the class should be made static.(若成員類中未訪問外圍類的非靜態成員,爲避免額外的空間和時間開銷,建議改用靜態成員類。)
 
問題原因:非靜態成員類和靜態成員類的區別在於,非靜態成員類是對象的,靜態成員類是類的。非靜態成員類可以訪問外圍類的任何成員,但前提是必須存在外圍類對象。JAVA需要額外維護非靜態成員類和外圍類對象的關係。分析代碼private class IccText和private class MediaMetadata {沒有訪問到外圍類的非靜態成員,所以findbugs建議將其設爲static型。
 
解決方法:將這2個內部類改爲static型。
 
7、BUG: Switch statement found where one case falls through to the next case
BUG描述:This method contains a switch statement where one case branch will fall through to the next case. Usually you need to end this case with a break or return.(Switch語句中一個分支執行後又執行了下一個分支。通常case後面要跟break或者return語句來跳出。)
 
問題原因:case MotionEvent.ACTION_UP執行完之後沒有break,會繼續走case MotionEvent.ACTION_CANCEL分支。分析代碼邏輯,手指擡起後,鎖屏圖標需要回到初始位置,而回到初始位置的邏輯是在ACTION_CANCEL裏做的。即ACTION_UP後的邏輯還需要ACTION_CANCEL裏面的邏輯。
 
解決方法:將ACTION_CANCEL中的邏輯拉出來做成一個函數,ACTION_UP邏輯後調用這個函數後再做break操作。
 
8、BUG: Unread field
BUG描述:This field is never read.  Consider removing it from the class.(類中定義的屬性從未被調用,建議刪除。)
 
問題原因:在類中定義了成員變量private HwViewProperty mCondition = null;代碼中只有賦值操作mCondition = new HwViewProperty(mContext,value, ViewPropertyType.TYPE_CONDITION, mCallback);但沒有使用這個變量mCondition的地方。
 
解決方法:去掉mCondition的定義及賦值語句。但需注意,mCondition = new HwViewProperty(mContext,value, ViewPropertyType.TYPE_CONDITION, mCallback);賦值中,雖然mCondition變量後續沒有使用到,但new HwViewProperty對象調用HwViewProperty的構造方法時,其實是做了功能操作的。因此,去掉mCondition,但需要保留new HwViewProperty(mContext,value, ViewPropertyType.TYPE_CONDITION, mCallback);
 
9、BUG: Write to static field from instance method
BUG描述:This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.(實例方法直接寫靜態變量。)
 
問題原因:sInstance是類的靜態成員變量,非靜態方法unregisterCallbaks直接對其賦值,非靜態方法是與對象相關聯的,當多個對象同時對該變量進行賦值時可能出現問題。
 
解決方法:在使用靜態成員變量時使用get和set方法。
發佈了6 篇原創文章 · 獲贊 7 · 訪問量 22萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章