findbugs的警告类型

大的分类主要包括以下几种：

Bad practice 不好的习惯

主要是命名问题,比如类名最好以大写开头,字符串不要使用等号不等号进行比较,可能会有异常最好用try-catch包裹的代码,方法有返回值但被忽略等等,这些如果不想改可以直接忽略.

Correctness 代码的正确性

主要是没有对变量进行不为空判定,在特殊情况可能发生空指针异常.

Dodgy 小问题

·比如一个double/float被强制转换成int/long可能会导致精度损失,一些接近零的浮点数会被直接截断,事实上我们应该保留.
这里顺便提一点,这两天看了《app研发录》,在规范代码,尽量规避错误这方面我也有了一些收获.
在类型转换的时候,我们应该为类型转换提供一个安全的转换方法,因为我们永远不会知道,我们的app在用户手里会发生什么,所以我们要尽可能的去减少这种发生错误的可能.

·比如使用switch的时候没有提供default。

·多余的空检查，就是不可能为空的值，增加了不为空判断，这是没有必要的。属于代码冗余

·不安全的类型转换等等。
这项太多了，就不一一列举了。

Malicious code vulnerability 恶意代码

听起来很吓人呀,主要是一些属性直接使用public让别的类来获取,建议改为private并为其提供get/set方法.
还有一些public的静态字段,可能会被别的包获取之类的.
这些也需要根据项目具体情况来,个人意见,在有的不重要类,有时直接公开使用属性,可能更为便捷.如果你认为这些不需要修改,完全可以忽略.

Internationalization 国际化问题

Performance 性能问题

主要是一些无用的代码,比如声明了没有用到的属性等等

Security 安全性问题

Multithreaded currectness 线程问题

Experrimental 实验性问题

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