android内存泄漏

最近项目中的内存越来越大，于是了解关于Android内存分析相关的知识，用以解决实际问题。现在有很多好的内存分析工具比如： LeakCanary、DDMS、mat。 一、首先简单介绍下LeakCanary： 在build.gradle文件中添加 　在应用的application onCreate方法中添加LeakCanary.install(this)，如下 　应用运行起来后，LeakCanary会自动去分析当前的内存状态，如果检测到泄漏会发送到通知栏，点击通知栏就可以跳转到具体的泄漏分析页面。 二、下面重点介绍下DDMS结合mat分析内存泄漏问题。 使用mat分析首先要通过eclipse或是Android studio生成hprof文件，然后使用命令cd到Android sdk的目录下： cd /usr/local/android/sdk/tools //改成自己的sdk目录 hprof-conv com.scics.huaxi.hprof ff.hprof //转换格式命令 这样就生成可供mat分析的hprof文件。http://www.eclipse.org/mat/ 此处可下载mat，可以下载独立版亦可以下载eclipse插件版，本人下的是独立版本。将我们得到的hprof文件导入mat中得如下结果： 深色区域的3.6MB、9.3MB、9.6MB标示有内存泄漏的

一丶设计模式与使用场景 建造者模式： 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 使用场景比如最常见的 AlertDialog,拿我们开发过程中举例，比如 Camera 开发过 程中，可能需要设置一个初始化的相机配置，设置摄像头方向，闪光灯开闭，成 像质量等等，这种场景下就可以使用建造者模式 装饰者模式： 动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模 式比生成子类更为灵活。装饰者模式可以在不改变原有类结构的情况下曾强类的 功能，比如 Java 中的 BufferedInputStream 包装 FileInputStream ，举个开发中的 例子，比如在我们现有网络框架上需要增加新的功能，那么再包装一层即可，装 饰者模式解决了继承存在的一些问题，比如多层继承代码的臃肿，使代码逻辑更 清晰 还有等等.......观察者模式， 代理模式，门面模式，单例模式，生产者消费者模式。 二丶java 中的线程创建方式，线程池的工作原理 java 中有三种创建线程的方式，或者说四种 1.继承 Thread 类实现多线程 2.实现 Runnable 接口 3.实现 Callable 接口 4.通过线程池 线程池的工作原理： 线程池可以减少创建和销毁线程的次数，从而减少系统资源 的消耗，当一个任务提交到线程池时 a. 首先判断核心线程池中的线程是否已经满了

1、静态变量 类中定义了静态Activity变量，把当前的Activity赋值给静态变量，如果Activity生命周期结束的时候静态变量没有清空，就会导致内存泄漏。static变量是贯穿整个应用的生命周期，所以被泄漏的Activity就会一直存在于应用的进程中，不会被回收。 private static Activity sActivity; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main2); sActivity = this; findViewById(R.id.btn_back).setOnClickListener(new View.OnClickListener() { @Override public void onClick(View view) { finish(); } }); } } 2、 非静态内部类 创建 静态实例 这里的非静态内部类是Config，创建的静态实例是sConfig 造成内存泄漏的原因是 内部类会隐式持有外部类的引用 ，这里的外部类是NonStaticActivity，然而内部类sConfig又是static静态变量

由于最近疫情的问题，很多上班族都延迟的上班时间在家办公，对于疫情祖国已经做出了指示，解放军来了，我们更加坚定必胜信心，希望可以尽快得到控制，为解放军点赞o(￣▽￣)ｄ 那很多人在家选择办公发现真的没有真的在公司那么充实，也刚好金三银四快要到了，这段时间刚好在家可以抽空多充实下自己，今天就更一篇关于性能优化的总结 相关内容之后会在GitHub上更新，希望多多关注 （ 顺手留下GitHub链接，需要获取相关面试等内容的可以自己去找 ） https://github.com/xiangjiana/Android-MS (VX：mm14525201314) ↓获取如下面试笔记 一、Android性能优化的方面 针对Android的性能优化，主要有以下几个有效的优化方法： 1.布局优化 2.绘制优化 3.内存泄漏优化 4.响应速度优化 5.ListView/RecycleView及Bitmap优化 6.线程优化 7.其他性能优化的建议 下面我们具体来介绍关于以上这几个方面优化的具体思路及解决方案。 二、布局优化 关于布局优化的思想很简单，就是尽量减少布局文件的层级。这个道理很浅显，布 局中的层级少了，就意味着Android绘制时的工作量少了，那么程序的性能自然就 提高了。 如何进行布局优化？ ①删除布局中无用的控件和层次，其次有选择地使用性能比较低的 ViewGroup

性能优化简图 打造一个高质量的应用应该以4个方向为目标：快、稳、省、小。 快：使用时避免出现卡顿，响应速度快，减少用户等待的时间，满足用户期望。 稳：减低 crash 率和 ANR 率，不要在用户使用过程中崩溃和无响应。 省：节省流量和耗电，减少用户使用成本，避免使用时导致手机发烫。 小：安装包小可以降低用户的安装成本。 要想达到这4个目标，具体实现是在右边框里的问题：卡顿、内存使用不合理、代码质量差、代码逻辑乱、安装包过大，这些问题也是在开发过程中碰到最多的问题，在实现业务需求同时，也需要考虑到这点，多花时间去思考，如何避免功能完成后再来做优化，不然的话等功能实现后带来的维护成本会增加。 卡顿优化 Android 应用启动慢，使用时经常卡顿，是非常影响用户体验的，应该尽量避免出现。卡顿的场景有很多，按场景可以分为4类：UI 绘制、应用启动、页面跳转、事件响应，如图： 卡顿场景分析 这4种卡顿场景的根本原因可以分为两大类： 界面绘制。主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。 数据处理。导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。 引起卡顿的原因很多

0、 https://square.github.io/#android 这是它家官网，开源了好多库，我只能说真牛逼，佩服佩服！！！ 1、Android上开发一个App，从网络库、图片库、内存泄漏库，全套都可以用它们的，真是一家牛逼的公司！下面是知名度相对较高的几个库！！超级轮子，牛逼！！ picasso （图片库） okhttp （网络库） leakcanary （内存泄漏） retrofit moshi 等等…… 2、 http://www.piwai.info/index.html 接着我发现一个大佬，它是square的一个技术leader，leakcanary它是作者之一，牛逼，它的CV可真漂亮 这哥们的自我介绍： Pierre-Yves Ricau 我住在旧金山。 我在Square做软件工程师。 我领导了一个团队，专注于让外部移动开发者在使用Square的商业平台时获得成功 他的工作愿景： My Ideal Job（我是不是也该想想自己的Ideal Job，这也是我的理想） Strong technical culture High impact Remote friendly Small teams 我理想的工作环境 雄厚的技术文化 激情满满 充满友善 小型团队 他现在的感受： py.ricau@gmail.com 我很少回复招聘邮件。 我在Square真的很开心。

又到年底了，每到这个时候，我们都会慢慢反思，这一年都做了什么？有什么进步？年初的计划都实现了吗？明年年初有跳槽的底气了吗？况且今年的互联网环境太差，需要自己有足够的知识储备，才能够应对这凌冽的寒风。 本文主要是整理了中高级安卓需要会的（或者说面试被频繁问到的内容），主要作为参考大纲，之后会陆续更新每个详细部分，供大家参考，互相学习。 面试板块(PDF版如下)： BAT面试合集（Binder，组件化插件化，热修复，AOP，QQ换肤，虚拟机，https，线程池原理，音视频原理） 算法合集（Hash,KMP 等） 中小厂面试合集（内存泄漏，Handler，View，MVC.MVP.MVVM，） 大厂相关更新技术（Glide,数据库，NDK） 面试小知识（java小知识） 设计模式（设计模式原则和分类） 数据结构（数据结构等等） 网络编程（三次握手和四次握手，Volley，OKHttps,Retrofit） 源码解析(属性动画实现原理等） 多线程解析（线程同步，进程线程） 性能优化（Webview,内存泄漏和内存溢出等） （ 顺手留下GitHub链接，需要获取相关面试或者面试宝典核心笔记PDF等内容的可以自己去找 ） https://github.com/xiangjiana/Android-MS 一丶设计模式与使用场景 (如）建造者模式： 将一个复杂对象的构建与它的表示分离

前言 这个系列的文章： 1、用通俗易懂的讲解方式，讲解一门技术的实用价值 2、详细书写源码的追踪，源码截图，绘制类的结构图，尽量详细地解释原理的探索过程 3、提供Github 的 可运行的Demo工程,但是我所提供代码，更多是提供思路，抛砖引玉，请酌情cv 4、集合整理原理探索过程中的一些坑，或者demo的运行过程中的注意事项 5、用gif图，最直观地展示demo运行效果 如果觉得细节太细，直接跳过看结论即可。本人能力有限，如若发现描述不当之处，欢迎留言批评指正。 学到老活到老，路漫漫其修远兮。与众君共勉 !，和我一起当个CV工程师吧，手动滑稽 正文大纲 jvm内存管理常识 检测以及处理内存抖动 检测以及处理内存泄漏 正文 jvm内存管理常识 LMK （LowMemoryKill）机制 android底层会在系统内存告急的时候，按照一定规则杀死一些进程来满足其他进程的内存需要。其中 消耗内存的高低就是其中一项指标，所以，优化app的内存占用，能够有效降低app被系统杀死的概率。 GC STW机制 GC，垃圾回收进程，在 GC 线程执行任务的时候，会存在一个 STW (stop the world) 机制，他就会把其他所有线程都挂起。如果 GC 非常频繁地调用，那就会导致主线程不流畅，给用户的感觉就是 卡顿。 内存抖动频繁引起OOM 内存抖动太频繁，导致大量对象频繁创建和销毁

阿里P7移动互联网架构师进阶视频（每日更新中）免费学习请点击： https://space.bilibili.com/474380680 本篇文章将继续从以下两个内容来介绍内存优化: [内存抖动] [内存泄漏] <meta charset="utf-8"> 其实大多数App或多或少都存在一定的内存泄漏情况，这些内存泄漏可能存在于特定的运行环境时才会发生。而内存泄漏堆积会引发严重后果OOM。内存抖动是指内存频繁地分配和回收，而频繁的gc会导致卡顿，严重时和内存泄漏一样会导致OOM。 接下来我们一起讨论该如何查看以及解决这部分问题思路。 一、内存泄漏 内存泄露是指程序中间动态分配了内存，但在程序结束时没有释放这部分内存，从而造成那部分内存不可用的情况，重启计算机可以解决，但也有可能再次发生内存泄露，内存泄露和硬件没有关系，它是由软件设计缺陷引起的。 简单点说：应该被释放的资源没有被释放。 1、内存泄漏的种类 1）常发性内存泄漏 。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。 2）偶发性内存泄漏 。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。 3) 一次性内存泄漏 。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷

1.静态分析工具-Lint 检查内存泄漏 Android Studio 自带的工具，使用方式 Analyze -》Inspect Code 然后选择想要扫面的区域 2.LeakCanary工具 3.Android Monitor 内存溢出和内存泄漏的区别 内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。 内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。 来源： https://www.cnblogs.com/acg88688/p/11870578.html