关于AudioFlinger中ashmem匿名共享内存的理解

《android的ashmem和pmem确实通过BpMemoryHeap和mmap完成了IPC通信》

哎,汗,把ashmem匿名共享内存看完之后,没有在ashmem中找到IPC共享的一丁点东西,
回过头来看AudioFlinger的audio_track_cblk_t

MediaPlayerService::AudioOutput::open
==> new AudioTrack
==> set(streamType, sampleRate, format, channels, frameCount, flags, cbf, user, notificationFrames, 0);
==> createTrack(streamType, sampleRate, format, channelCount, frameCount, flags, sharedBuffer, output);
==> AudioTrack::createTrack
==> audioFlinger->createTrack
==> sp cblk = track->getCblk();

才发现类MediaPlayerService,AudioFlinger,CameraService和AudioPolicyService
都被包到了mediaserver系统服务进程这一个进程了,
那这些类之间memory操作就不存在IPC了[luther.gliethttp],我汗啊！！！！

frameworks/base/media/mediaserver/main_mediaserver.cpp
int main(int argc, char** argv)
{
    sp proc(ProcessState::self());
    sp sm = defaultServiceManager();
    LOGI("ServiceManager: %p", sm.get());
    AudioFlinger::instantiate();
    MediaPlayerService::instantiate(); // 注册"media.player"服务
    CameraService::instantiate();
    AudioPolicyService::instantiate();
    ProcessState::self()->startThreadPool();
    IPCThreadState::self()->joinThreadPool();
}
下面是ashmem被使用的代码
AudioFlinger::Client::Client(const sp& audioFlinger, pid_t pid)
    : mMemoryDealer(new MemoryDealer(1024*1024)),

MemoryDealer::MemoryDealer(size_t size, uint32_t flags, const char* name)
    : mHeap(new SharedHeap(size, flags, name)),
SharedHeap::SharedHeap(size_t size, uint32_t flags, char const * name)
    : MemoryHeapBase(size, flags, name)

MemoryHeapBase::MemoryHeapBase(size_t size, uint32_t flags, char const * name)
int fd = ashmem_create_region(name == NULL ? "MemoryHeapBase" : name, size);
mapfd(fd, size)

发现ashmem确实是个好东西,从短短的几百行驱动代码mm/ashmem.c中可以看到,
它实质是在ashmem_mmap时调用了shmem_file_setup,如果vma->vm_flags是VM_SHARED共享类型,那么
vma的ops将使用shmem_vm_ops,即vma->vm_ops = &shmem_vm_ops;用户通过mmap得到的offset地址当
被用户首次访问时会因为缺页而导致异常函数shmem_fault被执行,这样用户访问的offset对应的物理内存页将被动态申请,
ashmem的表现就像Heap堆一样,所以使用ashmem分配的内存,不像malloc,calloc之类,物理内存立即分配,
ashmem只有当用户访问offset地址对应的物理页时,相应的内存物理页才被缺页异常处理,进而为offset虚拟地址申请和映射实体
物理内存页,带来的直接好处就是,应用程序可以申请很大的内存,而应用程序最终实际占用的物理内存数量,会根据
用户应用程序的实际访问offset的数量由ashmem驱动(确切的说是shmem驱动shmem_fault异常处理函数)
动态增长,对这方面有需求的应用,可以考虑使用ashmem,而摒弃malloc,calloc之类[luther.gliethttp]