-
通常的
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调用
的参数传递是通过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
是否已经创建
每个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();//读取并处理驱动发送的消息
if (result < NO_ERROR && result != TIMED_OUT && result != -ECONNREFUSED && result != -EBADF) {
abort();
}
// Let this thread exit the thread pool if it is no longer
// needed and it is not the main process thread.
if(result == TIMED_OUT && !isMain) {
break;
}
} while (result != -ECONNREFUSED && result != -EBADF);
mOut.writeInt32(BC_EXIT_LOOPER); //退出前向驱动发送线程退出消息
talkWithDriver(false);
}
joinThreadPool
函数的结构是一个while循环。
-
传入的参数 isMain
-
如果为 true(通常是线程池第一个线程发起的调用),则向驱动发送 BC_ENTER_LOOPER 消息
-
发送
BC_ENTER_LOOPER
的线程会被驱动标记为“主”线程 -
不会在空闲时间被驱动要求退出
-
否则,发送
BC_REGISTER_LOOPER
。 -
这两条消息都是告诉驱动:本线程已经做好准备接收驱动来的Binder调用了
-
进入循环,调用了 processPendingDerefs() 函数
-
用来处理 IPCThreadState 对象中 mPendingWeakDerefs
和 mPendingStrongDerefs 的 Binder对象 的引用计数
-
mPendingWeakDerefs
和mPendingStrongDerefs
都是Vector
集合 -
当接收到驱动发来的
BR_RELEASE
消息时,就会把其中的Binder对象
放到mPendingStrongDerefs
中 -
并在
processPendingDerefs()
函数中介绍对象的引用计数 -
调用 getAndExecuteCommand 函数
-
函数中调用
talkWithDriver
读取驱动传递的数据 -
然后调用
executeCommand
来执行
到这里,我们再来看下talkWithDriver
和executeCommand
两个函数
talkWithDriver
函数
talkWithDriver
函数的作用是把IPCThreadState
类中的mOut变量
保存的数据通过ioctl
函数发送到驱动,同时把驱动返回的数据放到类的mIn变量
中。
talkWithDriver
函数的代码如下:
status_t IPCThreadState::talkWithDriver(bool doReceive)
{
if (mProcess->mDriverFD <= 0) {
return -EBADF;
}
//ioctl 传输时所使用的的数据结构
binder_write_read bwr;
// Is the read buffer empty?
// 判断 mIn 中的数据是否已经读取完毕,没有的话还需要继续读取
const bool needRead = mIn.dataPosition() >= mIn.dataSize();
// We don’t want to write anything if we are still reading
// from data left in the input buffer and the caller
// has requested to read the next data.
// 英文描述的很详细了哟
// 如果不需要读取数据(doReceive=false,needRead=true),那么就可以准备写数据了
const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;
bwr.write_size = outAvail;//表示要写入的长度
bwr.write_buffer = (uintptr_t)mOut.data();//要写入的数据的指针
// This is what we’ll read.
if (doReceive && needRead) {
bwr.read_size = mIn.dataCapacity();
bwr.read_buffer = (uintptr_t)mIn.data();
} else {
bwr.read_size = 0;
bwr.read_buffer = 0;
}
// Return immediately if there is nothing to do.
if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;
bwr.write_consumed = 0;//这个字段后面会被填上驱动读取到的数据长度(写入到驱动的数据长度)
bwr.read_consumed = 0;// 这个字段后面会被填上从驱动返回的数据长度
status_t err;
do {
// 9.0增加了一些平台判断,可能以后要多平台去支持了吧
#if defined(ANDROID)
// 用ioctl和驱动交换数据
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
else
err = -errno;
#else
err = INVALID_OPERATION;
#endif
if (mProcess->mDriverFD <= 0) {
// 这个情况应该是设备节点不可用
err = -EBADF;
}
} while (err == -EINTR);
if (err >= NO_ERROR) {
if (bwr.write_consumed > 0) {
if (bwr.write_consumed < mOut.dataSize())
// 如果已经写入驱动的数据长度小于mOut中的数据长度
// 说明还没发送完,把已经写入驱动的数据移除掉
// 剩下的数据等待下次发送
mOut.remove(0, bwr.write_consumed);
else {
// 数据已经全部写入驱动,复位mOut
mOut.setDataSize(0);
// 做一些指针的清理工作
processPostWriteDerefs();
}
}
if (bwr.read_consumed > 0) {
// 说明从驱动中读到了数据,设置好mInt对象
mIn.setDataSize(bwr.read_consumed);
mIn.setDataPosition(0);
}
return NO_ERROR;
}
return err;
}
-
准备发送到驱动中的数据保存在成员变量
mOut
中 -
从驱动中读取到的数据保存在成员变量
mInt
中 -
调用 talkWithDriver 时,如果 mInt 还有数据
-
表示还没有处理完驱动发来的消息
-
本次函数调用将不会从驱动中读取数据
-
ioctl 函数
-
使用的命令是
BINDER_WRITE_READ
-
需要
binder_write_read
结构体作为参数 -
驱动篇再看
executeCommand
函数
executeCommand
函数是一个大的switch语句,处理从驱动传递过来的消息。
我们前面遇到了一些消息,大概包括:
-
BR_SPAWN_LOOP
:驱动通知启动新线程的消息 -
BR_DEAD_BINDER
:驱动通知Binder服务
死亡的消息 -
BR_FINISHED
:驱动通知线程退出的消息 -
BR_ERROR
,BR_OK
,BR_NOOP
:驱动简单的回复消息 -
BR_RELEASE
,BR_INCREFS
,BR_DECREFS
:驱动通知增加和减少Binder对象
跨进程的引用计数 -
BR_TRANSACTION
,:驱动通知进行Binder调用
的消息
重点是BR_TRANSACTION
,代码定义如下:
case BR_TRANSACTION:
{
binder_transaction_data tr;
result = mIn.read(&tr, sizeof(tr));
if (result != NO_ERROR) break; // 数据异常直接退出
Parcel buffer;
//用从驱动接收的数据设置Parcel对象Buffer
buffer.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);
const pid_t origPid = mCallingPid;
const uid_t origUid = mCallingUid;
const int32_t origStrictModePolicy = mStrictModePolicy;
const int32_t origTransactionBinderFlags = mLastTransactionBinderFlags;
// 从消息中取出调用者的进程ID和euid
mCallingPid = tr.sender_pid;
mCallingUid = tr.sender_euid;
mLastTransactionBinderFlags = tr.flags;
Parcel reply;
status_t error;
if (tr.target.ptr) {
// We only have a weak reference on the target object, so we must first try to
// safely acquire a strong reference before doing anything else with it.
if (reinterpret_castRefBase::weakref_type*(
tr.target.ptr)->attemptIncStrong(this)) {
// 如果ptr指针不为空,cookie保存的是BBinder的指针
// 调用cookie的transact函数
error = reinterpret_cast<BBinder*>(tr.cookie)->transact(tr.code, buffer,
&reply, tr.flags);
// 及时清除指针
reinterpret_cast<BBinder*>(tr.cookie)->decStrong(this);
} else {
error = UNKNOWN_TRANSACTION;
}
} else {
//如果tr.target.ptr为0 表示是ServiceManager
error = the_context_object->transact(tr.code, buffer, &reply, tr.flags);
}
// 如果是同步调用,则把reply对象发送回去,否则什么也不做
if ((tr.flags & TF_ONE_WAY) == 0) {
LOG_ONEWAY(“Sending reply to %d!”, mCallingPid);
if (error < NO_ERROR) reply.setError(error);
sendReply(reply, 0);
} else {
LOG_ONEWAY(“NOT sending reply to %d!”, mCallingPid);
}
mCallingPid = origPid;
mCallingUid = origUid;
mStrictModePolicy = origStrictModePolicy;
mLastTransactionBinderFlags = origTransactionBinderFlags;
}
break;
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
尾声
最后,我再重复一次,如果你想成为一个优秀的 Android 开发人员,请集中精力,对基础和重要的事情做深度研究。
对于很多初中级Android工程师而言,想要提升技能,往往是自己摸索成长,不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路,本文的重点是你有没有收获与成长,其余的都不重要,希望读者们能谨记这一点。
这里,笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家梳理了多年的架构经验,筹备近6个月最新录制的,相信这份视频能给你带来不一样的启发、收获。
Android进阶学习资料库
一共十个专题,包括了Android进阶所有学习资料,Android进阶视频,Flutter,java基础,kotlin,NDK模块,计算机网络,数据结构与算法,微信小程序,面试题解析,framework源码!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!**
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
[外链图片转存中…(img-u7wjFYyP-1713677951010)]
[外链图片转存中…(img-jBnhHIOd-1713677951012)]
[外链图片转存中…(img-BPcQtcIr-1713677951013)]
[外链图片转存中…(img-hwzBfSAH-1713677951014)]
[外链图片转存中…(img-qCur7qs1-1713677951015)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
尾声
最后,我再重复一次,如果你想成为一个优秀的 Android 开发人员,请集中精力,对基础和重要的事情做深度研究。
对于很多初中级Android工程师而言,想要提升技能,往往是自己摸索成长,不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路,本文的重点是你有没有收获与成长,其余的都不重要,希望读者们能谨记这一点。
这里,笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家梳理了多年的架构经验,筹备近6个月最新录制的,相信这份视频能给你带来不一样的启发、收获。
[外链图片转存中…(img-7OgojgDH-1713677951016)]
Android进阶学习资料库
一共十个专题,包括了Android进阶所有学习资料,Android进阶视频,Flutter,java基础,kotlin,NDK模块,计算机网络,数据结构与算法,微信小程序,面试题解析,framework源码!
[外链图片转存中…(img-9ZDCyK3z-1713677951017)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!