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

2301_79655438

已于 2024-04-11 16:05:36 修改

阅读量161

点赞数 1

分类专栏： 2024年程序员学习文章标签： android

于 2024-04-11 16:05:34 首次发布

本文链接：https://blog.csdn.net/2301_79655438/article/details/137642737

版权

2024年程序员学习专栏收录该内容

185 篇文章 0 订阅

订阅专栏

//这个house就是全局变量
private var house: House? = null

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_detail)
    //这个person就是局部变量
    val person = Person()
  }

 findViewById<TextView>(R.id.button).setOnClickListener { v->
        //这个person2就是局部变量
        person2 = Person()
        Log.e("dq","create Person "+person2!!.hashCode());
    }

}


* Activity中定义的**全局变量**，如果不为null，那么只能在 Activity 的onDestory()的5秒后被GC释放内存，**xml里的View的内存机制也是一样** 无论你有没有把View设置为全局变量
* Activity中定义的全局变量如果被你 = null，那么他的生命周期和**局部变量**是一样的，都是在触发GC的时候会释放内存
* 很多手机，你用代码主动调用System.gc() 毫无效果
* 如果内存不紧张，那么系统会在当前Activity走了生命周期方法（比如**onPause、onDestory**）后再过5、6秒触发GC（onDestory后5秒是一定会GC的，home回到桌面会走onPause再过5秒也会GC。但是再回来走onResume就不GC了）
* onDestory的5秒后触发了GC，Activity和全局变量才彻底被回收（即：WeakReference.get() == null)
* 系统触发GC有时候会在logcat里打印，有时候不会，虽然GC会 stop 所有线程，但是简单的GC 的pause的时长只有5ms，0.0004秒

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,String>();
                map.put("title","1");
                linklist.add(map); //72M - 88M - 105M - 121M = 每次差额为17M
            }


## 如何监听变量生命周期？

class Person : Object() {

var name: String? = null

//走了finalize方法就说明该Object被回收了
@kotlin.jvm.Throws(Throwable::class)
override fun finalize() {
    Log.e("dq","Person 被回收 " +hashCode())
}

}


## 如何监听系统GC？

public class GcWatcherInternal {

private static WeakReference<GcWatcher> sGcWatcher;

private static ArrayList<Runnable> sGcWatchers = new ArrayList<>();
private static Object lock = new Object();

private static final class GcWatcher {
    @Override
    protected void finalize() throws Throwable {
        sLastGcTime = SystemClock.uptimeMillis();
        ArrayList<Runnable> sTmpWatchers;
        synchronized (lock) {
            sTmpWatchers = sGcWatchers;
            try {
                for (int i = 0; i < sTmpWatchers.size(); i++) {
                    if (sTmpWatchers.get(i) != null) {
                        sTmpWatchers.get(i).run();
                    }
                }
            } catch (Throwable e){
                e.printStackTrace();
            }
            sGcWatcher = new WeakReference<>(new GcWatcher());
        }
    }
}

public static void addGcWatcher(Runnable watcher) {
    synchronized (lock) {
        sGcWatchers.add(watcher);
        if(sGcWatcher==null)
            sGcWatcher = new WeakReference<>(new GcWatcher());
    }
}

}

//MainActivity中写一次就好
GcWatcherInternal.addGcWatcher { Log.e(“dq”,“触发GC ！！！”) }


## 怎么优化内存



> 
> 网上别人写的什么bitmap、handle内存泄漏、静态单例 一堆乱七八糟的东西，我在这里就不写了。我就只针对上述我自己的研究成果说一下我自己的看法
> 
> 
> 


在Activity\Fragment中，无论你是否把View设为全局变量，View的生命周期都是一样的。所以性能和内存占用是一样的。


在Activity\Fragment中，没必要设为全局变量的，尽量使用局部变量，不要设为全局变量：


* 主观原因是：全局变量会让**逻辑混乱**，Activity代码看起来脏，别人接手你的代码容易改错。
* 客观原因是：只要Activity不死，全局变量不会被GC回收内存。如果你用局部变量，那么Activity只要走了任何生命周期（比如**onCreate、onPause、onResume**），这个局部变量的内存就被释放了。


确定不再需要用的全局变量，可以用代码设置为 **= null**，这样也会被及时GC回收。同理，全局变量中的全局变量，如果不需要用到了，也可以 = null。比如 this.house.image = null 。



