移动开发最新深入Android系统 Binder-3-原理，如何做一个面试官流程

最后附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题 （含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总）

面试成功其实是必然的，因为我做足了充分的准备工作，包括刷题啊，看一些Android核心的知识点，看一些面试的博客吸取大家面试的一些经验，下面这份PDF是我翻阅了差不多1个月左右一些Android大博主的博客从他们那里取其精华去其糟泊所整理出来的一些Android的核心知识点， 全部都是精华中的精华，我能面试到现在资深开发人员跟我整理的这本Android核心知识点有密不可分的关系，在这里本着共赢的心态分享给各位朋友。

这份PDF囊括了JVM，Java集合，Java多线程并发，Java基础，生命周期，微服务， 进程,Parcelable 接口，IPC，屏幕适配,线程异步,ART，架构，Jetpack，NDK开发，计算机网络基础，类加载器，Android 开源库源码分析，设计模式汇总，Gradle 知识点汇总…

由于篇幅有限，就不做过多的介绍，大家请自行脑补

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

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

• 这块内存并不是给上层应用使用

• 这块内存用于Binder驱动中接受传递给本进程的Binder数据

• 这块内存在内核和本应用中共享

• 得到 ProcessState 类的实例后，调用它的 startThreadPool() 函数启动线程池，看下代码：

void ProcessState::startThreadPool(){

AutoMutex _l(mLock);

if (!mThreadPoolStarted) {

mThreadPoolStarted = true;

spawnPooledThread(true);

}

}

• 先判断mThreadPoolStarted是否为true，不为true才继续执行

• 然后把mThreadPoolStarted设置为true，这说明startThreadPool()在进程中只会运行一次

• 接着调用spawnPooledThread函数，参数为true

void ProcessState::spawnPooledThread(bool isMain)

{

if (mThreadPoolStarted) {

String8 name = makeBinderThreadName();

ALOGV(“Spawning new pooled thread, name=%s\n”, name.string());

sp t = new PoolThread(isMain);

t->run(name.string());

}

}

• spawnPooledThread函数的作用是创建加入线程池的线程

• 函数中创建了一个PoolThread类，类的run函数会创建线程

• 传入的参数为true，说明这个线程是线程池的第一个线程

• 以后再创建的线程都是接到驱动通知后创建的，传入的参数为false，像这样

status_t IPCThreadState::executeCommand(int32_t cmd){

//…

case BR_SPAWN_LOOPER:

  mProcess->spawnPooledThread(false);

  break;

//…

}

• 我们再看下PoolThread类的业务实现threadLoop函数

protected:

virtual bool threadLoop()

{

IPCThreadState::self()->joinThreadPool(mIsMain);

return false;

}

  * 返回`false`代表执行一次，为什么是在`threadLoop()`中执行业务逻辑，可以看下[Android 中的`threadLoop`]( )

  * 具体调用细节大家阅读`frameworks`源码吧，路径应该是在：`frameworks/av/services/audioflinger/Threads.h`

  * `threadLoop`函数只是调用了`IPCThreadState`的`joinThreadPool`函数，这个函数后面单练它

好的，我们先来梳理下线程池这部分内容：

• 首先，应用启动时会执行onZygoteInit函数，这部分会打开Binder设备并申请共享内存空间

• 然后，执行ProcessState的startThreadPool创建线程池

• 然后，通过创建PoolThread的实例，创建线程池中的第一个线程

• 最后，PoolThread只是简单调用了IPCThreadState的joinThreadPool函数

关于IPCThreadState，稍后详谈

调用Binder服务的线程

客户端Binder服务的调用是通过IBinder的transact函数完成的。这里的IBInder实际上是BpBinder对象，代码如下：

status_t BpBinder::transact(

uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

// Once a binder has died, it will never come back to life.

if (mAlive) {

status_t status = IPCThreadState::self()->transact(

mHandle, code, data, reply, flags);

if (status == DEAD_OBJECT) mAlive = 0;

return status;

}

return DEAD_OBJECT;

}

这部分代码做了：

• 通过 IPCThreadState 的 self 静态函数获取 IPCThreadState 的指针

• IPCThreadState对象会和每个线程关联

• self函数会判断本线程是否有关联的IPCThreadState对象

• 没有关联的对象则新创建一个IPCThreadState对象，并保存到当前线程中

• 得到IPCThreadState对象后，接着调用了IPCThreadState的transact，我们看下代码：

status_t IPCThreadState::transact(int32_t handle,

uint32_t code, const Parcel& data,

Parcel* reply, uint32_t flags)

