【AndroidFrameWork】综合面试问题，作为一个Android开发者

• 用于检查死锁或者线程异常

• BlockCanary

• 开源框架&＃xff0c;用于检查线程是否有耗时任务

WatchDog WatchDog的作用上面说过&＃xff1a;一是检查是否发生了死锁&＃xff0c;二是检查线程是否被任务blocked

• WatchDog是一个线程

• 看下WatchDog的关键变量&＃xff1a;

• mHandlerCheckers是核心列表&＃xff0c;添加了多个HandlerChecker

• 每一个Checker都对应了一个线程&＃xff0c;比如主线程、前台线程、IO线程等&＃xff0c;这几个线程都是system_server中非常重要的工作线程

• 每一个HandlerChecker下都有一个Monitor列表

• addMonitor实质上是向mMonitorChecker加了一个BinderThreadMonitor&＃xff0c;用于检测binder线程是否正常

• 

看下下图

• 第一个MonitorChecker用户检查系统服务是否发生了死锁&＃xff0c;在单独的线程中检查&＃xff0c;

• 原理就是在另外的线程中去尝试拿到锁&＃xff0c;拿到了就正常返回

• 如果一直拿不到&＃xff0c;就可能是产生了死锁问题

• 如图AMS中代码细节

• 同时服务还会把自己的工作线程new一个HandlerChecker&＃xff0c;也注册到watchDog&＃xff0c;每一个handlerChecker都会对应一个线程&＃xff0c;在线程中派发handlerChecker

BlockCanary 原理就是通过messageLogging在消息分发前后的时间戳打印&＃xff0c;利用时间戳的差算出消息执行耗时

5. 怎么同步处理消息

「同步处理消息」&＃xff1a;我们发了一个消息到另外一个线程去处理&＃xff0c;并没有直接返回&＃xff0c;而是挂在那里等待消息处理完毕&＃xff0c;有些时候还需要拿到消息处理结果&＃xff0c;这就是同步处理消息

适用场景如图124

应用要访问另一个进程的服务&＃xff0c;请求会调到服务进程的binder线程池中&＃xff0c;binder线程切换到工作线程处理请求&＃xff0c;工作线程工作的时候binder线程会一直等待&＃xff0c;应用端也会一直等着&＃xff0c;等到处理完成后返回结果给给应用

6. 你去了解framework是为了解决一个什么样的问题&＃xff0c;怎么解决的&＃xff1f;

考察点

• 你有没有解决复杂问题的经验

• 你有没有深入研究底层原理的习惯

• 你的知识体系是否有一定深度

7. 应用组件相关题目

• 为什么Activity在onResume之后才会显示出来

• ActivityThread handleResumeActivity时WindowManager才会addView并makeVisible

• bindService的时候Rebind总是调不到&＃xff0c;研究原理

• TODO

• 广播onReceive的context可否启动Activity, 显示Dialog?

• TODO

• 发现provider的onCreate比Application还早,研究一下

• Application 构造方法 –> Application.attachBaseContext –> ContentProvider.onCreate –> Application.onCreate –> Activity.onCreate

• 看下 ActivityThread.java 的 handleBindApplication方法&＃xff1a;

• 图130

8. 消息通信相关题目

• intent带的数据量大了会异常&＃xff0c;研究原因

• binder机制 1m限制

• 需要跨进程传大图&＃xff0c;研究Bitmap传输原理&＃xff0c;Ashmem机制

• 想知道Handler消息延时的精度怎么样&＃xff0c;去了解原理

• 延迟处理不是延迟发送&＃xff0c;精度不太准确

• 为什么有时候IdleHandler调不到&＃xff0c;去了解原理

• 主线程繁忙&＃xff0c;一直在处理消息

• 比如&＃xff1a;

• 在View的onDraw方法里面无限制的直接或者间接调用View的invalidate方法。

• 做一个无限轮询的View动画。

9.性能优化相关题目

• ANR了&＃xff0c;看主线程是否有耗时任务

• 卡顿掉帧&＃xff0c;了解屏幕刷新机制&＃xff0c;研究Choregrapher

• 启动速度优化&＃xff0c;了解应用启动原理

• 内存优化&＃xff0c;清理不必要的资源

