Some common problems with Android FindBugs

FindBugs warning 26. There are 9 main types of problems. 1, Bug:hard coded reference to an absolute pathname Bug description: This code constructs a File object using a hard coded to an ABSO lute Pathname (This code contains the file object as an absolute pathname) causes the problem: hard-coded points to an absolute path. File Prefile = new file (Preferences_file_full_path); and private static final String Preferences_file_full_path = "/data/data/com.android.mms/shared_prefs/auto_download.xml "; Preferences_file_full_path declaration for final type, immutable. If the subsequent file path is changed, the reference is not available, but the path is not changed, the problem is introduced. Workaround: Remove Final. 2, Bug:Pattern:Dead store to local variable Bug description: This instruction assigns a value to a local variable, but the value is Not read or used in any subsequent instruction. Often, this indicates a error, because the value computed is never used. (the directive assigns a value to a local variable, but does not make any use of it afterwards.) Typically, this indicates an error because the value has never been used. The problem causes: The lock screen prompts dead store to Velocityx, the parsing code case motionevent.action_pointer_1_up The local variable Velocityx defined in the statement, and only if ( Mdirectionflag && Velocityx > 0) | | (!mdirectionflag && Velocityx < 0)) Velocityx =-velocityx, the value is not used again after the assignment. Therefore there is no need to assign a value, and the parsing code does not requireThe variable that can be removed. Workaround: Remove the definition of Velocityx variable and assign value. 3. Bug:inconsistent Synchronization BUG Description: The fields of this class appear to be accessed inconsistently with respect to Sy Nchronization. (unreasonable synchronization) problem reason: According to the description Configloader file in the Munlockappdatamap in 46% of the time is in a locked state. The parsing code Munlockappdatamap is locked in the Checkunlockappconfigchange function. And the method public synchronized Boolean Checkunlockappconfigchange (context context) has no place to call. Workaround: Remove the Synchronized keyword. 4. Bug:incorrect lazy initialization of static field BUG Description: This method contains a unsynchronized lazy initialization of a Non-volatile static field. Because the compiler or processor may reorder instructions, threads is not guaranteed-see a completely initialized obj ECT, if the method can be called by multiple threads. (This method contains a non-volatile static field that does not synchronize lazy initialization.) Because the compiler or processor may rearrange the instructions, if the method can be called by more than one thread, the thread is not guaranteed to see a fully initialized object. Cause: Sinstance is a static type, the clean () method may be called by multiple threads, and after Sinstance is judged to be non-empty, there may be a problem when empty null is cleared. WORKAROUND: Add the keyword synchronized. public static synchronized void clean () 5, Bug:redundant Nullcheck of ValUE known to be non-null Bug Description: This method contains a redundant check of a known Non-null value against the constant null. ( method is used to determine whether a value that is not NULL is empty. The cause of the problem: Analyze FindBugs Error in this code 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 if NULL, returns directly. There is no need to judge if (Minputstream! = null) later. Solution: In the Minputstream after the empty sentence is no longer repeated, the next if judgment in the Minputstream changed to Mdbuilder. 6. Bug:should be a static inner class BUG Description: This class was an inner class, but does not use it embedded reference to the O Bject which created it. This reference makes the instances of the class larger, and could keep the reference to the Creator object alive longer than necessary. If possible, the class should be made static. (If non-static members of the perimeter class are not accessed in the member class, it is recommended to use static member classes instead of additional space and time overhead.) Problem reason: The difference between a non-static member class and a static member class is that a non-static member class is an object, and a static member class is a class. A non-static member class can access any member of the perimeter class, but only if the perimeter class object must exist. Java requires extra maintenance of non-static member classesAnd the relationship of the outer class object. The analysis Code private class Icctext and private class Mediametadata {Do not have access to the non-static members of the perimeter class, so findbugs recommends setting it as a static type. Workaround: Change these 2 inner classes to a static type. 7. Bug:switch statement found where one case falls through to the next case BUG Description: This method contains a Switch statement Where one case branch would fall through to the next case. Usually you need to end this case with a break or return. (the switch statement executes the next branch after one of the branches executes.) Usually the case is followed by a break or return statement to jump out. Problem reason: Case MOTIONEVENT.ACTION_UP does not break after execution, will continue to walk case Motionevent.action_cancel branch. Parsing the code logic, when the finger is lifted, the lock screen icon needs to go back to the initial position, and the logic to return to the initial position is done in Action_cancel. The logic behind the ACTION_UP also needs to action_cancel the logic inside. Workaround: Pull the logic out of the action_cancel to make a function, and then call this function after the action_up logic to do the break operation. 8. Bug:unread Field BUG Description: This field is never read. Consider removing it from the class. (Properties defined in the class have never been called, it is recommended to delete.) The problem causes: the member variable is defined in the class private hwviewproperty mcondition = null; only the assignment operation mcondition = new Hwviewproperty (Mcontext,value, Viewpropertytype.type_condition, mcallback); but there is no place to use this variable mcondition. Workaround: Remove the definition of mcondition and the assignment statement. Be aware, however, that mcondition = new HwVIewproperty (Mcontext,value, viewpropertytype.type_condition, Mcallback); In the assignment, although the mcondition variable is not used later, the new When the Hwviewproperty object calls the Hwviewproperty construction method, it actually does the function operation. Therefore, remove mcondition, but need to keep new Hwviewproperty (Mcontext,value, viewpropertytype.type_condition, Mcallback); 9, bug:write to static field from instance method BUG Description: This instance method writes to a static field. This was tricky to get correct if multiple instances was being manipulated, and generally bad practice. (Instance methods write static variables directly.) Problem reason: Sinstance is a static member variable of a class, the non-static method Unregistercallbaks directly assigns it, non-static methods are associated with the object, and problems can occur when multiple objects are assigned to the variable at the same time. Workaround: Use the Get and set methods when using static member variables.http://shnk.familydoctor.com.cn/nxzx/szzx/

Some common problems with Android FindBugs