1、Activity和Fragment生命周期有哪些？
oncreate（）：做一些初始化相关工作，加载视图。
onstart（）：页面已经初始化完成，页面还处在后台，看不见也不能交互
onresume（）：页面从后台进入前台，可以和用户交互
onpause（）：页面还在前台能看见，但是不能交互，比如弹窗，这里最好不要做缓存持久化操作，因为会影响打开页面的速度
onstop（）：页面进入后台，看不见，可以做些缓存数据持久化操作
ondestroy（）：页面进入销毁阶段，可以做些资源回收操作
2、横竖屏切换时Activity的生命周期
不设置Activity的android:configChanges时，切屏会重新回调各个生命周期，切横屏时会执行一次，切竖屏时会执行两次。 设置Activity的android:configChanges=”orientation”时，切屏还是会调用各个生命周期，切换横竖屏只会执行一次 设置Activity的android:configChanges=”orientation |keyboardHidden”时，切屏不会重新调用各个生命周期，只会执行onConfigurationChanged方法
3、onSaveInstanceState() 与 onRestoreIntanceState()
Activity的 onSaveInstanceState() 和 onRestoreInstanceState()并不是生命周期方法，它们不同于 onCreate()、onPause()等生命周期方法，它们并不一定会被触发。当应用遇到意外情况（如：内存不足、用户直接按Home键）由系统销毁一个Activity时，onSaveInstanceState() 会被调用。但是当用户主动去销毁一个Activity时，例如在应用中按返回键，onSaveInstanceState()就不会被调用。因为在这种情况下，用户的行为决定了不需要保存Activity的状态。通常onSaveInstanceState()只适合用于保存一些临时性的状态，而onPause()适合用于数据的持久化保存。 在activity被杀掉之前调用保存每个实例的状态,以保证该状态可以在onCreate(Bundle)或者onRestoreInstanceState(Bundle) (传入的Bundle参数是由onSaveInstanceState封装好的)中恢复。这个方法在一个activity被杀死前调用，当该activity在将来某个时刻回来时可以恢复其先前状态。 例如，如果activity B启用后位于activity A的前端，在某个时刻activity A因为系统回收资源的问题要被杀掉，A通过onSaveInstanceState将有机会保存其用户界面状态，使得将来用户返回到activity A时能通过onCreate(Bundle)或者onRestoreInstanceState(Bundle)恢复界面的状态
4、Bunder传递对象为什么需要序列化？Serialzable和Parcelable的区别？
因为bundle传递数据时只支持基本数据类型，所以在传递对象时需要序列化转换成可存储或可传输的本质状态（字节流）。序列化后的对象可以在网络、IPC（比如启动另一个进程的Activity、Service和Reciver）之间进行传输，也可以存储到本地。
Serializable（Java自带）：
Serializable 是序列化的意思，表示将一个对象转换成存储或可传输的状态。序列化后的对象可以在网络上进传输，也可以存储到本地。
Parcelable（android专用）：
除了Serializable之外，使用Parcelable也可以实现相同的效果，不过不同于将对象进行序列化，Parcelable方式的实现原理是将一个完整的对象进行分解，而分解后的每一部分都是Intent所支持的数据类型，这也就实现传递对象的功能了。
可以肯定的是，两者都是支持序列化和反序列化的操作。
两者最大的区别在于 存储媒介的不同，Serializable 使用 I/O 读写存储在硬盘上，而 Parcelable 是直接 在内存中读写。很明显，内存的读写速度通常大于 IO 读写，所以在 Android 中传递数据优先选择 Parcelable。
Serializable 会使用反射，序列化和反序列化过程需要大量 I/O 操作， Parcelable 自已实现封送和解封（marshalled &unmarshalled）操作不需要用反射，数据也存放在 Native 内存中，效率要快很多。
5、context相关内容：
Context 本身是一个抽象类，主要实现类为 ContextImpl，另外有子类 ContextWrapper 和 ContextThemeWrapper
Context是Android应用程序与系统环境进行交互的桥梁，主要实现类是ContextImpl, 可以访问应用程序资源/启动组件/访问系统服务/访问应用程序的文件等，而Context可以分为三种：ContextImpl/ContextWrapper/ContextThemeWrapper，不同ContextImpl 是Context的主要实现类，ContextWrapper是简单的包装类，所有的实现都由其内部的mBase成员完成，ContextThemeWrapper继承自ContextWrapper ，它的主要继承者是Activity，和其他两个Context不同的是，他内部对应用资源和主题有不同的行为，在应用中使用跟主题相关的Context时，最好使用activity，而不要使用getBaseContext或者applictaion.
service和application的context启动activity需要加上FLAG_ACTIVITY_NEW_TASK这个flag，个人理解activity的context启动activity是默认添加到自己所在的栈中，而service和application没有activity栈的概念。
6、IntentService和HandlerThread
handlerThread是继承了Thread，创建了自己线程的loop，可以用来执行心跳或者定时任务
IntentService处理异步请求，内部是由handlerThread实现的，在onHandleIntent中处理耗时操作，多个耗时任务会依次执行，执行完毕自动结束，已经被弃用了，可以使用WorkManage替代
7、怎么在Service中创建Dialog对话框？
1.在我们取得Dialog对象后，需给它设置类型，即：
dialog.getWindow().setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT)
2.在Manifest中加上权限:
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINOW" />
8、Asset目录与res目录的区别？
assets：不会在 R 文件中生成相应标记，存放到这里的资源在打包时会打包到程序安装包中。（通过 AssetManager 类访问这些文件）
res：会在 R 文件中生成 id 标记，资源在打包时如果使用到则打包到安装包中，未用到不会打入安装包中。
res/anim：存放动画资源。
res/raw：和 asset 下文件一样，打包时直接打入程序安装包中（会映射到 R 文件中）。
9、Handler相关
消息队列是一个单链表，里面的消息是按照消息执行时间when排序的，在enqueueMessage中对新加入的消息进行排序。
关于loop死循环问题：
这里就涉及到Linux pipe/epoll机制，简单说就是在主线程的MessageQueue没有消息时，便阻塞在loop的queue.next()中的nativePollOnce()方法里，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生，通过往pipe管道写端写入数据来唤醒主线程工作。这里采用的epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质是同步I/O，即读写是阻塞的。所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。
同步屏障相关问题：
首先同步屏障是通过一个target为null的message来实现的，也就是说，开启同步屏障回往消息队列中添加一个target==null的message，当执行到这个消息时，会在消息队列中寻找异步消息，即isAsynchronous==true的消息，然后派发出去，由对应的handler执行，如果没有移除同步屏障那么同步消息一直得不到执行，移除同步屏障也就是移除添加同步屏障时的那个target==null的消息。
9、线程池的相关知识。
Android中的线程池都是直接或间接通过配置ThreadPoolExecutor来实现不同特性的线程池.Android中最常见的类具有不同特性的线程池分别为FixThreadPool、CachedhreadPool、SingleThreadPool、ScheduleThreadExecutr.
1).FixThreadPool
只有核心线程,并且数量固定的,也不会被回收,所有线程都活动时,因为队列没有限制大小,新任务会等待执行.
优点:更快的响应外界请求.
2).SingleThreadPool
只有一个核心线程,确保所有的任务都在同一线程中按序完成.因此不需要处理线程同步的问题.
3).CachedThreadPool
只有非核心线程,最大线程数非常大,所有线程都活动时会为新任务创建新线程,否则会利用空闲线程(60s空闲时间,过了就会被回收,所以线程池中有0个线程的可能)处理任务.
优点:任何任务都会被立即执行(任务队列SynchronousQuue相当于一个空集合);比较适合执行大量的耗时较少的任务.
4).ScheduledThreadPool
核心线程数固定,非核心线程（闲着没活干会被立即回收数）没有限制.
优点:执行定时任务以及有固定周期的重复任务
10、OOM 是否可以try catch ？
只有在一种情况下，这样做是可行的：
在try语句中声明了很大的对象，导致OOM，并且可以确认OOM是由try语句中的对象声明导致的，那么在catch语句中，可以释放掉这些对象，解决OOM的问题，继续执行剩余语句。
但是这通常不是合适的做法。
Java中管理内存除了显式地catch OOM之外还有更多有效的方法：比如SoftReference, WeakReference, 硬盘缓存等。 在JVM用光内存之前，会多次触发GC，这些GC会降低程序运行的效率。 如果OOM的原因不是try语句中的对象（比如内存泄漏），那么在catch语句中会继续抛出OOM。
11、广播传输的数据是否有限制，是多少，为什么要限制？
Intent在传递数据时是有大小限制的，大约限制在1MB之内，你用Intent传递数据，实际上走的是跨进程通信（IPC），跨进程通信需要把数据从内核copy到进程中，每一个进程有一个接收内核数据的缓冲区，默认是1M；如果一次传递的数据超过限制，就会出现异常。
不同厂商表现不一样有可能是厂商修改了此限制的大小，也可能同样的对象在不同的机器上大小不一样。
传递大数据，不应该用Intent；考虑使用ContentProvider或者直接匿名共享内存。简单情况下可以考虑分段传输。
12、Bitmap相关
ALPHA_8 每个像素占用1byte内存
ARGB_4444 每个像素占用2byte内存
ARGB_8888 每个像素占用4byte内存（默认）
RGB_565 每个像素占用2byte内存
Bitamp 占用内存大小 = 宽度像素 x （inTargetDensity / inDensity） x 高度像素 x （inTargetDensity / inDensity）x 一个像素所占的内存
BitmapFactory.Options 参数inSampleSize的使用，先把options.inJustDecodeBounds设为true，只是去读取图片的大小，在拿到图片的大小之后和要显示的大小做比较通过calculateInSampleSize()函数计算inSampleSize的具体值，得到值之后。options.inJustDecodeBounds设为false读图片资源
13、请解释安卓为啥要加签名机制。
1、发送者的身份认证 由于开发商可能通过使用相同的 Package Name 来混淆替换已经安装的程序，以此保证签名不同的包不被替换。
2、保证信息传输的完整性 签名对于包中的每个文件进行处理，以此确保包中内容不被替换。
3、防止交易中的抵赖发生， Market 对软件的要求。
签名类型分为v1、v2、v3类型，v1到v2变化大，v2到v3只是小优化，主要了解v1、v2：
apk 本质是个 zip 文件，解压缩后，在 META-INFO 文件夹中可以看到有 MANIFEST.MF、CERT.SF、CERT.RSA 三个文件。这三个文件在签名时创建，在安装时用于验证签名。
v1签名：打包过程中，对每个文件进行sha1数字摘要存放在MANIFEST.MF中，这样保证了所有文件不被篡改，然后又对MANIFEST.MF文件整体及每个文件摘要再次进行sha1数字摘要，生成了CERT.SF文件；为了保证CERT.SF不被篡改， CERT.SF 文件用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。
v2签名：首先v1签名存在的缺点有两个：1、文件过多会导致摘要时间过长，2、没法保证整个apk的完整性（签名文件所在的META-INFO目录没有校验，前期的渠道包信息就是通过这里将含有渠道名的空文件写到这个目录的）
在了解下zip文件格式：
V2 签名时，会将 签名信息块 插入到 Zip 文件的「文件信息」和「中央目录」之间，
14、计算一个view的嵌套层级
private int getParents(ViewParents view){
if(view.getParents() == null)
return 0;
} else {
return (1 + getParents(view.getParents));
}
}
15、SharedPrefrences的apply和commit有什么区别？
这两个方法的区别在于：
apply没有返回值而commit返回boolean表明修改是否提交成功。
apply是将修改数据原子提交到内存, 而后异步真正提交到硬件磁盘, 而commit是同步的提交到硬件磁盘，因此，在多个并发的提交commit的时候，他们会等待正在处理的commit保存到磁盘后在操作，从而降低了效率。而apply只是原子的提交到内容，后面有调用apply的函数的将会直接覆盖前面的内存数据，这样从一定程度上提高了很多效率。
apply方法不会提示任何失败的提示。 由于在一个进程中，sharedPreference是单实例，一般不会出现并发冲突，如果对提交的结果不关心的话，建议使用apply，当然需要确保提交成功且有后续操作的话，还是需要用commit的。
16、Base64、MD5是加密方法么？
Base64是什么？
Base64是用文本表示二进制的编码方式，它使用4个字节的文本来表示3个字节的原始二进制数据。 它将二进制数据转换成一个由64个可打印的字符组成的序列：A-Za-z0-9+/
MD5是什么？
MD5是哈希算法的一种，可以将任意数据产生出一个128位（16字节）的散列值，用于确保信息传输完整一致。我们常在注册登录模块使用MD5，用户密码可以使用MD5加密的方式进行存储。如：md5(hello world,32) = 5eb63bbbe01eeed093cb22bb8f5acdc3
加密，指的是对数据进行转换以后，数据变成了另一种格式，并且除了拿到解密方法的人，没人能把数据转换回来。 MD5是一种信息摘要算法，它是不可逆的，不可以解密。所以它只能算的上是一种单向加密算法。 Base64也不是加密算法，它是一种数据编码方式，虽然是可逆的，但是它的编码方式是公开的，无所谓加密。
17、启动模式
standard，singleTop，singleTask，singleInstance
需要注意的是：taskAffinity 默认值是应用包名，这个属性不能单独决定activity所属任务栈，需要结合FLAG_ACTIVITY_NEW_TASK ，也就是说同一个任务栈中可以包含不同taskAffinity 的activity。
非 Activity 启动 Activity 都必须添加 Intent.FLAG_ACTIVITY_NEW_TASK 才行，为啥？
如果某个活动不是通过 Activity 启动的，说明不是用户主动的行为，也就是说这个活动可能会出现在任何 APP 的活动之上，这时如果不用 Intent.FLAG_ACTIVITY_NEW_TASK 将这个活动限制在自己的 Task 中，就可能让用户误以为新的活动是属于当前 APP，这是不合理的。
FLAG_ACTIVITY_CLEAR_TASK 单独使用没用，需要结合其它flag，常见和FLAG_ACTIVITY_NEW_TASK 一起：
如果目标 Task 已存在，就先清空目标 Task（将目标 Task 原有的 Activity 全部出栈），然后新 Activity 称为目标 Task 的根 Activity。如果目标 Task 还不存在，就新建目标 Task，新 Activity 成为根 Activity（这和单独设置 Intent.FLAG_ACTIVITY_NEW_TASK 的效果一样）。
18、对于 SharedPreferences 的 apply 和 commit 方法，在使用上存在一些区别。
commit():
commit 方法是同步提交，它会将修改的数据立即写入磁盘，并返回一个布尔值来表示提交是否成功。同时，commit 方法会阻塞当前线程，直到写入磁盘操作完成。如果写入操作耗时较长，可能会对性能产生影响。
apply():
apply 方法是异步提交，它会将修改的数据放入内存缓存，并启动一个新的线程用于将数据异步写入磁盘。因为使用了异步线程，所以 apply 方法不会阻塞当前线程，不会对性能造成太大的影响。注意，apply 方法没有返回值，也无法得知写入是否成功。
总结来说，commit 方法是同步的，会阻塞当前线程，立即将数据写入磁盘，而 apply 方法则是异步的，不会阻塞当前线程，将数据写入内存缓存后，再通过新的线程异步写入磁盘。
19、如何保证Service不被杀死？
Android 进程不死从3个层面入手：
A.提供进程优先级，降低进程被杀死的概率
方法一：监控手机锁屏解锁事件，在屏幕锁屏时启动1个像素的 Activity，在用户解锁时将 Activity 销毁掉。
方法二：启动前台service。
方法三：提升service优先级：
在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = "1000"这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时适用于广播。
B. 在进程被杀死后，进行拉活
方法一：注册高频率广播接收器，唤起进程。如网络变化，解锁屏幕，开机等
方法二：双进程相互唤起。
方法三：依靠系统唤起。
方法四：onDestroy方法里重启service：service + broadcast 方式，就是当service走ondestory的时候，发送一个自定义的广播，当收到广播的时候，重新启动service；
20、dp与px
计算的公式为：1dp=(屏幕的dpi/160)px，如果以我们的1080*1920的5英寸屏幕为例那就是1dp=(441/160)px=2.8px。
21、View的事件分发机制？滑动冲突怎么解决？
了解Activity的构成
一个Activity包含了一个Window对象，这个对象是由PhoneWindow来实现的。PhoneWindow将DecorView作为整个应用窗口的根View，而这个DecorView又将屏幕划分为两个区域：一个是TitleView，另一个是ContentView，而我们平时所写的就是展示在ContentView中的。
触摸事件的类型
触摸事件对应的是MotionEvent类，事件的类型主要有如下三种：
ACTION_DOWN
ACTION_MOVE(移动的距离超过一定的阈值会被判定为ACTION_MOVE操作)
ACTION_UP
ACTION_CANCEL
View事件分发本质就是对MotionEvent事件分发的过程。即当一个MotionEvent发生后，系统将这个点击事件传递到一个具体的View上。
一些重要的结论：
1、事件传递优先级：onTouchListener.onTouch > onTouchEvent > onClickListener.onClick。
2、正常情况下，一个时间序列只能被一个View拦截且消耗。因为一旦一个元素拦截了此事件，那么同一个事件序列内的所有事件都会直接交给它处理（即不会再调用这个View的拦截方法去询问它是否要拦截了，而是把剩余的ACTION_MOVE、ACTION_DOWN等事件直接交给它来处理）。特例：通过将重写View的onTouchEvent返回false可强行将事件转交给其他View处理。
3、如果View不消耗除ACTION_DOWN以外的其他事件，那么这个点击事件会消失，此时父元素的onTouchEvent并不会被调用，并且当前View可以持续收到后续的事件，最终这些消失的点击事件会传递给Activity处理。
4、ViewGroup默认不拦截任何事件（返回false）。
5、View的onTouchEvent默认都会消耗事件（返回true），除非它是不可点击的（clickable和longClickable同时为false）。View的longClickable属性默认都为false，clickable属性要分情况，比如Button的clickable属性默认为true，而TextView的clickable默认为false。
6、View的enable属性不影响onTouchEvent的默认返回值。
7、通过requestDisallowInterceptTouchEvent方法可以在子元素中干预父元素的事件分发过程，但是ACTION_DOWN事件除外。
记住这个图的传递顺序,面试的时候能够画出来,就很详细了：
ACTION_CANCEL什么时候触发，触摸button然后滑动到外部抬起会触发点击事件吗，再滑动回去抬起会么？
一般ACTION_CANCEL和ACTION_UP都作为View一段事件处理的结束。如果在父View中拦截ACTION_UP或ACTION_MOVE，在第一次父视图拦截消息的瞬间，父视图指定子视图不接受后续消息了，同时子视图会收到ACTION_CANCEL事件。
如果触摸某个控件，但是又不是在这个控件的区域上抬起（移动到别的地方了），就会出现action_cancel。
点击事件被拦截，但是想传到下面的View，如何操作？
重写子类的requestDisallowInterceptTouchEvent()方法返回true就不会执行父类的onInterceptTouchEvent()，即可将点击事件传到下面的View。
如何解决View的事件冲突？举个开发中遇到的例子？
常见开发中事件冲突的有ScrollView与RecyclerView的滑动冲突、RecyclerView内嵌同时滑动同一方向。
滑动冲突的处理规则：
对于由于外部滑动和内部滑动方向不一致导致的滑动冲突，可以根据滑动的方向判断谁来拦截事件。
对于由于外部滑动方向和内部滑动方向一致导致的滑动冲突，可以根据业务需求，规定何时让外部View拦截事件，何时由内部View拦截事件。
对于上面两种情况的嵌套，相对复杂，可同样根据需求在业务上找到突破点。
滑动冲突的实现方法：
外部拦截法：指点击事件都先经过父容器的拦截处理，如果父容器需要此事件就拦截，否则就不拦截。具体方法：需要重写父容器的onInterceptTouchEvent方法，在内部做出相应的拦截。
内部拦截法：指父容器不拦截任何事件，而将所有的事件都传递给子容器，如果子容器需要此事件就直接消耗，否则就交由父容器进行处理。具体方法：需要配合requestDisallowInterceptTouchEvent方法。
22、View的绘制流程
view的生命周期：参考
从ViewRootImpl的performTraversals开始从上到下进行遍历整个view树，调用onMeasure,onLayout,onDraw进行测量布局绘制。
理解MeasureSpec
MeasureSpec表示的是一个32位的整形值，它的高2位表示测量模式SpecMode，低30位表示某种测量模式下的规格大小SpecSize。MeasureSpec是View类的一个静态内部类，用来说明应该如何测量这个View。它由三种测量模式，如下：
EXACTLY：精确测量模式，视图宽高指定为match_parent或具体数值时生效，表示父视图已经决定了子视图的精确大小，这种模式下View的测量值就是SpecSize的值。
AT_MOST：最大值测量模式，当视图的宽高指定为wrap_content时生效，此时子视图的尺寸可以是不超过父视图允许的最大尺寸的任何尺寸。
UNSPECIFIED：不指定测量模式, 父视图没有限制子视图的大小，子视图可以是想要的任何尺寸，通常用于系统内部，应用开发中很少用到。
MeasureSpec通过将SpecMode和SpecSize打包成一个int值来避免过多的对象内存分配，为了方便操作，其提供了打包和解包的方法，打包方法为makeMeasureSpec，解包方法为getMode和getSize。
普通View的MeasureSpec的创建规则如下：
对于DecorView而言，它的MeasureSpec由窗口尺寸和其自身的LayoutParams共同决定；对于普通的View，它的MeasureSpec由父视图的MeasureSpec和其自身的LayoutParams共同决定。
View绘制流程之Measure
首先，在ViewGroup中的measureChildren()方法中会遍历测量ViewGroup中所有的View，当View的可见性处于GONE状态时，不对其进行测量。
然后，测量某个指定的View时，根据父容器的MeasureSpec和子View的LayoutParams等信息计算子View的MeasureSpec。
最后，将计算出的MeasureSpec传入View的measure方法，这里ViewGroup没有定义测量的具体过程，因为ViewGroup是一个抽象类，其测量过程的onMeasure方法需要各个子类去实现。不同的ViewGroup子类有不同的布局特性，这导致它们的测量细节各不相同，如果需要自定义测量过程，则子类可以重写这个方法。（setMeasureDimension方法用于设置View的测量宽高，如果View没有重写onMeasure方法，则会默认调用getDefaultSize来获得View的宽高）
自定义View时手动处理wrap_content时的情形
直接继承View的控件需要重写onMeasure方法并设置wrap_content时的自身大小，否则在布局中使用wrap_content就相当于使用match_parent。此时，可以在wrap_content的情况下（对应MeasureSpec.AT_MOST）指定内部宽/高(mWidth和mHeight)。
View的绘制流程之Layout
首先，会通过setFrame方法来设定View的四个顶点的位置，即View在父容器中的位置。然后，会执行到onLayout空方法，子类如果是ViewGroup类型，则重写这个方法，实现ViewGroup中所有View控件布局流程。
View的绘制流程之Draw
Draw的基本流程：
绘制基本上可以分为六个步骤：
首先绘制View的背景；
如果需要的话，保持canvas的图层，为fading做准备；
然后，绘制View的内容；
接着，绘制View的子View；
如果需要的话，绘制View的fading边缘并恢复图层；
最后，绘制View的装饰(例如滚动条等等)。
invalidate() 和 postInvalidate()、requestLayout的区别 ？
invalidate()与postInvalidate()都会调用ondraw()用于刷新View，主要区别是invalidate()在主线程中调用，若在子线程中使用需要配合handler；而postInvalidate()可在子线程中直接调用。
requestLayout会触发三大流程。
23、进程间通信IPC
Android中进程和线程的关系？区别？
线程是CPU调度的最小单元，同时线程是一种有限的系统资源；而进程一般指一个执行单元，在PC和移动设备上指一个程序或者一个应用。
一般来说，一个App程序至少有一个进程，一个进程至少有一个线程（包含与被包含的关系），通俗来讲就是，在App这个工厂里面有一个进程，线程就是里面的生产线，但主线程（即主生产线）只有一条，而子线程（即副生产线）可以有多个。
进程有自己独立的地址空间，而进程中的线程共享此地址空间，都可以并发执行。
管道、消息队列、共享内存，Binder
小结：client进程、service进程，serviceManager、Binder驱动
Binder驱动主要负责建立从client进程内核缓冲区到service进程用户空间内存之间的内存映射mmap。
ServiceManager负责service进程的注册以及查找client进程需要的service进程。
Binder需要一次拷贝，管道、消息队列需要两次拷贝，共享内存不需要拷贝但需要解决进程同步问题。
24、app启动流程
1、点击桌面应用图标，Launcher进程将启动Activity（MainActivity）的请求以Binder的方式发送给了AMS。
2、AMS接收到启动请求后，交付ActivityStarter处理Intent和Flag等信息，然后再交给ActivityStackSupervisior/ActivityStack 处理Activity进栈相关流程。同时以Socket方式请求Zygote进程fork新进程。
3、Zygote接收到新进程创建请求后fork出新进程。
4、在新进程里创建ActivityThread对象，新创建的进程就是应用的主线程，在主线程里开启Looper消息循环，开始处理创建Activity。
5、ActivityThread利用ClassLoader去加载Activity、创建Activity实例，并回调Activity的onCreate()方法，这样便完成了Activity的启动。
25、说下安卓虚拟机和java虚拟机的原理和不同点?（JVM、Davilk、ART三者的原理和区别）
JVM 和Dalvik虚拟机的区别
JVM:.java -> javac -> .class -> jar -> .jar
架构: 堆和栈的架构.
DVM:.java -> javac -> .class -> dx.bat -> .dex
架构: 寄存器(cpu上的一块高速缓存)
Android2个虚拟机的区别（一个5.0之前，一个5.0之后）
Dalvik
谷歌设计专用于 Android 平台的 Java 虚拟机，可直接运行 .dex 文件，适合内存和处理速度有限的系统
JVM 指令集是基于栈的；Dalvik 指令集是基于寄存器的，代码执行效率更优
ART
Dalvik 每次运行都要将字节码转换成机器码；ART 在应用安装时就会转换成机器码，执行速度更快
ART 存储机器码占用空间更大，空间换时间
什么是Dalvik：Dalvik是Google公司自己设计用于Android平台的Java虚拟机。Dalvik虚拟机是Google等厂商合作开发的Android移动设备平台的核心组成部分之一，它可以支持已转换为.dex(即Dalvik Executable)格式的Java应用程序的运行，.dex格式是专为Dalvik应用设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik应用作为独立的Linux进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。
什么是ART:Android操作系统已经成熟，Google的Android团队开始将注意力转向一些底层组件，其中之一是负责应用程序运行的Dalvik运行时。Google开发者已经花了两年时间开发更快执行效率更高更省电的替代ART运行时。ART代表Android Runtime,其处理应用程序执行的方式完全不同于Dalvik，Dalvik是依靠一个Just-In-Time(JIT)编译器去解释字节码。开发者编译后的应用代码需要通过一个解释器在用户的设备上运行，这一机制并不高效，但让应用能更容易在不同硬件和架构上运行。ART则完全改变了这套做法，在应用安装的时候就预编译字节码为机器语言，这一机制叫Ahead-Of-Time(AOT)编译。在移除解释代码这一过程后，应用程序执行将更有效率，启动更快。
ART优点：
系统性能的显著提升。
应用启动更快、运行更快、体验更流畅、触感反馈更及时。
更长的电池续航能力。
支持更低的硬件。
ART缺点：
更大的存储空间占用，可能会增加10%-20%。
更长的应用安装时间。
AOT和JIT以及混合编译的区别、优势
AOT和JIT是什么？AOT,即Ahead-of-time,指预先编译. JIT,即Just-In-Time,指即时编译.
区别: 主要区别在于是否在“运行时”进行编译.
优劣: AOT优点：1.在程序运行前编译,可以避免在运行时的编译性能消耗和内存消耗. 2.可以在程序运行初期就达到最高性能. 3.可以显著的加快程序的启动. AOT缺点：1.在程序运行前编译会使程序安装的时间增加. 2.牺牲Java的一致性. 3.将提前编译的内容保存会占用更多的外存.
JIT优点：1.可以根据当前硬件情况实时编译生成最优机器指令(ps:AOT也可以做到,在用户使用是使用字节码根据机器情况在做一次编译). 2.可以根据当前程序的运行情况生成最优的机器指令序列. 3.当程序需要支持动态链接时,只能使用JIT. 4.可以根据进程中内存的实际情况调整代码,使内存能够更充分的利用. JIT缺点：1.编译需要占用运行时资源,会导致进程卡顿. 2.由于编译时间需要占用运行时间,对于某些代码的编译优化不能完全支持,需要在程序流畅和编译时间之间做权衡. 3.在编译准备和识别频繁使用的方法需要占用时间,使得初始编译不能达到最高性能.
混合编译: Android N引入了使用编译+解释+JIT的混合运行时,以获得安装时间,内存占用,电池消耗和性能之间的最佳折衷. 优点: 即使是大型应用程序的安装时间也减少到几秒钟. 系统更新安装得更快,因为它们不需要优化步骤. 应用程序的RAM占用空间较小,在某些情况下降至50％. 改善了表现. 降低电池消耗.
25、一个图片在app中调用R.id后是如何找到的？
在编译的时候，AAPT会扫描你所定义的所有资源（在不同文件中定义的以及单独的资源文件），然后给它们指定不同的资源ID。
资源ID 是一个32bit的数字，格式是PPTTNNNN ， PP代表资源所属的包(package) ,TT代表资源的类型(type)，NNNN代表这个类型下面的资源的名称。 对于应用程序的资源来说，PP的取值是0×77。
TT 和NNNN 的取值是由AAPT工具随意指定的–基本上每一种新的资源类型的数字都是从上一个数字累加的（从1开始）；而每一个新的资源条目也是从数字1开始向上累加的。
所以如果我们的这几个资源文件按照下面的顺序排列，AAPT会依次处理：
<code>layout/main.xml </code>
<code>drawable/icon.xml </code>
<code>layout/listitem.xml</code>
按照顺序，第一个资源的类型是”layout” 所以指定TT==1， 这个类型下面的第一个资源是”main” ，所以指定NNNN==1 ，最后这个资源就是0x7f010001。
第二个资源类型是”drawable”，所以指定TT==2，这个类型下的”icon” 指定NNNN ==1，所以最终的资源ID 是 0x7f020001。
第三个资源类型是”layout”，而这个资源类型在前面已经有定义了，所以TT仍然是1，但是”listitem”这个名字是新出现的，所以指定NNNN==2，因此最终的资源ID 就是 0x7f010002。
注意的是，AAPT在每一次编译的时候不会去保存上一次生成的资源ID标示，每当/res目录发生变化的时候，AAPT可能会去重新给资源指定ID号，然后重新生成一个R.java文件。因此，在做开发的时候，你不应该在程序中将资源ID持久化保存到文件或者数据库。而资源ID在每一次编译后都有可能变化。
一旦资源被编译成二进制文件的时候，AAPT会生成R.java 文件和“resources.arsc”文件，“R.java”用于代码的编译，而”resources.arsc”则包含了全部的资源名称、资源ID和资源的内容（对于单独文件类型的资源，这个内容代表的是这个文件在其.apk 文件中的路径信息）。这样就把运行环境中的资源ID 和具体的资源对应起来了。
26、Recycleview和ListView缓存区别
ListView的缓存机制相对比较好理解，它只有两级缓存，一级缓存Active View是负责屏幕内的ItemView快速复用，而Scrap View是缓存屏幕外的数据，当该数据从屏幕外滑动到屏幕内的时候需要走一遍getView（）方法。
ListView有两级缓存，分别是Active View和Scrap View，缓存的对象是ItemView；而RecyclerView有四级缓存，分别是Scrap、Cache、ViewCacheExtension和RecycledViewPool，缓存的对象是ViewHolder。Scrap和Cache分别是通过position去找ViewHolder可以直接复用；ViewCacheExtension自定义缓存，目前来说应用场景比较少却需慎用；RecycledViewPool通过type来获取ViewHolder，获取的ViewHolder是个全新，需要重新绑定数据。
27、非UI线程可以更新UI吗?
可以，当访问UI时，ViewRootImpl会调用checkThread方法去检查当前访问UI的线程是哪个，如果不是UI线程则会抛出异常。执行onCreate方法的那个时候ViewRootImpl还没创建，无法去检查当前线程.ViewRootImpl的创建在onResume方法回调之后。
