稳住，今天周一，长文面试题奉上。

更多BAT面试解析资料包内容私信我【资料】查看

1、说说View/ViewGroup的绘制流程

View的绘制流程是从ViewRoot的performTraversals开始的，它经过measure，layout，draw三个过程最终将View绘制出来。performTraversals会依次调用performMeasure，performLayout，performDraw三个方法，他们会依次调用measure，layout，draw方法，然后又调用了onMeasure，onLayout，dispatchDraw。

measure ：对于自定义的单一view的测量，只需要根据父 view 传递的MeasureSpec进行计算大小。

对于ViewGroup的测量，一般要重写onMeasure方法，在onMeasure方法中，父容器会对所有的子View进行Measure，子元素又会作为父容器，重复对它自己的子元素进行Measure，这样Measure过程就从DecorView一级一级传递下去了，也就是要遍历所有子View的的尺寸，最终得出出总的viewGroup的尺寸。Layout和Draw方法也是如此。

layout ：根据 measure 子 View 所得到的布局大小和布局参数，将子View放在合适的位置上。

对于自定义的单一view，计算本身的位置即可。

对于ViewGroup来说，需要重写onlayout方法。除了计算自己View的位置，还需要确定每一个子View在父容器的位置以及子view的宽高（getMeasuredWidth和getMeasuredHeight），最后调用所有子view的layout方法来设定子view的位置。

draw ：把 View 对象绘制到屏幕上。

draw（）会依次调用四个方法：

1）drawBackground()，根据在 layout 过程中获取的 View 的位置参数，来设置背景的边界。2）onDraw()，绘制View本身的内容，一般自定义单一view会重写这个方法，实现一些绘制逻辑。

3） dispatchDraw()，绘制子View 4）onDrawScrollBars(canvas)，绘制装饰，如 滚动指示器、滚动条、和前景.

2、说说你理解的MeasureSpec

MeasureSpec是由父View的MeasureSpec和子View的LayoutParams通过简单的计算得出一个针对子View的测量要求，这个测量要求就是MeasureSpec。

首先，MeasureSpec是一个大小跟模式的组合值,MeasureSpec中的值是一个整型（32位）将size和mode打包成一个Int型，其中高两位是mode，后面30位存的是size

// 获取测量模式  int specMode = MeasureSpec.getMode(measureSpec)  // 获取测量大小  int specSize = MeasureSpec.getSize(measureSpec)  // 通过Mode 和 Size 生成新的SpecMode  int measureSpec=MeasureSpec.makeMeasureSpec(size, mode);

其次，每个子View的MeasureSpec值根据子View的布局参数和父容器的MeasureSpec值计算得来的，所以就有一个父布局测量模式，子视图布局参数，以及子view本身的MeasureSpec关系图：

其实也就是getChildMeasureSpec方法的源码逻辑，会根据子View的布局参数和父容器的MeasureSpec计算出来单个子view的MeasureSpec。

最后是实际应用时：

对于自定义的单一view，一般可以不处理onMeasure方法，如果要对宽高进行自定义，就重写onMeasure方法，并将算好的宽高通过setMeasuredDimension方法传进去。对于自定义的ViewGroup，一般需要重写onMeasure方法，并且调用measureChildren方法遍历所有子View并进行测量（measureChild方法是测量具体某一个view的宽高），然后可以通过getMeasuredWidth/getMeasuredHeight获取宽高，最后通过setMeasuredDimension方法存储本身的总宽高。

3、Scroller是怎么实现View的弹性滑动？在MotionEvent.ACTION_UP事件触发时调用startScroll()方法，该方法并没有进行实际的滑动操作，而是记录滑动相关量（滑动距离、滑动时间）接着调用invalidate/postInvalidate()方法，请求View重绘，导致View.draw方法被执行当View重绘后会在draw方法中调用computeScroll方法，而computeScroll又会去向Scroller获取当前的scrollX和scrollY；然后通过scrollTo方法实现滑动；接着又调用postInvalidate方法来进行第二次重绘，和之前流程一样，如此反复导致View不断进行小幅度的滑动，而多次的小幅度滑动就组成了弹性滑动，直到整个滑动过成结束。

