3W+字长文深度总结｜Android程序员面试题精华版集合（内附思维导图）！_android面试题(1)

pCITv1C

于 2024-04-20 18:38:40 发布

阅读量851

点赞数 10

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

本文链接：https://blog.csdn.net/pCITv1C/article/details/138007268

版权

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

232 篇文章 2 订阅

订阅专栏

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

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

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

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

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

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

正文

2）Stub类：Binder的实现类，服务端通过这个类来提供服务。

3）Proxy类：服务器的本地代理，客户端通过这个类调用服务器的方法。

4）asInterface()：客户端调用，将服务端的返回的Binder对象，转换成客户端所需要的AIDL接口类型对象。如果客户端和服务端位于统一进程，则直接返回Stub对象本身，否则返回系统封装后的Stub.proxy对象

5）asBinder()：根据当前调用情况返回代理Proxy的Binder对象。

6）onTransact()：运行服务端的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。

7）transact()：运行在客户端，当客户端发起远程请求的同时将当前线程挂起。之后调用服务端的onTransact()直到远程请求返回，当前线程才继续执行。

当有多个业务模块都需要AIDL来进行IPC，此时需要为每个模块创建特定的aidl文件，那么相应的
Service就会很多。必然会出现系统资源耗费严重、应用过度重量级的问题。解决办法是建立Binder连
接池，即将每个业务模块的Binder请求统一转发到一个远程Service中去执行，从而避免重复创建
Service。
工作原理：每个业务模块创建自己的AIDL接口并实现此接口，然后向服务端提供自己的唯一标识和其对应的Binder对象。服务端只需要一个Service，服务器提供一个queryBinder接口，它会根据业务模块的特征来返回相应的Binder对象，不同的业务模块拿到所需的Binder对象后就可进行远程方法的调用了

12、Activity中onNewIntent方法的调用时机和使用场景？

在该Activity的实例已经存在于Task和Back stack中(或者通俗的说可以通过按返回键返回到该Activity )时,当使用
intent来再次启动该Activity的时候,如果此次启动不创建该Activity的新实例,则系统会调用原有实例onNewIntent()
方法来处理此intent.

且在下面情况下系统不会创建该Activity的新实例:

1、如果该Activity在Manifest中的android:launchMode定义为singleTask或者singleInstance.

2、如果该Activity在Manifest中的android:launchMode定义为singleTop且该实例位于Backstack的栈顶.

3、如果该Activity在Manifest中的android:launchMode定义为singleTop,且上述intent包含Intent.FLAG_ACTIVITY_CLEAR_TOP标志

4、如果上述intent中包含Intent.FLAG_ACTIVITY_CLEAR_TOP标志和且包含Intent.FLAG_ACTIVITY_SINGLE_TOP标志.

5、如果上述intent中包含Intent.FLAG_ACTIVITY_SINGLE_TOP 标志且该实例位于Back stack的栈顶。
上述情况满足其一,则系统将不会创建该Activity的新实例.

13、Intent传输数据的大小有限制吗？如何解决？

Intent 中的 Bundle 是使用 Binder 机制进行数据传送的, 数据会写到内核空间, Binder 缓冲区域;
Binder 的缓冲区是有大小限制的, 有些 ROM 是 1M, 有些ROM 是 2M;这个限制定义在frameworks/native/libs/binder/processState.cpp 类中 , 如果超过这个限制, 系统就会报错;

#define BINDER_VM_SIZE ((110241024) - (4096*2)) ;

因为 Binder 本身就是为了进程间频繁-灵活的通信所设计的, 并不是为了拷贝大量数据;如果非 ipc 就很简单了, static 变量, eventBus 之类的都可以;如果是 ipc, 一定要一次性传大文件, 可以用 file 或者socket;

14、说说ContentProvider、ContentResolver、ContentObserver 之间的关系？

ContentProvider：内容提供者, 用于对外提供数据,比如联系人应用中就是用了
ContentProvider：一个应用可以实现ContentProvider来提供给别的应用操作, 通过ContentResolver来操作别的应用数据

ContentResolver：内容解析者, 用于获取内容提供者提供的数据
ContentResolver.notifyChange(uri)发出消息

ContentObserver：内容监听者,可以监听数据的改变状态，观察(捕捉)特定的Uri引起的数据库的变化

ContentResolver.registerContentObserver()监听消息

概括:
使用ContentResolver来获取ContentProvider提供的数据, 同时注册ContentObserver监听数据的变化

15、说说Activity加载的流程？

App 启动流程（基于Android8.0）：

点击桌面 App图标，Launcher进程采用 BinderIPC（具体为ActivityManager.getService 获取 AMS 实例）向
system_server的AMS发起 startActivity请求，system_server 进程收到请求后，向 Zygote 进程发送创建进程的请求；

