为了记录自己的学习进度，亦或者是为了锻炼自己的思维能力和全局的思想，我在简书写下自己学习的情况，其中肯定有许多的不足和至少遗漏的点，所以肯请发现的朋友指点一二，不甚感激！
在简书偶遇到的大神，推荐大家将其博客看完，将所写的知识变为自己的。 我写这些博客也是借鉴了大神，看完了他写一天一道面试题，不由得感慨自己见识短浅，写作水平也是非常差劲； 所以在这里很感谢大神的分享，我也会学习他的分享精神和孜孜不倦的态度、坚持编写博客，锻炼自己的写作能力！
内存泄漏问题大家都有遇到过，从一开始的惶惶不安到最后一点点的抠出内存泄漏的点，过程很是艰辛；一开始遇到内存泄漏是无从下手的，所以我们赶紧找谷歌：
从谷歌搜索的结果来看，内存泄漏检测还是很方便的；LeakCanary这个工具我们应该使用过，很是方便，但是从检测到的结果来看，我们并不能很清晰的看到哪些地方我们内存泄漏了。所以我们得使用一些工具来检测：
- Android Studio
- Android Profiler
- MAT
检测内存泄漏点
当一个APP已成形，界面有几十上百个之后，内存泄漏的检测只能说难上加难；所以我们只能在写代码的时候，尽量有性能方面的顾虑；小问题没问题，项目一旦开始写，整个团队都付出自己最大的精力去写，如果所有人都不注意内存泄漏的点，一开始没有发现问题，后面发现问题之后就已经晚了。
之所以这样说，是因为之前有接手一个项目，已经成形项目上线了；但是在上线之后，运行APP频繁发现奔溃，当时没多想，可能是接口或者代码上有问题报异常了，后面突发奇想的想检测一些内存问题，发现了整个项目泄漏的点非常多！
因为是接手的项目，所以检测内存泄漏只能每个页面点一下查看内存问题；该项目是由五个Tab页面组成，一级界面再分发为二级多级界面，相信大家都有过类似的项目（这里不作具体展示，公司外面的接手项目不便）；现在我们使用Android studio 中的Android Profiler查看内存使用情况：
界面有几十个，刚刚开始启动页面只有五个子页面Fragment懒加载，内存很平稳，当点击多个页面之后，页面开始飙升，这是正常的现象。当我们打开很多界面之后，然后又回到应用启动开始的界面，接下来，我们点击android profiler左上角的垃圾桶按钮，回收内存：
我们看到点击回收之后，内存使用开始下降，说明不少对象被回收掉！ 但是到这里，我们并不知道内存使用情况，下面将使用profiler中的记录内存情况，点击垃圾桶旁边的按钮：
等AS自动记录完之后，将自动生成可视化的内存使用情况，我们下拉显示包名：
找到自己的包名，红框里面显示的就是当前内存中对象的个数情况，截止到现在，我们已经知道怎么去获取一段时间内内存使用情况，但是我们还是不知道哪里有内存泄漏；接下来我们就要将当前内存快照给导出一个hprof文件，使用当前界面的左上角导出按钮，生成一个hprof格式文件：
生成该文件是为了方便查找到对象的引用、个数情况，不同的对象地址个数将很清晰的检测到；不过，我们得将该文件拖动到Android Studio中，Package Tree View 同样也是根据包名来查看：
这里查看到对象的个数，我们一般查找相同对象多的，如果同一个对象在内存中多次新建，而内存垃圾回收器回收之后也同样存在，说明该对象存在内存泄漏，在这里，我们看到有很多相同的对象数量有多个，说明了该项目泄漏比较严重；同时也说明了现在很多应用都不注重性能优化，接下来我们查看某一个对象泄漏：
在这里，我们举例优化；上面红框代表当前对象有多个实例，可能是有内存泄漏的情况，具体操作我们到下一节说明！
小结
一开始大家都是码农，毕业几年之后，总发现自己不停的写业务画界面；了解了总体的编写过程之后，我们总需要作出一些改变，这就是三五年和一两年的区别。
性能优化在我们项目中有着不可或缺的地位，总不能项目上线之后，用户反馈到老板面前说Android端应用总是出现奔溃的情况吧？所以，我们得一开始就要注意，比如单例类引用Context、Handler使用，监听器注册与反注册等这些非常细节的点。
