Android面试常见问题总结

你的名字 2021-12-03 03:01 388阅读 0赞

**1、AsyncTask是什么？ 有什么缺陷？**  
AsyncTask是一种轻量级的异步任务类，它可以在线程池中执行后台任务，然后把执行的进度和最终结果传递给主线程并在主线程中更新UI。多个AsyncTask对象是串行执行的。Android 1.5刚开始引入AsyncTask的时候，execute方法确实是串行执行的，类定义里面只有SERIAL\_EXECUTOR线程池；到1.6版本时，改用并行线程池THREAD\_POOL\_EXECUTOR，再到3.0版本至今，就成了上面说的模样————定义两个线程池，但是默认用串行池。  
缺陷：1)生命周期，当activity销毁时，AsynTask会一直执行，直到doInBackground()方法执行完毕，持有activity的引用，造成 内存泄漏  
解决方案：第一，在Activity生命周期结束前，去cancel AsyncTask  
第二，如果一定要写成内部类的形式，对context采用WeakRefrence,在使用之前判断是否为空。

**2、HandlerThread原理**  
当系统中有多个耗时任务需要执行时，每个任务都会开启新的线程去执行耗时任务，这样会造成系统多次创建和销毁线程，影响系统性能。为了解决这个问题，google提出了HandlerThread，它本质是一个线程类，继承于Thread。  
HandlerThread有自己的内部Looper对象，可以进行loopr循环。通过获取HandlerThread的looper对象传递给Handler对象，可以在handleMessage()方法中执行异步任务。创建HandlerThread后必须先调用HandlerThread.start()方法，Thread会先调用run方法，创建Looper对象。当有耗时任务进入队列时，则不需要开启新线程，在原有的线程中执行耗时任务即可，否则线程阻塞。它在Android中的一个具体的使⽤场景是IntentService。  
2）HanlderThread的优缺点  
HandlerThread优点是异步不会堵塞，减少系统创建线程和销毁线程对性能的消耗。  
HandlerThread缺点是不能同时继续进行多任务处理，要等待进行处理，处理效率较低。 HandlerThread与线程池不同，HandlerThread是一个串队列，背后只有一个线程。  
3）怎样使⽤HandlerThread？  
a. 创建HandlerThread的实例对象 HandlerThread handlerThread = newHandlerThread(“myHandlerThread”); 该参数表示线程的名字，可以随便选择。  
b. 启动我们创建的HandlerThread线程 handlerThread.start();  
c. 将handlerThread与Handler绑定在一起。即将线程的looper与Handler绑定在一起，在handleMessage()中处理任务。

**3、IntentService**  
IntentService是一种特殊的Service，它继承了Service并且它是一个抽象类，因此必须创建它的子类才能使用IntentService  
原理  
在实现上，IntentService封装了HandlerThread和Handler。当IntentService被第一次启动时，它的onCreate()方法会被调用，onCreat()方法会创建一个HandlerThread，  
然后使用它的Looper来构造一个Handler对象mServiceHandler，这样通过mServiceHandler发送的消息最终都会在HandlerThread中执行。  
生成一个默认的且与主线程互相独立的工作者线程来执行所有传送至onStartCommand()方法的Intetnt。  
生成一个工作队列来传送Intent对象给onHandleIntent()方法，同一时  
刻只传送一个Intent对象，这样一来，你就不必担心多线程的问题。在所有的请求(Intent)都被执行完以后会自动停止服务，  
所以，你不需要自己去调用stopSelf()方法来停止。

**4、Binder机制**  
Binder是Android系统进程间通信(IPC)方式之一。  
Binder使用Client－Server通信方式。Binder框架定义了四个角色：Server,Client,ServiceManager以及Binder驱动。  
其中Server,Client,ServiceManager运行于用户空间，驱动运行于内核空间。Binder驱动程序提供设备文件/dev/binder与用户空间交互，Client、Server和Service Manager通过open和ioctl文件操作函数与Binder驱动程序进行通信。  
其中Client、Server、Service Manager运行在用户空间，Binder驱动程序运行内核空间。Binder就是一种把这四个组件粘合在一起的粘连剂了，其中，核心组件便是Binder驱动程序了，ServiceManager提供了辅助管理的功能，Client和Server正是Binder驱动和ServiceManager提供的基础设施上，进行Client-Server之间的通信。  
Client和Server之间的进程间通信通过Binder驱动程序间接实现  
ServiceManager是一个守护进程，用来管理Server，并向Client提供查询Server接口的能力