{

status_t err;

flags |= TF_ACCEPT_FDS;

//…

//把要发送的数据放到类的成员变量mOut中

err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);

if (err != NO_ERROR) {

if (reply) reply->setError(err);

return (mLastError = err);

}

if ((flags & TF_ONE_WAY) == 0) {// 同步调用方式

//…

if (reply) {

// 调用者要求返回结果，此时向底层发送数据并等待返回值

err = waitForResponse(reply);

} else {

// 调用者不需要返回值，但是还要等待远程执行完毕

// 这里用fakeRely来接收返回的Parcel对象

Parcel fakeReply;

err = waitForResponse(&fakeReply);

}

//…

} else {// 异步调用方式，函数会立即返回

err = waitForResponse(NULL, NULL);

}

return err;

}

• IPCThreadState的transact首先执行writeTransactionData包要传输的数据保存到mOut变量中

• 然后通过waitForResponse把mOut中的数据通过ioctl发送给底层驱动

对于一个进程而言，只有一个Binder驱动的文件描述符，所有ioctl调用都是使用这个描述符。如果客户端有好几个线程同时执行远程调用，它们都将在同一个描述符的ioctl函数上等待。那么当数据到来时，哪个线程会受到回复呢？

• 通常的IO模型，在同一个描述符上等待的多个线程会被随机唤醒一个

• 但是Android在 Binder驱动 中记录了每次Binder调用的信息，其中就包括 线程ID，因此Binder驱动知道返回值应该交给哪个线程

• 由驱动来处理线程的唤醒比在应用层做同样的事情要更简单，效率也更高

• 但是，从架构的角度来看，这种设计比较糟糕，应用层和驱动产生了耦合。

好的，我们在对这部分做个小结：

• 客户端从某个线程中发起调用，将参数打包后，通过ioctl函数传递给驱动

• 客户端挂起并等待ioctl返回函数的结果

• binder驱动记录下调用线程的信息，然后根据调用的binder对象寻找Binder服务所在的进程，也就是服务端

• binder驱动找到服务端后先查看是否有空闲线程，没有则通知服务端创建

• 服务端得到空闲线程后，根据binder驱动中保存的BBinder对象的指针调用相应的函数

• 服务端在函数返回后在通过ioctl把结果打包传递给binder驱动

• binder驱动根据返回信息查找调用者线程

• binder驱动找到调用的线程后并唤醒它，并通过ioctl函数把结果传递回去

• 客户端的线程得到返回结果后继续运行

Binder对象的传递

---

当Binder对象作为参数传递是，会有两种情形：

• Binder实体对象作为参数传递：非Binder对象的传递是通过在接收端复制对象完成的，但是Binder实体对象是无法复制的，因此需要在客户进程中创建一个Binder引用对象来代替实体对象。

• Binder引用 对象作为参数传递：

• 如果传递的目的地是该引用对象对应实体对象所在的进程，那么：

• Binder框架必须把这个引用对象转换成Binder实体对象。

• 不能再创建一个新的实体对象

• 必须找到并使用原来的实体对象

• 如果传递的目的地是另一个客户端进程，那么：

• 不能简单的复制引用对象

• 需要建立目的进程中的引用对象和实体对象的关系

• 这个关系的建立是在Binder驱动中完成的

Binder对象传递流程简介

Binder调用的参数传递是通过Parcel类来完成的。先来简单看下Binder实体对象转换成Binder引用对象的过程：

• 在服务进程中将IBinder（BBinder）对象加入到Parcel对象后，Parcel对象会：

• 打包数据，并把数据类型标记为BINDER_TYPE_BINDER

• 把BpBinder的指针放进cookie字段

• 通过ioctl把Parcel对象的数据传递到Binder驱动中

• Binder驱动会检查传递进来的数据，如果发现了标记为BINDER_TYPE_BINDER的数据：

• 会先查找和服务进程相关的Binder实体对象表：

• 如果表中还没有这个实体对象的记录，则创建新的节点，并保存信息。

• 然后驱动会查看客户进程的Binder对象引用表：

• 如果没有引用对象的记录，同样会创建新的节点

• 并让这个节点中某个字段指向服务进程的Binder实体对象表中的节点

• 接下来驱动对Parcel对象中的数据进行改动：

• 把数据从BINDER_TYPE_BINDER改为BINDER_TYPE_HANEL

• 同时把handle的值设为Binder对象引用表中的节点

• 最后，把改动的数据传到客户进程

• 客户端接收到数据，发现数据中的Binder类型为BINDER_TYPE_HANEL后

