Android面试题

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);

@Override
public 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);
}

@Override
public void computeScroll() {
    // 重写computeScroll()方法，并在其内部完成平滑滚动的逻辑
    if (mScroller.computeScrollOffset()) {
        scrollTo(mScroller.getCurrX(), mScroller.getCurrY());
        invalidate();
    }
}

4.OKHttp有哪些拦截器，分别起什么作用？

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连接，以及负责编码解码的HttpCodec

• networkInterceptors，这里也是开发者自己设置的，所以本质上和第一个拦截器差不多，但是由于位置不同，所以用处也不同。这个位置添加的拦截器可以看到请求和响应的数据了，所以可以做一些网络调试。

• 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计数方法：

    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);
      }
    }
  }
}

观察者模式

之前我写过一篇文章，是关于Okhttp中websocket的使用，由于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架构，其实也是官方想进行项目架构的统一。

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

9.ViewModel 是什么，说说你所理解的ViewModel？

如果看过我上一篇文章的小伙伴应该都有所了解，ViewModel是MVVM架构的一个层级，用来联系View和model之间的关系。而我们今天要说的就是官方出的一个框架——ViewModel。

ViewModel 类旨在以注重生命周期的方式存储和管理界面相关的数据

官方是这么介绍的，这里面有两个信息：

注重生命周期的方式。由于ViewModel的生命周期是作用于整个Activity的，所以就节省了一些关于状态维护的工作，最明显的就是对于屏幕旋转这种情况，以前对数据进行保存读取，而ViewModel则不需要，他可以自动保留数据。

其次，由于ViewModel在生命周期内会保持局部单例，所以可以更方便Activity的多个Fragment之间通信，因为他们能获取到同一个ViewModel实例，也就是数据状态可以共享了。

存储和管理界面相关的数据。

ViewModel层的根本职责，就是负责维护界面上UI的状态，其实就是维护对应的数据，因为数据会最终体现到UI界面上。所以ViewModel层其实就是对界面相关的数据进行管理，存储等操作。

ViewModel 为什么被设计出来，解决了什么问题？

在ViewModel组件被设计出来之前，MVVM又是怎么实现ViewModel这一层级的呢？

其实就是自己编写类，然后通过接口，内部依赖实现View和数据的双向绑定。所以Google出这个ViewModel组件，无非就是为了规范MVVM架构的实现，并尽量让ViewModel这一层级只触及到业务代码，不去关心VIew层级的引用等。然后配合其他的组件，包括livedata，databindingrang等让MVVM架构更加完善，规范，健硕。

解决了什么问题呢？

其实上面已经说过一些了，比如：

1）不会因为屏幕旋转而销毁，减少了维护状态的工作 。

2）由于在作用域内单一实例的特性，使得多个fragment之间可以方便通信，并且维护同一个数据状态。

3）完善了MVVM架构，使得解耦更加纯粹。

10.说说ViewModel原理。

首先说说是怎么保存生命周期。

ViewModel2.0之前呢，其实原理是在Activity上add一个HolderFragment，然后设置setRetainInstance(true)方法就能让这个Fragment在Activity重建时存活下来，也就保证了ViewModel的状态不会随Activity的状态所改变。

2.0之后，其实是用到了Activity的onRetainNonConfigurationInstance()和getLastNonConfigurationInstance()这两个方法，相当于在横竖屏切的时候会保存ViewModel的实例，然后恢复，所以也就保证了ViewModel的数据。

再说说怎么保证作用域内唯一实例

首先，ViewModel的实例是通过反射获取的，反射的时候带上application的上下文，这样就保证了不会持有Activity或者Fragment等View的引用。然后实例创建出来会保存到一个ViewModelStore容器里面，其实也就是一个集合类，这个ViewModelStore 类其实就是保存在界面上的那个实例，而我们的ViewModel就是里面的一个集合类的子元素。

所以我们每次获取的时候，首先看看这个集合里面有无我们的ViewModel，如果没有就去实例化，如果有就直接拿到实例使用，这样就保证了唯一实例。最后在界面销毁的时候，会去执行ViewModelStore的clear方法，去清除集合里面的ViewModel数据。一小段代码说明下：

