51CTO首页
AI.x社区
博客
学堂
精品班
软考社区
免费课
企业培训
鸿蒙开发者社区
WOT技术大会
IT证书
公众号矩阵
移动端
短视频免费课程课程排行直播课软考学堂
全部课程厂商认证IT技术24年11月软考PMP项目管理免费题库
在线学习
文章资源问答课堂专栏直播
51CTO
鸿蒙开发者社区
51CTO技术栈
51CTO官微
51CTO学堂
51CTO博客
CTO训练营
鸿蒙开发者社区订阅号
51CTO软考
51CTO学堂APP
51CTO学堂企业版APP
鸿蒙开发者社区视频号
51CTO软考题库
账号设置 退出

Android深入浅出之AudioFlinger分析

作者：佚名
移动开发 Android
在AT（AudioTrack）中，我们涉及到的都是流程方面的事务，而不是系统Audio策略上的内容。WHY？因为AT是AF的客户端，而AF是Android系统中Audio管理的中枢。AT我们分析的是按流程方法，那么以AT为切入点的话，AF的分析也应该是流程分析了。

一 目的

本文承接Audio第一部分的AudioTrack，通过AudioTrack作为AF（AudioFlinger）的客户端，来看看AF是如何完成工作的。

在AT（AudioTrack）中，我们涉及到的都是流程方面的事务，而不是系统Audio策略上的内容。WHY？因为AT是AF的客户端，而AF是Android系统中Audio管理的中枢。AT我们分析的是按流程方法，那么以AT为切入点的话，AF的分析也应该是流程分析了。

对于分析AT来说，只要能把它的调用顺序（也就是流程说清楚就可以了），但是对于AF的话，简单的分析调用流程 我自己感觉是不够的。因为我发现手机上的声音交互和管理是一件比较复杂的事情。举个简单例子，当听music的时候来电话了，声音处理会怎样？

虽然在Android中，还有一个叫AudioPolicyService的（APS）东西，但是它最终都会调用到AF中去，因为AF实际创建并管理了硬件设备。所以，针对Android声音策略上的分析，我会单独在以后来分析。

二 从AT切入到AF

直接从头看代码是没法掌握AF的主干的，必须要有一个切入点，也就是用一个正常的调用流程来分析AF的处理流程。先看看AF的产生吧，这个C/S架构的服务者是如何产生的呢？

2.1 AudioFlinger的诞生

AF是一个服务，这个就不用我多说了吧？代码在

  1. framework/base/media/mediaserver/Main_mediaServer.cpp中。 
  2.  
  3. int main(int argc, char** argv) 
  4.  
  5. { 
  6.  
  7.     sp<ProcessState> proc(ProcessState::self()); 
  8.  
  9. sp<IServiceManager> sm = defaultServiceManager(); 
  10.  
  11. .... 
  12.  
  13.     AudioFlinger::instantiate();--->AF的实例化 
  14.  
  15. AudioPolicyService::instantiate();--->APS的实例化 
  16.  
  17. .... 
  18.  
  19.     ProcessState::self()->startThreadPool(); 
  20.  
  21.     IPCThreadState::self()->joinThreadPool(); 
  22.  
  23. } 

哇塞，看来这个程序的负担很重啊。没想到。为何AF，APS要和MediaService和CameraService都放到一个篮子里？

看看AF的实例化静态函数，在framework/base/libs/audioFlinger/audioFlinger.cpp中

 

  1. void AudioFlinger::instantiate() { 
  2.  
  3.     defaultServiceManager()->addService( //把AF实例加入系统服务 
  4.  
  5.             String16("media.audio_flinger"), new AudioFlinger()); 
  6.  
  7. } 

再来看看它的构造函数是什么做的。

 

  1. AudioFlinger::AudioFlinger() 
  2.  
  3.     : BnAudioFlinger(),//初始化基类 
  4.  
  5.         mAudioHardware(0), //audio硬件的HAL对象 
  6.  
  7. mMasterVolume(1.0f), mMasterMute(false), mNextThreadId(0) 
  8.  
  9. { 
  10.  
  11. mHardwareStatus = AUDIO_HW_IDLE; 
  12.  
  13. //创建代表Audio硬件的HAL对象 
  14.  
  15.     mAudioHardware = AudioHardwareInterface::create(); 
  16.  
  17.   
  18.  
  19.     mHardwareStatus = AUDIO_HW_INIT; 
  20.  
  21.     if (mAudioHardware->initCheck() == NO_ERROR) { 
  22.  
  23.         setMode(AudioSystem::MODE_NORMAL); 
  24.  
  25. //设置系统的声音模式等，其实就是设置硬件的模式 
  26.  
  27.         setMasterVolume(1.0f); 
  28.  
  29.         setMasterMute(false); 
  30.  
  31.     } 
  32.  
  33. } 

AF中经常有setXXX的函数，到底是干什么的呢？我们看看setMode函数。

 

  1. status_t AudioFlinger::setMode(int mode) 
  2.  
  3. { 
  4.  
  5.      mHardwareStatus = AUDIO_HW_SET_MODE; 
  6.  
  7.     status_t ret = mAudioHardware->setMode(mode);//设置硬件的模式 
  8.  
  9.     mHardwareStatus = AUDIO_HW_IDLE; 
  10.  
  11.     return ret; 
  12.  
  13. } 

当然，setXXX还有些别的东西，但基本上都会涉及到硬件对象。我们暂且不管它。等分析到Audio策略再说。

好了，Android系统启动的时候，看来AF也准备好硬件了。不过，创建硬件对象就代表我们可以播放了吗？

2.2 AT调用AF的流程

我这里简单的把AT调用AF的流程列一下，待会按这个顺序分析AF的工作方式。

--参加AudioTrack分析的4.1节

1. 创建

 

  1. AudioTrack* lpTrack = new AudioTrack(); 
  2.  
  3. lpTrack->set(...); 

这个就进入到C++的AT了。下面是AT的set函数

 

  1. audio_io_handle_t output = 
  2.  
  3. AudioSystem::getOutput((AudioSystem::stream_type)streamType, 
  4.  
  5.             sampleRate, format, channels, (AudioSystem::output_flags)flags); 
  6.  
  7.     status_t status = createTrack(streamType, sampleRate, format, channelCount, 
  8.  
  9.                                   frameCount, flags, sharedBuffer, output); 
  10.  
  11. ----->creatTrack会和AF打交道。我们看看createTrack重要语句 
  12.  
  13. const sp<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger(); 
  14.  
  15.    //下面很重要，调用AF的createTrack获得一个IAudioTrack对象 
  16.  
  17.     sp<IAudioTrack> track = audioFlinger->createTrack(); 
  18.  
  19.     sp<IMemory> cblk = track->getCblk();//获取共享内存的管理结构 

总结一下创建的流程，AT调用AF的createTrack获得一个IAudioTrack对象，然后从这个对象中获得共享内存的对象。

2. start和write

看看AT的start，估计就是调用IAudioTrack的start吧？

 
  1. void AudioTrack::start() 
  2.  
  3. { 
  4.  
  5. //果然啊... 
  6.  
  7.    status_t status = mAudioTrack->start(); 
  8.  
  9. } 

那write呢?我们之前讲了，AT就是从共享buffer中:

l         Lock缓存

l         写缓存

l         Unlock缓存

注意，这里的Lock和Unlock是有问题的，什么问题呢?待会我们再说

按这种方式的话，那么AF一定是有一个线程在那也是：

l         Lock，

l         读缓存，写硬件

l         Unlock

总之，我们知道了AT的调用AF的流程了。下面一个一个看。

2.3 AF流程

1 createTrack

 
  1. sp<IAudioTrack> AudioFlinger::createTrack( 
  2.  
  3.         pid_t pid,//AT的pid号 
  4.  
  5.         int streamType,//MUSIC，流类型 
  6.  
  7.         uint32_t sampleRate,//8000 采样率 
  8.  
  9.         int format,//PCM_16类型 
  10.  
  11.         int channelCount,//2，双声道 
  12.  
  13.         int frameCount,//需要创建的buffer可包含的帧数 
  14.  
  15.         uint32_t flags, 
  16.  
  17.         const sp<IMemory>& sharedBuffer,//AT传入的共享buffer，这里为空 
  18.  
  19.         int output,//这个是从AuidoSystem获得的对应MUSIC流类型的索引 
  20.  
  21.         status_t *status) 
  22.  
  23. { 
  24.  
  25.     sp<PlaybackThread::Track> track; 
  26.  
  27.     sp<TrackHandle> trackHandle; 
  28.  
  29.     sp<Client> client; 
  30.  
  31.     wp<Client> wclient; 
  32.  
  33.     status_t lStatus; 
  34.  
  35.   
  36.  
  37.        { 
  38.  
  39.         Mutex::Autolock _l(mLock); 
  40.  
  41. //根据output句柄，获得线程？ 
  42.  
  43.         PlaybackThread *thread = checkPlaybackThread_l(output); 
  44.  
  45. //看看这个进程是不是已经是AF的客户了 
  46.  
  47. //这里说明一下，由于是C/S架构，那么作为服务端的AF肯定有地方保存作为C的AT的信息 
  48.  
  49. //那么，AF是根据pid作为客户端的唯一标示的 
  50.  
  51. //mClients是一个类似map的数据组织结构 
  52.  
  53.          wclient = mClients.valueFor(pid); 
  54.  
  55.         if (wclient != NULL) { 
  56.  
  57.        } else { 
  58.  
  59.          //如果还没有这个客户信息，就创建一个，并加入到map中去 
  60.  
  61.             client = new Client(this, pid); 
  62.  
  63.             mClients.add(pid, client); 
  64.  
  65.         } 
  66.  
  67. //从刚才找到的那个线程对象中创建一个track 
  68.  
  69.         track = thread->createTrack_l(client, streamType, sampleRate, format, 
  70.  
  71.                 channelCount, frameCount, sharedBuffer, &lStatus); 
  72.  
  73.     } 
  74.  
  75. //喔，还有一个trackHandle，而且返回到AF端的是这个trackHandle对象 
  76.  
  77.      trackHandle = new TrackHandle(track); 
  78.  
  79.    return trackHandle; 
  80.  
  81. } 

