总结：一般一面主要考基础知识，以及基于基础知识解决问题的能力

总结：二面主要是看着做的APP问的，APP里涉及到的技术，不管是不是自己负责的模块，只要面试官感兴趣都会问。各种问题最终都要问到底层实现或者原理。

共同点：

对基础性、原理性的东西比较重视

具体问题的解决能力、项目的架构能力

不同点：

公司不同、产品业务线不同，所以涉及的技术重点和方向不同

思考：

有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题

有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西

1.图片加载三级缓存，有一个功能，做一个能放大缩小的图片查看器，加载一张巨大的图片，怎么做

（1）什么是三级缓存

网络加载，不优先加载，速度慢，浪费流量

本地缓存，次优先加载，速度快

内存缓存，优先加载，速度最快

（2）为什么要使用三级缓存

如今的 Android App 经常会需要网络交互，通过网络获取图片是再正常不过的事了

假如每次启动的时候都从网络拉取图片的话，势必会消耗很多流量。在当前的状况下，对于非wifi用户来说，流量还是很贵的，一个很耗流量的应用，其用户数量级肯定要受到影响

特别是，当我们想要重复浏览一些图片时，如果每一次浏览都需要通过网络获取，流量的浪费可想而知

所以提出三级缓存策略，通过网络、本地、内存三级缓存图片，来减少不必要的网络交互，避免浪费流量

（3）三级缓存原理

首次加载 Android App 时，肯定要通过网络交互来获取图片，之后我们可以将图片保存至本地SD卡和内存中

之后运行 App 时，优先访问内存中的图片缓存，若内存中没有，则加载本地SD卡中的图片

总之，只在初次访问新内容时，才通过网络获取图片资源

2.图片加载如何避免 OOM

我们知道内存中的 Bitmap 大小的计算公式是：长所占像素 宽所占像素 每个像素所占内存。想避免 OOM 有两种方法：等比例缩小长宽、减少每个像素所占的内存。

等比缩小长宽。我们知道 Bitmap 的创建是通过 BitmapFactory 的工厂方法，decodeFile()、decodeStream()、decodeByteArray()、decodeResource()。这些方法中都有一个 Options 类型的参数，这个 Options 是 BitmapFactory 的内部类，存储着 BItmap 的一些信息。Options 中有一个属性：inSampleSize。我们通过修改 inSampleSize 可以缩小图片的长宽，从而减少 BItma p 所占内存。需要注意的是这个 inSampleSize 大小需要是 2 的幂次方，如果小于 1，代码会强制让inSampleSize为1。

减少像素所占内存。Options 中有一个属性 inPreferredConfig，默认是 ARGB_8888，代表每个像素所占尺寸。我们可以通过将之修改为 RGB_565 或者 ARGB_4444 来减少一半内存。

大图加载

加载高清大图，比如清明上河图，首先屏幕是显示不下的，而且考虑到内存情况，也不可能一次性全部加载到内存。这时候就需要局部加载了，Android中有一个负责局部加载的类：BitmapRegionDecoder。使用方法很简单，通过BitmapRegionDecoder.newInstance()创建对象，之后调用decodeRegion(Rect rect, BitmapFactory.Options options)即可。第一个参数rect是要显示的区域，第二个参数是BitmapFactory中的内部类Options。

3.Android与 js 是如何交互的

在 Android 中，Android 与js 的交互分为两个方面：Android 调用 js 里的方法、js 调用 Android 中的方法。

Android调js。 Android 调 js 有两种方法：

WebView.loadUrl("javascript:js中的方法名")。 这种方法的优点是很简洁，缺点是没有返回值，如果需要拿到js方法的返回值则需要js调用Android中的方法来拿到这个返回值。

WebView.evaluateJavaScript("javascript:js中的方法名",ValueCallback)。 这种方法比 loadUrl 好的是可以通过 ValueCallback 这个回调拿到 js方法的返回值。缺点是这个方法 Android4.4 才有，兼容性较差。不过放在 2018 年来说，市面上绝大多数 App 都要求最低版本是 4.4 了，所以我认为这个兼容性问题不大。