public <T extends ViewModel> T get(Class<T> modelClass) {
      // 先从ViewModelStore容器中去找是否存在ViewModel的实例
      ViewModel viewModel = mViewModelStore.get(key);

      // 若ViewModel已经存在，就直接返回
      if (modelClass.isInstance(viewModel)) {
            return (T) viewModel;
      }

      // 若不存在，再通过反射的方式实例化ViewModel，并存储进ViewModelStore
      viewModel = modelClass.getConstructor(Application.class).newInstance(mApplication);
      mViewModelStore.put(key, viewModel);
      return (T) viewModel;
 }


public class ViewModelStore {
    private final HashMap<String, ViewModel> mMap = new HashMap<>();

     public final void clear() {
        for (ViewModel vm : mMap.values()) {
            vm.onCleared();
        }
        mMap.clear();
    }
}



 @Override
protected void onDestroy() {
    super.onDestroy();

   if (mViewModelStore != null && !isChangingConfigurations()) {
        mViewModelStore.clear();
    }

}

11.ViewModel怎么实现自动处理生命周期？

为什么在旋转屏幕后不会丢失状态？为什么ViewModel可以跟随Activity/Fragment的生命周期而又不会造成内存泄漏呢？

这三个问题很类似，都是关于生命周期的问题，其实也就是问为什么ViewModel能管理生命周期，并且不会因为重建等情况造成影响。

ViewModel2.0之前

利用一个无view 的HolderFragment来维持它的生命周期，我们知道ViewModel实例是存储到一个ViewModelStore容器里的，那么这个空的fragment就可以用来管理这个容器，只要Activity处于活动状态，HolderFragment也就不会被销毁，就保证了ViewModel的生命周期。

而且设置setRetainInstance(true)方法可以保证configchange时的生命周期不被改变，让这个Fragment在Activity重建时存活下来。

总结来说就是用一个空的fragment来管理维护ViewModelStore，然后对应的activity销毁的时候就去把viewmodel的映射删除。就让ViewModel的生命周期保持和Activity一样了。这也是很多三方库用到的巧妙方法，比如Glide，也是建立空的Fragment来管理。

2.0之后，有了androidx支持

其实是用到了Activity的一个子类ComponentActivity，然后重写了onRetainNonConfigurationInstance()方法保存ViewModelStore，并在需要的时候，也就是重建的Activity中去通过getLastNonConfigurationInstance()方法获取到ViewModelStore实例。这样也就保证了ViewModelStore中的ViewModel不会随Activity的重建而改变。

同时由于实现了LifecycleOwner接口，所以能利用Lifecycles组件组件感知每个页面的生命周期，就可以通过它来订阅当Activity销毁时，且不是因为配置导致的destory情况下，去清除ViewModel，也就是调用ViewModelStore的clear方法。

getLifecycle().addObserver(new LifecycleEventObserver() {
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {
            if (event == Lifecycle.Event.ON_DESTROY) {
                // 判断是否因为配置更改导致的destroy
                if (!isChangingConfigurations()) {
                    getViewModelStore().clear();
                }
            }
        }
    });

这里的onRetainNonConfigurationInstance方法再说下，是会在Activity因为配置改变而被销毁时被调用，跟onSaveInstanceState方法调用时机比较相像，不同的是onSaveInstanceState保存的是Bundle，Bundle是有类型限制和大小限制的，而且需要在主线程进行序列号。而onRetainNonConfigurationInstance方法都没有限制，所以更倾向于用它。

所以，到这里，第三个问题应该也可以回答了，2.0之前呢，都是通过他们创建了一个空的fragment，然后跟随这个fragment的生命周期。

2.0之后呢，是因为不管是Activity或者Fragment，都实现了LifecycleOwner接口，所以ViewModel是可以通过Lifecycles感知到他们的生命周期，从而进行实例管理的。

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")

13.LiveData 为什么被设计出来，解决了什么问题？

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

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

• 不会发生内存泄漏 观察者会绑定到 Lifecycle对象，并在其关联的生命周期遭到销毁后进行自我清理。

• 不会因 Activity 停止而导致崩溃 如果观察者的生命周期处于非活跃状态（如返回栈中的 Activity），则它不会接收任何 LiveData 事件。

• 自动判断生命周期并回调方法 如果观察者的生命周期处于 STARTED 或 RESUMED状态，则 LiveData 会认为该观察者处于活跃状态，就会调用onActive方法，否则，如果 LiveData 对象没有任何活跃观察者时，会调用 onInactive()方法。