这个AF函数中，突然冒出来了很多新类型的数据结构。说实话，我刚开始接触的时候，大脑因为常接触到这些眼生的东西而死机！大家先不要拘泥于这些东西，我会一一分析到的。

先进入到checkPlaybackThread_l看看。

 
  1. AudioFlinger::PlaybackThread *AudioFlinger::checkPlaybackThread_l(int output) const 
  2.  
  3. { 
  4.  
  5. PlaybackThread *thread = NULL; 
  6.  
  7. //看到这种indexOfKey的东西，应该立即能想到： 
  8.  
  9. //喔，这可能是一个map之类的东西，根据key能找到实际的value 
  10.  
  11.     if (mPlaybackThreads.indexOfKey(output) >= 0) { 
  12.  
  13.         thread = (PlaybackThread *)mPlaybackThreads.valueFor(output).get(); 
  14.  
  15. } 
  16.  
  17. //这个函数的意思是根据output值，从一堆线程中找到对应的那个线程 
  18.  
  19.     return thread; 
  20.  
  21. } 

看到这里很疑惑啊：

l         AF的构造函数中没有创建线程，只创建了一个audio的HAL对象

l         如果AT是AF的第一个客户的话，我们刚才的调用流程里边，也没看到哪有创建线程的地方呀。

l         output是个什么玩意儿？为什么会根据它作为key来找线程呢？

看来，我们得去Output的来源那看看了。

我们知道，output的来源是由AT的set函数得到的：如下：

 

  1. audio_io_handle_t output = AudioSystem::getOutput( 
  2.  
  3. (AudioSystem::stream_type)streamType, //MUSIC类型 
  4.  
  5.             sampleRate, //8000 
  6.  
  7. format, //PCM_16 
  8.  
  9. channels, //2两个声道 
  10.  
  11. (AudioSystem::output_flags)flags//0 
  12.  
  13. ); 

上面这几个参数后续不再提示了，大家知道这些值都是由AT做为切入点传进去的

然后它在调用AT自己的createTrack，最终把这个output值传递到AF了。其中audio_io_handle_t类型就是一个int类型。

//叫handle啊？好像linux下这种叫法的很少，难道又是受MS的影响吗？

我们进到AudioSystem::getOutput看看。注意，大家想想这是系统的第一次调用,而且发生在AudioTrack那个进程里边。AudioSystem的位置在framework/base/media/libmedia/AudioSystem.cpp中

 
  1. audio_io_handle_t AudioSystem::getOutput(stream_type stream, 
  2.  
  3.                                     uint32_t samplingRate, 
  4.  
  5.                                     uint32_t format, 
  6.  
  7.                                     uint32_t channels, 
  8.  
  9.                                     output_flags flags) 
  10.  
  11. { 
  12.  
  13.     audio_io_handle_t output = 0; 
  14.  
  15.     if ((flags & AudioSystem::OUTPUT_FLAG_DIRECT) == 0 && 
  16.  
  17.         ((stream != AudioSystem::VOICE_CALL && stream != AudioSystem::BLUETOOTH_SCO) || 
  18.  
  19.          channels != AudioSystem::CHANNEL_OUT_MONO || 
  20.  
  21.          (samplingRate != 8000 && samplingRate != 16000))) { 
  22.  
  23.         Mutex::Autolock _l(gLock); 
  24.  
  25. //根据我们的参数，我们会走到这个里边来 
  26.  
  27. //喔，又是从map中找到stream=music的output。可惜啊，我们是第一次进来 
  28.  
  29. //output一定是0 
  30.  
  31.         output = AudioSystem::gStreamOutputMap.valueFor(stream); 
  32.  
  33.        } 
  34.  
  35. if (output == 0) { 
  36.  
  37. //我晕，又到AudioPolicyService(APS) 
  38.  
  39. //由它去getOutput 
  40.  
  41.         const sp<IAudioPolicyService>& aps = AudioSystem::get_audio_policy_service(); 
  42.  
  43.         output = aps->getOutput(stream, samplingRate, format, channels, flags); 
  44.  
  45.         if ((flags & AudioSystem::OUTPUT_FLAG_DIRECT) == 0) { 
  46.  
  47.             Mutex::Autolock _l(gLock); 
  48.  
  49. //如果取到output了，再把output加入到AudioSystem维护的这个map中去 
  50.  
  51. //说白了，就是保存一些信息吗。免得下次又这么麻烦去骚扰APS！ 
  52.  
  53.             AudioSystem::gStreamOutputMap.add(stream, output); 
  54.  
  55.         } 
  56.  
  57.     } 
  58.  
  59.     return output; 
  60.  
  61. } 

怎么办？需要到APS中才能找到output的信息？

没办法，硬着头皮进去吧。那先得看看APS是如何创建的。不过这个刚才已经说了，是和AF一块在那个Main_mediaService.cpp中实例化的。

位置在framework/base/lib/libaudioflinger/ AudioPolicyService.cpp中

 
  1. AudioPolicyService::AudioPolicyService() 
  2.  
  3.     : BnAudioPolicyService() , mpPolicyManager(NULL) 
  4.  
  5. { 
  6.  
  7.     // 下面两个线程以后再说 
  8.  
  9. mTonePlaybackThread = new AudioCommandThread(String8("")); 
  10.  
  11. mAudioCommandThread = new AudioCommandThread(String8("ApmCommandThread")); 
  12.  
  13.   
  14.  
  15. #if (defined GENERIC_AUDIO) || (defined AUDIO_POLICY_TEST) 
  16.  
  17. //喔，使用普适的AudioPolicyManager，把自己this做为参数 
  18.  
  19. //我们这里先使用普适的看看吧 
  20.  
  21. mpPolicyManager = new AudioPolicyManagerBase(this); 
  22.  
  23. //使用硬件厂商提供的特殊的AudioPolicyManager 
  24.  
  25.     //mpPolicyManager = createAudioPolicyManager(this); 
  26.  
  27.     } 
  28.  
  29. } 

我们看看AudioManagerBase的构造函数吧，在framework/base/lib/audioFlinger/

AudioPolicyManagerBase.cpp中。

 
  1. AudioPolicyManagerBase::AudioPolicyManagerBase(AudioPolicyClientInterface *clientInterface) 
  2.  
  3.     : mPhoneState(AudioSystem::MODE_NORMAL), mRingerMode(0), mMusicStopTime(0), mLimitRingtoneVolume(false) 
  4.  
  5. { 
  6.  
  7. mpClientInterface = clientInterface;这个client就是APS，刚才通过this传进来了 
  8.  
  9. AudioOutputDescriptor *outputDesc = new AudioOutputDescriptor(); 
  10.  
  11. outputDesc->mDevice = (uint32_t)AudioSystem::DEVICE_OUT_SPEAKER; 
  12.  
  13.     mHardwareOutput = mpClientInterface->openOutput(&outputDesc->mDevice, 
  14.  
  15.                                     &outputDesc->mSamplingRate, 
  16.  
  17.                                     &outputDesc->mFormat, 
  18.  
  19.                                     &outputDesc->mChannels, 
  20.  
  21.                                     &outputDesc->mLatency, 
  22.  
  23.                                     outputDesc->mFlags); 
  24.  
  25.   openOutput又交给APS的openOutput来完成了，真绕.... 
  26.  
  27. } 

唉，看来我们还是得回到APS，

 
  1. audio_io_handle_t AudioPolicyService::openOutput(uint32_t *pDevices, 
  2.  
  3.                                 uint32_t *pSamplingRate, 
  4.  
  5.                                 uint32_t *pFormat, 
  6.  
  7.                                 uint32_t *pChannels, 
  8.  
  9.                                 uint32_t *pLatencyMs, 
  10.  
  11.                                 AudioSystem::output_flags flags) 
  12.  
  13. { 
  14.  
  15.     sp<IAudioFlinger> af = AudioSystem::get_audio_flinger(); 
  16.  
  17. //FT,FT,FT,FT,FT,FT,FT 
  18.  
  19. //绕了这么一个大圈子，竟然回到AudioFlinger中了啊？？ 
  20.  
  21. return af->openOutput(pDevices, pSamplingRate, (uint32_t *)pFormat, pChannels, 
  22.  
  23.  pLatencyMs, flags); 
  24.  
  25. } 

在我们再次被绕晕之后，我们回眸看看足迹吧：

l         在AudioTrack中，调用set函数

l         这个函数会通过AudioSystem::getOutput来得到一个output的句柄

l         AS的getOutput会调用AudioPolicyService的getOutput

l         然后我们就没继续讲APS的getOutPut了，而是去看看APS创建的东西

l         发现APS创建的时候会创建一个AudioManagerBase，这个AMB的创建又会调用APS的openOutput。

l         APS的openOutput又会调用AudioFlinger的openOutput

有一个疑问，AT中set参数会和APS构造时候最终传入到AF的openOutput一样吗？如果不一样，那么构造时候openOutput的又是什么参数呢？

先放下这个悬念，我们继续从APS的getOutPut看看。

 

  1. audio_io_handle_t AudioPolicyService::getOutput(AudioSystem::stream_type stream, 
  2.  
  3.                                     uint32_t samplingRate, 
  4.  
  5.                                     uint32_t format, 
  6.  
  7.                                     uint32_t channels, 
  8.  
  9.                                     AudioSystem::output_flags flags) 
  10.  
  11. { 
  12.  
  13.      Mutex::Autolock _l(mLock); 
  14.  
  15. //自己又不干活，由AudioManagerBase干活 
  16.  
  17.     return mpPolicyManager->getOutput(stream, samplingRate, format, channels, flags); 
  18.  
  19. } 

