Android 变量生命周期、变量内存释放机制、GC触发时机研究、内存优化建议_background young concurrent copying gc freed

com.dq.qkotlin: Background young concurrent copying GC freed 58306(1766KB) AllocSpace objects, 4(68KB) LOS objects, 32% free, 3959KB/5892KB, paused 5.216ms total 23.590ms

• 所以GC比你想象中频繁的多
• 如果你的Object比较简单，里面就包含几个String，int。那么这个Object占用的内存非常少，10000个Object只占用2M的内存，我当时轮询创建了1000多个局部变量Object，都没触发系统GC。也就是说这1000多个局部变量Object都在内存里没释放
• 即便如此，还是不建议你疯狂的创建局部变量，因为可能出现无连续可用内存而导致oom
• 如果你创建的局部变量非常大，就会"惊动"系统，系统会主动触发GC来回收局部变量

意外发现

如果来回频繁的上下滚动RecyclerView或ListView（即便滚动的距离非常短，没触发ViewHolder的复用）。就仅仅是手指在屏幕上快速的上下戳动10秒左右，也会触发GC（而且当时我并没有new Object()

这是唯一我发现的 Activity生命周期没改变且内存占用不紧张 的情况下也会触发GC的场景，推测可能是android底层自己处理的。

存储同样的数据，HashMap的内存占用约等于Model的3倍，我原本以为会是17倍左右，毕竟他底层是个int[16] 。但是实际测试只是3倍左右

//每调用一次创建十万个对象，检测内存变化
                for (int i = 0; i < 100000; i++) {
                    linklist.add(new Object()); //内存变化：73M - 76M - 79M  - 82M
                    linklist.add(new HashMap<String,String>()); //内存变化：79M - 85M - 91M

                    GiftBean bean = new GiftBean();
                    bean.setTitle("1");
                    linklist.add(bean); //71M - 77M - 83M - 88M - 94M = 每次差额为6M

                    HashMap<String,String> map = new HashMap<String