app应用内存分析

背景介绍

工作中需要用一个小窗口来滚动显示app中感兴趣的信息，原理是实现单例的信息窗口，持有消息队列，无限循环处理的客户端将感兴趣的消息加入到队列，信息显示窗口从队列里poll出队首消息显示，采用WindowManager.LayoutParams.TYPE_SYSTEM_ERROR结合ScrollView来实现。但是应用开始跑的时候很正常，过了一个突然就没了，日志中打印如下：

[16:43:35]01-29 16:43:36.122 11220 11220 D Test: set configuration
[16:43:38]01-29 16:43:38.326  2327  2341 I ActivityManager: Killing 11220:com.*.demo/1000 (adj 0): stop com.*.demo
[16:43:38]01-29 16:43:38.327  2327  2341 I Process : Sending signal Quiet. PID: 11220 SIG: 9
[16:43:38]01-29 16:43:38.547  2327  2341 D ActivityManager: cleanUpApplicationRecord -- 11220

分析验证

在app中是无限循环向窗口添加感兴趣信息，显示在浮动窗口中，那么很有可能是在集合中remove了元素，但是实际对象并没有被回收导致内存泄露，或者在无限循环中出现内存一直分配未释放。详细分析步骤参见
如何排查Java内存泄露(内附各种排查工具介绍)
JAVA 内存泄露详解（原因、例子及解决）

• 怀疑1：队列中元素过多，没及时回收
  通过打印队列数发现元素及时被处理了，而且队列中移除元素的操作没见有参考2中的方式
• 怀疑2：TextView中中无限append内存增加导致应用被杀掉？
  app中整个无限环的地方除了上面的，就是这个地方了，而且很合理。一直往 TextView中append字符串，虽然ScrollView向上滚动了，但是还在持有所有之前添加的信息
  使用Android Studio中的Android Profiler功能也可以验证上述怀疑是正确的
  app跑起来后内存在24M左右，如下图所示
  

点击Record Memory Allocations按钮后跟踪内存分配状态，找分配对象数最多地方如下图所示，发现AS直接给定位为代码了，碉堡了啊

解决方案

确定问题所在后，相应解决方案就有了，定时清空Textview中的字符
表现在窗口上即为定时会刷新下窗口