Android 内存泄露原因

最新推荐文章于 2023-07-04 23:37:27 发布
最新推荐文章于 2023-07-04 23:37:27 发布
阅读量601 收藏
点赞数
分类专栏： memory 文章标签： 内存优化

彻底搞懂Java内存泄露

Java内存回收方式

Java判断对象是否可以回收使用的而是可达性分析算法。

在主流的商用程序语言中(Java和C#)，都是使用可达性分析算法判断对象是否存活的。这个算法的基本思路就是通过一系列名为”GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，下图对象object5, object6, object7虽然有互相判断，但它们到GC Roots是不可达的，所以它们将会判定为是可回收对象。


在Java语言里，可作为GC Roots对象的包括如下几种（摘自《深入理解Java虚拟机》）：

  • 虚拟机栈(栈桢中的本地变量表)中的引用的对象

  • 方法区中的类静态属性引用的对象

  • 方法区中的常量引用的对象

  • 本地方法栈中JNI的引用的对象

使用leakcanary检测泄漏

关于LeakCanary使用参考以下文章：

  • LeakCanary:让内存泄露无所遁形(https://www.liaohuqiu.net/cn/posts/leak-canary )

  • LeakCanary中文使用说明( https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/ )

LeakCanary的内存泄露提示一般会包含三个部分:第一部分(LeakSingle类的sInstance变量)引用第二部分(LeakSingle类的mContext变量),导致第三部分(MainActivity类的实例instance)泄露.


leakcanary使用注意

即使是空的Activity，如果检测泄露时候遇到了如下这样的泄露，注意，把refWatcher.watct()放在onDestroy里面即可解决，或者忽略这样的提示。由于文章已写很多，下面的就不再修改，忽略这种错误即可。

* com.less.demo.TestActivity has leaked:
* GC ROOT static android.app.ActivityThread.sCurrentActivityThread
* references android.app.ActivityThread.mActivities
* references android.util.ArrayMap.mArray
* references array java.lang.Object[].[1]
* references android.app.ActivityThread$ActivityClientRecord.activity
* leaks com.less.demo.TestActivity instance
protected void onDestroy() {    
    super.onDestroy();
    RefWatcher refWatcher = App.getRefWatcher(this);
    refWatcher.watch(this);
}

leakcanary和代码示例说明内存泄露

案例一：静态成员引起的内存泄露

public class App extends Application {    
    private RefWatcher refWatcher;    
    
    @Override
    public void onCreate() {        
        super.onCreate();
        refWatcher = LeakCanary.install(this);
    }
    
    public static RefWatcher getRefWatcher(Context context) {
        App application = (App) context.getApplicationContext();        return application.refWatcher;
    }
}

测试内部类持有外部类引用，内部类是静态的(GC-ROOT,将一直连着这个外部类实例)，静态的会和Application一个生命周期，这会导致一直持有外部类引用(内部类隐含了一个成员变量$0), 即使外部类制空= null，也无法释放。

OutterClass

public class OutterClass {    
    private String name;    
    class Inner{        
        public void list(){
            System.out.println("outter name is " + name);
        }
    }
}

TestActivity

public class TestActivity extends Activity {    // 静态的内部类实例
    private static OutterClass.Inner innerClass;

    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        OutterClass outterClass = new OutterClass();
        innerClass = outterClass.new Inner();

        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(outterClass);// 监控的对象

        outterClass = null;
    }
}


案例二：单例模式引起的内存泄露

DownloadManager

public class DownloadManager {    
     private static DownloadManager instance;    
     private Task task ;    

     public static DownloadManager getInstance(){        
        if (instance == null) {
            instance = new DownloadManager();
        }        
        return instance;
    }    
    public Task newTask(){        
        this.task = new Task();        
        return task;
    }
}

Task

public class Task {    
    private Call call;    
    public Call newCall(){        
        this.call = new Call();        
        return call;
    }
}

Call

public class Call {    
    public void execute(){
        System.out.println("=========> execute call");
    }
}


TestActivity

public class TestActivity extends Activity {    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        RefWatcher refWatcher = App.getRefWatcher(this);

        Task task = DownloadManager.getInstance().newTask();
        Call call = task.newCall();
        call.execute();
        refWatcher.watch(call);// 监控的对象
        call = null; // 无法回收，DownloadManager是静态单例，引用task，task引用了call，即使call置为空，也无法回收，切断GC_ROOT 联系即可避免内存泄露，即置task为空。
    }
}

