面试必考体系庞大的Handler你真的都了解吗？Handler二十七问带你打破砂锅问到底！_handler和synchronized优缺点(3)

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数HarmonyOS鸿蒙开发工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上HarmonyOS鸿蒙开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注鸿蒙获取）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

然后继续看看ThreadLocalMap哪来的，也就是getMap方法：

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

    //Thread.java
    ThreadLocal.ThreadLocalMap threadLocals = null;

原来这个ThreadLocalMap变量是存储在线程类Thread中的。

所以ThreadLocal的基本机制就搞清楚了：

在每个线程中都有一个threadLocals变量，这个变量存储着ThreadLocal和对应的需要保存的对象。

这样带来的好处就是，在不同的线程，访问同一个ThreadLocal对象，但是能获取到的值却不一样。

挺神奇的是不是，其实就是其内部获取到的Map不同，Map和Thread绑定，所以虽然访问的是同一个ThreadLocal对象，但是访问的Map却不是同一个，所以取得值也不一样。

这样做有什么好处呢？为什么不直接用Map存储线程和对象呢？

打个比方：

• ThreadLocal就是老师。
• Thread就是同学。
• Looper（需要的值）就是铅笔。

现在老师买了一批铅笔，然后想把这些铅笔发给同学们，怎么发呢？两种办法：

1、老师把每个铅笔上写好每个同学的名字，放到一个大盒子里面去（map），用的时候就让同学们自己来找。

这种做法就是Map里面存储的是同学和铅笔，然后用的时候通过同学来从这个Map里找铅笔。

这种做法就有点像使用一个Map，存储所有的线程和对象，不好的地方就在于会很混乱，每个线程之间有了联系，也容易造成内存泄漏。

2、老师把每个铅笔直接发给每个同学，放到同学的口袋里（map），用的时候每个同学从口袋里面拿出铅笔就可以了。

这种做法就是Map里面存储的是老师和铅笔，然后用的时候老师说一声，同学只需要从口袋里拿出来就行了。

很明显这种做法更科学，这也就是ThreadLocal的做法，因为铅笔本身就是同学自己在用，所以一开始就把铅笔交给同学自己保管是最好的，每个同学之间进行隔离。

还有哪些地方运用到了ThreadLocal机制？

比如：Choreographer。

public final class Choreographer {

    // Thread local storage for the choreographer.
    private static final ThreadLocal<Choreographer> sThreadInstance =
            new ThreadLocal<Choreographer>() {
        @Override
        protected Choreographer initialValue() {
            Looper looper = Looper.myLooper();
            if (looper == null) {
                throw new IllegalStateException("The current thread must have a looper!");
            }
            Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
            if (looper == Looper.getMainLooper()) {
                mMainInstance = choreographer;
            }
            return choreographer;
        }
    };

    private static volatile Choreographer mMainInstance;

Choreographer主要是主线程用的，用于配合 VSYNC中断信号。

所以这里使用ThreadLocal更多的意义在于完成线程单例的功能。

可以多次创建Looper吗？

Looper的创建是通过Looper.prepare方法实现的，而在prepare方法中就判断了，当前线程是否存在Looper对象，如果有，就会直接抛出异常：

private static void prepare(boolean quitAllowed) {
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        sThreadLocal.set(new Looper(quitAllowed));
    }

    private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }

所以同一个线程，只能创建一个Looper，多次创建会报错。

Looper中的quitAllowed字段是啥？有什么用？

按照字面意思就是是否允许退出，我们看看他都在哪些地方用到了：

void quit(boolean safe) {
        if (!mQuitAllowed) {
            throw new IllegalStateException("Main thread not allowed to quit.");
        }

        synchronized (this) {
            if (mQuitting) {
                return;
            }
            mQuitting = true;

            if (safe) {
                removeAllFutureMessagesLocked();
            } else {
                removeAllMessagesLocked();
            }
        }
    }