Binder通信的四个角色  
Client进程：使用服务的进程。  
Server进程：提供服务的进程。  
ServiceManager进程：ServiceManager的作用是将字符形式的Binder名字转化成Client中对该Binder的引用，使得Client能够通过 Binder名字获得对Server中Binder实体的引用。  
Binder驱动：驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和 交互等一系列底层支持。

Client/Server/ServiceManage之间的相互通信都是基于Binder机制。既然基于Binder机制通信，那么同样也是C/S架构，则图中的3大步骤都有相应的Client端与Server端。

注册服务(addService)：Server进程要先注册Service到ServiceManager。该过程：Server是客户端，ServiceManager是服务端。

获取服务(getService)：Client进程使用某个Service前，须先向ServiceManager中获取相应的Service。该过程：Client是客户端，ServiceManager是服务端。

使用服务：Client根据得到的Service信息建立与Service所在的Server进程通信的通路，然后就可以直接与Service交互。该过程：client是客户端，server是服务端。

**5、事件分发机制**  
4个touch事件，down/move/cancle/up  
在Activity/ViewGroup/view中进行传递，  
分发过程由dispatchTouchEvent()、onInterceptTouchEvent()和onTouchEvent()完成  
返回true表示消费事件，不继续往下传递  
如果都是不消费事件的话,就是一个完整的U型状态 事件依次  
是:Activity.dispatchTouchEvent -->ViewGroup.dispatchTouchEvent— >ViewGroup.onInterceptTouchEvent—>View.dispatchTouchEvent  
— >View.onTouchEvent—>ViewGroup.onTouchEvent—>Activity.onTouchEvent

三个方法的关系可以用如下伪代码表示：

public boolean dispatchTouchEvent(MotionEvent event)  
\{  
boolean consume = false;  
if(onInterceptTouchEvent(ev))  
\{  
consume = onTouchEvent(ev);  
\}  
else  
\{  
consume = child.dispatchTouchEvent(ev);  
\}  
return consume;  
\}

OnTouchListener的优先级比onTouchEvent要高  
如果给一个view设置了OnTouchListener，那么OnTouchListener中的onTouch方法会被回调。这时事件如何处理还要看onTouch的返回值，  
如果返回false，那么当前view的onTouchEvent方法会被调用；如果返回true，那么onTouchEvent方法将不会被调用。 在onTouchEvent方法中，  
如果当前view设置了OnClickListener，那么它的onClick方法会被调用，所以OnClickListener的优先级最低。