部分日志打印如下:当前的GC_ROOT是DownloadManager的instance实例。

In com.leakcanary.demo:1.0:1.
* com.less.demo.Call has leaked:
* GC ROOT static com.less.demo.DownloadManager.instance
* references com.less.demo.DownloadManager.task
* references com.less.demo.Task.call
* leaks com.less.demo.Call instance

关于上面两种方式导致的内存泄露问题，这里再举两个案例说明以加强理解。

案例三：静态变量导致的内存泄露

public class TestActivity extends Activity {    
    private static Context sContext;    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        sContext = this;

        RefWatcher refWatcher = App.getRefWatcher(this);

        refWatcher.watch(this);// 监控的对象
    }
}


打印日志如下：

In com.leakcanary.demo:1.0:1.
com.less.demo.TestActivity has leaked:
GC ROOT static com.less.demo.TestActivity.sContext
leaks com.less.demo.TestActivity instance

从这段日志可以分析出：声明static后，sContext的生命周期将和Application一样长，Activity即使退出到桌面，Application依然存在->sContext依然存在，GC此时想回收Activity却发现Activity仍然被sContext(GC-ROOT连接着)，导致死活回收不了，内存泄露。

上面的代码改造一下，如下。

public class TestActivity extends Activity {    
    private static View sView;    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        sView = new View(this);

        RefWatcher refWatcher = App.getRefWatcher(this);

        refWatcher.watch(this);
    }
}


日志如下

In com.leakcanary.demo:1.0:1.
com.less.demo.TestActivity has leaked:
GC ROOT static com.less.demo.TestActivity.sView
references android.view.View.mContext
leaks com.less.demo.TestActivity instance

案例四：单例模式导致的内存泄露

DownloadManager

public class DownloadManager {    
    private static DownloadManager instance;    
    private List<DownloadListener> mListeners = new ArrayList<>();    
    public interface DownloadListener {        
        void done();
    }    
        
    public static DownloadManager getInstance(){        
        if (instance == null) {
            instance = new DownloadManager();
        }        
        return instance;
    }    
        
    public void register(DownloadListener downloadListener){        
        if (!mListeners.contains(downloadListener)) {
            mListeners.add(downloadListener);
        }
    }    
    public void unregister(DownloadListener downloadListener){        if (mListeners.contains(downloadListener)) {
            mListeners.remove(downloadListener);
    }
}

TestActivity

public class TestActivity extends Activity implements DownloadManager.DownloadListener{    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        DownloadManager.getInstance().register(this);

        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }    

    @Override
    protected void onDestroy() {        
        super.onDestroy();        // 忘记 unregister
        // DownloadManager.getInstance().unregister(this);
    }    
        
    @Override
    public void done() {
        System.out.println("done!");
    }
}


In com.leakcanary.demo:1.0:1.
* com.less.demo.TestActivity has leaked:
* GC ROOT static com.less.demo.DownloadManager.instance
* references com.less.demo.DownloadManager.mListeners
* references java.util.ArrayList.array
* references array java.lang.Object[].[0]
* leaks com.less.demo.TestActivity instance

错误写法一定导致内存泄露吗？

答案是：否定的。如下案例，有限时间内是可以挽救内存泄露发生的，所以控制好生命周期，其他情况：如单例对象(静态变量)的生命周期比其持有的sContext的生命周期更长时 ->内存泄露，更短时->躲过内存泄露。

public class TestActivity extends Activity {    
    private static Context sContext;    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        sContext = this;        
        new Handler().postDelayed(new Runnable() {            
            @Override
            public void run() {
                sContext = null; 
            }
        },1000);// 分别测试1s和12s,前者不会内存泄露，后者一定泄露。所以如果赶在GC之前切断GC_ROOT是可以避免内存泄露的。
    }    
    
    @Override
    protected void onDestroy() {        
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}

Handler引起的内存泄露详细分析

handler导致的内存泄露可能我们大多数都犯过.注意以下代码中的注释,非静态内部类虽然持有外部类引用，但是持有并不代表一定泄露，而是看gc时谁的命长。经过测试 情况(1)始终没有内存泄露。

