3 丽萨的托马斯

尚未进行身份认证

暂无相关简介

等级
TA的排名 20w+

设计模式之适配器模式

一、适配器模式概述:适配器模式不是在设计阶段考虑的,而是在系统服役阶段使用的,通常用于拓展新需求。这个模式跟装饰模式类似,都是做了一个包装,只不过该**模式的定义是将一个类的接口变换成客户端所期待的另一种接口, 从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。**在实际应用中,适配器分为类适配器和对象适配器。二、类适配器及其demo:图中的adapter就是适配器,其本质相当...

2020-01-14 09:50:47

设计模式之责任链模式与装饰模式

一、责任链模式简介:责任链模式的核心就是“链”,使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止。责任链模式的缺点是性能问题,每个请求都是从链头遍历到链尾,特别是在链比较长的时候, 性能是一个非常大的问题。二、责任链模式demo:责任链模式作者选取的demo是古代妇女的“三从”,也就是说一个妇女在古...

2020-01-13 09:49:47

设计模式之中介者模式与命令模式

一、引言:中介者模式用于处理多个类高耦合的场景,类似于星型拓扑结构,在该结构中抽象出一个中介者,并配备同事类,实现不同的业务逻辑。该模式有三部分组成:中介者-同事-业务实现类。抽象中介者定义统一的接口,用于各同事角色之间通信,具体中介者用于协调各同事角色最终的协作,必须依赖各个同事,同事角色不能与其他同事类有依赖,如果需要的话,必须通过中介者才能完成。中介者的模式好处是减少类中的依赖,降...

2020-01-09 16:34:50

设计模式之原型模式及clone涉及的深拷贝与浅拷贝探究