• 使用handle值作为参数，调用ProcessState类中的函数getStrongProxyFoHandle来得到BpBinder对象

• 如果对象不存在则创建一个新的对象

• 这个BpBinder对象会一直保存在ProcessState的mHandleToObject表中

• 这样，客户端就得到了Binder引用对象

写入Binder对象的过程

有了上面的整体流程，我们来看下Binder对象的写入细节：

• Parcel类中：

• 写入Binder对象的函数是：

• writeStrongBinder：写入强引用Binder对象

• writeWeakBinder：写入弱引用Binder对象

• 读取Binder对象的函数是：

• readStrongBinder：获取强引用Binder对象

• 强引用的Binder对象可以分为实体对象和引用对象

• readWeakBinder：获取弱引用Binder对象

• 弱引用则没有区分实体对象和引用对象

看下writeStrongBinder的代码：

status_t Parcel::writeStrongBinder(const sp& val)

{

return flatten_binder(ProcessState::self(), val, this);

}

status_t flatten_binder(const sp& /proc/,

const sp& binder, Parcel* out)

{

// flatten_binder 整个方法其实是在向obj这个结构体存放数据

flat_binder_object obj;

if (IPCThreadState::self()->backgroundSchedulingDisabled()) {

/* minimum priority for all nodes is nice 0 */

obj.flags = FLAT_BINDER_FLAG_ACCEPTS_FDS;

} else {

/* minimum priority for all nodes is MAX_NICE(19) */

obj.flags = 0x13 | FLAT_BINDER_FLAG_ACCEPTS_FDS;

}

if (binder != NULL) {

// 调用localBinder函数开区分是实体对象还是引用对象

IBinder *local = binder->localBinder();

if (!local) { //binder引用对象

BpBinder *proxy = binder->remoteBinder();

if (proxy == NULL) {

ALOGE(“null proxy”);

}

const int32_t handle = proxy ? proxy->handle() : 0;

obj.hdr.type = BINDER_TYPE_HANDLE;

obj.binder = 0; /* Don’t pass uninitialized stack data to a remote process */

obj.handle = handle;

obj.cookie = 0;

} else { // binder实体对象

obj.hdr.type = BINDER_TYPE_BINDER;

obj.binder = reinterpret_cast<uintptr_t>(local->getWeakRefs());

obj.cookie = reinterpret_cast<uintptr_t>(local);

}

} else {

obj.hdr.type = BINDER_TYPE_BINDER;

obj.binder = 0;

obj.cookie = 0;

}

return finish_flatten_binder(binder, obj, out);

}

flatten_binder整个方法其实是在向flat_binder_object这个结构体存放数据。我们看下flat_binder_object的结构：

struct flat_binder_object {

/* 8 bytes for large_flat_header. */

__u32 type;

__u32 flags;

/* 8 bytes of data. */

union {

binder_uintptr_t binder; /* local object */

__u32 handle; /* remote object */

};

/* extra data associated with local object */

binder_uintptr_t cookie;

};

我们看下flat_binder_object中的属性：

• type 的类型：

• BINDER_TYPE_BINDER：用来表示Binder实体对象

• BINDER_TYPE_WEAK_BINDER：用来表示Bindr实体对象的弱引用

• BINDER_TYPE_HANDLE：用来表示Binder引用对象

• BINDER_TYPE_WEAK_HANDLE：用来表示Binder引用对象的弱引用

• BINDER_TYPE_FD：用来表示一个文件描述符

• flag字段用来保存向驱动传递的标志

• union.binder在打包实体对象时存放的是对象的弱引用指针

• union.handle在打包引用对象时存放的是对象中的handle值

• cookie字段只用在打包实体对象时，存放的是BBinder指针

解析强引用Binder对象数据的过程

Parcel 类中解析数据的函数是unflatten_binder，代码如下：

status_t unflatten_binder(const sp& proc,

const Parcel& in, sp* out)

{

const flat_binder_object* flat = in.readObject(false);

if (flat) {

switch (flat->hdr.type) {

case BINDER_TYPE_BINDER:

out = reinterpret_cast<IBinder>(flat->cookie);

return finish_unflatten_binder(NULL, *flat, in);

case BINDER_TYPE_HANDLE:

*out = proc->getStrongProxyForHandle(flat->handle);

return finish_unflatten_binder(

static_cast<BpBinder*>(out->get()), *flat, in);

}

}

return BAD_TYPE;

}

unflatten_binder的逻辑是：