14.说说LiveData原理

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

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

简单看看源码：

@MainThread
public 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看起：

@MainThread
protected 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接口即可，简单写个例子：

//导入库
implementation 'com.qiniu:happy-dns:0.2.13'
implementation 'com.qiniu.pili:pili-android-qos:0.8'


//实现DNS接口
public class HttpDns implements Dns {

private DnsManager dnsManager;

public HttpDns() {
    IResolver[] resolvers = new IResolver[1];
    try {
        resolvers[0] = new Resolver(InetAddress.getByName("119.29.29.29"));
        dnsManager = new DnsManager(NetworkInfo.normal, resolvers);
    } catch (UnknownHostException e) {
        e.printStackTrace();
    }
}

@Override
public List<InetAddress> lookup(String hostname) throws UnknownHostException {
    if (dnsManager == null)  //当构造失败时使用默认解析方式
        return Dns.SYSTEM.lookup(hostname);

    try {
        String[] ips = dnsManager.query(hostname);  //获取HttpDNS解析结果
        if (ips == null || ips.length == 0) {
            return Dns.SYSTEM.lookup(hostname);
        }

        List<InetAddress> result = new ArrayList<>();
        for (String ip : ips) {  //将ip地址数组转换成所需要的对象列表
            result.addAll(Arrays.asList(InetAddress.getAllByName(ip)));
        }
        //在返回result之前，我们可以添加一些其他自己知道的IP
        return result;
    } catch (IOException e) {
        e.printStackTrace();
    }
    //当有异常发生时，使用默认解析
    return Dns.SYSTEM.lookup(hostname);
}
}


//替换okhttp的dns解析
OkHttpClient okHttpClient = new OkHttpClient.Builder().dns(new HttpDns()).build();

速度优化

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

private static class TestDNS implements Dns{
    @Override
    public List<InetAddress> lookup(@NotNull String hostname) throws UnknownHostException {
        if ("www.test.com".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);
        }
    }
}

17.DNS解析超时怎么办

当我们在用OKHttp做网络请求时，如果网络设备切换路由，访问网络出现长时间无响应，很久之后会抛出 UnknownHostException。虽然我们在OkHttp中设置了connectTimeout超时时间，但是它其实对DNS的解析是不起作用的。

这种情况我们就需要在自定义的Dns类中做超时判断：

public class TimeDns implements Dns {
    private long timeout;

    public TimeDns(long timeout) {
        this.timeout = timeout;
    }

    @Override
    public List<InetAddress> lookup(final String hostname) throws UnknownHostException {
        if (hostname == null) {
            throw new UnknownHostException("hostname == null");
        } else {
            try {
                FutureTask<List<InetAddress>> task = new FutureTask<>(
                        new Callable<List<InetAddress>>() {
                            @Override
                            public List<InetAddress> call() throws Exception {
                                return Arrays.asList(InetAddress.getAllByName(hostname));
                            }
                        });
                new Thread(task).start();
                return task.get(timeout, TimeUnit.MILLISECONDS);
            } catch (Exception var4) {
                UnknownHostException unknownHostException =
                        new UnknownHostException("Broken system behaviour for dns lookup of " + hostname);
                unknownHostException.initCause(var4);
                throw unknownHostException;
            }
        }
    }
}

//替换okhttp的dns解析
OkHttpClient okHttpClient = new OkHttpClient.Builder().dns(new TimeDns(5000)).build();

18.注解是什么？有哪些元注解

注解，在我看来它是一种信息描述，不影响代码执行，但是可以用来配置一些代码或者功能。

常见的注解比如@Override,代表重写方法，看看它是怎么生成的：

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

可以看到Override被@interface所修饰，代表注解，同时上方还有两个注解@Target和@Retention，这种修饰注解的注解叫做元注解，很好理解吧，就是最基本的注解呗。java中一共有四个元注解：

• @Target：表示注解对象的作用范围。

• @Retention：表示注解保留的生命周期

• @Inherited：表示注解类型能被类自动继承。

• @Documented：表示含有该注解类型的元素(带有注释的)会通过javadoc或类似工具进行文档化。

具体说下这几个元注解都是怎么用的

• @Target

target，表示注解对象的作用范围，比如Override注解所标示的就是ElementType.METHOD，即所作用的范围是方法范围，也就是只能在方法头上加这个注解。另外还有以下几个修饰范围参数：