js 调 Android。 js 调 Android有三种方法：

WebView.addJavascriptInterface()。 这是官方解决 js 调用 Android 方法的方案，需要注意的是要在供 js 调用的 Android 方法上加上 @JavascriptInterface 注解，以避免安全漏洞。这种方案的缺点是 Android4.2 以前会有安全漏洞，不过在 4.2 以后已经修复了。同样，在 2018 年来说，兼容性问题不大。

重写 WebViewClient的shouldOverrideUrlLoading()方法来拦截url， 拿到 url 后进行解析，如果符合双方的规定，即可调用 Android 方法。优点是避免了 Android4.2 以前的安全漏洞，缺点也很明显，无法直接拿到调用 Android 方法的返回值，只能通过 Android 调用 js 方法来获取返回值。

重写 WebChromClient 的 onJsPrompt() 方法，同前一个方式一样，拿到 url 之后先进行解析，如果符合双方规定，即可调用Android方法。最后如果需要返回值，通过 result.confirm("Android方法返回值") 即可将 Android 的返回值返回给 js。方法的优点是没有漏洞，也没有兼容性限制，同时还可以方便的获取 Android 方法的返回值。其实这里需要注意的是在 WebChromeClient 中除 了 onJsPrompt 之外还有 onJsAlert 和 onJsConfirm 方法。那么为什么不选择另两个方法呢？原因在于 onJsAlert 是没有返回值的，而 onJsConfirm 只有 true 和 false 两个返回值，同时在前端开发中 prompt 方法基本不会被调用，所以才会采用 onJsPrompt。

4.怎么做上传下载的断点续传

断点续传和断点下载都是用的RandomAccessFile, 它具有移动指定的文件大小的位置的功能seek 。

断点续传是由服务器给客户端一个已经上传的位置标记position，然后客户端再将文件指针移动到相应的position，通过输入流将文件剩余部分读出来传输给服务器

断点下载 是由客户端告诉服务器已经下载的大小，然后服务器会将指针移动到相应的position，继续读出，把文件返回给客户端。 当然为了下载的更快一下，也可以多线程下载，那么基本实现就是给每个线程分配固定的字节的文件，分别去读

5.讲解Activity和Window，View的关系，以及DecorView结构

Activity

Activity并不负责视图控制，它只是控制生命周期和处理事件。真正控制视图的是Window。一个Activity包含了一个Window，Window才是真正代表一个窗口。Activity就像一个控制器，统筹视图的添加与显示，以及通过其他回调方法，来与Window、以及View进行交互。

Window

Window是视图的承载器，内部持有一个 DecorView，而这个DecorView才是 view的根布局。Window是一个抽象类，实际在Activity中持有的是其子类PhoneWindow。PhoneWindow中有个内部类DecorView，通过创建DecorView来加载Activity中设置的布局 R.layout.activity_main 。Window 通过WindowManager将DecorView加载其中，并将DecorView交给ViewRoot，进行视图绘制以及其他交互。

DecorView

DecorView是FrameLayout的子类，它可以被认为是Android视图树的根节点视图。DecorView作为顶级View，一般情况下它内部包含一个竖直方向的LinearLayout，在这个LinearLayout里面有上下三个部分，上面是个ViewStub,延迟加载的视图（应该是设置ActionBar,根据Theme设置），中间的是标题栏(根据Theme设置，有的布局没有)，下面的是内容栏。

ViewRoot

ViewRoot可能比较陌生，但是其作用非常重大。所有View的绘制以及事件分发等交互都是通过它来执行或传递的。ViewRoot对应ViewRootImpl类，它是连接WindowManagerService和DecorView的纽带，View的三大流程(测量（measure），布局（layout），绘制（draw）)均通过ViewRoot来完成。ViewRoot并不属于View树的一份子。从源码实现上来看，它既非View的子类，也非View的父类，但是，它实现了ViewParent接口，这让它可以作为View的名义上的父视图。RootView继承了Handler类，可以接收事件并分发，Android的所有触屏事件、按键事件、界面刷新等事件都是通过ViewRoot进行分发的。