10. Android FrameWork用到了哪些设计模式&＃xff1f;请举例说明

单例模式

• Framework中&＃xff1a;SingleTon类&＃xff0c;应用IAM

• 

• 线程内:

• 线程间/进程内&＃xff1a;Choreographer&＃xff0c;ThreadLocal线程私有&＃xff0c;不同线程获取不同的实例&＃xff0c;同一线程获取同一实例

• 图125

125.png

• 进程间&＃xff1a;

• 进程间的内存是相互隔离的&＃xff0c;如何保证在进程间的单例呢&＃xff0c;这个时候就需要一个中间人&＃xff0c;所谓的中间人&＃xff0c;就是他可以和所有进程进行通信&＃xff0c;由其确保这个对象是单例的

• 下面的例子中&＃xff0c;单例是ServiceManager&＃xff0c;中间人是binder驱动

• 对所有的进程来说&＃xff0c;ServiceManager对应的binder句柄都是一个即0&＃xff0c;这样binder驱动在转发请求的时候都会送往同一个目标&＃xff0c;即ServiceManager所在的进程&＃xff0c;这样就能保证ServiceManager是跨进程单例的

• 图127

观察者模式

• 分为进程内和跨进程两种

• 应用&＃xff1a;

• 广播(同时支持进程内和进程间)

• 推送&＃xff08;基于网络&＃xff09;

• 应用层

• Rxjava

• RecyclerView&＃xff1a;Adapter的notifyChanged、notifyItemChanged等

代理模式

• 静态代理

• ActivityManagerProxy

• IActivityManager的接口调用都会转交给mRemote

• 128

• 动态代理

11.Framework中有什么你觉得设计很巧妙的地方&＃xff0c;请举例说明

1. Binder调用&＃xff0c;模糊进程边界&＃xff0c;让IPC调用像在一个进程中一样简单&＃xff0c;使开发者不必过分关注跨进程通信的事&＃xff0c;将重点放在业务上

• 请求的转发&＃xff1a;请求由应用端发起&＃xff0c;通过binder驱动转发给目标进程去处理&＃xff0c;目标进程处理完毕之后&＃xff0c;会把返回结果通过binder驱动传回Client端

• binder对象的传递&＃xff1a;包含实体对象和引用对象&＃xff0c;这两种实体在经过binder驱动层的时候会自动转换&＃xff0c;比如binder实体对象跨进程之后就变成了代理对象&＃xff0c;代理对象回到实体对象所在的进程之后又会还原为实体对象&＃xff1b;不论实体对象还是代理对象&＃xff0c;应用层拿到的都是统一的接口对象&＃xff0c;方便调用

2. Bitmap大图传输&＃xff0c;高性能

• 传递匿名共享内存的句柄&＃xff0c;到了目标进程之后映射内存&＃xff0c;这样目标进程就能获取bitmap的像素数据

3. Zygote预加载资源创建应用进程&＃xff0c;共享资源&＃xff0c;这样应用进程就不必重复加载资源

• init进程启动后&＃xff0c;会启动一些系统服务和Zygote进程zygote预加载资源&＃xff08;系统主题资源&＃xff0c;常用的类等 &＃xff09;并启动system_server&＃xff0c;并开启循环等待socket请求&＃xff0c;孵化应用进程

• 图129

129.png

4. Intent解耦&＃xff0c;模糊进程边界&＃xff0c;把调用者和组件之间进行解耦

• 应用只需要表达自己的意图&＃xff0c;由AMS选择处理意图的组件

• 调用者和组件之间可能是同一进程的&＃xff0c;也可能不是同一进程的
  后&＃xff0c;会启动一些系统服务和Zygote进程zygote预加载资源&＃xff08;系统主题资源&＃xff0c;常用的类等 &＃xff09;并启动system_server&＃xff0c;并开启循环等待socket请求&＃xff0c;孵化应用进程

• 图129

129.png

4. Intent解耦&＃xff0c;模糊进程边界&＃xff0c;把调用者和组件之间进行解耦

• 应用只需要表达自己的意图&＃xff0c;由AMS选择处理意图的组件

• 调用者和组件之间可能是同一进程的&＃xff0c;也可能不是同一进程的