• TYPE：类、接口、枚举、注解类型。

• FIELD：类成员（构造方法、方法、成员变量）。

• METHOD：方法。

• PARAMETER：参数。

• CONSTRUCTOR：构造器。

• LOCAL_VARIABLE：局部变量。

• ANNOTATION_TYPE：注解。

• PACKAGE：包声明。

• TYPE_PARAMETER：类型参数。

• TYPE_USE：类型使用声明。

比如ANNOTATION_TYPE就是表示该注解的作用范围就是注解，哈哈，有点绕吧，看看Target注解的代码：

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Target {
    /**
     * @return an array of the kinds of elements an annotation type
     * can be applied to
     */
    ElementType[] value();
}

带了一个ElementType类型的参数，也就是上面说到的作用范围参数，另外还被Target注解修饰了，传的参数就是ANNOTATION_TYPE，也就是我注解我自己，我设置我自己的作用范围是注解。大家自己绕一下。。

• @Retention

表示注解保留的生命周期，或者说表示该注解所保留的时长，主要有以下几个可选参数：

• SOURCE：仅存在Java源文件，经过编译器后便丢弃相应的注解。适用于一些检查性的操作，比如@Override。

• CLASS：编译class文件时生效，存在Java源文件，以及经编译器后生成的Class字节码文件，但在运行时VM不再保留注释。这个也是默认的参数。适用于在编译时进行一些预处理操作，比如ButterKnife的@BindView，可以在编译时生成一些辅助的代码或者完成一些功能。

• RUNTIME：存在源文件、编译生成的Class字节码文件，以及保留在运行时VM中，可通过反射性地读取注解。适用于一些需要运行时动态获取注解信息，类似反射获取注解等。

• @Inherited

表示注解类型能被类自动继承。这里需要注意两点：

• 类。也就是说只有在类集成关系中，子类才会集成父类使用的注解中被@Inherited所修饰的那个注解。其他的接口集成关系，类实现接口关系中，都不会存在自动继承注解。

• 自动继承。也就是说如果父类有@Inherited所修饰的那个注解，那么子类不需要去写这个注解，就会自动有了这个注解。

还是看个例子：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Inherited
public @interface MyInheritedAnnotation {
 //注解1，有Inherited注解修饰
}

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface MyAnnotation {
 //注解2，没有Inherited注解修饰
}


@MyInheritedAnnotation
@MyAnnotation
public class BaseClass {
 //父类，有以上两个注解
}

public class ExtendClass extends BaseClass  {

 //子类会继承父类的MyInheritedAnnotation注解，
 //而不会继承MyAnnotation注解
}

.@Documented

表示拥有该注解的元素可通过javadoc此类的工具进行文档化，也就是说生成JavaAPI文档的时候会被写进文档中。

注解可以用来做什么

主要有以下几个用处：

• 降低项目的耦合度。

• 自动完成一些规律性的代码。

• 自动生成java代码，减轻开发者的工作量。

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方法中被创建。

21.requestLayout和invalidate

requestLayout方法是用来触发绘制流程，他会会一层层调用 parent 的requestLayout，一直到最上层也就是ViewRootImpl的requestLayout，这里也就是判断线程的地方了，最后会执行到performMeasure -> performLayout -> performDraw 三个绘制流程，也就是测量——布局——绘制。

@Override
public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
        checkThread();
        mLayoutRequested = true;
        scheduleTraversals();//执行绘制流程
    }
}

其中performMeasure方法会执行到View的measure方法，用来测量大小。performLayout方法会执行到view的layout方法，用来计算位置。performDraw方法需要注意下，他会执行到view的draw方法，但是并不一定会进行绘制，只有只有 flag 被设置为 PFLAG_DIRTY_OPAQUE 才会进行绘制。

invalidate方法也是用来触发绘制流程，主要表现就是会调用draw()方法。虽然他也会走到scheduleTraversals方法，也就是会走到三大流程，但是View会通过mPrivateFlags来判断是否进行onMeasure和onLayout操作。而在用invalidate方法时，更新了mPrivateFlags，所以不会进行measure和layout。同时他也会设置Flag为PFLAG_DIRTY_OPAQUE，所以肯定会执行onDraw方法。