哦，就是这个quit方法用到了，如果这个字段为false，代表不允许退出，就会报错。

但是这个quit方法又是干嘛的呢？从来没用过呢。还有这个safe又是啥呢？

其实看名字就差不多能了解了，quit方法就是退出消息队列，终止消息循环。

• 首先设置了mQuitting字段为true。
• 然后判断是否安全退出，如果安全退出，就执行removeAllFutureMessagesLocked方法，它内部的逻辑是清空所有的延迟消息，之前没处理的非延迟消息还是需要取处理，然后设置非延迟消息的下一个节点为空（p.next=null）。
• 如果不是安全退出，就执行removeAllMessagesLocked方法，直接清空所有的消息，然后设置消息队列指向空（mMessages = null）

然后看看当调用quit方法之后，消息的发送和处理：

//消息发送
    boolean enqueueMessage(Message msg, long when) {
        synchronized (this) {
            if (mQuitting) {
                IllegalStateException e = new IllegalStateException(
                        msg.target + " sending message to a Handler on a dead thread");
                Log.w(TAG, e.getMessage(), e);
                msg.recycle();
                return false;
            }
        }

当调用了quit方法之后，mQuitting为true，消息就发不出去了，会报错。

再看看消息的处理，loop和next方法：

Message next() {
        for (;;) {
            synchronized (this) {
                if (mQuitting) {
                    dispose();
                    return null;
                } 
            }  
        }
    }

    public static void loop() {
        for (;;) {
            Message msg = queue.next();
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }
        }
    }

很明显，当mQuitting为true的时候，next方法返回null，那么loop方法中就会退出死循环。

那么这个quit方法一般是什么时候使用呢？

• 主线程中，一般情况下肯定不能退出，因为退出后主线程就停止了。所以是当APP需要退出的时候，就会调用quit方法，涉及到的消息是EXIT_APPLICATION，大家可以搜索下。
• 子线程中，如果消息都处理完了，就需要调用quit方法停止消息循环。

Looper.loop方法是死循环，为什么不会卡死（ANR）？

关于这个问题，强烈建议看看Gityuan的回答：https://www.zhihu.com/question/34652589

我大致总结下：

• 主线程本身就是需要一只运行的，因为要处理各个View，界面变化。所以需要这个死循环来保证主线程一直执行下去，不会被退出。
• 真正会卡死的操作是在某个消息处理的时候操作时间过长，导致掉帧、ANR，而不是loop方法本身。
• 在主线程以外，会有其他的线程来处理接受其他进程的事件，比如Binder线程（ApplicationThread），会接受AMS发送来的事件
• 在收到跨进程消息后，会交给主线程的Hanlder再进行消息分发。所以Activity的生命周期都是依靠主线程的Looper.loop，当收到不同Message时则采用相应措施，比如收到msg=H.LAUNCH_ACTIVITY，则调用ActivityThread.handleLaunchActivity()方法，最终执行到onCreate方法。
• 当没有消息的时候，会阻塞在loop的queue.next()中的nativePollOnce()方法里，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生。所以死循环也不会特别消耗CPU资源。

Message是怎么找到它所属的Handler然后进行分发的？

在loop方法中，找到要处理的Message，然后调用了这么一句代码处理消息：

msg.target.dispatchMessage(msg);

所以是将消息交给了msg.target来处理，那么这个target是啥呢？

找找它的来头：

//Handler
    private boolean enqueueMessage(MessageQueue queue,Message msg,long uptimeMillis) {
        msg.target = this;

        return queue.enqueueMessage(msg, uptimeMillis);
    }

在使用Hanlder发送消息的时候，会设置msg.target = this，所以target就是当初把消息加到消息队列的那个Handler。

Handler 的 post(Runnable) 与 sendMessage 有什么区别

Hanlder中主要的发送消息可以分为两种：

• post(Runnable)
• sendMessage

