android内存泄漏

非静态内部类导致内存泄漏主要原因：：：App可能会因为大量的内存泄漏导致内存耗尽，引发Crash，如果内存耗尽，App会由于内存空间不足，出现频繁的GC，每一次GC都是一个耗时阻塞操作，会造成设备卡顿。 非静态内部类中创建了一个静态实例，导致该实例的生命周期和应用ClassLoader级别，又因为该静态实例会隐式持有其外部类的引用，所以导致其外部类无法正常释放，出现泄漏问题。 （classloader：用来动态加载某个class文件到内存当中，只有class被载入到内存中之后，才能被其他class所引用） 1.非静态内部类会对外部类存在一个隐式引用 非静态(匿名)内部类会持有外部类的引用，静态内部类中未持有外部类的引用。 2.非静态内部类中存在异步任务，可能导致其对应的外部类内存资源无法正常释放 3.非静态内部类中创建了一个静态实例，会导致内存泄漏 解决思路：：：：去掉隐式引用（静态（匿名）内部类），手动管理对象引用（修改静态内部类的构造方法，手动引入其外部类引用）当内存不可用时，不执行不可控代码（Android 可以结合智能指针 ，WeakReference包裹外部类实例） 总结：：：：不是所有内部类只能使用静态内部类，只有在该内部类中的生命周期不可控的情况下，采用静态内部类。 多想想对象之间的引用关系。 来源： https://www.cnblogs.com/acg88688

1.概述 如果使用MAT来分析内存问题，会有一些难度，并且效率也不是很高，对于一个内存泄漏问题，可能要进行多次排查和对比。 为了能够简单迅速的发现内存泄漏，Square公司基于MAT开源了 LeakCanary 。 2.使用LeakCanary 首先配置build.gradle： dependencies { debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.2' releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.2' } 1 2 3 4 接下来在Application加入如下代码。 public class LeakApplication extends Application { @Override public void onCreate () { super .onCreate(); if (LeakCanary.isInAnalyzerProcess( this )) { //1 // This process is dedicated to LeakCanary for heap analysis. // You should not init your app in this process. return ;

GITHUB https://blog.51cto.com/6342127/2307514 说明 这篇文章是将很久以来看过的文章,包括自己写的一些测试代码的总结.属于笔记的性质,没有面面俱到,一些自己相对熟悉的点可能会略过.<br> 最开始看到的性能优化的文章,就是胡凯的优化典范系列,后来又陆续看过一些人写的,个人觉得anly_jun和胡凯的质量最好.<br> 文章大的框架也是先把优化典范过一遍,记录个人认为重要的点,然后是anly_jun的系列,将之前未覆盖的补充进去,也包括HenCoder的一些课程相关内容.<br> 当然除了上面几位,还有很多其他大神的文章,时间久了也记不太清,在此一并谢过. 笔记内容引用来源 胡凯 anly_jun HenCoder 1.Android性能优化之渲染篇 1.VSYNC 帧率:GPU在1秒内绘制操作的帧数.如60fps. 我们通常都会提到60fps与16ms,这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新. 开发app的性能目标就是保持60fps,这意味着每一帧只有16ms=1000/60的时间来处理所有的任务 刷新率:屏幕在1秒内刷新屏幕的次数.如60Hz,每16ms刷新1次屏幕. GPU获取图形数据进行渲染,然后屏幕将渲染后的内容展示在屏幕上. 大多数手机屏幕的刷新率是60Hz,如果GPU渲染1帧的时间低于1000/60

什么是内存泄露？ 　　就是该回收的内存由于种种原因没有被回收，还驻留在内存中。 内存泄露有什么影响？ 　　可能一处小小的内存泄露就会导致整个应用卡顿，甚至崩溃。 例子说明：　　 Toast.makeText(MainActivity.this,"Hello",Toast.LENGTH_SHORT).show(); 　　这段代码可能会出现内存泄露。 为什么说可能会造成内存泄露？ 　　如果在Toast消失之前，Toast 持有了当前的 Activity，而此时，用户点击了返回键，导致 Activity 无法被 GC（Garbage Collection垃圾回收） 回收，这个Activity 就引起了内存泄露。 解决方法？ 　　所有和当前 Activity 无关的 Context 都可以传入，避免内存泄露的方法同样使用其他需要传入 Context 的地方。（这句话我表示理解不了）如下 Toast.makeText(getApplicationContext(),"Hello",Toast.LENGTH_SHORT).show(); 　　getApplicationContext()是整个应用的上下文，不会持有某个 Activity 对象。 注意 　　dialog的上下文不能使用getApplicationContext()，程序会崩掉，dialog实例化必须持有 Activity对象。

一、Android性能优化的方面 针对Android的性能优化，主要有以下几个有效的优化方法： 1.布局优化 2.绘制优化 3.内存泄漏优化 4.响应速度优化 5.ListView/RecycleView及Bitmap优化 6.线程优化 7.其他性能优化的建议 下面我们具体来介绍关于以上这几个方面优化的具体思路及解决方案。 二、布局优化 关于布局优化的思想很简单，就是尽量减少布局文件的层级。这个道理很浅显，布局中的层级少了，就意味着Android绘制时的工作量少了，那么程序的性能自然就提高了。 如何进行布局优化？ ①删除布局中无用的控件和层次，其次有选择地使用性能比较低的ViewGroup。 关于有选择地使用性能比较低的ViewGroup,这就需要我们开发就实际灵活选择了。 例如：如果布局中既可以使用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，这是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup，因此可以考虑使用它们，但是 很多时候单纯通过一个LinearLayout或者FrameLayout无法实现产品效果，需要通过嵌套的方式来完成。这种情况下还是建议采用RelativeLayout

前言 这篇文章的内容是我回顾和再学习 Android 内存优化的过程中整理出来的，整理的目的是让我自己对 Android 内存优化相关知识的认识更全面一些，分享的目的是希望大家也能从这些知识中得到一些启发。 Android 应用运行在 ART 环境上，ART 是基于 JVM 优化而来的，ART 优化的目标就是为了让 Android 应用能更高效地在 Android 平台运行。 不严谨地说，Android 应用就是一个在 Android 平台运行良好的 Java 程序，承载着 Android 应用的 ActivityThread 同样有 main 方法。 因此只有了解了 Java 的内存管理机制，才能更好地理解 Android 的内存管理机制，如果你对这一块还不熟悉的话，可以看我的上一篇文章 《 Java 内存管理机制 》。 本文的内容可分为下面两部分，大家可以根据自己的需要选择性地阅读。 第一部分 讲的是 Android 内存管理机制相关的一些知识，包括 Dalvik 虚拟机和 ART 环境等。 第二部分 讲的是内存问题的解决与优化方法，包括 Memory Profiler、LeakCanary 工具的使用方法。 1. 为什么要做内存优化？ 内存优化能让应用挂得少、活得好和活得久 。 挂得少 “挂”指的是 Crash，假如一个满分的应用是 100 分，那么一个会 Crash