private void invalidateRectOnScreen(Rect dirty) {
    final Rect localDirty = mDirty;
    //...
    if (!mWillDrawSoon && (intersected || mIsAnimating)) {
        scheduleTraversals();//执行绘制流程
    }
}

最后看一下scheduleTraversals方法中三大绘制流程逻辑，是不是我们之前说的那样，FORCE_LAYOUT标志才会onMeasure和onLayout，PFLAG_DIRTY_OPAQUE标志才会onDraw：

public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
    final boolean forceLayout = (mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT;
    // 只有mPrivateFlags为PFLAG_FORCE_LAYOUT的时候才会进行onMeasure方法
    if (forceLayout || needsLayout) {
      onMeasure(widthMeasureSpec, heightMeasureSpec);
    }

    // 设置 LAYOUT_REQUIRED flag
    mPrivateFlags |= PFLAG_LAYOUT_REQUIRED;
  }


  public void layout(int l, int t, int r, int b) {
    ...
    //判断标记位为PFLAG_LAYOUT_REQUIRED的时候才进行onLayout方法
    if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
        onLayout(changed, l, t, r, b);
     }
 }



public void draw(Canvas canvas) {
    final int privateFlags = mPrivateFlags;
    // flag 是 PFLAG_DIRTY_OPAQUE 则需要绘制
    final boolean dirtyOpaque = (privateFlags & PFLAG_DIRTY_MASK) == PFLAG_DIRTY_OPAQUE &&
            (mAttachInfo == null || !mAttachInfo.mIgnoreDirtyState);
    mPrivateFlags = (privateFlags & ~PFLAG_DIRTY_MASK) | PFLAG_DRAWN;
    if (!dirtyOpaque) {
        drawBackground(canvas);
    }
    if (!dirtyOpaque) onDraw(canvas);
    // 绘制 Child
    dispatchDraw(canvas);
    // foreground 不管 dirtyOpaque 标志，每次都会绘制
    onDrawForeground(canvas);
} 

参考文章中有一段总结挺好的：

虽然两者都是用来触发绘制流程，但是在measure和layout过程中，只会对 flag 设置为 FORCE_LAYOUT 的情况进行重新测量和布局，而draw方法中只会重绘flag为 dirty 的区域。requestLayout 是用来设置FORCE_LAYOUT标志，invalidate 用来设置 dirty 标志。所以 requestLayout 只会触发 measure 和 layout，invalidate 只会触发 draw。

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方法：

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
} 

ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}    

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}    

首先看看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请求。

24.Binder在在Android中的应用

Binder在Android中的应用除了刚才的ServiceManager，你还想到了什么呢？

• 系统服务是用过getSystemService获取的服务，内部也就是通过ServiceManager。例如四大组件的启动调度等工作，就是通过Binder机制传递给ActivityManagerService，再反馈给Zygote。而我们自己平时应用中获取服务也是通过getSystemService(getApplication().WINDOW_SERVICE)代码获取。

• AIDL（Android Interface definition language）。例如我们定义一个IServer.aidl文件，aidl工具会自动生成一个IServer.java的java接口类（包含Stub，Proxy等内部类）。

• 前台进程通过bindService绑定后台服务进程时，onServiceConnected(ComponentName name, IBinder service)传回IBinder对象，并且可以通过IServer.Stub.asInterface(service)获取IServer的内部类Proxy的对象，其实现了IServer接口。

25.Binder优势

在Linux中，进程通信的方式肯定不止Binder这一种，还有以下这些：

管道（Pipe）
信号（Signal）
消息队列（Message）
共享内存（Share Memory）
套接字（Socket）
Binder

而Binder在这之后主要有以下优点：

• 性能高，效率高：传统的IPC（套接字、管道、消息队列）需要拷贝两次内存、Binder只需要拷贝一次内存、共享内存不需要拷贝内存。

• 安全性好：接收方可以从数据包中获取发送发的进程Id和用户Id，方便验证发送方的身份，其他IPC想要实验只能够主动存入，但是这有可能在发送的过程中被修改。

熟悉Zygote的朋友可能知道，在fork()进程的时候，也就是向Zygote进程发出创建进程的消息的时候，用到的进程间通信方式就不是Binder了，而换成了Socket，这主要是因为fork不允许存在多线程，Binder通讯偏偏就是多线程。

所以具体的情况还是要去具体选择合适的IPC方式。