• 如果是BINDER_TYPE_BINDER类型的数据，说明接收到的数据类型是Binder实体对象，此时cookie字段存放的是本进程的Binder实体对象的指针，可直接转化成IBinder的指针

• 如果是 BINDER_TYPE_HANDLE 类型的数据，则调用 ProcessState类的 getStrongProxyForHandle函数来得到 BpBinder对象，函数代码如下：

sp ProcessState::getStrongProxyForHandle(int32_t handle)

{

sp result;

AutoMutex _l(mLock);

// 根据handle查看进程中是否已经创建了引用对象

// 如果进程中不存在handle对应的引用对象，在表中插入新的元素并返回

handle_entry* e = lookupHandleLocked(handle);

if (e != NULL) {

IBinder* b = e->binder;

//根据返回元素中的binder值来判断是否有引用对象

if (b == NULL || !e->refs->attemptIncWeak(this)) {

if (handle == 0) { // handle为0 表示是ServiceManager的引用对象

Parcel data;

//发送PING_TRANSACTION检查ServiceManager是否存在

status_t status = IPCThreadState::self()->transact(

0, IBinder::PING_TRANSACTION, data, NULL, 0);

if (status == DEAD_OBJECT)

return NULL;

}

b = BpBinder::create(handle); // 创建一个新的引用对象

e->binder = b;// 放入元素中的binder属性

if (b) e->refs = b->getWeakRefs();

result = b;

} else {

result.force_set(b);// 如果引用对象已经存在，放入到返回的对象result中

e->refs->decWeak(this);

}

}

return result;

}

getStrongProxyForHandle()函数会调用lookupHandleLocked()来查找handle在进程中对应的引用对象。所有进程的引用对象都保存在 ProcessState 的 mHandleToObject

变量中。 mHandleToObject 变量定义如下：

Vector<handle_entry> mHandleToObject;

• mHandleToObject 是一个 Vector 集合类，元素类型 handle_entry

• handle_entry

结构很简单：

struct handle_entry {

IBinder* binder;

RefBase::weakref_type* refs;

};

• lookupHandleLocked()函数就是使用handle作为关键项来查找对应的handle_entry，没有则创建新的handle_entry，并添加到集合中

• 当获得 handle_entry 后，如果 handle 值为0，表明要创建的是 ServiceManager 的 引用对象

• 并发送PING_TRANSACTION消息来检查ServiceManager是否已经创建

IPCThreadState类

---

每个Binder线程都会有一个关联的IPCThreadState类的对象。IPCThreadState类主要的作用是和Binder驱动交互，发送接收Binder数据，处理和Binder驱动之间来往的消息。

我们在Binder线程模型中已经知道：

• Binder服务启动时，服务线程调用了joinThreadPool()函数

• 远程调用Binder服务时，客户线程调用了waitForResponse()函数

这两个函数都是定义在IPCThreadState类中，我们分别来看下这两个函数。

waitForResponse()函数

函数定义如下：

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)

{

uint32_t cmd;

int32_t err;

while (1) {

if ((err=talkWithDriver()) < NO_ERROR) break;//和驱动通信

err = mIn.errorCheck();

if (err < NO_ERROR) break;

if (mIn.dataAvail() == 0) continue;//没有数据，重新开始循环

cmd = (uint32_t)mIn.readInt32();//读取数据

//…

switch (cmd) {

case BR_TRANSACTION_COMPLETE:

if (!reply && !acquireResult) goto finish;

break;

//…省略部分case语句

case BR_REPLY:

// Binder调用返回的消息

default:

err = executeCommand(cmd);

if (err != NO_ERROR) goto finish;

break;

}

}

finish:

//… 错误处理

return err;

}

waitForResponse()函数中是一个无限while循环，在循环中，重复下面的工作：

• 调用talkWithDriver函数发送/接收数据

• 如果有消息从驱动返回，会通过 switch语句处理消息。

• 如果收到错误消息或者调用返回的消息，将通过goto语句跳出while循环

• 如果还有未处理的消息，则交给executeCommand函数处理

我们再仔细看下Binder调用收到的返回类型为BR_REPLY的代码：

case BR_REPLY:

{

binder_transaction_data tr;

//按照 binder_transaction_data 结构大小读取数据

err = mIn.read(&tr, sizeof(tr));

ALOG_ASSERT(err == NO_ERROR, “Not enough command data for brREPLY”);

if (err != NO_ERROR) goto finish;

if (reply) {

//reply 不为null，表示调用者需要返回结果

if ((tr.flags & TF_STATUS_CODE) == 0) {

//binder 调用成功，把从驱动来的数据设置到reply对象中

reply->ipcSetDataReference(

reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),

tr.data_size,

reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),

tr.offsets_size/sizeof(binder_size_t),

freeBuffer, this);

} else {

//binder调用失败，使用freeBuffer函数释放驱动中分配的缓冲区

err = reinterpret_cast<const status_t>(tr.data.ptr.buffer);

freeBuffer(NULL,

reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),

tr.data_size,

reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),