为什么会这样， 很早阅读Handler源码时候记得这几个货都是互相引用来引用去的，Message有个target字段, message.target = handler;
handler.post(message);又把这个message推入了MessageQueue中，而MessageQueue是在一个Looper线程中不断轮询处理消息，而有时候message还是个老不死，能够重复利用。如果当Activity退出时候，还有消息未处理或正在处理，由于message引用handler,handler又引用Activity，此时将引发内存泄露。

public class TestActivity extends Activity {    
    private Handler handler = new Handler() {        
        @Override
        public void handleMessage(Message msg) {            
            super.handleMessage(msg);
            System.out.println("===== handle message ====");
        }
    };    
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);        // (1) 不会导致内存泄露
        handler.sendEmptyMessageDelayed(0x123,0);        // (2) 会导致内存泄露，非静态内部类（包括匿名内部类，比如这个 Handler 匿名内部类）会引用外部类对象 this（比如 Activity）
        // 当它使用了 postDelayed 的时候，如果 Activity 已经 finish 了，而这个 handler 仍然引用着这个 Activity 就会致使内存泄漏
        // 因为这个 handler 会在一段时间内继续被 main Looper 持有，导致引用仍然存在.
        handler.sendEmptyMessageDelayed(0x123, 12000);
    }    
    
    @Override
    protected void onDestroy() {        
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}


com.less.demo.TestActivity has leaked:
* GC ROOT android.view.inputmethod.InputMethodManager$ControlledInputConnectionWrapper.mH
* references com.android.internal.view.IInputConnectionWrapper$MyHandler.mQueue
* references android.os.MessageQueue.mMessages
* references android.os.Message.target , matching exclusion field android.os.Message#target
* references com.less.demo.TestActivity$1.this$0 (anonymous subclass of android.os.Handler)
* leaks com.less.demo.TestActivity instance

知道了原理后，即使写出易于内存泄露的代码也能够避免内存泄露啦。上述代码只需在onDestroy()函数中调用mHandler.removeCallbacksAndMessages(null);在Activity退出的时候的移除消息队列中所有消息和所有的Runnable。

内部类引起的内存泄露

内部类种类大致如下：

  • 非静态内部类(成员内部类)

  • 静态内部类(嵌套内部类)

  • 局部内部类(定义在方法内或者作用域内的类,好似局部变量,所以不能有访问控制符和static等修饰)

  • 匿名内部类(没有名字,仅使用一次new个对象即扔掉类的定义)


为什么非静态内部类持有外部类引用,静态内部类不持有外部引用?

这个问题非常简单，就像 static的方法只能调用static的东西，非static可以调用非static和static的一样。static→ 针对class, 非static->针对 对象，我是这么简单理解的。看图：


匿名内部类

将局部内部类的使用再深入一步，假如只创建某个局部内部类的一个对象，就不必命名了。

匿名内部类的类型可以是如下几种方式。

  • 接口匿名内部类

  • 抽象类匿名内部类

  • 类匿名内部类

匿名内部类总结:

其实主要就是类定义一次就失效了，主要使用的是这个类(不知道名字)的实例。根据内部类的特性，能够实现回调和闭包。JavaScript和Python的回调传递的是fuction,Java传递的是object。Java中常常用到回调，而回调的本质就是传递一个对象，JavaScript或其他语言则是传递一个函数(如Python，或者C,使用函数指针的方式),由于传递一个对象可以携带其他的一些信息，所以Java认为传递一个对象比传递一个函数要灵活的多(当然java也可以用Method反射对象传递函数)。参考《Java核心技术》

非静态内部类导致内存泄露(前提dog的命长)

下面的案例将导致内存泄露其中private static Dog dog ; 导致Dog的命比TestActivity长，这就糟糕了，但是注意，如果改为private Dog dog ; 即使Dog是非静态内部类，也不会导致内存泄露，要死也是Dog先死,毕竟Dog是TestActivity的家庭成员，开挂也得看主人。

public class TestActivity extends Activity {    
    private static Dog dog ;    
    class Dog {        
        public void say(){
            System.out.println("I am lovely dog!");
        }
    }    
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        dog = new Dog();
    }    
        
    @Override
    protected void onDestroy() {        
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}


