面试官提了一个问题,咱们来看看 😎、😨 和 🤔️ 三位同窗的表现如何吧java
😎 自认为无所不知,水平已达应用开发天花板,目前月薪 10kandroid
面试官:如何跨进程传递大图c++
😎:很简单,把图片存到 SD 卡,而后把路径传过去,在别的进程读出来这不就完事了嘛。面试
面试官:这个须要文件操做,效率不行,有别的方法吗?缓存
😎:Bitmap 实现了 Parcelable 接口,能够经过 Intent.putExtra(String name, Parcelable value) 方法直接放 Intent 里面传递。markdown
面试官:那这个方法有什么缺点?app
😎:Bitmap 太大就会抛异常,因此我更喜欢传路径ide
面试官:为何会抛异常?学习
😎:.....spa
面试官:好的,回去等通知吧
😨 业余时间常常打游戏、追剧、熬夜,目前月薪 15k
面试官:Intent 直接传 Bitmap 会有什么问题?
😨:Bitmap 太大会抛 TransactionTooLargeException 异常,缘由是:底层判断只要 Binder Transaction 失败,且 Intent 的数据大于 200k 就会抛这个异常了。(见:android_util_Binder.cpp 文件 signalExceptionForError 方法)
面试官:为何 Intent 传值会有大小限制。
😨:应用进程在启动 Binder 机制时会映射一块 1M 大小的内存,全部正在进行的 Binder 事务共享这 1M 的缓冲区 。当使用 Intent 进行 IPC 时申请的缓存超过 1M - 其余事务占用的内存时,就会申请失败抛 TransactionTooLargeException 异常了。 (哼,不会像上次同样答不出来了。见:“谈谈你对 binder 的理解?这样回答才过关”)
面试官:如何绕开这个限制呢?
😨:经过 AIDL 使用 Binder 进行 IPC 就不受这个限制,具体代码以下:
Bundle bundle = new Bundle(); bundle.putBinder("binder", new IRemoteGetBitmap.Stub() { @Override public Bitmap getBitMap() throws RemoteException { return mBitmap; } }); intent.putExtras(bundle); 复制代码
面试官:这是什么原理呢?
😨:还没去细看
面试官:好的,回去等通知吧
🤔️ 坚持天天学习、不断的提高本身,目前月薪 30k
面试官:为何经过 putBinder 的方式传 Bitmap 不会抛 TransactionTooLargeException 异常
🤔️:这个问题,咱们先来看下,底层在 IPC 时是怎么把 Bitmap 写进 Parcel 的。
Android - 28 Bitmap.cpp static jboolean Bitmap_writeToParcel(JNIEnv* env, jobject, ...) { // 拿到 Native 的 Bitmap auto bitmapWrapper = reinterpret_cast<BitmapWrapper*>(bitmapHandle); // 拿到其对应的 SkBitmap, 用于获取 Bitmap 的像素信息 bitmapWrapper->getSkBitmap(&bitmap); int fd = bitmapWrapper->bitmap().getAshmemFd(); if (fd >= 0 && !isMutable && p->allowFds()) { // Bitmap 带了 ashmemFd && Bitmap 不可修改 && Parcel 容许带 fd // 就直接把 FD 写到 Parcel 里,结束。 status = p->writeDupImmutableBlobFileDescriptor(fd); return JNI_TRUE; } // 不知足上面的条件就要把 Bitmap 拷贝到一块新的缓冲区 android::Parcel::WritableBlob blob; // 经过 writeBlob 拿到一块缓冲区 blob status = p->writeBlob(size, mutableCopy, &blob); // 获取像素信息并写到缓冲区 const void* pSrc = bitmap.getPixels(); if (pSrc == NULL) { memset(blob.data(), 0, size); } else { memcpy(blob.data(), pSrc, size); } } 复制代码
接下来咱们看一下 writeBlob 是怎么获取缓冲区的(注意虽然方法名写着 write , 可是实际往缓冲区写数据是在这个方法执行以后)
Android - 28 Parcel.cpp // Maximum size of a blob to transfer in-place. static const size_t BLOB_INPLACE_LIMIT = 16 * 1024; status_t Parcel::writeBlob(size_t len, bool mutableCopy, WritableBlob* outBlob) { if (!mAllowFds || len <= BLOB_INPLACE_LIMIT) { // 若是不容许带 fd ,或者这个数据小于 16K // 就直接在 Parcel 的缓冲区里分配一块空间来保存这个数据 status = writeInt32(BLOB_INPLACE); void* ptr = writeInplace(len); outBlob->init(-1, ptr, len, false); return NO_ERROR; } // 另外开辟一个 ashmem,映射出一块内存,后续数据将保存在 ashmem 的内存里 int fd = ashmem_create_region("Parcel Blob", len); void* ptr = ::mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); ... // parcel 里只写个 fd 就行了,这样就算数据量很大,parcel 本身的缓冲区也不用很大 status = writeFileDescriptor(fd, true /*takeOwnership*/); outBlob->init(fd, ptr, len, mutableCopy); return status; } 复制代码
经过上面的分析,咱们能够看出,同一个 Bitmap 写入到 Parcel 所占的缓冲区大小和 Pacel 的 allowFds 有关。
直接经过 Intent 传 Bitmap 容易抛 TransactionTooLargeException 异常,就是由于 Parcel 的 allowFds = false,直接把 Bitmap 写入缓冲区占用了较大的内存。
接下来,咱们来看一下,allowFds 是何时被设置成 false 的呢:
// 启动 Activity 执行到 Instrumentation.java 的这个方法 public ActivityResult execStartActivity(..., Intent intent, ...){ ... intent.prepareToLeaveProcess(who); ActivityManager.getService().startActivity(...,intent,...) } // Intent.java public void prepareToLeaveProcess(boolean leavingPackage) { // 这边一层层传递到最后设置 Parcel 的 allowfds setAllowFds(false); .... } 复制代码
面试官:太多了,你懂的。
🤔️:总结一下:较大的 bitmap 直接经过 Intent 传递容易抛异常是由于 Intent 启动组件时,系统禁掉了文件描述符 fd 机制 , bitmap 没法利用共享内存,只能拷贝到 Binder 映射的缓冲区,致使缓冲区超限, 触发异常; 而经过 putBinder 的方式,避免了 Intent 禁用描述符的影响,bitmap 写 parcel 时的 allowFds 默认是 true , 能够利用共享内存,因此能高效传输图片。
面试官:能够,咱们再来聊聊别的。