Zygote 进程 fork 出新的子进程，即 App 进程App 进程创建即初始化 ActivityThread，然后通过BinderIPC 向 system_server 进程的 AMS 发起attachApplication 请求，system_server 进程的 AMS 在收到attachApplication 请求后，做一系列操作后，通知 ApplicationThread bindApplication，然后发送H.BIND_APPLICATION 消息。

主线程收到 H.BIND_APPLICATION 消息，调用handleBindApplication 处理后做一系列的初始化操作，
初始化 Application 等，system_server 进程的 AMS 在 bindApplication 后，会调用 ActivityStackSupervisor.attachApplicationLocked，之后经过一系列操作，在 realStartActivityLocked 方法通过Binder IPC 向 App 进程发送scheduleLaunchActivity 请求；

App进程的 binder 线程（ApplicationThread）在收到请求后，通过 handler 向主线程发送LAUNCH_ACTIVITY 消息；主线程收到 message后经过 handleLaunchActivity，performLaunchActivity 方法，然后通过反射机制创建目标Activity；

通过 Activityattach方法创建 window并且和 Activity 关联，然后设置 WindowManager 用来管理 window，然后通知 Activity 已创建，即调用 onCreate，然后调用 handleResumeActivity，Activity可见

16、自定义 Handler 时如何有效地避免内存泄漏问题？

自定义的静态handler
可以加一个弱引用
还有一个主意的就是当你activity被销毁的时候如果还有消息没有发出去就remove掉吧
removecallbacksandmessages去清除Message和Runnable 加null 写在生命周的ondestroy()就行

17、哪些情况下会导致oom问题？

例如handler 在界面销毁的时候消息还未发送
file没有关流
查询到结果还没有停止
内部类持有外部类引用得不到释放
不用的对象最好null 让GC回收一下
图片资源什么的最好加一个软引用

18、一般什么情况下会导致内存泄漏问题？

资源对象没关闭造成的内存泄漏（如： Cursor、File 等）
ListView 的 Adapter 中没有使用缓存的ConvertView
Bitmap对象不在使用时调用recycle()释放内存
集合中对象没清理造成的内存泄漏（特别是 static 修饰的集合）
接收器、监听器注册没取消造成的内存泄漏
Activity 的 Context 造成的泄漏，可以使用ApplicationContext
Handler 造成的内存泄漏问题（一般由于 Handler 生命周期比其外部类的生命周期长引起的）

19、ANR 出现的场景以及解决方案？

在Android中，应用的响应性被活动管理器（Activity Manager）和窗口管理器（Window Manager）这两个系统服
务所监视。当用户触发了输入事件（如键盘输入，点击按钮等）,如果应用5秒内没有响应用户的输入事件，那么，
Android会认为该应用无响应，便弹出ANR对话框。而弹出ANR异常，也主要是为了提升用户体验。解决方案是对于耗时的操作，比如访问网络、访问数据库等操作，需要开辟子线程，在子线程处理耗时的操作，主线程主要实现UI的操作

20、谈谈Android中内存优化的方式？

关于内存泄漏，一般像单例模式的使用不当啊、集合的操作不当啊、资源的缺乏有效的回收机制啊、Handler、线程的使
用不当等等都有可能引发内存泄漏。

单例模式引发的内存泄漏：

原因：单例模式里的静态实例持有对象的引用，导致对象无法被回收，常见为持有Activity的引用

优化：改为持有Application的引用，或者不持有使用的时候传递。

集合操作不当引发的内存泄漏：

原因：集合只增不减
优化：有对应的删除或卸载操作

线程的操作不当引发的内存泄漏：

原因：线程持有对象的引用在后台执行，与对象的生命周期不一致

优化：静态实例+弱引用(WeakReference)方式，使其生命周期一致

匿名内部类/非静态内部类操作不当引发的内存泄漏：

原因：内部类持有对象引用，导致无法释放，比如各种回调

优化：保持生命周期一致，改为静态实例+对象的弱引用方式（WeakReference）

常用的资源未关闭回收引发的内存泄漏：

原因：BroadcastReceiver，File，Cursor，IO流，Bitmap等资源使用未关闭

优化：使用后有对应的关闭和卸载机制

Handler使用不当造成的内存泄漏：

原因：Handler持有Activity的引用，其发送的Message 中持有Handler的引用，当队列处理Message的时间过长会导致
Handler无法被回收

优化：静态实例+弱引用(WeakReference)方式内存

21、谈谈布局优化的技巧？

降低Overdraw（过度绘制），减少不必要的背景绘制
减少嵌套层次及控件个数
使用Canvas的clipRect和clipPath方法限制View的绘制区域
通过imageDrawable方法进行设置避免ImageView的background和imageDrawable重叠
借助ViewStub按需延迟加载
选择合适的布局类型
熟悉API尽量借助系统现有的属性来实现一些UI效果