In com.leakcanary.demo:1.0:1.
* com.less.demo.TestActivity has leaked:
* GC ROOT static com.less.demo.TestActivity.dog
* references com.less.demo.TestActivity$Dog.this$0
* leaks com.less.demo.TestActivity instance

哪些内部类或者回调函数是否持有外部类对象？

一个反射案例说明一切

/**
 * 作者: limitless
 * 描述: 一个案例测试所有类型内部类对外部类对象的持有情况
 * 网站: https://github.com/wangli0
 */

public class Main {    /* 持有外部类引用 */
    private IAppListener mAppListener = new IAppListener() {        
        private String name;        
        
        @Override
        public void done() {
            System.out.println("匿名内部类对象作为成员变量");
        }
    };    /* 未持有 */
    private static IAppListener sAppListener = new IAppListener() {        private String name;        @Override
        public void done() {
            System.out.println("匿名内部类对象作为static成员变量");
        }
    };    
   public static void main(String args[]) {
        Main main = new Main();
        main.test1();
        main.test2();
        main.test3();// test3 《=》test4
        main.test4();
        main.test5();
        main.test6();
    }    
   
    class Dog {        
        private String name;
    }    /* 持有外部类引用 */


    public void test1(){
        Dog dog = new Dog();
        getAllFieldName(dog.getClass());
    }    
    static class Cat {        
         private String name;
    }    
    /* 未持有 */
    private void test2() {
        Cat cat = new Cat();
        getAllFieldName(cat.getClass());
    }    
    
    /* 持有外部类引用 */
    private void test3() {        
        class Monkey{
            String name;
        }
        Monkey monkey = new Monkey();
        getAllFieldName(monkey.getClass());
    }    /* 持有外部类引用 */
    
    private void test4() {        
        // 常用作事件回调的地方(有可能引起内存泄露)
        IAppListener iAppListener = new IAppListener() {            
            private String name;            
            @Override
            public void done() {
                System.out.println("匿名内部类");
            }
        };
        getAllFieldName(iAppListener.getClass());
    }    
    
    /* 持有外部类引用 */
    private void test5() {
        getAllFieldName(mAppListener.getClass());
    }    
    
    /* 未持有 */
    private void test6() {
        getAllFieldName(sAppListener.getClass());
    }    
    
    private void getAllFieldName(Class<?> clazz) {
        System.out.println("className: ======> " + clazz.getSimpleName());
        Field[] fields = clazz.getDeclaredFields();        
        for (Field field : fields) {
            System.out.println(field.getName());
        }
    }
}


上述结果足够说明，即使是方法内的回调对象也是持有外部类引用的，那么虽然作用域是局部的，也有存在内存泄露的可能。我多次强调 持有某对象 不代表一定泄露，看的是谁命长。回调在Android开发过程中几乎处处可见，如果持有就会内存泄露的话，那几乎就没法玩了。一般情况下，我们常常设置某个方法内的xx.execute(new Listener(){xx});是不会导致内存泄露的，这个方法执行完，局部作用域就失效了。但是如果在execute(listener);过程中，某个单例模式的对象 突然引用了这个listener对象，那么就会导致内存泄露。

下面用实例证明我的想法

TestActivity

public class TestActivity extends Activity {    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);

        Task task = new Task();
        task.execute(new ICallback() {            
            @Override
            public void done() {
                System.out.println("下载完成！");
            }
        });
    }    
    
    @Override
    protected void onDestroy() {        
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}

Task

public class Task {    
    public void execute(ICallback iCallback) {
        DownloadManager.getInstance().execute(iCallback);
    }
}

DownloadManager

public class DownloadManager {    
    public static DownloadManager instance;    
    private ICallback mICallback;    
    public static DownloadManager getInstance(){        
        if (instance == null) {
            instance = new DownloadManager();
        }        
        return instance;
    }    
        
    public void execute(ICallback iCallback) {        
        this.mICallback = iCallback;// 反例，千万不要这么做，将导致内存泄露,如果注释掉这行，内存泄露不会发生
        iCallback.done();
    }
}


这足以证明我的想法是正确的，Callback的不巧当使用同样会导致内存泄露的发送。

总结

  • 如果某些单例需要使用到Context对象，推荐使用Application的context，不要使用Activity的context，否则容易导致内存泄露。单例对象的生命周期和Application一致，这样Application和单例对象就一起销毁。

  • 优先使用静态内部类而不是非静态的,因为非静态内部类持有外部类引用可能导致垃圾回收失败。如果你的静态内部类需要宿主Activity的引用来执行某些东西，你要将这个引用封装在一个WeakReference中，避免意外导致Activity泄露,被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收 只被弱引用关联 的对象，只被 说明这个对象本身已经没有用处了。

public class TestActivity extends Activity {    
    private MyHandler myHandler = new MyHandler(this);    
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);

    }    
    
    static class MyHandler extends Handler {        
        private WeakReference<Activity> mWeakReference;
              
        public MyHandler(Activity activity){
            mWeakReference = new WeakReference<Activity>(activity);
        }
        
        @Override
        public void handleMessage(Message msg) {            
            super.handleMessage(msg);
            Toast.makeText(mWeakReference.get(), "xxxx", Toast.LENGTH_LONG).show();
            Log.d("xx", mWeakReference.get().getPackageName());
        }
    }    
    
    @Override
    protected void onDestroy() {        
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}
清风紫竹001
关注
专栏目录
Android 内存泄露原因分析
09-16
Android 内存泄露原因分析。通过原因分析，再接合代码可查明具体原因，发现对策
Java内存回收方式
a_maker的博客
12-14 1576
文章转载自https://mp.weixin.qq.com/s/hw5d0FJXzaDZPN-vRPzjSA Java内存回收方式 Java判断对象是否可以回收使用的而是可达性分析算法。 在主流的商用程序语言中(Java和C#)，都是使用可达性分析算法判断对象是否存活的。这个算法的基本思路就是通过一系列名为”GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索
Android InputMethodmanager 引发的内存泄露
ProgramerQ 的博客
12-26 593
InputMethodmanager 引发的内存泄露是Android 输入法的系统 bug，在15 &amp;amp;lt;= API &amp;amp;lt;= 23 中都存在。 通过反射来拿到这个 View 并且置空。 @Override protected void onDestroy() { super.onDestroy(); InputMethodManager im = (Inp...
LeakCanary原理解析
xusiquan12的博客
04-07 427
使用 LeakCanary是Square为Android应用提供的一个监测内存泄露的工具，源码地址：https://github.com/square/leakcanary。 在gradle文件中引入依赖： dependencies { debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.4' releaseC...
ActivityThread.performLaunchActivity(ActivityThread$ActivityClientRecord, Intent) 错误
wletv的专栏
03-25 4870
ActivityThread.performLaunchActivity(ActivityThread$ActivityClientRecord, Intent) line: 1816 ZygoteInit$MethodAndArgsCaller.run() line: 845 AndroidManifest.xm添l加activity和 在 添加android:name=".M
android 软键盘 InputMethodManager
热门推荐
10-20 1万+
android 软键盘 InputMethodManager
Android内存溢出及内存泄漏原因进行
08-18
总结起来，内存溢出和内存泄漏的根本原因在于内存资源的管理不当，导致本应被回收的内存没有得到释放。预防这些问题的关键在于： 1. 适当管理数据量，避免一次性加载大量数据。 2. 使用集合类时，及时清除不再需要...
Android 内存溢出和内存泄漏的问题
01-04
Android 内存溢出和内存泄漏的问题 在面试中，经常有面试官会问“你知道什么是内存溢出？什么是内存泄漏？怎么避免？”通过这篇文章，你可以回答出来了。 内存溢出 （OOM）是指程序在申请内存时，没有足够的内存空间...
Android 内存泄漏
07-03
自己收集的android方面关于内存泄漏方面的视频以及学习资料，自己之前花钱搞到的，现在对外公开。文档里面是链接和密码，永久有效！
记MarqueeTextView内存泄漏原因
m0_59162559的博客
05-09 371
项目中使用了`MarqueeTextView`组件，用于以跑马灯的形式展示公告信息。在当前页启动新的Activity时，Leakcanary检测到新的Activity内存泄漏了~~
Android 性能优化 内存抖动 内存泄漏
最新发布
feather(猎羽)
07-04 892
Shallow Size = [类定义] + 父类fields所占空间 + 自身fields所占空间 + [alignment]5、Memory Profiler的Record java/kotlin allocations的作用？4、Memory Profiler的Capture heap dump的作用？CPU、内存、电量，网络赚到了Network Inspector。11、Glide LruArrayPool怎么实现的？10、byte数组的对象池需要满足的条件。1、内存泄漏用什么工具监控？
内存优化之内存泄漏
zhonglunshun的专栏
06-02 4194
我们能通过这篇文章学到什么？我们这篇文章主要通过两点来讲： 探讨关于内存泄露的原因； 1.1 JVM垃圾回收机制 1.2 GC Root 实战找出内存泄漏并解决； 什么是内存泄漏 内存泄漏是指对象不再被应用程序使用，但是垃圾回收器却不能移除它们，因为它们正在被引用。为了方便大家理解，我用一个例子帮助大家理解垃圾回收机制； 大家去过食堂吃饭吧，吃完饭后，需要我...
Android内存优化(一)之Android常见的Java层内存泄露场景及合理的修复方案
longlong2015的博客
02-12 1391
首先解释下内存泄露: 内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。 内存泄露分为永久性泄露和临时性泄露.永久性泄露是指只要泄露出现,泄露的内存永远不会回收,此种情况一般问题比较严重,一旦发现,需快速解决.临时性泄露是指泄露场景出现后,在在未来的某段时间...
Android P 应用兼容常见错误及建议
m0_70082867的博客
05-06 506
只使用 Android SDK 中的公开接口进行应用开发。公开 SDK 接口有详细的技术文档和支持渠道，未来的 Android 新版本也会保证公开 SDK 接口的兼容性 (即使有改动，也会在文档中详细阐明)。 请尽早在 Android P 预览版中测试您的应用，您可以运行并操作应用，然后在 adb logcat 中查找类似下方的内容，其中包含了应用调用的非 SDK 接口名，所属黑/灰名单和调用的方式: Accessing hidden field Landroid/os/Message;->flags
[Android] InputMethodManager内存泄露现象及解决 输入法造成的内存泄露
qq_26585943的博客
01-04 5966
当遇到这个输入法造成的内存泄露的时候，我表示一脸惊讶，因为我整个Activity中没有如何一个输入类控件，更不存在使用输入键盘。但是内存就这样不知不觉的泄露了。既然遇到了问题，我们就要寻求解决方案。 先看一下内存泄露对象InputMethodManager的引用路径 要想让Activity释放掉,思路就是将path togc这个链路剪断就可以.在这个bug中这个链路上有两个节点mContext(
InputMethodManager内存泄露现象及解决
stormCoder的博客
10-19 1232
现象: 在特定的机型上,某个界面上出现InputMethodManager持有一Activity,导致该Activity无法回收.如果该Activity再次被打开,则旧的会释放掉,但新打开的会被继续持有无法释放回收. 要想让Activity释放掉,思路就是将path togc这个链路剪断就可以.在这个bug中这个链路上有两个节点mContext(DecorView)和 mCurRootVie
千里马android framework开发解决Accessing hidden method限制，让应用访问隐藏方法（需要可以修改系统源码方案）
learnframework的博客
04-27 1万+
hi，粉丝朋友们大家好！ 今天来给大家分享一下，就是经常大家会做安卓系统开发工作问到一个问题，那就是我如果framework代码中增加了一个方法啥的，但是我又不想公开给第三方应用知道，只想让我系统的应用知道，那该怎么办呢？其实这个时候经常就会用到一个hidden的标签，来代表这个方法是隐藏方法，隐藏方法就是给系统内部用的，意味着第三方app就无法使用。这个其实也很常见，自从android p开始android系统就开始对访问hidden的限制越来越严格，虽然我们网络上有各种奇葩招来逃避不允许调用hidden
Android常见内存泄露原因与调试方法
Android内存泄露是Android应用开发中常见的问题，特别是在使用Java编写应用时，由于嵌入式设备通常内存资源有限，不当的内存管理可能导致性能下降甚至应用崩溃。本文将重点介绍几种常见的内存泄露情况以及相应的解决...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值