每日面试题分享，祝你剑指苍穹斩获Offer，2024年最新2024年最新Android面试点梳理-CSDN博客

本文链接：https://blog.csdn.net/2401_84002339/article/details/137878548

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

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

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

如果你需要这些资料，可以添加V获取：vip204888 （备注Android）

正文

###1.谈谈ThreadLocal用法和原理？

ThreadLocal用于保存某个线程共享变量：对于同一个static ThreadLocal，不同线程只能从中get，set，remove自己的变量，而不会影响其他线程的变量。

1、ThreadLocal.get: 获取ThreadLocal中当前线程共享变量的值。
2、ThreadLocal.set: 设置ThreadLocal中当前线程共享变量的值。
3、ThreadLocal.remove: 移除ThreadLocal中当前线程共享变量的值。
4、ThreadLocal.initialValue: ThreadLocal没有被当前线程赋值时或当前线程刚调用remove方法后调用get方法，返回此方法值。

###2.自定义Handler时如何有效地避免内存泄漏问题？

1.自定义的静态处理器
2.可以加一个弱引用
3.还有一个主意的就是当你活动被销毁的时候如果还有消息没有发出去就删除掉吧
4.远程回发消息去清除Message和Runnable加NULL写在生命周的ondelete()就行

问题原因:一般非静态内部类持有外部类的引用的情况下，造成外部类在使用完成后不能被系统回收内存，从而造成内存泄漏.这里Handler持有外部类Active的引用，一旦Activity被销毁，而此时Handler依然持有Activity引用，就会造成内存泄漏。

解决方案:将Handler以静态内部类的形式声明，然后通过弱引用的方式让Handler持有外部类Activity的引用，这样就可以避免内存泄漏问题了：

private var mHandler: Handler? = WithoutLeakHandler(this)

companion object {
const val CODE_LOAD_DATA: Int = 101
private class WithoutLeakHandler( activity: EditAddressActivity) : Handler(){
private var mActivity: WeakReference = WeakReference(activity)

override fun handleMessage(msg: Message) {
super.handleMessage(msg)
val activity = mActivity.get()
when(msg.what){

CODE_LOAD_DATA -> {
//data load started

}

}
}
}
}

…

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
mHandler?.sendEmptyMessage(CODE_LOAD_DATA)
}

**拓展:**如果在非自定义Handler情况下，还可以通过Activity生命周期来及时清除消息，从而及时回收活动：

override fun onDestroy() {
super.onDestroy()
if (mHandler != null){
mHandler?.removeCallbacksAndMessages(null)
}
}

使用弱引用是对的，静态内部类也是对的.

问题2：不使用这些方法，Handler直接持有Activity的引用是否一定会导致内存泄漏？

1.如果Handler中没什么耗时操作，任务完成也就释放了Activity引用.
2.如果Handler中是一个2秒的操作，在活动退出的2s后，释放了活动的指
针，这种情况属于短时间的内存泄漏？
3.处理程序中是啥死循环的话，就内存泄露了.

个人写的Handler，且没有耗时操作.没必要保护.
公司项目对于代码规范的话，还是加上保护比较好.避免后续有同事，加上了耗时操作，出现问题.

正常情况下是不会内存泄漏的，除非处理程序队列等待太久(什么情况会这样呢？ANR？延时太久？)

理解到泄漏的原因(处理程序持有了活动，然后消息持有处理程序，然后MQ持有消息)，持有链了解清楚了也就好解决了：处理程序持有活动可以通过弱引用或者内部静态类等方式解决，远程向量回发消息则是清除后面的引用。

其实却是内存大，泄漏点也没啥，只是规范使然，就像过马路最好走斑马线，不然说不定哪天就被撞死了

###3.一般什么情况下会导致内存泄漏问题？

1.资源对象没关闭造成的内存泄漏(如：Cursor、File(等)

2.ListView的适配器中没有使用缓存的转换视图

ListView的适配器中没有使用缓存的转换视图。因为前两天刚看了列表视图源码，转换视图其实是滑出屏幕的视图的缓存，不使用转换视图会频繁创建新的视图对象，只会造成内存溢出，而不是内存泄漏。这个问题我们首先要明白内存泄漏的真正原因：A对象引用B对象，但是A对象的生命周期比B对象的生命周期长的多B生命周期到了还在被A引用，导致B对象不能回收，从而引起内存泄漏

3.Bitmap对象不在使用时调用循环()释放内存
4.集合中对象没清理造成的内存泄漏(特别是static(修饰的集合)
5.接收器、监听器注册没取消造成的内存泄漏
6.Activity 的 Context造成的泄漏，可以使用ApplicationContext
7.Handler造成的内存泄漏问题(一般由于Handler(生命周期比其外部类的生命周期长引起的)

###4.哪些情况下会导致oom问题？
1、根据java的内存模型会出现内存溢出的内存有堆内存、方法区内存、虚拟机栈内存、本机方法区内存；

2、一般说的OOM基本都是针对堆内存；

3、对于堆内存溢出主的根本原因有两种: