Nuplayer源代码分析2

最新推荐文章于 2021-06-20 09:07:57 发布

最新推荐文章于 2021-06-20 09:07:57 发布 · 172 阅读

文章标签：

本文深入探讨了Android多媒体框架中的OpenMAX与NUPlayer的内存管理策略。通过对比传统的Awesomeplayer方式与NUPlayer的改进渲染流程，阐述了在流媒体播放中内存分配重复的问题，并解释了4.0版本引入的新内存管理机制如何有效避免这一问题，提升多媒体应用的性能。

先说一下我了解的openmax，omx的数据流动是port方式，内存分配和释放都在port上面进行。在android上面omx作为一个binder，是和mediaserver在同一个process。就是了解这么一点点，有深入了再写

接着说nuplayer，nuplayer的render方式为什么会换成现在这种方式，说一下我的理解，因为代码还没看完，只是感觉是这样的，有错误后面再修复。

以前的render方式就是awesomeplayer方式，inport和outport的分配内存都在omx这端，render的时候需要得到omx的指针就可以render数据，在流媒体播放的时候数据得需要在本地开内存，而到omx端需要重新分配内存，这样就会造成分配重复，现在4.0的这种方式分配内存都在本地这端，omx取本地的指针来做解码处理，这样就避免了分配重复。

会涉及到binder部分，还不是非常熟悉，但是感觉应该是上面那样。

上篇写到了数据在framework中的几个类之间的流动，这回说一下acodec这个文件。

acodec继承自 AHierarchicalStateMachine，这个父类会更换播放的状态，从而根据不同的state做初始化操作和选择不同的message去分发处理，写的相当的巧妙。

            OWNED_BY_US,
            OWNED_BY_COMPONENT,
            OWNED_BY_UPSTREAM,
            OWNED_BY_DOWNSTREAM,
            OWNED_BY_NATIVE_WINDOW,

几个buffer 的info可以知道buffer在本地和omx之间的转换。详细的等下篇吧，有事情要做了，这篇就到这了