26.RecyclerView预取机制与缓存机制

讲一下RecyclerView的缓存机制,滑动10个，再滑回去，会有几个执行onBindView。缓存的是什么？cachedView会执行onBindView吗?

这两个问题都是关于缓存的，我就一起说了。

1）首先说下RecycleView的缓存结构：

Recycleview有四级缓存，分别是mAttachedScrap(屏幕内)，mCacheViews(屏幕外)，mViewCacheExtension(自定义缓存)，mRecyclerPool(缓存池)

• mAttachedScrap(屏幕内)，用于屏幕内itemview快速重用，不需要重新createView和bindView

• mCacheViews(屏幕外)，保存最近移出屏幕的ViewHolder，包含数据和position信息，复用时必须是相同位置的ViewHolder才能复用，应用场景在那些需要来回滑动的列表中，当往回滑动时，能直接复用ViewHolder数据，不需要重新bindView。

• mViewCacheExtension(自定义缓存)，不直接使用，需要用户自定义实现，默认不实现。

• mRecyclerPool(缓存池)，当cacheView满了后或者adapter被更换，将cacheView中移出的ViewHolder放到Pool中，放之前会把ViewHolder数据清除掉，所以复用时需要重新bindView。

2）四级缓存按照顺序需要依次读取。所以完整缓存流程是：

保存缓存流程：

• 插入或是删除itemView时，先把屏幕内的ViewHolder保存至AttachedScrap中

• 滑动屏幕的时候，先消失的itemview会保存到CacheView，CacheView大小默认是2，超过数量的话按照先入先出原则，移出头部的itemview保存到RecyclerPool缓存池（如果有自定义缓存就会保存到自定义缓存里），RecyclerPool缓存池会按照itemview的itemtype进行保存，每个itemType缓存个数为5个，超过就会被回收。

获取缓存流程：

• AttachedScrap中获取，通过pos匹配holder——>获取失败，从CacheView中获取，也是通过pos获取holder缓存 ——>获取失败，从自定义缓存中获取缓存——>获取失败，从mRecyclerPool中获取 ——>获取失败，重新创建viewholder——createViewHolder并bindview。

3）了解了缓存结构和缓存流程，我们再来看看具体的问题 滑动10个，再滑回去，会有几个执行onBindView？

• 由之前的缓存结构可知，需要重新执行onBindView的只有一种缓存区，就是缓存池mRecyclerPool。

所以我们假设从加载RecyclView开始盘的话（页面假设可以容纳7条数据）：

• 首先，7条数据会依次调用onCreateViewHolder和onBindViewHolder。

• 往下滑一条（position=7），那么会把position=0的数据放到mCacheViews中。此时mCacheViews缓存区数量为1，mRecyclerPool数量为0。然后新出现的position=7的数据通过postion在mCacheViews中找不到对应的ViewHolder，通过itemtype也在mRecyclerPool中找不到对应的数据，所以会调用onCreateViewHolder和onBindViewHolder方法。

• 再往下滑一条数据（position=8），如上。

• 再往下滑一条数据（position=9），position=2的数据会放到mCacheViews中，但是由于mCacheViews缓存区默认容量为2，所以position=0的数据会被清空数据然后放到mRecyclerPool缓存池中。而新出现的position=9数据由于在mRecyclerPool中还是找不到相应type的ViewHolder，所以还是会走onCreateViewHolder和onBindViewHolder方法。所以此时mCacheViews缓存区数量为2，mRecyclerPool数量为1。

• 再往下滑一条数据（position=10），这时候由于可以在mRecyclerPool中找到相同viewtype的ViewHolder了。所以就直接复用了，并调用onBindViewHolder方法绑定数据。

• 后面依次类推，刚消失的两条数据会被放到mCacheViews中，再出现的时候是不会调用onBindViewHolder方法，而复用的第三条数据是从mRecyclerPool中取得，就会调用onBindViewHolder方法了。

4）所以这个问题就得出结论了（假设mCacheViews容量为默认值2）：

• 如果一开始滑动的是新数据，那么滑动10个，就会走10个bindview方法。然后滑回去，会走10-2个bindview方法。一共18次调用。

• 如果一开始滑动的是老数据，那么滑动10-2个，就会走8个bindview方法。然后滑回去，会走10-2个bindview方法。一共16次调用。