进去看看吧

 

  1. audio_io_handle_t AudioPolicyManagerBase::getOutput(AudioSystem::stream_type stream, 
  2.  
  3.                                     uint32_t samplingRate, 
  4.  
  5.                                     uint32_t format, 
  6.  
  7.                                     uint32_t channels, 
  8.  
  9.                                     AudioSystem::output_flags flags) 
  10.  
  11. { 
  12.  
  13.     audio_io_handle_t output = 0; 
  14.  
  15.     uint32_t latency = 0; 
  16.  
  17.     // open a non direct output 
  18.  
  19.     output = mHardwareOutput; //这个是在哪里创建的？在AMB构造的时候.. 
  20.  
  21.     return output; 
  22.  
  23. } 

具体AMB的分析待以后Audio系统策略的时候我们再说吧。反正，到这里，我们知道了，在APS构造的时候会open一个Output，而这个Output又会调用AF的openOutput。

 
  1. int AudioFlinger::openOutput(uint32_t *pDevices, 
  2.  
  3.                                 uint32_t *pSamplingRate, 
  4.  
  5.                                 uint32_t *pFormat, 
  6.  
  7.                                 uint32_t *pChannels, 
  8.  
  9.                                 uint32_t *pLatencyMs, 
  10.  
  11.                                 uint32_t flags) 
  12.  
  13. { 
  14.  
  15.     status_t status; 
  16.  
  17.     PlaybackThread *thread = NULL; 
  18.  
  19.     mHardwareStatus = AUDIO_HW_OUTPUT_OPEN; 
  20.  
  21.     uint32_t samplingRate = pSamplingRate ? *pSamplingRate : 0; 
  22.  
  23.     uint32_t format = pFormat ? *pFormat : 0; 
  24.  
  25.     uint32_t channels = pChannels ? *pChannels : 0; 
  26.  
  27.     uint32_t latency = pLatencyMs ? *pLatencyMs : 0; 
  28.  
  29.   
  30.  
  31.      Mutex::Autolock _l(mLock); 
  32.  
  33.    //由Audio硬件HAL对象创建一个AudioStreamOut对象 
  34.  
  35.     AudioStreamOut *output = mAudioHardware->openOutputStream(*pDevices, 
  36.  
  37.                                                              (int *)&format, 
  38.  
  39.                                                              &channels, 
  40.  
  41.                                                              &samplingRate, 
  42.  
  43.                                                              &status); 
  44.  
  45.    mHardwareStatus = AUDIO_HW_IDLE; 
  46.  
  47. if (output != 0) { 
  48.  
  49. //创建一个Mixer线程 
  50.  
  51.         thread = new MixerThread(this, output, ++mNextThreadId); 
  52.  
  53.         } 
  54.  
  55. //终于找到了，把这个线程加入线程管理组织中 
  56.  
  57.         mPlaybackThreads.add(mNextThreadId, thread); 
  58.  
  59.        return mNextThreadId; 
  60.  
  61.     } 
  62.  
  63. } 

明白了，看来AT在调用AF的createTrack的之前，AF已经在某个时候把线程创建好了，而且是一个Mixer类型的线程，看来和混音有关系呀。这个似乎和我们开始设想的AF工作有点联系喔。Lock，读缓存，写Audio硬件，Unlock。可能都是在这个线程里边做的。