DecorView 继承自 FrameLayout，是一个 ViewGroup

DecorView 是 Window / Activity 的最顶级视图

DecorView 是在我们调用 Activity 的setContentView()方法时创建的，期间还会获取并应用我们设置的窗口属性，所以在setContentView()之前设置的窗口属性才能生效

6.EventBus原理

什么是EventBus

EventBus是一个Android端优化的publish/subscribe消息总线，简化了应用程序内各组件间、组件与后台线程间的通信。比如请求网络，等网络返回时通过Handler或Broadcast通知UI，两个Fragment之间需要通过Listener通信，这些需求都可以通过EventBus实现。

EventBus框架

大家谈到EventBus，总会想到greenrobot的EventBus，但是实际上EventBus是一个通用的叫法，例如Google出品的Guava，Guava是一个庞大的库，EventBus只是它附带的一个小功能，因此实际项目中使用并不多。用的最多的是greenrobot/EventBus，这个库的优点是接口简洁，集成方便，但是限定了方法名，不支持注解。另一个库square/otto修改自 Guava ，用的人也不少。

  EventBus是一个用于简化Andorid、Fragment、Threads、Service之间信息传递的一个发布/订阅事件集。

    传统的Android组件之间的通信方式有：Activity之间使用Intent；Service向Activity发送broadcast；Fragment和Activity之间相互持有对方的引用（随后可以调用对方的相关方法进行事件传递）。传统的事件传递的问题在于：通信方式没有实现解耦，是硬编码在组件中的。组件一旦发生修改，对应的通信方式就需要跟着修改。其实不管什么场景下，我们最好能够使得自己编写的代码最大限度的解耦，这是一个很好的习惯，避免无用功，提高代码利用率。

    使用EventBus的建议：

并不建议将应用中所有的事件都通过EventBus进行发送，尤其对于一对一的组件之间通信，建议不要使用EventBus。EventBus的使用场景更像是一种广播，当我们向EventBus发送一个事件，则该事件将会传递给多个该事件的订阅者，比如Service向Activities发送事件。跟LoacalBroadCast有点近似

在Activity和Fragment中使用EventBus时，要注意在组件的生命周期开始时registered EventBus，在生命周期结束时unregistered EventBus。否则容易导致OOM；

    使用EventBus的好处在于：

简化组件之间的通信方式

让业务代码更加简洁（但是需要配合相应注解进行使用）

可以指定事件处理方法的执行线程，和订阅者的优先级（跟广播类似）

足够的稳定，已经被很多Android应用使用，你绝对不是第一个吃螃蟹的人

原理

7.ManiFest原理，APP启动流程，APK打包流程

ManiFest原理

Android  安装一个 APK 的时候首先会解析 APK ，这里要做很多事情，其中一个事情就是解析 Manifest.xml 文件，并将所有 APK 的Manifest 封装到各种对象中并保存在内存当中

APP启动流程

(1)ActivityManagerService组织回退栈时以ActivityRecord为基本单位，所有的ActivityRecord放在同一个ArrayList里，可以将mHistory看作一个栈对象，索引0所指的对象位于栈底，索引mHistory.size()-1所指的对象位于栈顶

(2)Zygote进程孵化出新的应用进程后，会执行ActivityThread类的main方法.在该方法里会先准备好Looper和消息队列，然后调用attach方法将应用进程绑定到ActivityManagerService，然后进入loop循环，不断地读取消息队列里的消息，并分发消息。

(3)ActivityThread的main方法执行后,应用进程接下来通知ActivityManagerService应用进程已启动，ActivityManagerService保存应用进程的一个代理对象，这样ActivityManagerService可以通过这个代理对象控制应用进程，然后ActivityManagerService通知应用进程创建入口Activity的实例，并执行它的生命周期方法