mScroller = new Scroller(context);@Overridepublic boolean onTouchEvent(MotionEvent event) {    switch (event.getAction()) {        case MotionEvent.ACTION_UP:            // 滚动开始时X的坐标,滚动开始时Y的坐标,横向滚动的距离,纵向滚动的距离            mScroller.startScroll(getScrollX(), 0, dx, 0);            invalidate();            break;    }    return super.onTouchEvent(event);}@Overridepublic void computeScroll() {    // 重写computeScroll()方法，并在其内部完成平滑滚动的逻辑    if (mScroller.computeScrollOffset()) {        scrollTo(mScroller.getCurrX(), mScroller.getCurrY());        invalidate();    }}

OKHTTP的拦截器是把所有的拦截器放到一个list里，然后每次依次执行拦截器，并且在每个拦截器分成三部分：

预处理拦截器内容通过proceed方法把请求交给下一个拦截器下一个拦截器处理完成并返回，后续处理工作。

这样依次下去就形成了一个链式调用，看看源码，具体有哪些拦截器：

Response getResponseWithInterceptorChain() throws IOException {    // Build a full stack of interceptors.    List<Interceptor> interceptors = new ArrayList<>();    interceptors.addAll(client.interceptors());    interceptors.add(retryAndFollowUpInterceptor);    interceptors.add(new BridgeInterceptor(client.cookieJar()));    interceptors.add(new CacheInterceptor(client.internalCache()));    interceptors.add(new ConnectInterceptor(client));    if (!forWebSocket) {      interceptors.addAll(client.networkInterceptors());    }    interceptors.add(new CallServerInterceptor(forWebSocket));    Interceptor.Chain chain = new RealInterceptorChain(        interceptors, null, null, null, 0, originalRequest);    return chain.proceed(originalRequest);}

根据源码可知，一共七个拦截器：

addInterceptor(Interceptor)，这是由开发者设置的，会按照开发者的要求，在所有的拦截器处理之前进行最早的拦截处理，比如一些公共参数，Header都可以在这里添加。RetryAndFollowUpInterceptor，这里会对连接做一些初始化工作，以及请求失败的充实工作，重定向的后续请求工作。跟他的名字一样，就是做重试工作还有一些连接跟踪工作。BridgeInterceptor，这里会为用户构建一个能够进行网络访问的请求，同时后续工作将网络请求回来的响应Response转化为用户可用的Response，比如添加文件类型，content-length计算添加，gzip解包。CacheInterceptor，这里主要是处理cache相关处理，会根据OkHttpClient对象的配置以及缓存策略对请求值进行缓存，而且如果本地有了可⽤的Cache，就可以在没有网络交互的情况下就返回缓存结果。ConnectInterceptor，这里主要就是负责建立连接了，会建立TCP连接或者TLS连接，以及负责编码解码的HttpCodecnetworkInterceptors，这里也是开发者自己设置的，所以本质上和第一个拦截器差不多，但是由于位置不同，所以用处也不同。这个位置添加的拦截器可以看到请求和响应的数据了，所以可以做一些网络调试。CallServerInterceptor，这里就是进行网络数据的请求和响应了，也就是实际的网络I/O操作，通过socket读写数据。5、OkHttp怎么实现连接池

为什么需要连接池？

频繁的进行建立Sokcet连接和断开Socket是非常消耗网络资源和浪费时间的，所以HTTP中的keepalive连接对于降低延迟和提升速度有非常重要的作用。

keepalive机制是什么呢？

也就是可以在一次TCP连接中可以持续发送多份数据而不会断开连接。所以连接的多次使用，也就是复用就变得格外重要了，而复用连接就需要对连接进行管理，于是就有了连接池的概念。

OkHttp中使用ConectionPool实现连接池，默认支持5个并发KeepAlive，默认链路生命为5分钟。

怎么实现的？

1）首先，ConectionPool中维护了一个双端队列Deque，也就是两端都可以进出的队列，用来存储连接。

2）然后在ConnectInterceptor，也就是负责建立连接的拦截器中，首先会找可用连接，也就是从连接池中去获取连接，具体的就是会调用到ConectionPool的get方法。

RealConnection get(Address address, StreamAllocation streamAllocation, Route route) {    assert (Thread.holdsLock(this));    for (RealConnection connection : connections) {      if (connection.isEligible(address, route)) {        streamAllocation.acquire(connection, true);        return connection;      }    }    return null;  }

也就是遍历了双端队列，如果连接有效，就会调用acquire方法计数并返回这个连接。

3）如果没找到可用连接，就会创建新连接，并会把这个建立的连接加入到双端队列中，同时开始运行线程池中的线程，其实就是调用了ConectionPool的put方法。

public final class ConnectionPool {    void put(RealConnection connection) {        if (!cleanupRunning) {         //没有连接的时候调用            cleanupRunning = true;            executor.execute(cleanupRunnable);        }        connections.add(connection);    }}

4）其实这个线程池中只有一个线程，是用来清理连接的，也就是上述的cleanupRunnable

private final Runnable cleanupRunnable = new Runnable() {        @Override        public void run() {            while (true) {                //执行清理，并返回下次需要清理的时间。                long waitNanos = cleanup(System.nanoTime());                if (waitNanos == -1) return;                if (waitNanos > 0) {                    long waitMillis = waitNanos / 1000000L;                    waitNanos -= (waitMillis * 1000000L);                    synchronized (ConnectionPool.this) {                        //在timeout时间内释放锁                        try {                            ConnectionPool.this.wait(waitMillis, (int) waitNanos);                        } catch (InterruptedException ignored) {                        }                    }                }            }        }    };

这个runnable会不停的调用cleanup方法清理线程池，并返回下一次清理的时间间隔，然后进入wait等待。

怎么清理的呢？看看源码：

long cleanup(long now) {    synchronized (this) {      //遍历连接      for (Iterator<RealConnection> i = connections.iterator(); i.hasNext(); ) {        RealConnection connection = i.next();        //检查连接是否是空闲状态，        //不是，则inUseConnectionCount + 1        //是 ，则idleConnectionCount + 1        if (pruneAndGetAllocationCount(connection, now) > 0) {          inUseConnectionCount++;          continue;        }        idleConnectionCount++;        // If the connection is ready to be evicted, we're done.        long idleDurationNs = now - connection.idleAtNanos;        if (idleDurationNs > longestIdleDurationNs) {          longestIdleDurationNs = idleDurationNs;          longestIdleConnection = connection;        }      }      //如果超过keepAliveDurationNs或maxIdleConnections，      //从双端队列connections中移除      if (longestIdleDurationNs >= this.keepAliveDurationNs          || idleConnectionCount > this.maxIdleConnections) {              connections.remove(longestIdleConnection);      } else if (idleConnectionCount > 0) {      //如果空闲连接次数>0,返回将要到期的时间        // A connection will be ready to evict soon.        return keepAliveDurationNs - longestIdleDurationNs;      } else if (inUseConnectionCount > 0) {        // 连接依然在使用中，返回保持连接的周期5分钟        return keepAliveDurationNs;      } else {        // No connections, idle or in use.        cleanupRunning = false;        return -1;      }    }    closeQuietly(longestIdleConnection.socket());    // Cleanup again immediately.    return 0;  }

也就是当如果空闲连接maxIdleConnections超过5个或者keepalive时间大于5分钟，则将该连接清理掉。

5）这里有个问题，怎样属于空闲连接？

其实就是有关刚才说到的一个方法acquire计数方法：

public void acquire(RealConnection connection, boolean reportedAcquired) {    assert (Thread.holdsLock(connectionPool));    if (this.connection != null) throw new IllegalStateException();    this.connection = connection;    this.reportedAcquired = reportedAcquired;    connection.allocations.add(new StreamAllocationReference(this, callStackTrace));}

在RealConnection中，有一个StreamAllocation虚引用列表allocations。每创建一个连接，就会把连接对应的StreamAllocationReference添加进该列表中，如果连接关闭以后就将该对象移除。

6）连接池的工作就这么多，并不负责，主要就是管理双端队列Deque<RealConnection>，可以用的连接就直接用，然后定期清理连接，同时通过对StreamAllocation的引用计数实现自动回收。

6、OkHttp里面用到了什么设计模式

责任链模式

这个不要太明显，可以说是okhttp的精髓所在了，主要体现就是拦截器的使用，具体代码可以看看上述的拦截器介绍。

建造者模式

在Okhttp中，建造者模式也是用的挺多的，主要用处是将对象的创建与表示相分离，用Builder组装各项配置。比如Request：

public class Request {  public static class Builder {    @Nullable HttpUrl url;    String method;    Headers.Builder headers;    @Nullable RequestBody body;    public Request build() {      return new Request(this);    }  }}

工厂模式

工厂模式和建造者模式类似，区别就在于工厂模式侧重点在于对象的生成过程，而建造者模式主要是侧重对象的各个参数配置。例子有CacheInterceptor拦截器中又个CacheStrategy对象：

CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();public Factory(long nowMillis, Request request, Response cacheResponse) {  this.nowMillis = nowMillis;  this.request = request;  this.cacheResponse = cacheResponse;  if (cacheResponse != null) {    this.sentRequestMillis = cacheResponse.sentRequestAtMillis();    this.receivedResponseMillis = cacheResponse.receivedResponseAtMillis();    Headers headers = cacheResponse.headers();    for (int i = 0, size = headers.size(); i < size; i++) {      String fieldName = headers.name(i);      String value = headers.value(i);      if ("Date".equalsIgnoreCase(fieldName)) {        servedDate = HttpDate.parse(value);        servedDateString = value;      } else if ("Expires".equalsIgnoreCase(fieldName)) {        expires = HttpDate.parse(value);      } else if ("Last-Modified".equalsIgnoreCase(fieldName)) {        lastModified = HttpDate.parse(value);        lastModifiedString = value;      } else if ("ETag".equalsIgnoreCase(fieldName)) {        etag = value;      } else if ("Age".equalsIgnoreCase(fieldName)) {        ageSeconds = HttpHeaders.parseSeconds(value, -1);      }    }  }}

观察者模式

由于webSocket属于长连接，所以需要进行监听，这里是用到了观察者模式：

final WebSocketListener listener;@Override public void onReadMessage(String text) throws IOException {    listener.onMessage(this, text);}

另外有的博客还说到了策略模式，门面模式等，这些大家可以网上搜搜，毕竟每个人的想法看法都会不同，细心找找可能就会发现。

7、介绍一下你们之前做的项目的架构

这个问题大家就真实回答就好，重点是要说完后提出对自己项目架构的认同或不认同的观点，也就是要有自己的思考和想法。

MVP,MVVM,MVC 区别

MVC

架构介绍

Model：数据模型，比如我们从数据库或者网络获取数据View：视图，也就是我们的xml布局文件Controller：控制器，也就是我们的Activity

模型联系

View --> Controller，也就是反应View的一些用户事件（点击触摸事件）到Activity上。Controller --> Model, 也就是Activity去读写一些我们需要的数据。Controller --> View, 也就是Activity在获取数据之后，将更新内容反映到View上。

这样一个完整的项目架构就出来了，也是我们早期进行开发比较常用的项目架构。

优缺点

这种缺点还是比较明显的，主要表现就是我们的Activity太重了，经常一写就是几百上千行了。造成这种问题的原因就是Controller层和View层的关系太过紧密，也就是Activity中有太多操作View的代码了。

但是！但是！其实Android这种并称不上传统的MVC结构，因为Activity又可以叫View层又可以叫Controller层，所以我觉得这种Android默认的开发结构，其实称不上什么MVC项目架构，因为他本身就是Android一开始默认的开发形式，所有东西都往Activity中丢，然后能封装的封装一下，根本分不出来这些层级。当然这是我个人看法，可以都来讨论下。

MVP

架构介绍

之前不就是因为Activity中有操作view，又做Controller工作吗。所以其实MVP架构就是从原来的Activity层把view和Controller区分开，单独抽出来一层Presenter作为原来Controller的职位。然后最后演化成，将View层写成接口的形式，然后Activity去实现View接口，最后在Presenter类中去实现方法。

Model：数据模型，比如我们从数据库或者网络获取数据。View：视图，也就是我们的xml布局文件和Activity。Presenter：主持人，单独的类，只做调度工作。

模型联系

View --> Presenter，反应View的一些用户事件到Presenter上。Presenter --> Model, Presenter去读写操作一些我们需要的数据。Controller --> View, Presenter在获取数据之后，将更新内容反馈给Activity，进行view更新。

优缺点

这种的优点就是确实大大减少了Activity的负担，让Activity主要承担一个更新View的工作，然后把跟Model交互的工作转移给了Presenter，从而由Presenter方来控制和交互Model方以及View方。所以让项目更加明确简单，顺序性思维开发。

缺点也很明显：首先就是代码量大大增加了，每个页面或者说功能点，都要专门写一个Presenter类，并且由于是面向接口编程，需要增加大量接口，会有大量繁琐的回调。其次，由于Presenter里持有了Activity对象，所以可能会导致内存泄漏或者view空指针，这也是需要注意的地方。

MVVM

架构介绍

MVVM的特点就是双向绑定，并且有Google官方加持，更新了Jetpack中很多架构组件，比如ViewModel，Livedata，DataBinding等等，所以这个是现在的主流框架和官方推崇的框架。

Model：数据模型，比如我们从数据库或者网络获取数据。View：视图，也就是我们的xml布局文件和Activity。ViewModel：关联层，将Model和View绑定，使他们之间可以相互绑定实时更新

模型联系

View --> ViewModel -->View，双向绑定，数据改动可以反映到界面，界面的修改可以反映到数据。ViewModel --> Model, 操作一些我们需要的数据。

优缺点

优点就是官方大力支持，所以也更新了很多相关库，让MVVM架构更强更好用，而且双向绑定的特点可以让我们省去很多View和Model的交互。也基本解决了上面两个架构的问题。

8、具体说说你理解的MVVM

1）先说说MVVM是怎么解决了其他两个架构所在的缺陷和问题：

解决了各个层级之间耦合度太高的问题，也就是更好的完成了解耦。MVP层中，Presenter还是会持有View的引用，但是在MVVM中，View和Model进行双向绑定，从而使viewModel基本只需要处理业务逻辑，无需关系界面相关的元素了。解决了代码量太多，或者模式化代码太多的问题。由于双向绑定，所以UI相关的代码就少了很多，这也是代码量少的关键。而这其中起到比较关键的组件就是DataBinding，使所有的UI变动都交给了被观察的数据模型。解决了可能会有的内存泄漏问题。MVVM架构组件中有一个组件是LiveData，它具有生命周期感知能力，可以感知到Activity等的生命周期，所以就可以在其关联的生命周期遭到销毁后自行清理，就大大减少了内存泄漏问题。解决了因为Activity停止而导致的View空指针问题。在MVVM中使用了LiveData，那么在需要更新View的时候，如果观察者的生命周期处于非活跃状态（如返回栈中的 Activity），则它不会接收任何 LiveData 事件。也就是他会保证在界面可见的时候才会进行响应，这样就解决了空指针问题。解决了生命周期管理问题。这主要得益于Lifecycle组件，它使得一些控件可以对生命周期进行观察，就能随时随地进行生命周期事件。

2）再说说响应式编程

响应式编程，说白了就是我先构建好事物之间的关系，然后就可以不用管了。他们之间会因为这层关系而互相驱动。其实也就是我们常说的观察者模式，或者说订阅发布模式。

为什么说这个呢，因为MVVM的本质思想就是类似这种。不管是双向绑定，还是生命周期感知，其实都是一种观察者模式，使所有事物变得可观察，那么我们只需要把这种观察关系给稳定住，那么项目也就稳健了。

3）最后再说说MVVM为什么这么强大？

我个人觉得，MVVM强大不是因为这个架构本身，而是因为这种响应式编程的优势比较大，再加上Google官方的大力支持，出了这么多支持的组件，来维系MVVM架构，其实也是官方想进行项目架构的统一。

优秀的架构思想+官方支持=强大

..............

12、LiveData 是什么？

LiveData 是一种可观察的数据存储器类。与常规的可观察类不同，LiveData 具有生命周期感知能力，意指它遵循其他应用组件（如 Activity、Fragment 或 Service）的生命周期。这种感知能力可确保 LiveData 仅更新处于活跃生命周期状态的应用组件观察者。

官方介绍如下，其实说的比较清楚了，主要作用在两点：

数据存储器类。也就是一个用来存储数据的类。可观察。这个数据存储类是可以观察的，也就是比一般的数据存储类多了这么一个功能，对于数据的变动能进行响应。

主要思想就是用到了观察者模式思想，让观察者和被观察者解耦，同时还能感知到数据的变化，所以一般被用到ViewModel中，ViewModel负责触发数据的更新，更新会通知到LiveData，然后LiveData再通知活跃状态的观察者。

var liveData = MutableLiveData<String>()liveData.observe(this, object : Observer<String> {    override fun onChanged(t: String?) {    }})liveData.setVaile("xixi")//子线程调用liveData.postValue("test")

LiveData作为一种观察者模式设计思想，常常被和Rxjava一起比较，观察者模式的最大好处就是事件发射的上游 和 接收事件的下游 互不干涉，大幅降低了互相持有的依赖关系所带来的强耦合性。

其次，LiveData还能无缝衔接到MVVM架构中，主要体现在其可以感知到Activity等生命周期，这样就带来了很多好处：

不会发生内存泄漏 观察者会绑定到 Lifecycle对象，并在其关联的生命周期遭到销毁后进行自我清理。不会因 Activity 停止而导致崩溃 如果观察者的生命周期处于非活跃状态（如返回栈中的 Activity），则它不会接收任何 LiveData 事件。自动判断生命周期并回调方法 如果观察者的生命周期处于 STARTED 或 RESUMED状态，则 LiveData 会认为该观察者处于活跃状态，就会调用onActive方法，否则，如果 LiveData 对象没有任何活跃观察者时，会调用 onInactive()方法。14、说说LiveData原理

说到原理，其实就是两个方法：

订阅方法，也就是observe方法。通过该方法把订阅者和被观察者关联起来，形成观察者模式。

简单看看源码：

@MainThreadpublic void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {    assertMainThread("observe");    //...    LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);    ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);    if (existing != null && !existing.isAttachedTo(owner)) {        throw new IllegalArgumentException("Cannot add the same observer"                + " with different lifecycles");    }    if (existing != null) {        return;    }    owner.getLifecycle().addObserver(wrapper);}  public V putIfAbsent(@NonNull K key, @NonNull V v) {    Entry<K, V> entry = get(key);    if (entry != null) {        return entry.mValue;    }    put(key, v);    return null;}

这里putIfAbsent方法是讲生命周期相关的wrapper和观察者observer作为key和value存到了mObservers中。

回调方法，也就是onChanged方法。通过改变存储值，来通知到观察者也就是调用onChanged方法。从改变存储值方法setValue看起：

@MainThreadprotected void setValue(T value) {    assertMainThread("setValue");    mVersion++;    mData = value;    dispatchingValue(null);}private void dispatchingValue(@Nullable ObserverWrapper initiator) {    //...    do {        mDispatchInvalidated = false;        if (initiator != null) {            considerNotify(initiator);            initiator = null;        } else {            for (Iterator<Map.Entry<Observer<T>, ObserverWrapper>> iterator =                    mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {                considerNotify(iterator.next().getValue());                if (mDispatchInvalidated) {                    break;                }            }        }    } while (mDispatchInvalidated);    mDispatchingValue = false;}private void considerNotify(ObserverWrapper observer) {    if (!observer.mActive) {        return;    }    // Check latest state b4 dispatch. Maybe it changed state but we didn't get the event yet.    //    // we still first check observer.active to keep it as the entrance for events. So even if    // the observer moved to an active state, if we've not received that event, we better not    // notify for a more predictable notification order.    if (!observer.shouldBeActive()) {        observer.activeStateChanged(false);        return;    }    if (observer.mLastVersion >= mVersion) {        return;    }    observer.mLastVersion = mVersion;    //noinspection unchecked    observer.mObserver.onChanged((T) mData);}

这一套下来逻辑还是比较简单的，遍历刚才的map——mObservers，然后找到观察者observer，如果观察者不在活跃状态（活跃状态，也就是可见状态，处于 STARTED 或 RESUMED状态），则直接返回，不去通知。否则正常通知到观察者的onChanged方法。

当然，如果想任何时候都能监听到，都能获取回调，调用observeForever方法即可。

15、说说DNS，以及存在的问题

DNS用来做域名解析工作的，当输入一个域名后，需要把域名转化为IP地址，这个转换过程就是DNS解析。

但是传统的DSN解析会有一些问题，比如：

域名缓存问题本地做一个缓存，直接返回缓存数据。可能会导致全局负载均衡失败，因为上次进行的缓存，不一定是这次离客户最近的地方，可能会绕远路。域名转发问题如果是A运营商将解析的请求转发给B运营商，B去权威DNS服务器查询的话，权威服务器会认为你是B运营商的，就返回了B运营商的网站地址，结果每次都会跨运营商。出口NAT问题做了网络地址转化后，权威的DNS服务器，没法通过地址来判断客户到底是哪个运营商，极有可能误判运营商，导致跨运营商访问。域名更新问题本地DNS服务器是由不同地区，不同运营商独立部署的，对域名解析缓存的处理上，有区别，有的会偷懒忽略解析结果TTL的时间限制，导致服务器没有更新新的ip而是指向旧的ip。解析延迟DNS的查询过程需要递归遍历多个DNS服务器，才能获得最终结果。可能会带来一定的延时。域名劫持DNS域名解析服务器有可能会被劫持，或者被伪造，那么正常的访问就会被解析到错误的地址。不可靠由于DNS解析是运行在UDP协议之上的，而UDP我之前也说过是一种不可靠的协议，他的优势在于实时性，但是有丢包的可能。

这些问题不仅会让访问速度变慢，还有可能会导致访问异常，访问页面被替换等等。

16、怎么优化DNS解析

安全优化

总之DNS还是会有各种问题吧，怎么解决呢？就是用HTTPDNS。

HTTPDNS是一个新概念，他会绕过传统的运营商DNS服务器，不走传统的DNS解析。而是换成HTTP协议，直接通过HTTP协议进行请求某个DNS服务器集群，获取地址。

由于绕过了运营商，所以可以避免域名被劫持。它是基于访问的来源ip，所以能获得更准确的解析结果会有预解析，解析缓存等功能，所以解析延迟也很小

所以首先的优化，针对安全方面，就是要替换成HTTPDNS解析方式，就要借用阿里云和腾讯云等服务，但是这些服务可不是免费的，有没有免费的呢？有的，七牛云的 happy-dns。添加依赖库，然后去实现okhttp的DNS接口即可，简单写个例子：

@MainThreadprotected void setValue(T value) {    assertMainThread("setValue");    mVersion++;    mData = value;    dispatchingValue(null);}private void dispatchingValue(@Nullable ObserverWrapper initiator) {    //...    do {        mDispatchInvalidated = false;        if (initiator != null) {            considerNotify(initiator);            initiator = null;        } else {            for (Iterator<Map.Entry<Observer<T>, ObserverWrapper>> iterator =                    mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {                considerNotify(iterator.next().getValue());                if (mDispatchInvalidated) {                    break;                }            }        }    } while (mDispatchInvalidated);    mDispatchingValue = false;}private void considerNotify(ObserverWrapper observer) {    if (!observer.mActive) {        return;    }    // Check latest state b4 dispatch. Maybe it changed state but we didn't get the event yet.    //    // we still first check observer.active to keep it as the entrance for events. So even if    // the observer moved to an active state, if we've not received that event, we better not    // notify for a more predictable notification order.    if (!observer.shouldBeActive()) {        observer.activeStateChanged(false);        return;    }    if (observer.mLastVersion >= mVersion) {        return;    }    observer.mLastVersion = mVersion;    //noinspection unchecked    observer.mObserver.onChanged((T) mData);}

速度优化

如果在测试环境，其实我们可以直接配置ip白名单，然后跳过DNS解析流程，直接获取ip地址。比如：

private static class TestDNS implements Dns{    @Override    public List<InetAddress> lookup(@NotNull String hostname) throws UnknownHostException {        if (";.equalsIgnoreCase(hostname)){            InetAddress byAddress=InetAddress.getByAddress(hostname,new byte[]{(byte)192,(byte)168,1,1});            return Collections.singletonList(byAddress);        }else {            return Dns.SYSTEM.lookup(hostname);        }    }}

...................

19、Activity从创建到我们看到界面，发生了哪些事

首先是通过setContentView加载布局，这其中创建了一个DecorView，然后根据然后根据activity设置的主题（theme）或者特征（Feature）加载不同的根布局文件，最后再通过inflate方法加载layoutResID资源文件，其实就是解析了xml文件，根据节点生成了View对象。流程图：

其次就是进行view绘制到界面上，这个过程发生在handleResumeActivity方法中，也就是触发onResume的方法。在这里会创建一个ViewRootImpl对象，作为DecorView的parent然后对DecorView进行测量布局和绘制三大流程。流程图：

20、Activity、PhoneWindow、DecorView、ViewRootImpl 的关系？PhoneWindow是Window 的唯一子类，每个Activity都会创建一个PhoneWindow对象，你可以理解它为一个窗口，但不是真正的可视窗口，而是一个管理类，是Activity和整个View系统交互的接口，是Activity和View交互系统的中间层。DecorView是PhoneWindow的一个内部类，是整个View层级的最顶层，一般包括标题栏和内容栏两部分，会根据不同的主题特性调整不同的布局。它是在setContentView方法中被创建，具体点来说是在PhoneWindow的installDecor方法中被创建。ViewRootImpl是DecorView的parent，用来控制View的各种事件，在handleResumeActivity方法中被创建。

........................

22、系统为什么提供Handler

这点大家应该都知道一些，就是为了切换线程，主要就是为了解决在子线程无法访问UI的问题。

那么为什么系统不允许在子线程中访问UI呢？

因为Android的UI控件不是线程安全的，所以采用单线程模型来处理UI操作，通过Handler切换UI访问的线程即可。

那么为什么不给UI控件加锁呢？

因为加锁会让UI访问的逻辑变得复杂，而且会降低UI访问的效率，阻塞线程执行。

Handler是怎么获取到当前线程的Looper的

大家应该都知道Looper是绑定到线程上的，他的作用域就是线程，而且不同线程具有不同的Looper，也就是要从不同的线程取出线程中的Looper对象，这里用到的就是ThreadLocal。

假设我们不知道有这个类，如果要完成这样一个需求，从不同的线程获取线程中的Looper，是不是可以采用一个全局对象，比如hashmap，用来存储线程和对应的Looper？

所以需要一个管理Looper的类，但是，线程中并不止这一个要存储和获取的数据，还有可能有其他的需求，也是跟线程所绑定的。所以，我们的系统就设计出了ThreadLocal这种工具类。

ThreadLocal的工作流程是这样的：我们从不同的线程可以访问同一个ThreadLocal的get方法，然后ThreadLocal会从各自的线程中取出一个数组，然后再数组中通过ThreadLocal的索引找出对应的value值。具体逻辑呢，我们还是看看代码，分别是ThreadLocal的get方法和set方法：

@Target(ElementType.METHOD)@Retention(RetentionPolicy.SOURCE)public @interface Override {}

首先看看set方法，获取到当前线程，然后取出线程中的threadLocals变量，是一个ThreadLocalMap类，然后将当前的ThreadLocal作为key，要设置的值作为value存到这个map中。

get方法就同理了，还是获取到当前线程，然后取出线程中的ThreadLocalMap实例，然后从中取到当前ThreadLocal对应的值。

其实可以看到，操作的对象都是线程中的ThreadLocalMap实例，也就是读写操作都只限制在线程内部，这也就是ThreadLocal故意设计的精妙之处了，他可以在不同的线程进行读写数据而且线程之间互不干扰。

画个图方便理解记忆：

当MessageQueue 没有消息的时候，在干什么，会占用CPU资源吗。

MessageQueue 没有消息时，便阻塞在 loop 的 queue.next() 方法这里。具体就是会调用到nativePollOnce方法里，最终调用到epoll_wait()进行阻塞等待。

这时，主线程会进行休眠状态，也就不会消耗CPU资源。当下个消息到达的时候，就会通过pipe管道写入数据然后唤醒主线程进行工作。

这里涉及到阻塞和唤醒的机制叫做 epoll 机制。

先说说文件描述符和I/O多路复用：

在Linux操作系统中，可以将一切都看作是文件,而文件描述符简称fd，当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符，可以理解为一个索引值。

I/O多路复用是一种机制，让单个进程可以监视多个文件描述符，一旦某个描述符就绪（一般是读就绪或写就绪），能够通知程序进行相应的读写操作

所以I/O多路复用其实就是一种监听读写的通知机制，而Linux提供的三种 IO 复用方式分别是：select、poll 和 epoll 。而这其中epoll是性能最好的多路I/O就绪通知方法。

所以，这里用到的epoll其实就是一种I/O多路复用方式，用来监控多个文件描述符的I/O事件。通过epoll_wait方法等待I/O事件，如果当前没有可用的事件则阻塞调用线程。

23、Binder通信过程和原理

首先，还是看一张图，原图也是出自神书中：

首先要明确的是客户端进程是无法直接操作服务端中的类和方法的，因为不同进程直接是不共享资源的。所以客户端这边操作的只是服务端进程的一个代理对象，也就是一个服务端的类引用，也就是Binder引用。

总体通信流程就是：

客户端通过代理对象向服务器发送请求。代理对象通过Binder驱动发送到服务器进程服务器进程处理请求，并通过Binder驱动返回处理结果给代理对象代理对象将结果返回给客户端。

再看看在我们应用中常常用到的工作模型，上图：

这就是在应用层面我们常用的工作模型，通过ServiceManager去获取各种系统进程服务。这里的通信过程如下：

服务端跨进程的类都要继承Binder类，所以也就是服务端对应的Binder实体。这个类并不是实际真实的远程Binder对象，而是一个Binder引用(即服务端的类引用)，会在Binder驱动里还要做一次映射。客户端要调用远程对象函数时，只需把数据写入到Parcel，在调用所持有的Binder引用的transact()函数transact函数执行过程中会把参数、标识符（标记远程对象及其函数）等数据放入到Client的共享内存，Binder驱动从Client的共享内存中读取数据，根据这些数据找到对应的远程进程的共享内存。然后把数据拷贝到远程进程的共享内存中，并通知远程进程执行onTransact()函数，这个函数也是属于Binder类。远程进程Binder对象执行完成后，将得到的写入自己的共享内存中，Binder驱动再将远程进程的共享内存数据拷贝到客户端的共享内存，并唤醒客户端线程。

所以通信过程中比较重要的就是这个服务端的Binder引用，通过它来找到服务端并与之完成通信。

看到这里可能有的人疑惑了，图中线程池怎么没用到啊？

可以从第一张图中看出，Binder线程池位于服务端，它的主要作用就是将每个业务模块的Binder请求统一转发到远程Servie中去执行，从而避免了重复创建Service的过程。也就是服务端只有一个，但是可以处理多个不同客户端的Binder请求。

......................

系统的面试复习路线

多余的话就不讲了，接下来将分享我之前面试的复习过程，如果你也在准备面试但是不知道怎么高效复习，可以参考一下我的复习路线，有任何问题也欢迎一起互相交流，加油吧！

这里给大家提供一个方向，进行体系化的学习：

1、看视频进行系统学习

这几年的Crud经历，让我明白自己真的算是菜鸡中的战斗机，也正因为Crud，导致自己技术比较零散，也不够深入不够系统，所以重新进行学习是很有必要的。我差的是系统知识，差的结构框架和思路，所以通过视频来学习，效果更好，也更全面。关于视频学习，个人可以推荐去B站进行学习，B站上有很多学习视频，唯一的缺点就是免费的容易过时。

另外，我自己也珍藏了好几套视频，有需要的我也可以分享给你。

2、进行系统梳理知识，提升储备

客户端开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。

系统学习方向：

架构师筑基必备技能：深入Java泛型+注解深入浅出+并发编程+数据传输与序列化+Java虚拟机原理+反射与类加载+动态代理+高效IOAndroid高级UI与FrameWork源码：高级UI晋升+Framework内核解析+Android组件内核+数据持久化360°全方面性能调优：设计思想与代码质量优化+程序性能优化+开发效率优化解读开源框架设计思想：热修复设计+插件化框架解读+组件化框架设计+图片加载框架+网络访问框架设计+RXJava响应式编程框架设计+IOC架构设计+Android架构组件JetpackNDK模块开发：NDK基础知识体系+底层图片处理+音视频开发微信小程序：小程序介绍+UI开发+API操作+微信对接Hybrid 开发与Flutter：Html5项目实战+Flutter进阶

知识梳理完之后，就需要进行查漏补缺，所以针对这些知识点，我手头上也准备了不少的电子书和笔记，这些笔记将各个知识点进行了完美的总结。

3、读源码，看实战笔记，学习大神思路

“编程语言是程序员的表达的方式，而架构是程序员对世界的认知”。所以，程序员要想快速认知并学习架构，读源码是必不可少的。阅读源码，是解决问题 + 理解事物，更重要的：看到源码背后的想法；程序员说：读万行源码，行万种实践。

主要内含微信 MMKV 源码、AsyncTask 源码、Volley 源码、Retrofit源码、OkHttp 源码等等。

4、面试前夕，刷题冲刺

面试的前一周时间内，就可以开始刷题冲刺了。请记住，刷题的时候，技术的优先，算法的看些基本的，比如排序等即可，而智力题，除非是校招，否则一般不怎么会问。

关于面试刷题，我个人也准备了一套系统的面试题，帮助你举一反三：

总结

改变人生，没有什么捷径可言，这条路需要自己亲自去走一走，只有深入思考，不断反思总结，保持学习的热情，一步一步构建自己完整的知识体系，才是最终的制胜之道，也是程序员应该承担的使命。

以上内容均免费分享给大家，需要完整版的朋友，直接转发+点赞+私信回复【资料】一键领取！！！