**6、SystemUI启动流程**  
开机–>启动SystemServer，在其MainThread中启动AMS–>AMS.systemReady后–>startSystemUI()–>startServiceUIAsUser()  
–>启动服务的OnCrete中调用systemUIApplication的startServicesIfNeeded方法。  
这个方法会调用 startServicesIfNeeded(SERVICES)方法启动一系列服务(并不是真正的service,都继承自SystemUI)。比如截图服务，usb，锁屏，状态栏  
[https://www.jianshu.com/p/1a1c53cc44c3][https_www.jianshu.com_p_1a1c53cc44c3]  
[https://blog.csdn.net/foreverjqq/article/details/76268404][https_blog.csdn.net_foreverjqq_article_details_76268404]

**7、Setting**  
[https://blog.csdn.net/csdnxialei/article/details/86555050][https_blog.csdn.net_csdnxialei_article_details_86555050]  
[https://blog.csdn.net/foreverJQQ/article/details/77067560][https_blog.csdn.net_foreverJQQ_article_details_77067560]  
[https://blog.csdn.net/wzy\_1988/article/details/50556113][https_blog.csdn.net_wzy_1988_article_details_50556113]

**8、view的测量和绘制原理**  
View的绘制流程是从ViewRoot的performTraversals方法开始的，它经过measure、layout、draw三个过程才能最终将一个View绘制出来，其中measure用来测量View的宽和高，  
layout用来确定View在父容器的放置位置，而draw则负责将View绘制在屏幕上。  
View的绘制是从上往下一层层迭代下来的。DecorView–>ViewGroup（— >ViewGroup）–>View ，按照这个流程从上往下，依次measure(测量),layout(布局),draw(绘制)。

**9、LeakCanary 内存泄露监测原理研究**  
[https://www.jianshu.com/p/261e70f3083f][https_www.jianshu.com_p_261e70f3083f]  
监测机制利用了Java的WeakReference和ReferenceQueue，通过将Activity包装到WeakReference中，被WeakReference包装过的Activity对象  
如果被回收，该WeakReference引用会被放到ReferenceQueue中，通过监测ReferenceQueue里面的内容就能检查到Activity是否能够被回收

**10、Activity的启动模式以及应用场景**  
standard启动模式，不管有没有已存在的实例，都生成新的实例  
singleTop启动模式，如果发现有对应的Activity实例正位于栈顶，则重复利用，不再生成新的实例，如果没有就重新生产新实例。  
singleTask模式，如果发现task中有对应的Activity实例，则使此Activity实例之上的其他Activity实例全部出栈，使此Activity成为栈顶对象，显示于界面。  
singleInstance模式是将该Activity放入一个新的返回栈，等旧返回栈没有返回任务时，就调用该返回栈。

**11、Android消息处理机制Handler**  
在子线程执行完耗时操作，当Handler发送消息时，将会调用MessageQueue.enqueueMessage，向消息队列中添加消息。当通  
过Looper.loop开启循环后，会不断地从线程池中读取消息，即调用MessageQueue.next，然后调用目标Handler（即发送该消息的Handler）的  
dispatchMessage⽅法传递消息，然后返回到Handler所在线程，⽬标Handler收到消  
息，调用handleMessage方法，接收消息，处理消息。

**12、Handler如何实现线程的切换**  
Handler机制其实就是借助共享变量来进行线程切换的  
消息发送的过程，我们在不同的线程发送消息，线程之间的资源是共享的.Handler中我们使用的是同一个MessageQueue对象，同一时间只能一个线程对消息进行入队操作。  
消息存储到队列中后，主线程的Looper还在一直循环loop()处理。这样主线程就能拿到子线程存储的Message对象，在我们没有看见的时候完成了线程的切换。

**13、广播的原理**  
广播使用了设计模式中的观察者模式，基于消息的发布/订阅事件模型  
原理描述：

1.  广播接收者 通过 Binder机制在 AMS 注册
2.  广播发送者 通过 Binder机制向 AMS 发送广播
3.  AMS 根据 广播发送者 要求，在已注册列表中，寻找合适的广播接收者 寻找依据：IntentFilter / Permission
4.  AMS将广播发送到合适的广播接收者相应的消息循环队列中
5.  广播接收者通过 消息循环 拿到此广播，并回调onReceive()  
    注册方式分为静态注册和动态注册，两种的优缺点

**14、Activity启动流程**  
应用启动  
大致流程如下：  
1、点击桌面图标，Launcher会启动程序默认的Acticity，之后再按照程序的逻辑启动各种Activity  
2、启动Activity都需要借助应用程序框架层的ActivityManagerService服务进程(Service也是由ActivityManagerService进程来启动的)；  
在Android应用程序框架层中，ActivityManagerService是一个非常重要的接口，  
它不但负责启动Activity和Service，还负责管理Activity和Service。  
Step 1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，  
都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口；  
Step 2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息；  
Step 3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，  
对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，  
而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了；  
Step 4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，  
看看是否需要创建新的进程来启动Activity；  
Step 5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，  
而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，  
因为新的Activity就在原来的Activity所在的进程中进行启动；  
Step 6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作；  
Step 7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。

以微信启动为例  
1.Launcher通知AMS 要启动微信了，并且告诉AMS要启动的是哪个页面也就是首页是哪个页面  
2.AMS收到消息告诉Launcher知道了，并且把要启动的页面记下来  
3.Launcher进入Paused状态，告诉AMS，你去找微信吧  
上述就是Launcher和AMS的交互过程  
4.AMS检查微信是否已经启动了也就是是否在后台运行，如果是在后台运行就直接启动，如果不是，AMS会在新的进程中创建一个ActivityThread对象，并启动其中的main函数。  
5.微信启动后告诉AMS，启动好了  
6.AMS通过之前的记录找出微信的首页，告诉微信应该启动哪个页面  
7.微信按照AMS通知的页面去启动就启动成功了。

**15、应用启动优化方案**  
冷启动优化  
1.减少在第一个页面中的onCreate方法中的工作量。  
2.不要让Application参与业务的操作。  
3.不要再Application中进行耗时的操作。  
4.优化界面布局，避免过度绘制。(stubview,merge)  
5.白屏/黑屏优化方案，在第一个启动页面处设置window主题（先创建decorview，和window，后面再添加activity的view。）

**16、什么是Low Memory Killer策略**  
[https://www.jianshu.com/p/5e9354506d34][https_www.jianshu.com_p_5e9354506d34]  
LowMemoryKiller 策略就是指那些被退出到后台的App，并不是不会被清理掉的，指是可能没有持有任何组件，不占用CPU资源，少量占用内存空间。当系统认为内存空间不同时，  
会根据 LRU List 的列表来进行有先后顺序的清理工作，回收一些内存空间，供新启动的程序使用。  
基于 LowMemoryKiller 策略，那么，为了让我们的App尽可能地存活下来，不被系统杀死。那就有两种方法：  
a、提高进程优先级  
b、降低内存占用

**17.Android性能分析工具**

[https://www.cnblogs.com/1996swg/archive/2018/11/23/10007602.html][https_www.cnblogs.com_1996swg_archive_2018_11_23_10007602.html] Android性能分析工具systrace使用

[https://blog.csdn.net/itfootball/article/details/44040801][https_blog.csdn.net_itfootball_article_details_44040801] Android性能测试中各种数据的获取方式

[https://blog.csdn.net/itfootball/article/details/48792435][https_blog.csdn.net_itfootball_article_details_48792435] Android性能专项测试之TraceView工具(Device Monitor)

**18.TraceView工具能做什么？**  
从代码层面分析性能问题，针对每个方法来分析，比如当我们发现我们的应用出现卡顿的时候，我们可以来分析出现卡顿时在方法的调用上有没有很耗时的操作，关注以下两个问题：  
1、调用次数不多，但是每一次执行都很耗时  
2、方法耗时不大，但是调用次数太多  
简单一点来说就是我们能找到频繁被调用的方法，也能找到执行非常耗时的方法，前者可能会造成Cpu频繁调用，手机发烫的问题，后者就是卡顿的问题

[https_www.jianshu.com_p_1a1c53cc44c3]: https://www.jianshu.com/p/1a1c53cc44c3
[https_blog.csdn.net_foreverjqq_article_details_76268404]: https://blog.csdn.net/foreverjqq/article/details/76268404
[https_blog.csdn.net_csdnxialei_article_details_86555050]: https://blog.csdn.net/csdnxialei/article/details/86555050
[https_blog.csdn.net_foreverJQQ_article_details_77067560]: https://blog.csdn.net/foreverJQQ/article/details/77067560
[https_blog.csdn.net_wzy_1988_article_details_50556113]: https://blog.csdn.net/wzy_1988/article/details/50556113
[https_www.jianshu.com_p_261e70f3083f]: https://www.jianshu.com/p/261e70f3083f
[https_www.jianshu.com_p_5e9354506d34]: https://www.jianshu.com/p/5e9354506d34
[https_www.cnblogs.com_1996swg_archive_2018_11_23_10007602.html]: https://www.cnblogs.com/1996swg/archive/2018/11/23/10007602.html
[https_blog.csdn.net_itfootball_article_details_44040801]: https://blog.csdn.net/itfootball/article/details/44040801
[https_blog.csdn.net_itfootball_article_details_48792435]: https://blog.csdn.net/itfootball/article/details/48792435