2 继续createTrack

 

  1. AudioFlinger::createTrack( 
  2.  
  3.         pid_t pid, 
  4.  
  5.         int streamType, 
  6.  
  7.         uint32_t sampleRate, 
  8.  
  9.         int format, 
  10.  
  11.         int channelCount, 
  12.  
  13.         int frameCount, 
  14.  
  15.         uint32_t flags, 
  16.  
  17.         const sp<IMemory>& sharedBuffer, 
  18.  
  19.         int output, 
  20.  
  21.         status_t *status) 
  22.  
  23. { 
  24.  
  25.     sp<PlaybackThread::Track> track; 
  26.  
  27.     sp<TrackHandle> trackHandle; 
  28.  
  29.     sp<Client> client; 
  30.  
  31.     wp<Client> wclient; 
  32.  
  33.     status_t lStatus; 
  34.  
  35.     { 
  36.  
  37. //假设我们找到了对应的线程 
  38.  
  39.         Mutex::Autolock _l(mLock); 
  40.  
  41.         PlaybackThread *thread = checkPlaybackThread_l(output); 
  42.  
  43.        //晕，调用这个线程对象的createTrack_l 
  44.  
  45. track = thread->createTrack_l(client, streamType, sampleRate, format, 
  46.  
  47.                 channelCount, frameCount, sharedBuffer, &lStatus); 
  48.  
  49.     } 
  50.  
  51.         trackHandle = new TrackHandle(track); 

return trackHandle；----》注意，这个对象是最终返回到AT进程中的。

  实在是....太绕了。再进去看看thread->createTrack_l吧。_l的意思是这个函数进入之前已经获得同步锁了。

跟着sourceinsight ctrl+鼠标左键就进入到下面这个函数。

下面这个函数的签名好长啊。这是为何？

原来Android的C++类中大量定义了内部类。说实话，我之前几年的C++的经验中基本没接触过这么频繁使用内部类的东东。--->当然，你可以说STL也大量使用了呀。

我们就把C++的内部类当做普通的类一样看待吧，其实我感觉也没什么特殊的含义，和外部类是一样的，包括函数调用，public/private之类的东西。这个和JAVA的内部类是大不一样的。

 

  1. sp<AudioFlinger::PlaybackThread::Track>  AudioFlinger::PlaybackThread::createTrack_l( 
  2.  
  3.         const sp<AudioFlinger::Client>& client, 
  4.  
  5.         int streamType, 
  6.  
  7.         uint32_t sampleRate, 
  8.  
  9.         int format, 
  10.  
  11.         int channelCount, 
  12.  
  13.         int frameCount, 
  14.  
  15.         const sp<IMemory>& sharedBuffer, 
  16.  
  17.         status_t *status) 
  18.  
  19. { 
  20.  
  21.     sp<Track> track; 
  22.  
  23.     status_t lStatus; 
  24.  
  25.     { // scope for mLock 
  26.  
  27.         Mutex::Autolock _l(mLock); 
  28.  
  29. //new 一个track对象 
  30.  
  31. //我有点愤怒了，Android真是层层封装啊，名字取得也非常相似。 
  32.  
  33. //看看这个参数吧，注意sharedBuffer这个，此时的值应是0 
  34.  
  35.         track = new Track(this, client, streamType, sampleRate, format, 
  36.  
  37.                 channelCount, frameCount, sharedBuffer); 
  38.  
  39.        mTracks.add(track); //把这个track加入到数组中，是为了管理用的。 
  40.  
  41. } 
  42.  
  43. lStatus = NO_ERROR; 
  44.  
  45.    return track; 
  46.  
  47. } 

看到这个数组的存在，我们应该能想到什么吗？这时已经有：

l         一个MixerThread，内部有一个数组保存track的

看来，不管有多少个AudioTrack，最终在AF端都有一个track对象对应，而且这些所有的track对象都会由一个线程对象来处理。----难怪是Mixer啊

再去看看new Track，我们一直还没找到共享内存在哪里创建的！！！

 

 

  1. AudioFlinger::PlaybackThread::Track::Track( 
  2.  
  3.             const wp<ThreadBase>& thread, 
  4.  
  5.             const sp<Client>& client, 
  6.  
  7.             int streamType, 
  8.  
  9.             uint32_t sampleRate, 
  10.  
  11.             int format, 
  12.  
  13.             int channelCount, 
  14.  
  15.             int frameCount, 
  16.  
  17.             const sp<IMemory>& sharedBuffer) 
  18.  
  19.     :   TrackBase(thread, client, sampleRate, format, channelCount, frameCount, 0, sharedBuffer), 
  20.  
  21.     mMute(false), mSharedBuffer(sharedBuffer), mName(-1) 
  22.  
  23. { 
  24.  
  25. // mCblk !=NULL?什么时候创建的？？ 
  26.  
  27. //只能看基类TrackBase，还是很愤怒，太多继承了。 
  28.  
  29.     if (mCblk != NULL) { 
  30.  
  31.        mVolume[0] = 1.0f; 
  32.  
  33.         mVolume[1] = 1.0f; 
  34.  
  35.         mStreamType = streamType; 
  36.  
  37.          mCblk->frameSize = AudioSystem::isLinearPCM(format) ? channelCount * 
  38.  
  39.  sizeof(int16_t) : sizeof(int8_t); 
  40.  
  41.     } 
  42.  
  43. } 

看看基类TrackBase干嘛了

 

  1. AudioFlinger::ThreadBase::TrackBase::TrackBase( 
  2.  
  3.             const wp<ThreadBase>& thread, 
  4.  
  5.             const sp<Client>& client, 
  6.  
  7.             uint32_t sampleRate, 
  8.  
  9.             int format, 
  10.  
  11.             int channelCount, 
  12.  
  13.             int frameCount, 
  14.  
  15.             uint32_t flags, 
  16.  
  17.             const sp<IMemory>& sharedBuffer) 
  18.  
  19.     :   RefBase(), 
  20.  
  21.         mThread(thread), 
  22.  
  23.         mClient(client), 
  24.  
  25.         mCblk(0), 
  26.  
  27.         mFrameCount(0), 
  28.  
  29.         mState(IDLE), 
  30.  
  31.         mClientTid(-1), 
  32.  
  33.         mFormat(format), 
  34.  
  35.         mFlags(flags & ~SYSTEM_FLAGS_MASK) 
  36.  
  37. { 
  38.  
  39.     size_t size = sizeof(audio_track_cblk_t); 
  40.  
  41.    size_t bufferSize = frameCount*channelCount*sizeof(int16_t); 
  42.  
  43.    if (sharedBuffer == 0) { 
  44.  
  45.        size += bufferSize; 
  46.  
  47.    } 

//调用client的allocate函数。这个client是什么？就是我们在CreateTrack中创建的

那个Client，我不想再说了。反正这里会创建一块共享内存

    mCblkMemory = client->heap()->allocate(size);

  有了共享内存，但是还没有里边有同步锁的那个对象audio_track_cblk_t

     mCblk = static_cast<audio_track_cblk_t *>(mCblkMemory->pointer());

     下面这个语法好怪啊。什么意思？？？

new(mCblk) audio_track_cblk_t();

  //各位，这就是C++语法中的placement new。干啥用的啊?new后面的括号中是一块buffer，再

后面是一个类的构造函数。对了，这个placement new的意思就是在这块buffer中构造一个对象。

我们之前的普通new是没法让一个对象在某块指定的内存中创建的。而placement new却可以。

这样不就达到我们的目的了吗？搞一块共享内存，再在这块内存上创建一个对象。这样，这个对象不也就能在两个内存中共享了吗？太牛牛牛牛牛了。怎么想到的？

   

  1.    // clear all buffers 
  2.  
  3.        mCblk->frameCount = frameCount; 
  4.  
  5.        mCblk->sampleRate = sampleRate; 
  6.  
  7.        mCblk->channels = (uint8_t)channelCount; 
  8.  
  9. } 

好了，解决一个重大疑惑，跨进程数据共享的重要数据结构audio_track_cblk_t是通过placement new在一块共享内存上来创建的。

回到AF的CreateTrack，有这么一句话：

trackHandle = new TrackHandle(track);

return trackHandle；----》注意，这个对象是最终返回到AT进程中的。

trackHandle的构造使用了thread->createTrack_l的返回值。

2.4 到底有少种对象

读到这里的人，一定会被异常多的class类型，内部类，继承关系搞疯掉。说实话，这里废点心血整个或者paste一个大的UML图未尝不可。但是我是不太习惯用图说话，因为图我实在是记不住。那好吧。我们就用最简单的话语争取把目前出现的对象说清楚。

1 AudioFlinger

class AudioFlinger : public BnAudioFlinger, public IBinder::DeathRecipient

AudioFlinger类是代表整个AudioFlinger服务的类，其余所有的工作类都是通过内部类的方式在其中定义的。你把它当做一个壳子也行吧。

2 Client

Client是描述C/S结构的C端的代表，也就算是一个AT在AF端的对等物吧。不过可不是Binder机制中的BpXXX喔。因为AF是用不到AT的功能的。

 
  1. class Client : public RefBase { 
  2.  
  3.     public: 
  4.  
  5.         sp<AudioFlinger>    mAudioFlinger;//代表S端的AudioFlinger 
  6.  
  7.         sp<MemoryDealer>    mMemoryDealer;//每个C端使用的共享内存，通过它分配 
  8.  
  9.         pid_t               mPid;//C端的进程id 
  10.  
  11.     }; 

3 TrackHandle

Trackhandle是AT端调用AF的CreateTrack得到的一个基于Binder机制的Track。

这个TrackHandle实际上是对真正干活的PlaybackThread::Track的一个跨进程支持的封装。

什么意思？本来PlaybackThread::Track是真正在AF中干活的东西，不过为了支持跨进程的话，我们用TrackHandle对其进行了一下包转。这样在AudioTrack调用TrackHandle的功能，实际都由TrackHandle调用PlaybackThread::Track来完成了。可以认为是一种Proxy模式吧。

这个就是AudioFlinger异常复杂的一个原因！！！

 
  1. class TrackHandle : public android::BnAudioTrack { 
  2.  
  3.     public: 
  4.  
  5.                             TrackHandle(const sp<PlaybackThread::Track>& track); 
  6.  
  7.         virtual             ~TrackHandle(); 
  8.  
  9.         virtual status_t    start(); 
  10.  
  11.         virtual void        stop(); 
  12.  
  13.         virtual void        flush(); 
  14.  
  15.         virtual void        mute(bool); 
  16.  
  17.         virtual void        pause(); 
  18.  
  19.         virtual void        setVolume(float left, float right); 
  20.  
  21.         virtual sp<IMemory> getCblk() const; 
  22.  
  23.         sp<PlaybackThread::Track> mTrack; 
  24.  
  25. }; 

 #p#

4 线程类

AF中有好几种不同类型的线程，分别有对应的线程类型：

l         RecordThread：

RecordThread : public ThreadBase, public AudioBufferProvider

用于录音的线程。

l         PlaybackThread:

class PlaybackThread : public ThreadBase

用于播放的线程

l         MixerThread

MixerThread : public PlaybackThread

用于混音的线程，注意他是从PlaybackThread派生下来的。

l         DirectoutputThread

DirectOutputThread : public PlaybackThread

直接输出线程，我们之前在代码里老看到DIRECT_OUTPUT之类的判断，看来最终和这个线程有关。

l         DuplicatingThread：

DuplicatingThread : public MixerThread

复制线程？而且从混音线程中派生？暂时不知道有什么用

这么多线程，都有一个共同的父类ThreadBase，这个是AF对Audio系统单独定义的一个以Thread为基类的类。------》FT，真的很麻烦。

ThreadBase我们不说了，反正里边封装了一些有用的函数。

我们看看PlayingThread吧，里边由定义了内部类：

 

5  PlayingThread的内部类Track

我们知道，TrackHandle构造用的那个Track是PlayingThread的createTrack_l得到的。

class Track : public TrackBase

晕喔，又来一个TrackBase。

TrackBase是ThreadBase定义的内部类

class TrackBase : public AudioBufferProvider, public RefBase

基类AudioBufferProvider是一个对Buffer的封装，以后在AF读共享缓冲，写数据到硬件HAL中用得到。

个人感觉：上面这些东西，其实完完全全可以独立到不同的文件中，然后加一些注释说明。

写这样的代码，要是我是BOSS的话，一定会很不爽。有什么意义吗？有什么好处吗？

2.5 AF流程继续

好了，这里终于在AF中的createTrack返回了TrackHandle。这个时候系统处于什么状态？

l         AF中的几个Thread我们之前说了，在AF启动的某个时间就已经起来了。我们就假设AT调用AF服务前，这个线程就已经启动了。

这个可以看代码就知道了：

 

  1. void AudioFlinger::PlaybackThread::onFirstRef() 
  2.  
  3. { 
  4.  
  5.     const size_t SIZE = 256; 
  6.  
  7.     char buffer[SIZE]; 
  8.  
  9.   
  10.  
  11.     snprintf(buffer, SIZE, "Playback Thread %p", this); 
  12.  
  13. //onFirstRef，实际是RefBase的一个方法，在构造sp的时候就会被调用 
  14.  
  15. //下面的run就真正创建了线程并开始执行threadLoop了 
  16.  
  17.     run(buffer, ANDROID_PRIORITY_URGENT_AUDIO); 
  18.  
  19. } 

到底执行哪个线程的threadLoop？我记得我们是根据output句柄来查找线程的。

看看openOutput的实行，真正的线程对象创建是在那儿。

 

  1. nt AudioFlinger::openOutput(uint32_t *pDevices, 
  2.  
  3.                                 uint32_t *pSamplingRate, 
  4.  
  5.                                 uint32_t *pFormat, 
  6.  
  7.                                 uint32_t *pChannels, 
  8.  
  9.                                 uint32_t *pLatencyMs, 
  10.  
  11.                                 uint32_t flags) 
  12.  
  13. { 
  14.  
  15.         if ((flags & AudioSystem::OUTPUT_FLAG_DIRECT) || 
  16.  
  17.             (format != AudioSystem::PCM_16_BIT) || 
  18.  
  19.             (channels != AudioSystem::CHANNEL_OUT_STEREO)) { 
  20.  
  21.             thread = new DirectOutputThread(this, output, ++mNextThreadId); 
  22.  
  23. //如果flags没有设置直接输出标准，或者format不是16bit，或者声道数不是2立体声 
  24.  
  25. //则创建DirectOutputThread。        
  26.  
  27. } else { 
  28.  
  29.     //可惜啊，我们创建的是最复杂的MixerThread   
  30.  
  31.  thread = new MixerThread(this, output, ++mNextThreadId);    
  32.  
  33. 1. MixerThread 
  34.  
  35. 非常重要的工作线程，我们看看它的构造函数。 
  36.  
  37. AudioFlinger::MixerThread::MixerThread(const sp<AudioFlinger>& audioFlinger, AudioStreamOut* output, int id) 
  38.  
  39.     :   PlaybackThread(audioFlinger, output, id), 
  40.  
  41.         mAudioMixer(0) 
  42.  
  43. { 
  44.  
  45. mType = PlaybackThread::MIXER; 
  46.  
  47. //混音器对象，传进去的两个参数时基类ThreadBase的，都为0 
  48.  
  49. //这个对象巨复杂，最终混音的数据都由它生成，以后再说... 
  50.  
  51.     mAudioMixer = new AudioMixer(mFrameCount, mSampleRate); 
  52.  
  53.    } 

2. AT调用start

此时，AT得到IAudioTrack对象后，调用start函数。

 

  1. status_t AudioFlinger::TrackHandle::start() { 
  2.  
  3.     return mTrack->start(); 
  4.  
  5. } //果然，自己又不干活，交给mTrack了，这个是PlayintThread createTrack_l得到的Track对象 
  6.  
  7. status_t AudioFlinger::PlaybackThread::Track::start() 
  8.  
  9. { 
  10.  
  11.     status_t status = NO_ERROR; 
  12.  
  13. sp<ThreadBase> thread = mThread.promote(); 
  14.  
  15. //这个Thread就是调用createTrack_l的那个thread对象，这里是MixerThread 
  16.  
  17.     if (thread != 0) { 
  18.  
  19.         Mutex::Autolock _l(thread->mLock); 
  20.  
  21.         int state = mState; 
  22.  
  23.          if (mState == PAUSED) { 
  24.  
  25.             mState = TrackBase::RESUMING; 
  26.  
  27.            } else { 
  28.  
  29.             mState = TrackBase::ACTIVE; 
  30.  
  31.         } 
  32.  
  33.   //把自己由加到addTrack_l了 
  34.  
  35. //奇怪，我们之前在看createTrack_l的时候，不是已经有个map保存创建的track了 
  36.  
  37. //这里怎么又出现了一个类似的操作？ 
  38.  
  39.         PlaybackThread *playbackThread = (PlaybackThread *)thread.get(); 
  40.  
  41.         playbackThread->addTrack_l(this); 
  42.  
  43.     return status; 
  44.  
  45. } 

看看这个addTrack_l函数

 

  1. status_t AudioFlinger::PlaybackThread::addTrack_l(const sp<Track>& track) 
  2.  
  3. { 
  4.  
  5.     status_t status = ALREADY_EXISTS; 
  6.  
  7.   
  8.  
  9.     // set retry count for buffer fill 
  10.  
  11.     track->mRetryCount = kMaxTrackStartupRetries; 
  12.  
  13.     if (mActiveTracks.indexOf(track) < 0) { 
  14.  
  15.         mActiveTracks.add(track);//啊，原来是加入到活跃Track的数组啊 
  16.  
  17.         status = NO_ERROR; 
  18.  
  19. } 

//我靠，有戏啊！看到这个broadcast，一定要想到：恩，在不远处有那么一个线程正

//等着这个CV呢。

 

  1.   mWaitWorkCV.broadcast(); 
  2.  
  3.    return status; 
  4.  
  5. } 

让我们想想吧。start是把某个track加入到PlayingThread的活跃Track队列，然后触发一个信号事件。由于这个事件是PlayingThread的内部成员变量，而PlayingThread又创建了一个线程，那么难道是那个线程在等待这个事件吗？这时候有一个活跃track，那个线程应该可以干活了吧？

这个线程是MixerThread。我们去看看它的线程函数threadLoop吧。

 
  1. bool AudioFlinger::MixerThread::threadLoop() 
  2.  
  3. { 
  4.  
  5.     int16_t* curBuf = mMixBuffer; 
  6.  
  7.     Vector< sp<Track> > tracksToRemove; 
  8.  
  9.  while (!exitPending()) 
  10.  
  11.     { 
  12.  
  13.         processConfigEvents(); 
  14.  
  15. //Mixer进到这个循环中来 
  16.  
  17.         mixerStatus = MIXER_IDLE; 
  18.  
  19.         { // scope for mLock 
  20.  
  21.            Mutex::Autolock _l(mLock); 
  22.  
  23.             const SortedVector< wp<Track> >& activeTracks = mActiveTracks; 
  24.  
  25. //每次都取当前最新的活跃Track数组 
  26.  
  27. //下面是预备操作，返回状态看看是否有数据需要获取 
  28.  
  29. mixerStatus = prepareTracks_l(activeTracks, &tracksToRemove); 
  30.  
  31.        } 
  32.  
  33. //LIKELY，是GCC的一个东西，可以优化编译后的代码 
  34.  
  35. //就当做是TRUE吧 
  36.  
  37. if (LIKELY(mixerStatus == MIXER_TRACKS_READY)) { 
  38.  
  39.             // mix buffers... 
  40.  
  41. //调用混音器，把buf传进去，估计得到了混音后的数据了 
  42.  
  43. //curBuf是mMixBuffer，PlayingThread的内部buffer，在某个地方已经创建好了， 
  44.  
  45. //缓存足够大 
  46.  
  47.             mAudioMixer->process(curBuf); 
  48.  
  49.             sleepTime = 0; 
  50.  
  51.             standbyTime = systemTime() + kStandbyTimeInNsecs; 
  52.  
  53.         } 
  54.  
  55. 有数据要写到硬件中，肯定不能sleep了呀 
  56.  
  57. if (sleepTime == 0) { 
  58.  
  59.            //把缓存的数据写到outPut中。这个mOutput是AudioStreamOut 
  60.  
  61. //由Audio HAL的那个对象创建得到。等我们以后分析再说 
  62.  
  63.            int bytesWritten = (int)mOutput->write(curBuf, mixBufferSize); 
  64.  
  65.             mStandby = false; 
  66.  
  67.         } else { 
  68.  
  69.             usleep(sleepTime);//如果没有数据，那就休息吧.. 
  70.  
  71.         } 

3. MixerThread核心

到这里，大家是不是有种焕然一新的感觉？恩，对了，AF的工作就是如此的精密，每个部分都配合得丝丝入扣。不过对于我们看代码的人来说，实在搞不懂这么做的好处----哈哈  有点扯远了。

MixerThread的线程循环中，最重要的两个函数：

 

  1. prepare_l和mAudioMixer->process，我们一一来看看。 
  2.  
  3. uint32_t AudioFlinger::MixerThread::prepareTracks_l(const SortedVector< wp<Track> >& activeTracks, Vector< sp<Track> > *tracksToRemove) 
  4.  
  5. { 
  6.  
  7.   
  8.  
  9.     uint32_t mixerStatus = MIXER_IDLE; 
  10.  
  11.     //得到活跃track个数，这里假设就是我们创建的那个AT吧，那么count=1 
  12.  
  13.     size_t count = activeTracks.size(); 
  14.  
  15.   
  16.  
  17.     float masterVolume = mMasterVolume; 
  18.  
  19.     bool  masterMute = mMasterMute; 
  20.  
  21.    for (size_t i=0 ; i<count ; i++) { 
  22.  
  23.         sp<Track> t = activeTracks[i].promote(); 
  24.  
  25.       Track* const track = t.get()； 
  26.  
  27.    //得到placement new分配的那个跨进程共享的对象 
  28.  
  29.         audio_track_cblk_t* cblk = track->cblk(); 
  30.  
  31. //设置混音器，当前活跃的track。 
  32.  
  33.         mAudioMixer->setActiveTrack(track->name()); 
  34.  
  35.         if (cblk->framesReady() && (track->isReady() || track->isStopped()) && 
  36.  
  37.                 !track->isPaused() && !track->isTerminated()) 
  38.  
  39.         { 
  40.  
  41.             // compute volume for this track 
  42.  
  43. //AT已经write数据了。所以肯定会进到这来。 
  44.  
  45.             int16_t left, right; 
  46.  
  47.             if (track->isMuted() || masterMute || track->isPausing() || 
  48.  
  49.                 mStreamTypes[track->type()].mute) { 
  50.  
  51.                 left = right = 0; 
  52.  
  53.                 if (track->isPausing()) { 
  54.  
  55.                     track->setPaused(); 
  56.  
  57.                 } 
  58.  
  59. //AT设置的音量假设不为零，我们需要聆听声音！ 
  60.  
  61. //所以走else流程 
  62.  
  63.             } else { 
  64.  
  65.                 // read original volumes with volume control 
  66.  
  67.                 float typeVolume = mStreamTypes[track->type()].volume; 
  68.  
  69.                 float v = masterVolume * typeVolume; 
  70.  
  71.                 float v_clamped = v * cblk->volume[0]; 
  72.  
  73.                 if (v_clamped > MAX_GAIN) v_clamped = MAX_GAIN; 
  74.  
  75.                 left = int16_t(v_clamped); 
  76.  
  77.                 v_clamped = v * cblk->volume[1]; 
  78.  
  79.                 if (v_clamped > MAX_GAIN) v_clamped = MAX_GAIN; 
  80.  
  81.                 right = int16_t(v_clamped); 
  82.  
  83. //计算音量 
  84.  
  85.             } 
  86.  
  87. //注意，这里对混音器设置了数据提供来源，是一个track，还记得我们前面说的吗？Track从 
  88.  
  89. AudioBufferProvider派生 
  90.  
  91.           mAudioMixer->setBufferProvider(track); 
  92.  
  93.             mAudioMixer->enable(AudioMixer::MIXING); 
  94.  
  95.   
  96.  
  97.             int param = AudioMixer::VOLUME; 
  98.  
  99.            //为这个track设置左右音量等 
  100.  
  101.           mAudioMixer->setParameter(param, AudioMixer::VOLUME0, left); 
  102.  
  103.             mAudioMixer->setParameter(param, AudioMixer::VOLUME1, right); 
  104.  
  105.             mAudioMixer->setParameter( 
  106.  
  107.                 AudioMixer::TRACK, 
  108.  
  109.                 AudioMixer::FORMAT, track->format()); 
  110.  
  111.             mAudioMixer->setParameter( 
  112.  
  113.                 AudioMixer::TRACK, 
  114.  
  115.                 AudioMixer::CHANNEL_COUNT, track->channelCount()); 
  116.  
  117.             mAudioMixer->setParameter( 
  118.  
  119.                 AudioMixer::RESAMPLE, 
  120.  
  121.                 AudioMixer::SAMPLE_RATE, 
  122.  
  123.                 int(cblk->sampleRate)); 
  124.  
  125.         } else { 
  126.  
  127.            if (track->isStopped()) { 
  128.  
  129.                 track->reset(); 
  130.  
  131.             } 
  132.  
  133.   //如果这个track已经停止了，那么把它加到需要移除的track队列tracksToRemove中去 
  134.  
  135. //同时停止它在AudioMixer中的混音 
  136.  
  137.             if (track->isTerminated() || track->isStopped() || track->isPaused()) { 
  138.  
  139.                 tracksToRemove->add(track); 
  140.  
  141.                 mAudioMixer->disable(AudioMixer::MIXING); 
  142.  
  143.             } else { 
  144.  
  145.                 mAudioMixer->disable(AudioMixer::MIXING); 
  146.  
  147.             } 
  148.  
  149.         } 
  150.  
  151.     } 
  152.  
  153.   
  154.  
  155.     // remove all the tracks that need to be... 
  156.  
  157.     count = tracksToRemove->size(); 
  158.  
  159.     return mixerStatus; 
  160.  
  161. } 
  162.  
  163. 看明白了吗？prepare_l的功能是什么？根据当前活跃的track队列，来为混音器设置信息。可想而知，一个track必然在混音器中有一个对应的东西。我们待会分析AudioMixer的时候再详述。 
  164.  
  165. 为混音器准备好后，下面调用它的process函数 
  166.  
  167. void AudioMixer::process(void* output) 
  168.  
  169. { 
  170.  
  171.     mState.hook(&mState, output);//hook？难道是钩子函数？ 
  172.  
  173. } 

晕乎，就这么简单的函数？？？

CTRL+左键，hook是一个函数指针啊，在哪里赋值的？具体实现函数又是哪个？

没办法了，只能分析AudioMixer类了。

4. AudioMixer

AudioMixer实现在framework/base/libs/audioflinger/AudioMixer.cpp中

 

  1. AudioMixer::AudioMixer(size_t frameCount, uint32_t sampleRate) 
  2.  
  3.     :   mActiveTrack(0), mTrackNames(0), mSampleRate(sampleRate) 
  4.  
  5. { 
  6.  
  7.     mState.enabledTracks= 0; 
  8.  
  9.     mState.needsChanged = 0; 
  10.  
  11.     mState.frameCount   = frameCount; 
  12.  
  13.     mState.outputTemp   = 0; 
  14.  
  15.     mState.resampleTemp = 0; 
  16.  
  17.     mState.hook         = process__nop;//process__nop，是该类的静态函数 
  18.  
  19. track_t* t = mState.tracks; 
  20.  
  21. //支持32路混音。牛死了 
  22.  
  23.     for (int i=0 ; i<32 ; i++) { 
  24.  
  25.         t->needs = 0; 
  26.  
  27.         t->volume[0] = UNITY_GAIN; 
  28.  
  29.         t->volume[1] = UNITY_GAIN; 
  30.  
  31.         t->volumeInc[0] = 0; 
  32.  
  33.         t->volumeInc[1] = 0; 
  34.  
  35.         t->channelCount = 2; 
  36.  
  37.         t->enabled = 0; 
  38.  
  39.         t->format = 16; 
  40.  
  41.         t->buffer.raw = 0; 
  42.  
  43.         t->bufferProvider = 0; 
  44.  
  45.         t->hook = 0; 
  46.  
  47.         t->resampler = 0; 
  48.  
  49.         t->sampleRate = mSampleRate; 
  50.  
  51.         t->in = 0; 
  52.  
  53.         t++; 
  54.  
  55.     } 
  56.  
  57. } 

//其中，mState是在AudioMixer.h中定义的一个数据结构

//注意，source insight没办法解析这个mState，因为....见下面的注释。

 

  1. struct state_t { 
  2.  
  3.         uint32_t        enabledTracks; 
  4.  
  5.         uint32_t        needsChanged; 
  6.  
  7.         size_t          frameCount; 
  8.  
  9.         mix_t           hook; 
  10.  
  11.         int32_t         *outputTemp; 
  12.  
  13.         int32_t         *resampleTemp; 
  14.  
  15.         int32_t         reserved[2]; 
  16.  
  17.         track_t         tracks[32];// __attribute__((aligned(32)));《--把这里注释掉 
  18.  
  19. //否则source insight会解析不了这个state_t类型 
  20.  
  21.     }; 

    int             mActiveTrack;

    uint32_t        mTrackNames;//names？搞得像字符串，实际是一个int

    const uint32_t  mSampleRate;

 

state_t         mState

好了，没什么吗。hook对应的可选函数实现有：

process__validate

process__nop

process__genericNoResampling

process__genericResampling

process__OneTrack16BitsStereoNoResampling

process__TwoTracks16BitsStereoNoResampling

AudioMixer构造的时候，hook是process__nop，有几个地方会改变这个函数指针的指向。

这部分涉及到数字音频技术，我就无力讲解了。我们看看最接近的函数

process__OneTrack16BitsStereoNoResampling

void AudioMixer::process__OneTrack16BitsStereoNoResampling(state_t* state, void* output)

{

单track，16bit双声道，不需要重采样,大部分是这种情况了

 

  1.   const int i = 31 - __builtin_clz(state->enabledTracks); 
  2.  
  3.     const track_t& t = state->tracks[i]; 
  4.  
  5.   
  6.  
  7.     AudioBufferProvider::Buffer& b(t.buffer); 
  8.  
  9.    
  10.  
  11.     int32_t* out = static_cast<int32_t*>(output); 
  12.  
  13.     size_t numFrames = state->frameCount; 
  14.  
  15.   
  16.  
  17.     const int16_t vl = t.volume[0]; 
  18.  
  19.     const int16_t vr = t.volume[1]; 
  20.  
  21.     const uint32_t vrl = t.volumeRL; 
  22.  
  23.     while (numFrames) { 
  24.  
  25.         b.frameCount = numFrames; 
  26.  
  27. //获得buffer 
  28.  
  29.         t.bufferProvider->getNextBuffer(&b); 
  30.  
  31.         int16_t const *in = b.i16; 
  32.  
  33.   
  34.  
  35.        size_t outFrames = b.frameCount; 
  36.  
  37.        if  UNLIKELY--->不走这. 
  38.  
  39.         else { 
  40.  
  41.             do { 
  42.  
  43.           //计算音量等数据，和数字音频技术有关。这里不说了 
  44.  
  45.                 uint32_t rl = *reinterpret_cast<uint32_t const *>(in); 
  46.  
  47.                 in += 2; 
  48.  
  49.                 int32_t l = mulRL(1, rl, vrl) >> 12; 
  50.  
  51.                 int32_t r = mulRL(0, rl, vrl) >> 12; 
  52.  
  53.                 *out++ = (r<<16) | (l & 0xFFFF); 
  54.  
  55.             } while (--outFrames); 
  56.  
  57.         } 
  58.  
  59.         numFrames -= b.frameCount; 
  60.  
  61. //释放buffer。 
  62.  
  63.         t.bufferProvider->releaseBuffer(&b); 
  64.  
  65.     } 
  66.  
  67. } 

好像挺简单的啊，不就是把数据处理下嘛。这里注意下buffer。到现在，我们还没看到取共享内存里AT端write的数据呐。

那只能到bufferProvider去看了。

注意，这里用的是AudioBufferProvider基类，实际的对象是Track。它从AudioBufferProvider派生。

我们用得是PlaybackThread的这个Track

 

  1. status_t AudioFlinger::PlaybackThread::Track::getNextBuffer(AudioBufferProvider::Buffer* buffer) 
  2.  
  3. { 
  4.  
  5. //一阵暗喜吧。千呼万唤始出来，终于见到cblk了 
  6.  
  7.      audio_track_cblk_t* cblk = this->cblk(); 
  8.  
  9.      uint32_t framesReady; 
  10.  
  11.      uint32_t framesReq = buffer->frameCount; 
  12.  
  13.  //哈哈，看看数据准备好了没， 
  14.  
  15.       framesReady = cblk->framesReady(); 
  16.  
  17.   
  18.  
  19.      if (LIKELY(framesReady)) { 
  20.  
  21.         uint32_t s = cblk->server; 
  22.  
  23.         uint32_t bufferEnd = cblk->serverBase + cblk->frameCount; 
  24.  
  25.         bufferEnd = (cblk->loopEnd < bufferEnd) ? cblk->loopEnd : bufferEnd; 
  26.  
  27.         if (framesReq > framesReady) { 
  28.  
  29.             framesReq = framesReady; 
  30.  
  31.         } 
  32.  
  33.         if (s + framesReq > bufferEnd) { 
  34.  
  35.             framesReq = bufferEnd - s; 
  36.  
  37.         } 
  38.  
  39. 获得真实的数据地址 
  40.  
  41.          buffer->raw = getBuffer(s, framesReq); 
  42.  
  43.          if (buffer->raw == 0) goto getNextBuffer_exit; 
  44.  
  45.   
  46.  
  47.          buffer->frameCount = framesReq; 
  48.  
  49.         return NO_ERROR; 
  50.  
  51.      } 
  52.  
  53. getNextBuffer_exit: 
  54.  
  55.      buffer->raw = 0; 
  56.  
  57.      buffer->frameCount = 0; 
  58.  
  59.     return NOT_ENOUGH_DATA; 
  60.  
  61. } 
  62.  
  63. 再看看释放缓冲的地方：releaseBuffer，这个直接在ThreadBase中实现了 
  64.  
  65. void AudioFlinger::ThreadBase::TrackBase::releaseBuffer(AudioBufferProvider::Buffer* buffer) 
  66.  
  67. { 
  68.  
  69.     buffer->raw = 0; 
  70.  
  71.     mFrameCount = buffer->frameCount; 
  72.  
  73.     step(); 
  74.  
  75.     buffer->frameCount = 0; 
  76.  
  77. } 

看看step吧。mFrameCount表示我已经用完了这么多帧。

 

  1. bool AudioFlinger::ThreadBase::TrackBase::step() { 
  2.  
  3.     bool result; 
  4.  
  5.     audio_track_cblk_t* cblk = this->cblk(); 
  6.  
  7. result = cblk->stepServer(mFrameCount);//哼哼，调用cblk的stepServer，更新 
  8.  
  9. 服务端的使用位置 
  10.  
  11.     return result; 
  12.  
  13. } 

到这里，大伙应该都明白了吧。原来AudioTrack中write的数据，最终是这么被使用的呀！！！

恩，看一个process__OneTrack16BitsStereoNoResampling不过瘾，再看看

process__TwoTracks16BitsStereoNoResampling。

 
  1. void AudioMixer::process__TwoTracks16BitsStereoNoResampling(state_t* state, void* 
  2.  
  3. output) 
  4.  
  5. int i; 
  6.  
  7.     uint32_t en = state->enabledTracks; 
  8.  
  9.   
  10.  
  11.     i = 31 - __builtin_clz(en); 
  12.  
  13.     const track_t& t0 = state->tracks[i]; 
  14.  
  15.     AudioBufferProvider::Buffer& b0(t0.buffer); 
  16.  
  17.   
  18.  
  19.     en &= ~(1<<i); 
  20.  
  21.     i = 31 - __builtin_clz(en); 
  22.  
  23.     const track_t& t1 = state->tracks[i]; 
  24.  
  25.     AudioBufferProvider::Buffer& b1(t1.buffer); 
  26.  
  27.    
  28.  
  29.     int16_t const *in0; 
  30.  
  31.     const int16_t vl0 = t0.volume[0]; 
  32.  
  33.     const int16_t vr0 = t0.volume[1]; 
  34.  
  35.     size_t frameCount0 = 0; 
  36.  
  37.   
  38.  
  39.     int16_t const *in1; 
  40.  
  41.     const int16_t vl1 = t1.volume[0]; 
  42.  
  43.     const int16_t vr1 = t1.volume[1]; 
  44.  
  45.     size_t frameCount1 = 0; 
  46.  
  47.    
  48.  
  49.     int32_t* out = static_cast<int32_t*>(output); 
  50.  
  51.     size_t numFrames = state->frameCount; 
  52.  
  53.     int16_t const *buff = NULL; 
  54.  
  55.   
  56.  
  57.   
  58.  
  59.     while (numFrames) { 
  60.  
  61.    
  62.  
  63.         if (frameCount0 == 0) { 
  64.  
  65.             b0.frameCount = numFrames; 
  66.  
  67.             t0.bufferProvider->getNextBuffer(&b0); 
  68.  
  69.             if (b0.i16 == NULL) { 
  70.  
  71.                 if (buff == NULL) { 
  72.  
  73.                     buff = new int16_t[MAX_NUM_CHANNELS * state->frameCount]; 
  74.  
  75.                 } 
  76.  
  77.                 in0 = buff; 
  78.  
  79.                 b0.frameCount = numFrames; 
  80.  
  81.             } else { 
  82.  
  83.                 in0 = b0.i16; 
  84.  
  85.             } 
  86.  
  87.             frameCount0 = b0.frameCount; 
  88.  
  89.         } 
  90.  
  91.         if (frameCount1 == 0) { 
  92.  
  93.             b1.frameCount = numFrames; 
  94.  
  95.             t1.bufferProvider->getNextBuffer(&b1); 
  96.  
  97.             if (b1.i16 == NULL) { 
  98.  
  99.                 if (buff == NULL) { 
  100.  
  101.                     buff = new int16_t[MAX_NUM_CHANNELS * state->frameCount]; 
  102.  
  103.                 } 
  104.  
  105.                 in1 = buff; 
  106.  
  107.                 b1.frameCount = numFrames; 
  108.  
  109.                } else { 
  110.  
  111.                 in1 = b1.i16; 
  112.  
  113.             } 
  114.  
  115.             frameCount1 = b1.frameCount; 
  116.  
  117.         } 
  118.  
  119.        
  120.  
  121.         size_t outFrames = frameCount0 < frameCount1?frameCount0:frameCount1; 
  122.  
  123.   
  124.  
  125.         numFrames -= outFrames; 
  126.  
  127.         frameCount0 -= outFrames; 
  128.  
  129.         frameCount1 -= outFrames; 
  130.  
  131.         
  132.  
  133.         do { 
  134.  
  135.             int32_t l0 = *in0++; 
  136.  
  137.             int32_t r0 = *in0++; 
  138.  
  139.             l0 = mul(l0, vl0); 
  140.  
  141.             r0 = mul(r0, vr0); 
  142.  
  143.             int32_t l = *in1++; 
  144.  
  145.             int32_t r = *in1++; 
  146.  
  147.             l = mulAdd(l, vl1, l0) >> 12; 
  148.  
  149.             r = mulAdd(r, vr1, r0) >> 12; 
  150.  
  151.             // clamping... 
  152.  
  153.             l = clamp16(l); 
  154.  
  155.             r = clamp16(r); 
  156.  
  157.             *out++ = (r<<16) | (l & 0xFFFF); 
  158.  
  159.         } while (--outFrames); 
  160.  
  161.        
  162.  
  163.         if (frameCount0 == 0) { 
  164.  
  165.             t0.bufferProvider->releaseBuffer(&b0); 
  166.  
  167.         } 
  168.  
  169.         if (frameCount1 == 0) { 
  170.  
  171.             t1.bufferProvider->releaseBuffer(&b1); 
  172.  
  173.         } 
  174.  
  175.     }   
  176.  
  177.        
  178.  
  179.     if (buff != NULL) { 
  180.  
  181.         delete [] buff;       
  182.  
  183.     } 
  184.  
  185. } 

看不懂了吧？？哈哈，知道有这回事就行了，专门搞数字音频的需要好好研究下了！

三 再论共享audio_track_cblk_t

为什么要再论这个？因为我在网上找了下，有人说audio_track_cblk_t是一个环形buffer，环形buffer是什么意思？自己查查！

这个吗，和我之前的工作经历有关系，某BOSS费尽心机想搞一个牛掰掰的环形buffer，搞得我累死了。现在audio_track_cblk_t是环形buffer？我倒是想看看它是怎么实现的。

顺便我们要解释下，audio_track_cblk_t的使用和我之前说的Lock,读/写，Unlock不太一样。为何？

l         第一因为我们没在AF代码中看到有缓冲buffer方面的wait，MixThread只有当没有数据的时候会usleep一下。

l         第二，如果有多个track，多个audio_track_cblk_t的话，假如又是采用wait信号的办法，那么由于pthread库缺乏WaitForMultiObjects的机制，那么到底该等哪一个？这个问题是我们之前在做跨平台同步库的一个重要难题。

1. 写者的使用

我们集中到audio_track_cblk_t这个类，来看看写者是如何使用的。写者就是AudioTrack端，在这个类中，叫user

l         framesAvailable，看看是否有空余空间

l         buffer，获得写空间起始地址

l         stepUser，更新user的位置。

2. 读者的使用

读者是AF端，在这个类中加server。

l         framesReady，获得可读的位置

l         stepServer，更新读者的位置

看看这个类的定义：

 
  1. struct audio_track_cblk_t 
  2.  
  3. { 
  4.  
  5.                Mutex       lock; //同步锁 
  6.  
  7.                 Condition   cv;//CV 
  8.  
  9. volatile    uint32_t    user;//写者 
  10.  
  11.     volatile    uint32_t    server;//读者 
  12.  
  13.                 uint32_t    userBase;//写者起始位置 
  14.  
  15.                 uint32_t    serverBase;//读者起始位置 
  16.  
  17.     void*       buffers; 
  18.  
  19.     uint32_t    frameCount; 
  20.  
  21.     // Cache line boundary 
  22.  
  23.     uint32_t    loopStart; //循环起始 
  24.  
  25.     uint32_t    loopEnd; //循环结束 
  26.  
  27.     int         loopCount; 
  28.  
  29. uint8_t     out;   //如果是Track的话，out就是1，表示输出。 
  30.  
  31. } 

注意这是volatile，跨进程的对象，看来这个volatile也是可以跨进程的嘛。

l         唉，又要发挥下了。volatile只是告诉编译器，这个单元的地址不要cache到CPU的缓冲中。也就是每次取值的时候都要到实际内存中去读，而且可能读内存的时候先要锁一下总线。防止其他CPU核执行的时候同时去修改。由于是跨进程共享的内存，这块内存在两个进程都是能见到的，又锁总线了，又是同一块内存，volatile当然保证了同步一致性。

l         loopStart和loopEnd这两个值是表示循环播放的起点和终点的，下面还有一个loopCount吗，表示循环播放次数的

那就分析下吧。

先看写者的那几个函数

4 写者分析

先用frameavail看看当前剩余多少空间，我们可以假设是第一次进来嘛。读者还在那sleep呢。

 
  1. uint32_t audio_track_cblk_t::framesAvailable() 
  2.  
  3. { 
  4.  
  5.     Mutex::Autolock _l(lock); 
  6.  
  7.     return framesAvailable_l(); 
  8.  
  9. } 
  10.  
  11. int32_t audio_track_cblk_t::framesAvailable_l() 
  12.  
  13. { 
  14.  
  15.     uint32_t u = this->user; 当前写者位置，此时也为0 
  16.  
  17.     uint32_t s = this->server; //当前读者位置，此时为0 
  18.  
  19.     if (out) { out为1 
  20.  
  21.         uint32_t limit = (s < loopStart) ? s : loopStart; 
  22.  
  23. 我们不设循环播放时间吗。所以loopStart是初始值INT_MAX，所以limit=0 
  24.  
  25.         return limit + frameCount - u; 
  26.  
  27. //返回0+frameCount-0，也就是全缓冲最大的空间。假设frameCount=1024帧 
  28.  
  29.     } 
  30.  
  31. } 

然后调用buffer获得其实位置，buffer就是得到一个地址位置。

void* audio_track_cblk_t::buffer(uint32_t offset) const

{

    return (int8_t *)this->buffers + (offset - userBase) * this->frameSize;

}

完了，我们更新写者，调用stepUser

uint32_t audio_track_cblk_t::stepUser(uint32_t frameCount)

{

//framecount，表示我写了多少，假设这一次写了512帧

    uint32_t u = this->user;//user位置还没更新呢，此时u=0；

 

    u += frameCount;//u更新了，u=512

    // Ensure that user is never ahead of server for AudioRecord

    if (out) {

       //没甚，计算下等待时间

}

//userBase还是初始值为0，可惜啊，我们只写了1024的一半

//所以userBase加不了

   if (u >= userBase + this->frameCount) {

        userBase += this->frameCount;

//但是这句话很重要，userBase也更新了。根据buffer函数的实现来看，似乎把这个

//环形缓冲铺直了....连绵不绝。

    }

    this->user = u;//喔，user位置也更新为512了，但是useBase还是0

    return u;

}

好了，假设写者这个时候sleep了，而读者起来了。

5 读者分析

 

 
  1. uint32_t audio_track_cblk_t::framesReady() 
  2.  
  3. { 
  4.  
  5.     uint32_t u = this->user; //u为512 
  6.  
  7.     uint32_t s = this->server;//还没读呢，s为零 
  8.  
  9.   
  10.  
  11.     if (out) { 
  12.  
  13.         if (u < loopEnd) { 
  14.  
  15.             return u - s;//loopEnd也是INT_MAX，所以这里返回512，表示有512帧可读了 
  16.  
  17.         } else { 
  18.  
  19.             Mutex::Autolock _l(lock); 
  20.  
  21.             if (loopCount >= 0) { 
  22.  
  23.                 return (loopEnd - loopStart)*loopCount + u - s; 
  24.  
  25.             } else { 
  26.  
  27.                 return UINT_MAX; 
  28.  
  29.             } 
  30.  
  31.         } 
  32.  
  33.     } else { 
  34.  
  35.         return s - u; 
  36.  
  37.     } 
  38.  
  39. } 

使用完了，然后stepServer

 

  1. bool audio_track_cblk_t::stepServer(uint32_t frameCount) 
  2.  
  3. { 
  4.  
  5.     status_t err; 
  6.  
  7.    err = lock.tryLock(); 
  8.  
  9.     uint32_t s = this->server; 
  10.  
  11.   
  12.  
  13.     s += frameCount; //读了512帧了，所以s=512 
  14.  
  15.     if (out) { 
  16.  
  17.         
  18.  
  19.     } 

   没有设置循环播放嘛，所以不走这个

  

  1.  if (s >= loopEnd) { 
  2.  
  3.        s = loopStart; 
  4.  
  5.         if (--loopCount == 0) { 
  6.  
  7.             loopEnd = UINT_MAX; 
  8.  
  9.             loopStart = UINT_MAX; 
  10.  
  11.         } 
  12.  
  13. } 

//一样啊，把环形缓冲铺直了

  

  1. if (s >= serverBase + this->frameCount) { 
  2.  
  3.        serverBase += this->frameCount; 
  4.  
  5.    } 
  6.  
  7.    this->server = s; //server为512了 
  8.  
  9.    cv.signal(); //读者读完了。触发下写者吧。 
  10.  
  11.    lock.unlock(); 
  12.  
  13.    return true; 

6 真的是环形缓冲吗？

环形缓冲是这样一个场景，现在buffer共1024帧。

假设：

l         写者先写到1024帧

l         读者读到512帧

l         那么，写者还可以从头写512帧。

所以，我们得回头看看frameavail是不是把这512帧算进来了。

 
  1. uint32_t audio_track_cblk_t::framesAvailable_l() 
  2.  
  3. { 
  4.  
  5.     uint32_t u = this->user;  //1024 
  6.  
  7.     uint32_t s = this->server;//512 
  8.  
  9.   
  10.  
  11.     if (out) { 
  12.  
  13.         uint32_t limit = (s < loopStart) ? s : loopStart; 
  14.  
  15.         return limit + frameCount - u;返回512，用上了！ 
  16.  
  17.     } 
  18.  
  19. } 

再看看stepUser这句话

  1. if (u >= userBase + this->frameCount) {u为1024，userBase为0，frameCount为1024 
  2.  
  3.         userBase += this->frameCount;//好，userBase也为1024了 
  4.  
  5. } 
  6.  
  7. 看看buffer 

return (int8_t *)this->buffers + (offset - userBase) * this->frameSize;

//offset是外界传入的基于user的一个偏移量。offset-userBase，得到的正式从头开始的那段数据空间。太牛了！

责任编辑：张叶青 来源： 博客园
AndroidAudioAudioFlinger
相关推荐
深入浅出的分析 Properties
最近在看java集合源码的时候，发现原来我们经常使用的Properties类既然继承自Hashtable！又涨见识了！

2019-11-11 14:51:19

Java数据结构Properties
Oracle COMMIT之深入浅出
这里介绍OracleCOMMIT发出后会将回滚段中的"前映像"标识为已提交.DML语句会产生一个SCN号，DBWN触发时写入到数据块的头部，COMMIT时也会产生一个SCN号，也会被写入数据块的头部。

2009-11-17 17:31:58

Oracle COMM
Oracle Sequence之深入浅出
这里介绍该OracleSequence的owner，或者有ALTERANYSequence权限才能改动Sequence.可以alter除start至以外的所有OracleSequence参数.

2009-11-18 13:30:37

Oracle Sequ
Cookie深入浅出
Cookie虽然是个很简单的东西，但它又是WEB开发中一个很重要的客户端数据来源，而且它可以实现扩展性很好的会话状态，所以我认为每个WEB开发人员都有必要对它有个清晰的认识。本文将对Cookie这个话题做一个全面的描述，也算是本人对Cookie的认识总结。

2011-07-04 10:39:57

Web
深入浅出AbstractQueuedSynchronizer
在Java多线程编程中，重入锁(ReentrantLock)和信号量(Semaphore)是两个极其重要的并发控制工具。相信大部分读者都应该比较熟悉它们的使用(如果不清楚的小伙伴，赶快拿出书本翻阅一下)。

2021-03-16 08:54:35

AQSAbstractQueJava
深入浅出的分析 Set集合
关于Set接口，在实际开发中，其实很少用到，但是如果你出去面试，它可能依然是一个绕不开的话题。

2019-11-14 09:53:30

Set集合存储
深入浅出 详解Android Surface系统
本文详细介绍了Android中的Surface系统，采用情景分析的办法，详解了何为SurfaceFlinger，以及SurfaceFlinger的工作流程，以Activity函数调用为切入点来研究SurfaceFlinger。

2011-05-05 14:44:43

SurfaceFlinSurfaceActivity
深入浅出 JavaScript 数组
数组是最常用的数据类型之一，ECMAScript数组跟其他语言的数组一样，都是一组有序的数据，但跟其他语言不同的是，数组中每个槽位可以存储任意类型的数据。除此之外，ECMAScript数组的长度也是动态的，会随着数据的增删而改变。

2022-09-26 09:01:15

语言数据JavaScript
深入浅出数据分析师
今天飞机回程途中，遇到位北海道银行来中国出差的女生；途中聊起了各自的职业；一直聊到北京，全程让我很苦恼的是数据分析、数据分析师这些玩意如何很容易的介绍给她；

2015-08-06 14:02:31

数据分析
深入浅出分析MySQL常用存储引擎
MyISAM：每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。.frm文件存储表定义。数据文件的扩展名为.MYD(MYData)。索引文件的扩展名是.MYI(MYIndex)。

2018-03-15 09:13:43

MySQL存储引擎
深入浅出 FlatBuffers 原理
FlatBuffers是一个开源的、跨平台的、高效的、提供了多种语言接口的序列化工具库。实现了与ProtocalBuffers类似的序列化格式。主要由WoutervanOortmerssen编写，并由Google开源。Oortmerssen最初为Android游戏和注重性能的应用而开发了FlatBuffers，现在它具有C++、C＃、C、Go、Java、PHP、Python和JavaScript的接口。

2021-07-20 15:20:02

FlatBuffers阿里云Java
深入浅出Hadoop YARN
在详细介绍Yarn之前，我们先简单聊聊Yarn，Yarn的全称是YetAnotherResourceNegotiator，意思是“另一种资源调度器”，这种命名和“有间客栈”这种可谓是异曲同工之妙。

2019-01-07 15:29:07

HadoopYarn架构调度器
Cocoa深入浅出：Framework
MacOSX扩展了framework的功能，让我们能够利用它来共享代码和资源。framework在概念上有点像Window下的库，但是比库更加强大，通过framework我们可以共享所有形式的资源，如动态共享库，nib文件，图像字符资源以及文档等。

2012-05-21 10:06:26

FrameworkCocoa
深入浅出AES算法
高级加密标准(AdvancedEncryptionStandard，AES)是美帝2001年发布的块加密算法，AES是属于块加密算法框架中的一个组件，所以理解AES的关键是搞清楚块加密算法。下面，就一起来讲讲块加密算法工作原理。

2017-07-02 18:04:53

块加密算法AES算法
深入浅出TCP之send和recv
每个TCPsocket在内核中都有一个发送缓冲区和一个接收缓冲区，TCP的全双工的工作模式以及TCP的滑动窗口便是依赖于这两个独立的buffer以及此buffer的填充状态。

2013-09-16 09:56:29

TCP协议网络协议send
深入浅出 Android核心组件Service(1)
在Android框架中，Service是比较难以理解的一部分，而网上的大多数资料最多就是讲述了如何去用Service，并没有对Service做一个深入的、系统的讲解。现在傻蛋将做一个系列文章，将对Service做一个由浅入深的梳理，帮助大家深入的掌握AndroidService。

2012-02-07 14:37:01

Android核心组件Service
深入浅出 Android核心组件Service(3)
本文51CTO专栏作者傻蛋将向我们介绍深入浅出Android核心组件Service第三部分的系列文章。当我们继想绑定一个Service又想在Activity停止时，Service不会停止，我们可以先StartService，然后再BindService()。

2012-02-07 15:09:03

Android核心组件Service
Android项目架构设计深入浅出
本文结合个人在架构设计上的思考和理解，介绍如何从0到1设计一个大型Android项目架构。

2022-01-13 09:38:25

Android架构设计
深入浅出 Android核心组件Service(2)
本文为51CTO专栏作者傻蛋做的AndroidService系列文章的第二篇，通过绑定的方式来启动Service。

2012-02-07 14:45:52

Android核心组件Service
深入浅出 Android核心组件Service(4)
本文51CTO专栏作者傻蛋将向我们介绍深入浅出Android核心组件Service第四部分的系列文章。

2012-02-07 15:16:01

Android核心组件Service
点赞
收藏

51CTO技术栈公众号

业务
速览
在线客服