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方法。