Android 接收大量数据如何避免频繁GC ？

GC会stop the world。会暂停程序的执行，带来延迟的代价。所以在开发中，我们不希望GC的次数过多。

本文将讨论如何在开发中改善各种细节，从而减少GC的次数。

(1)对象不用时最好显式置为 Null

一般而言,为 Null 的对象都会被作为垃圾处理,所以将不用的对象显式地设

为 Null,有利于 GC 收集器判定垃圾,从而提高了 GC 的效率。

(2)尽量少用 System.gc()

此函数建议 JVM进行主 GC,虽然只是建议而非一定,但很多情况下它会触发

主 GC,从而增加主 GC 的频率,也即增加了间歇性停顿的次数。

(3)尽量少用静态变量

静态变量属于全局变量,不会被 GC 回收,它们会一直占用内存。

(4)尽量使用 StringBuffer,而不用 String 来累加字符串

由于 String 是固定长的字符串对象,累加 String 对象时,并非在一个 String对象中扩增,而是重新创建新的 String 对象,如 Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+” *** 作时都必须创建新的 String 对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。 避免这种情况可以改用 StringBuffer 来累加字符串,因 StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象

(5)分散对象创建或删除的时间

集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM 在面临这种情况时,只能进行主 GC,以回收内存或整合内存碎片,从而增加主 GC 的频率。

集中删除对象,道理也是一样的。 它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主 GC 的机会。

（6） 尽量少用 finalize 函数

因为它会加大 GC 的工作量， 因此尽量少用finalize 方式回收资源。

（7） 使用软引用类型

如果需要使用经常用到的图片， 可以使用软引用类型， 它可以尽可能将图片保存在内存中， 供程序调用， 而不引起 OutOfMemory。

可以看到，单表批量写入82208条数据。

ContentProvider写入后，app造成了jvm的大量gc，并且阻塞了UI线程。

解决办法

重载实现contentProvider $ applyBatch() 时，使用事务

事务可以将多次的写入集合到一次事务当中。提高效率

applyBatch内部也时循环调用insert方法，加入insert中写有contentResolver.notifyChange逻辑时，将会造成大量的内存消耗。

1.只通知频率不高且无关业务的表更新

2.insert中加入是否正在批量插入标志符判断，当applybatch执行到最后时（期间记录数据uri），之后才执行通知

---