> 
> 有一些listview\recyclerView，你为了更好的显示，不得不在model里新加你自己定义的对象。最典型的比如聊天界面的表情SpannableString，但是要注意到如果你把SpannableString放到model中，他就不会被GC释放，特别是SpannableString里带ImageSpan的（一般是表情），就会比较占内存且不会被GC
> 
> 
> 


建议的解决办法：可以用LRUCache，或者你新建一个SpareArray<**SpannableString**>，只缓存最后20条左右的SpannableString。  
 也可以最简单粗暴的 把过早的信息的Model里的spannableString = null。万一用户手动翻到最早的聊天记录，你再重新拼接spannableString。


要是实在觉得无所谓，觉得你们app用户量不大，可以用空间换时间，不处理这些问题倒也没太大问题。但是依然要注意ImageSpan（一般是表情）需要做成单一变量，不要每条聊天消息都new ImageSpan()


## 一些恶劣的代码，以及会产生什么情况



> 
> 事先声明：网上别人写的什么handle内存泄漏、静态单例 一堆乱七八糟的东西，我在这里就不写了。我就只针对上述我自己的研究成果说一下我自己的看法
> 
> 
> 


**在无限循环的Thread里访问全局变量**：由于你的Thread在无限循环，所以Thread无法被回收这是正常的，可你在Thread里调用了Activity里的变量，会导致整个Activity无法被GC回收（包括Activity的全局变量也都无法回收） 。然后关闭Activity，Activity走了onDestroy。这时候按道理5秒后会正常触发GC回收Activity。这时候严重的来了： 由于系统这次GC无法回收onDestroy（因为她被thread引用了）。系统会每2.1秒GC一次，无限的尝试去释放这个Activity。代码如下：


![](https://img-blog.csdnimg.cn/81a57823285b47fda6b737c2a45624bd.png)


* **对上面截图的补充：**  
 1、把第148行换成最简单的 this@DetailActivity，也一样会导致内存泄漏：Activity和她的所有全局变量都无法释放  
 2、每2.1秒GC一次，是冲着想释放Activity来的（并不是因为截图中的sleep两秒，这个2.1秒是系统固定的）  
 3、如果Activity还没onDestory5秒，那么上面代码不会触发GC  


**自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。**

**深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！**

**因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。**
![img](https://img-blog.csdnimg.cn/img_convert/3d53c4adf28309740f24f53bb99cbd68.png)
![img](https://img-blog.csdnimg.cn/img_convert/0066bd13ee175aab5ae4f23005ca2674.png)
![img](https://img-blog.csdnimg.cn/img_convert/589ea214733c2cdd1bc3429feeb9031a.png)
![img](https://img-blog.csdnimg.cn/img_convert/7763c23c13ba8eb88c52f83288b99178.png)
![img](https://img-blog.csdnimg.cn/img_convert/068580aa159fceb8d8cf2de6e97323ed.png)
![img](https://img-blog.csdnimg.cn/img_convert/09b0a7d76af5c881899c719f39071b37.png)
![img](https://img-blog.csdnimg.cn/13f2cb2e05a14868a3f0fd6ac81d625c.png)

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！**

**由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新**

**如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）**
![img](https://img-blog.csdnimg.cn/img_convert/9895e1ff38b8c36fb6727bedba89b479.png)



# 总结

Android架构学习进阶是一条漫长而艰苦的道路，不能靠一时激情，更不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。**所以：贵在坚持！**

上面分享的字节跳动公司2021年的面试真题解析大全，笔者还把一线互联网企业主流面试技术要点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。
![](https://img-blog.csdnimg.cn/img_convert/199b19089dd7bf411f9fe875a369b53c.webp?x-oss-process=image/format,png)



**【Android高级架构视频学习资源】**

Android部分精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！



**一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
![img](https://img-blog.csdnimg.cn/img_convert/577cda1e2be3aae416081e3b47b52967.png)
上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！



**一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
[外链图片转存中...(img-3E3t8SgU-1712822718469)]

2301_79655438

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Android 变量生命周期、变量内存释放机制、GC触发时机研究、内存优化建议_background young concurrent copying gc freed

/内存变化：79M - 85M - 91M。//内存变化：73M - 76M - 79M - 82M。GcWatcherInternal.addGcWatcher { Log.e(“dq”,“触发GC！//每调用一次创建十万个对象，检测内存变化。//MainActivity中写一次就好。
复制链接

扫一扫