public final boolean post(@NonNull Runnable r) {
       return  sendMessageDelayed(getPostMessage(r), 0);
    }
    private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

通过post的源码可知，其实post和sendMessage的区别就在于：

post方法给Message设置了一个callback。

那么这个callback有什么用呢？我们再转到消息处理的方法dispatchMessage中看看：

public void dispatchMessage(@NonNull Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

    private static void handleCallback(Message message) {
        message.callback.run();
    }

这段代码可以分为三部分看：

• 如果msg.callback不为空，也就是通过post方法发送消息的时候，会把消息交给这个msg.callback进行处理，然后就没有后续了。
• 如果msg.callback为空，也就是通过sendMessage发送消息的时候，会判断Handler当前的mCallback是否为空，如果不为空就交给Handler.Callback.handleMessage处理。
• 如果mCallback.handleMessage返回true，则无后续了。
• 如果mCallback.handleMessage返回false，则调用handler类重写的handleMessage方法。

所以post(Runnable) 与 sendMessage的区别就在于后续消息的处理方式，是交给msg.callback还是 Handler.Callback或者Handler.handleMessage。

Handler.Callback.handleMessage 和 Handler.handleMessage 有什么不一样？为什么这么设计？

接着上面的代码说，这两个处理方法的区别在于Handler.Callback.handleMessage方法是否返回true：

• 如果为true，则不再执行Handler.handleMessage
• 如果为false，则两个方法都要执行。

那么什么时候有Callback，什么时候没有呢？这涉及到两种Hanlder的 创建方式：

val handler1= object : Handler(){
        override fun handleMessage(msg: Message) {
            super.handleMessage(msg)
        }
    }

    val handler2 = Handler(object : Handler.Callback {
        override fun handleMessage(msg: Message): Boolean {
            return true
        }
    })

常用的方法就是第1种，派生一个Handler的子类并重写handleMessage方法。而第2种就是系统给我们提供了一种不需要派生子类的使用方法，只需要传入一个Callback即可。

Handler、Looper、MessageQueue、线程是一一对应关系吗？

• 一个线程只会有一个Looper对象，所以线程和Looper是一一对应的。
• MessageQueue对象是在new Looper的时候创建的，所以Looper和MessageQueue是一一对应的。
• Handler的作用只是将消息加到MessageQueue中，并后续取出消息后，根据消息的target字段分发给当初的那个handler，所以Handler对于Looper是可以多对一的，也就是多个Hanlder对象都可以用同一个线程、同一个Looper、同一个MessageQueue。

总结：Looper、MessageQueue、线程是一一对应关系，而他们与Handler是可以一对多的。

ActivityThread中做了哪些关于Handler的工作？（为什么主线程不需要单独创建Looper）

主要做了两件事：

1、在main方法中，创建了主线程的Looper和MessageQueue，并且调用loop方法开启了主线程的消息循环。

public static void main(String[] args) {

        Looper.prepareMainLooper();

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }

        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

2、创建了一个Handler来进行四大组件的启动停止等事件处理

final H mH = new H();

class H extends Handler {
        public static final int BIND_APPLICATION        = 110;
        public static final int EXIT_APPLICATION        = 111;
        public static final int RECEIVER                = 113;
        public static final int CREATE_SERVICE          = 114;
        public static final int STOP_SERVICE            = 116;
        public static final int BIND_SERVICE            = 121;

IdleHandler是啥？有什么使用场景？

之前说过，当MessageQueue没有消息的时候，就会阻塞在next方法中，其实在阻塞之前，MessageQueue还会做一件事，就是检查是否存在IdleHandler，如果有，就会去执行它的queueIdle方法。

private IdleHandler[] mPendingIdleHandlers;

    Message next() {
        int pendingIdleHandlerCount = -1;
        for (;;) {
            synchronized (this) {
                //当消息执行完毕，就设置pendingIdleHandlerCount
                if (pendingIdleHandlerCount < 0
                        && (mMessages == null || now < mMessages.when)) {
                    pendingIdleHandlerCount = mIdleHandlers.size();
                }

                //初始化mPendingIdleHandlers
                if (mPendingIdleHandlers == null) {
                    mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
                }
                //mIdleHandlers转为数组
                mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
            }

            // 遍历数组，处理每个IdleHandler
            for (int i = 0; i < pendingIdleHandlerCount; i++) {
                final IdleHandler idler = mPendingIdleHandlers[i];
                mPendingIdleHandlers[i] = null; // release the reference to the handler

                boolean keep = false;
                try {
                    keep = idler.queueIdle();
                } catch (Throwable t) {
                    Log.wtf(TAG, "IdleHandler threw exception", t);
                }

                //如果queueIdle方法返回false，则处理完就删除这个IdleHandler
                if (!keep) {
                    synchronized (this) {
                        mIdleHandlers.remove(idler);
                    }
                }
            }

            // Reset the idle handler count to 0 so we do not run them again.
            pendingIdleHandlerCount = 0;
        }
    }

当没有消息处理的时候，就会去处理这个mIdleHandlers集合里面的每个IdleHandler对象，并调用其queueIdle方法。最后根据queueIdle返回值判断是否用完删除当前的IdleHandler。

然后看看IdleHandler是怎么加进去的：

Looper.myQueue().addIdleHandler(new IdleHandler() {  
    @Override  
    public boolean queueIdle() {  
        //做事情
        return false;    
    }  
});

    public void addIdleHandler(@NonNull IdleHandler handler) {
        if (handler == null) {
            throw new NullPointerException("Can't add a null IdleHandler");
        }
        synchronized (this) {
            mIdleHandlers.add(handler);
        }
    }

ok，综上所述，IdleHandler就是当消息队列里面没有当前要处理的消息了，需要堵塞之前，可以做一些空闲任务的处理。

常见的使用场景有：启动优化。

我们一般会把一些事件（比如界面view的绘制、赋值）放到onCreate方法或者onResume方法中。但是这两个方法其实都是在界面绘制之前调用的，也就是说一定程度上这两个方法的耗时会影响到启动时间。

所以我们可以把一些操作放到IdleHandler中，也就是界面绘制完成之后才去调用，这样就能减少启动时间了。

但是，这里需要注意下可能会有坑。

如果使用不当，IdleHandler会一直不执行，比如在View的onDraw方法里面无限制的直接或者间接调用View的invalidate方法。

其原因就在于onDraw方法中执行invalidate，会添加一个同步屏障消息，在等到异步消息之前，会阻塞在next方法，而等到FrameDisplayEventReceiver异步任务之后又会执行onDraw方法，从而无限循环。

HandlerThread是啥？有什么使用场景？

直接看源码：

public class HandlerThread extends Thread {
    @Override
    public void run() {
        Looper.prepare();
        synchronized (this) {
            mLooper = Looper.myLooper();
            notifyAll();
        }
        Process.setThreadPriority(mPriority);
        onLooperPrepared();
        Looper.loop();
    }

哦，原来如此。HandlerThread就是一个封装了Looper的Thread类。

就是为了让我们在子线程里面更方便的使用Handler。

这里的加锁就是为了保证线程安全，获取当前线程的Looper对象，获取成功之后再通过notifyAll方法唤醒其他线程，那哪里调用了wait方法呢？

public Looper getLooper() {
        if (!isAlive()) {
            return null;
        }

        // If the thread has been started, wait until the looper has been created.
        synchronized (this) {
            while (isAlive() && mLooper == null) {
                try {
                    wait();
                } catch (InterruptedException e) {
                }
            }
        }
        return mLooper;
    }

就是getLooper方法，所以wait的意思就是等待Looper创建好，那边创建好之后再通知这边正确返回Looper。

IntentService是啥？有什么使用场景？

老规矩，直接看源码：

public abstract class IntentService extends Service {

    private final class ServiceHandler extends Handler {
        public ServiceHandler(Looper looper) {
            super(looper);
        }

        @Override
        public void handleMessage(Message msg) {
            onHandleIntent((Intent)msg.obj);
            stopSelf(msg.arg1);
        }
    }

    @Override
    public void onCreate() {
        super.onCreate();
        HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
        thread.start();

        mServiceLooper = thread.getLooper();
        mServiceHandler = new ServiceHandler(mServiceLooper);
    }

    @Override
    public void onStart(@Nullable Intent intent, int startId) {
        Message msg = mServiceHandler.obtainMessage();
        msg.arg1 = startId;
        msg.obj = intent;
        mServiceHandler.sendMessage(msg);
    }

理一下这个源码：

• 首先，这是一个Service
• 并且内部维护了一个HandlerThread，也就是有完整的Looper在运行。
• 还维护了一个子线程的ServiceHandler。
• 启动Service后，会通过Handler执行onHandleIntent方法。
• 完成任务后，会自动执行stopSelf停止当前Service。

所以，这就是一个可以在子线程进行耗时任务，并且在任务执行后自动停止的Service。

BlockCanary使用过吗？说说原理

BlockCanary是一个用来检测应用卡顿耗时的三方库。

上文说过，View的绘制也是通过Handler来执行的，所以如果能知道每次Handler处理消息的时间，就能知道每次绘制的耗时了？那Handler消息的处理时间怎么获取呢？

再去loop方法中找找细节：

public static void loop() {
    for (;;) {
        // This must be in a local variable, in case a UI event sets the logger
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }

        msg.target.dispatchMessage(msg);

        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }
    }
}

可以发现，loop方法内有一个Printer类，在dispatchMessage处理消息的前后分别打印了两次日志。

那我们把这个日志类Printer替换成我们自己的Printer，然后统计两次打印日志的时间不就相当于处理消息的时间了？

Looper.getMainLooper().setMessageLogging(mainLooperPrinter);

    public void setMessageLogging(@Nullable Printer printer) {
        mLogging = printer;
    }

这就是BlockCanary的原理。

说说Hanlder内存泄露问题。

这也是常常被问的一个问题，Handler内存泄露的原因是什么？

“内部类持有了外部类的引用，也就是Hanlder持有了Activity的引用，从而导致无法被回收呗。”

其实这样回答是错误的，或者说没回答到点子上。

我们必须找到那个最终的引用者，不会被回收的引用者，其实就是主线程，这条完整引用链应该是这样：

主线程 —> threadlocal —> Looper —> MessageQueue —> Message —> Handler —> Activity

利用Handler机制设计一个不崩溃的App？

主线程崩溃，其实都是发生在消息的处理内，包括生命周期、界面绘制。

所以如果我们能控制这个过程，并且在发生崩溃后重新开启消息循环，那么主线程就能继续运行。

Handler(Looper.getMainLooper()).post {
        while (true) {
            //主线程异常拦截
            try {
                Looper.loop()
            } catch (e: Throwable) {
            }
        }
    }

还有一些特殊情况处理，比如onCreate内发生崩溃，具体可以看看文章

《能否让APP永不崩溃》https://juejin.cn/post/6904283635856179214

总结

大家应该可以发现，有一个问题常被问，但是全篇都没有提，那就是：

Hanlder机制的运行原理。

之所以不提这个问题，是因为要回答好这个问题需要大量知识储备，希望屏幕前的你在读完这篇之后，再结合自己的知识库，形成自己的**“完美答案”**。

Hanlder，I Got it！

面试复习路线

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

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

1、看视频进行系统学习

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

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

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

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

系统学习方向：

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

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

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

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

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

4、面试前夕，刷题冲刺

系统学习方向：

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

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

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

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

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

4、面试前夕，刷题冲刺