但是但是，实际情况又有点不一样。因为Recycleview在v25版本引入了一个新的机制，预取机制。

预取机制，就是在滑动过程中，会把将要展示的一个元素提前缓存到mCachedViews中，所以滑动10个元素的时候，第11个元素也会被创建，也就多走了一次bindview方法。但是滑回去的时候不影响，因为就算提前取了一个缓存数据，只是把bindview方法提前了，并不影响总的绑定item数量。

所以滑动的是新数据的情况下就会多一次调用bindview方法。

5）总结，问题怎么答呢？

• 四级缓存和流程说一下。

• 滑动10个，再滑回去，bindview可以是19次调用，可以是16次调用。

• 缓存的其实就是缓存item的view，在Recycleview中就是viewholder。

• cachedView就是mCacheViews缓存区中的view，是不需要重新绑定数据的。

27.如何实现RecyclerView的局部更新，用过payload吗,notifyItemChange方法中的参数？

• notifyDataSetChanged()，刷新全部可见的item。*notifyItemChanged(int)，刷新指定item。

• notifyItemRangeChanged(int,int)，从指定位置开始刷新指定个item。

• notifyItemInserted(int)、notifyItemMoved(int)、notifyItemRemoved(int)。插入、移动一个并自动刷新。

• notifyItemChanged(int, Object)，局部刷新。

可以看到，关于view的局部刷新就是notifyItemChanged(int, Object)方法，下面具体说说：

notifyItemChange有两个构造方法：

• notifyItemChanged(int position, @Nullable Object payload)

• notifyItemChanged(int position)

其中payload参数可以认为是你要刷新的一个标示，比如我有时候只想刷新itemView中的textview,有时候只想刷新imageview？又或者我只想某一个view的文字颜色进行高亮设置？那么我就可以通过payload参数来标示这个特殊的需求了。

具体怎么做呢？比如我调用了notifyItemChanged（14,"changeColor"）,那么在onBindViewHolder回调方法中做下判断即可：

@Override
public void onBindViewHolder(ViewHolderholder, int position, List<Object> payloads) {
    if (payloads.isEmpty()) {
        // payloads为空，说明是更新整个ViewHolder
        onBindViewHolder(holder, position);
    } else {
        // payloads不为空，这只更新需要更新的View即可。
        String payload = payloads.get(0).toString();
        if ("changeColor".equals(payload)) {
            holder.textView.setTextColor("");
        }
    }
}

28.RecyclerView嵌套RecyclerView滑动冲突，NestScrollView嵌套RecyclerView

1）RecyclerView嵌套RecyclerView的情况下，如果两者都要上下滑动，那么就会引起滑动冲突。默认情况下外层的RecycleView可滑，内层不可滑。

之前说过解决滑动冲突的办法有两种：内部拦截法和外部拦截法。这里我提供一种内部拦截法，还有一些其他的办法大家可以自己思考下。

holder.recyclerView.setOnTouchListener { v, event ->
    when(event.action){
        //当按下操作的时候，就通知父view不要拦截，拿起操作就设置可以拦截，正常走父view的滑动。
        MotionEvent.ACTION_DOWN,MotionEvent.ACTION_MOVE -> v.parent.requestDisallowInterceptTouchEvent(true)
        MotionEvent.ACTION_UP -> v.parent.requestDisallowInterceptTouchEvent(false)
    }
false}

2）关于ScrclerView的滑动冲突还是同样的解决办法，就是进行事件拦截。还有一个办法就是用Nestedscrollview代替ScrollView，Nestedscrollview是官方为了解决滑动冲突问题而设计的新的View。它的定义就是支持嵌套滑动的ScrollView。

所以直接替换成Nestedscrollview就能保证两者都能正常滑动了。但是要注意设置RecyclerView.setNestedScrollingEnabled(false)这个方法，用来取消RecyclerView本身的滑动效果。

这是因为RecyclerView默认是setNestedScrollingEnabled(true)，这个方法的含义是支持嵌套滚动的。也就是说当它嵌套在NestedScrollView中时,默认会随着NestedScrollView滚动而滚动,放弃了自己的滚动。所以给我们的感觉就是滞留、卡顿。所以我们将它设置为false就解决了卡顿问题，让他正常的滑动，不受外部影响。

 

转载：https://mp.weixin.qq.com/s/Xcu3yaEDcZnmjDo_eQV-HQ