一、原型模式介绍:原型模式的核心就一个clone方法。试想如下的场景,一个对象需要被多个修改者修改或者需要大量的对象但每个对象仅修改一些细节,比如,银行给不同客户发送的具有尊称的定制化信息。不通过new关键字来产生一个对象, 而是通过对象复制来实现的模式就叫做原型模式。原型模式理解上比较简单,但是难点在于正确理解java中的clone方法,需要注意clone对引用类型进行的是浅拷贝(数组,st...

2020-01-09 11:49:45

设计模式之模板方法模式和建造者模式

一、引言:模板方法模式非常简单,每个人在java代码编写中都会用到,其方针图如下:实际上,模板方法模式核心就是java的继承机制,父类叫做抽象模板,里面的方法分为两类:一类是基本方法,就是需要子类具体实现的方法,这类方法如果不需要过多的暴露接口,通常使用protected关键字声明,另一类就是模板方法,这类都是具体实现方法,完成固定逻辑,由父类完成,通常,在前面会加上关键字final,防止覆...

2020-01-07 10:20:57

设计模式之抽象工厂模式

一、引言:抽象工厂模式是工厂模式的升级版,书上说,这种模式的使用场景是:一个对象族(或是一组没有任何关系的对象)都有相同的约束,则可以使用抽象工厂模式。该模式的设计方针图如下:从图上可以看出,该模式的封装性非常好,client直接依赖于抽象工厂和抽象产品类就实现了产品的真正产出,也就是说,client端完全不需要知道工厂具体是怎么去产出的,只需要知道不同的工厂能生产什么产品就行了。这里举一...

2020-01-06 18:18:41

设计模式之工厂模式(factory)

一、引言:新人学java的时候,工厂模式和代理模式是必须掌握的两种设计模式,工厂模式的方针图如下:假设我们的产品是一个抽象接口,而我们的具体产品继承自该接口,为了实现工厂模式,我们同样声明了一个工厂接口Creator,里面就是我们需要实现的工厂方法,当我们需要产出一个具体的产品时,自然我们需要实例化一个具体的工厂类,该类就继承自抽象工厂接口,这样,上层产品不需要去关注类的具体实现,只需要关注...

2020-01-06 12:03:37

设计模式之单例模式(singleton)

一、引言:单例设计模式是非常常见的一种设计模式,在java中,单例设计模式确保了每个类只有一个实例,其实现的原理是将构造方法声明为private。二、示例代码:下面这段代码是最佳的单例模式代码:public class singleton{ public static void main(String[] args){ /* 调用三次,看是否只有一个对象生成 */ for(int...

2020-01-06 11:19:54

Android音频之多设备同时输出-cast通路分析

一、引言:有时候,我们在实际处理问题中会遇到这样的需求,播放一段音频或者播报一段语音希望同时从USB/蓝牙类设备和喇叭同时出声,按照Android的audiopolicy策略选择,这是不可行的,因为同一时间,audioflinger只会往一个hal层库里面写数据,而喇叭和USB/蓝牙都不是共用一个hal层的,这种情况下有些芯片厂商是怎么做的呢?最近,正好在公司遇到了这样一个需求,期望从USB的m...

2019-12-27 09:42:06

Android原生MediaPlayer调用时序图

一、引言:最近公司的同事经常会问我apk调用mediaplayer接口之后,native层的调用逻辑是什么样的,什么时候去打分播放器,什么时候创建native层的播放器等等,虽说mediaplayer在Android系统仅仅是一个“壳”,但是因为同时涉及apk和下层native,况且,这里面又借助了mediaplayerservice这么个binder服务,所以我花了些时间对整个mediapla...

2019-12-18 11:52:58

Android音频系统之USB设备通路(Android 5.1)

一、引言:输入/输出通路选择是Android音频中非常重要的一个内容,正常的一个Android系统,会支持喇叭,外放,USB设备或者蓝牙等等输出模组,所以,经常会有项目需要改变原有的策略选择,这类问题通常让人头大,在Android 5.1上面,策略选择是由audiopolicy来做的,audioflinger去执行下面的输入/输出设备的打开,所以,在实际处理中,一定要根据具体问题,多去分析aud...

2019-12-12 15:19:56

Android音频系统之AudioTrack起播线与underrun问题研究(Android 5.1)

一、引言:使用audiotrack进行pcm数据播放的时候,复杂场景下会遇到underrun问题,所谓underrun,是指生产者提供数据的速度跟不上消费者使用数据的速度。因为网上讲述这类问题的博客很少,所以这里分享一下自己的研究心得,但是由于underrun和audiotrack的buffer机制非常复杂,所以也会遗留一些问题,欢迎大神补充指正。二、代码分析:1.添加活跃track:首先...

2019-12-05 17:46:55

Android音频系统之音量控制详解(Android 5.1)

一、引言:Android的音量控制是典型的audiopolicy和audioflinger协作的例子,博文针对音量调节进行详细的解析.音量控制主要分成两大部分,一部分是java层完成的操作,用于响应音量调节,记录音量值,更新UI等操作,另一部分是native层完成,用于计算音量并执行。需要提一句的是,音量控制是设备厂商的适配重点,通常分为软音量和硬件音量,所谓软音量,就是Android原生针对a...

2019-12-03 18:22:54

Android音频系统之AudioTrack与AudioFlinger数据交互

一、前言:在前面的三篇博客中,分析了AP和AF,AT之间的初始化及流程,因为是按照代码逻辑分析的,所以相对比较按部就班,有些关键和需要串联的地方没有分析到,而这篇博客则是针对一些关键点,进行深入和串联,尽量能将三者的关系结合地更紧密。二、分析:1.native层audiotrack中,write操作是如何发起的?在代码调试中,我们看到,thread线程不停地读取audioflinger中共...

2019-11-26 11:40:18

Android音频系统之AudioTrack的创建及AudioPolicyService的策略选择(Android5.1)---下篇

一、引言:在上一篇中,我们着重分析了audiotrack创建过程中audiopolicyservice的表现,通过audiopolicyservice的策略选择,我们找到了一个适合的通路进行音频输出,在整个通路打通之后,我们似乎没有看到用于数据共享的buffer产生,而这个工作,就是由audioflinger来完成的。二、代码分析:上一篇,我们分析到,set@AudioTrack.cpp中,...

2019-11-18 16:33:38

Android音频系统之AudioTrack的创建及AudioPolicyService的策略选择(Android5.1)--- 上篇

一、引言:Android音频的两大服务就是audiopolicyservice和audioflinger,前一篇文章已经分析了audiopolicyservice的启动,而audioflinger的启动并没有什么特别需要分析的地方,但是,如果和audiotrack进行数据交互,那要分析的地方就太多了,本博文就audiotrack的应用demo为例,分析audiotrack的创建过程中,audio...

2019-11-14 16:45:58

Android音频系统之AudioPolicyService的启动及audio_policy.conf的加载(Android5.1)

一、引入:,在Android中,应用进行音频回放或者录音,最终在hal层需要选择用哪个输入/输出设备,而设备的加载,就跟audio_policy.conf息息相关,本博文分析的内容就是Android原生音频audio_policy.conf加载的过程(Android5.1)。二、源码分析:1.AudioPolicyService服务的启动:与音频相关的服务AudioFlinger和Audi...

2019-11-11 18:11:35

MediaCodec的简单测试sample及部分代码摘要

一、引言:mediacodec在framework层的代码逻辑确实比较复杂,因为对整个通路还不是很熟悉,所以这里摘要一些代码的查看心得,并在网上找了一个demo来了解一下mediacodec是怎么工作的。二、测试demo:测试代码摘录自何俊林,demo主要演示了如何渲染一个视频流文件到显示设备上:MediaCodec测试demo三、代码心得:1.mediacodec与omx的调用逻辑:...

2019-11-05 09:42:06

ACodec从UninitializedState状态到LoadedState状态分析

一、引言:mediacodec在应用层的逻辑时序图如下(create->start):进入到native层之后,mediacodec会先去实例化本对象,然后执行init操作,init函数关键代码贴出如下:MediaCodec.cppstatus_t MediaCodec::init(const AString &name, bool nameIsType, bool e...

2019-10-24 16:41:10

Acodec是如何通过其维护的状态来处理AMessage的?

一、问题引言:初读mediacodec的代码,分析了stagefright框架中大量使用的AHandler、ALooper和AMessage组成的消息机制,我们知道每个AHandler都会通过ALooper去发送消息,然后,最终通过ALooper的loop函数将AMessage分发到各自的AHandler进行处理,但在Acodec中,明明仅ACodec是一个AHandler,为什么处理消息的时候...

2019-10-24 09:46:18

查看更多

勋章 我的勋章
  • 持之以恒
    持之以恒
    授予每个自然月内发布4篇或4篇以上原创或翻译IT博文的用户。不积跬步无以至千里,不积小流无以成江海,程序人生的精彩需要坚持不懈地积累!
  • 1024勋章
    1024勋章
    #1024程序员节#活动勋章,当日发布原创博客即可获得
  • 勤写标兵Lv2
    勤写标兵Lv2
    授予每个自然周发布4篇到6篇原创IT博文的用户。本勋章将于次周周三上午根据用户上周的博文发布情况由系统自动颁发。