tr.offsets_size/sizeof(binder_size_t), this);

}

} else {

//调用者不需要返回结果，使用freeBuffer函数释放驱动中分配的缓冲区

freeBuffer(NULL,

reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),

tr.data_size,

reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),

tr.offsets_size/sizeof(binder_size_t), this);

continue;

}

}

针对BR_REPLY类型的处理流程是：

• 如果 Binder调用 成功返回，并且 调用者 也需要返回值

• 把接收到的数据放在Parcel对象reply中返回

• 如果 Binder调用 不成功，或者 调用者不需要返回数据

• 通过freeBuffer释放驱动中分配的缓冲区

因为Binder提供了一块驱动和应用层共享的内存空间，所以在接收Binder数据时不需要额外创建缓冲区并再进行一次拷贝了，但是如果不及时通知驱动释放缓冲区中占用的无用内存，会很快会耗光这部分共享空间。

上面代码中的reply->ipcSetDataReference方法，在设置Parcel对象的同时，同样也把freeBuffer的指针作为参数传入到对象中，这样reply对象删除时，也会调用freeBuffer函数来释放驱动中的缓冲区。

waitForResponse()函数的作用是发送Binder调用的数据并等待返回值。为什么还需要使用循环的方式反复和驱动交互？原因有两点：

• 一是消息协议中要求应用层通过 BC_TRANSACTION 发送 Binder 调用数据后：

• 驱动要先给应用层回复BC_TRANSACTION_COMPLETE消息，表示已经说到并且认可本次Binder调用数据。

• 然后上层应用再次调用talkWithDriver来等待驱动返回调用结果

• 如果调用结果返回了，会收到BR_REPLY消息

• 二是等待调用返回期间，驱动可能会给线程发送消息，利用这个线程帮忙干点活。。。。

joinThreadPool函数

在Binder线程池部分已经知道：应用启动时会伴随着启动Binder服务，而最后执行到的方法就是joinThreadPool函数。

我们看下函数定义：

void IPCThreadState::joinThreadPool(bool isMain)

{

mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER);

status_t result;

do {

processPendingDerefs();

//now get the next command to be processed, waiting if necessary

result = getAndExecuteCommand();//读取并处理驱动发送的消息

总结

其实要轻松掌握很简单，要点就两个：

1. 找到一套好的视频资料，紧跟大牛梳理好的知识框架进行学习。
2. 多练。 （视频优势是互动感强，容易集中注意力）

你不需要是天才，也不需要具备强悍的天赋，只要做到这两点，短期内成功的概率是非常高的。

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。

以上就是总结的关于在面试的一些总结，希望对大家能有些帮助，除了这些面试中需要注意的问题，当然最重要的就是刷题了，这里放上我之前整理的一份超全的面试专题PDF

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

这里只是整理出来的部分面试题，后续会持续更新，希望通过这些高级面试题能够降低面试Android岗位的门槛，让更多的Android工程师理解Android系统，掌握Android系统。喜欢的话麻烦点击一个喜欢在关注一下~

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

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

e::joinThreadPool(bool isMain)

{

mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER);

status_t result;

do {

processPendingDerefs();

//now get the next command to be processed, waiting if necessary

result = getAndExecuteCommand();//读取并处理驱动发送的消息

总结

其实要轻松掌握很简单，要点就两个：

1. 找到一套好的视频资料，紧跟大牛梳理好的知识框架进行学习。
2. 多练。 （视频优势是互动感强，容易集中注意力）

你不需要是天才，也不需要具备强悍的天赋，只要做到这两点，短期内成功的概率是非常高的。

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。

以上就是总结的关于在面试的一些总结，希望对大家能有些帮助，除了这些面试中需要注意的问题，当然最重要的就是刷题了，这里放上我之前整理的一份超全的面试专题PDF

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

[外链图片转存中…(img-znrcVKdf-1715462179461)]

这里只是整理出来的部分面试题，后续会持续更新，希望通过这些高级面试题能够降低面试Android岗位的门槛，让更多的Android工程师理解Android系统，掌握Android系统。喜欢的话麻烦点击一个喜欢在关注一下~

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

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