Subtotal for android Memory leakage and subtotal for android

Subtotal for android Memory leakage and subtotal for android

1. When debugging the android program today, I found that even if the program exits, it still occupies about 15 MB of memory. after multiple GC operations, we can see that the number is still 15. intuition tells me that memory leakage should happen. Use MAT to view the Memory Leak. I was surprised to find that it was InputMethodManager. This object always references Context. That is, Activity, which makes it unable to release memory. Later, google found that,

The following is a solution to help people in similar situations:

@Overrideprotected void onDestroy(){    super.onDestroy();    //fix for memory leak: http://code.google.com/p/android/issues/detail?id=34731    fixInputMethodManager();}private void fixInputMethodManager(){    final Object imm = getSystemService(Context.INPUT_METHOD_SERVICE);    final Reflector.TypedObject windowToken        = new Reflector.TypedObject(getWindow().getDecorView().getWindowToken(), IBinder.class);    Reflector.invokeMethodExceptionSafe(imm, "windowDismissed", windowToken);    final Reflector.TypedObject view        = new Reflector.TypedObject(null, View.class);    Reflector.invokeMethodExceptionSafe(imm, "startGettingWindowFocus", view);}

WindowDismissed and startGettingWindowFocus are called through reflection. I thought this problem was solved in this way. Who knows that there is another amazing situation. I found another amazing object: com. lflytek. speech.. My mind is exhausted. What is this? Through the Baidu query, we found that this is the speech recognition sdk of KEDA xunfei. Yes, my mind is exhausted. But no. How long is the lifecycle of this object. No. It must have been wrong. Later I read through the source code:

public RecognizerDialog(Context paramContext, String paramString)  {    super(paramContext);    this.a = new a(paramContext, paramString);  }  public void setListener(RecognizerDialogListener paramRecognizerDialogListener)  {    ((a)this.a).a(paramRecognizerDialogListener);  }

This is the only place in which the sdk can get my application, and other information is set. Is this the problem? Yes, you are correct!

On the surface, there seems to be no problem. You can see that many of our application sdks do not work like this. This is normal. No way. Even though the code has been obfuscated, I can only read it with my head to find out the truth. The Code keeps tracing and finally finds the secret.

Com. iflytek. speech. a. a has an amazing private class member.

Private static a e = null

  public static com.iflytek.speech.b b(Context paramContext, String paramString)  {    if (e == null)      e = new a(paramContext, paramString);    return e;  }

Are you not a tough guy? Why do we have to use static resources? This leads to long lifecycle of e and Activity, and memory leakage. (When I read the obfuscation of the C ++ sdk code, I found that it was collecting the location information of the device and the package name and signature information of the application. Of course, this is understandable, after all, we need to verify the package name and signature of the application ). This can be done, and the static is private. By the way, I think of reflection.

The following is the reflection code.

@Overridepublic void finish() {com.iflytek.a.a.a=null;try {Class clazz=Class.forName("com.iflytek.speech.a.a");Field field=clazz.getDeclaredField("e");if (field.isAccessible()==false) {field.setAccessible(true);}field.set(null, null);} catch (Exception e) {// TODO Auto-generated catch blocke.printStackTrace();}super.finish();}

Then debug and find that the problem is finally solved.

It seems that when using third-party sdks in the future, you must pay attention to it. You cannot use it as needed.