大表哥带你一步一步用Builder模式实现自定义相机(拍照+录制,附源码)

96
码农大表哥
0.4 2017.12.06 14:05* 字数 2794

1.前言

  • 1.1 初衷

在我们做很多项目的过程中,经常会遇到很多需要自定义的相机的需求,这个时候,很多人第一步都是网上查资料,包括我也是这样,但是我没有发现有比较靠谱没有Bug的开源项目,虽然这个需求也不是很难,但是由于android市场的碎片化,各机型的适配也是很头疼,一步一步去写难免会踩到不少的坑,所以,我打算长期维护这个项目,有问题的欢迎提交Issues,以便于我完善这个开源项目。

  • 1.2 简单介绍

该开源项目整体由Builder模式编写,方便后期扩展,支持链式调用。

目前可支持的自定义扩展项:
1、相机拍摄方式:拍照or录制
2、拍摄质量
3、拍摄保存路径、文件名
4、可预览的imageView
5、拍照分辨率
6、录制分辨率

2.准备

  • 2.1 了解SurfaceView

Google官方对SurfaceView的解释

2.1.1 简介

通常情况程序的View和用户响应都是在同一个线程中处理的,这也是为什么处理长时间事件(例如访问网络)需要放到另外的线程中去(防止阻塞当前UI线程的操作和绘制)。但是在其他线程中却不能修改UI元素,例如用后台线程更新自定义View(调用View的在自定义View中的onDraw函数)是不允许的。

如果需要在另外的线程绘制界面、需要迅速的更新界面或则渲染UI界面需要较长的时间,这种情况就要使用SurfaceView了。SurfaceView中包含一个Surface对象,而Surface是可以在后台线程中绘制的。Surface属于OPhone底层显示系统,SurfaceView的性质决定了其比较适合一些场景:需要界面迅速更新、对帧率要求较高的情况。

SurfaceView的核心提供了两个线程:UI线程和渲染线程。应该注意的是:
a.所有的SurfaceView和SurfaceHolder.Callback的方法都应该在UI线程里调用,一般来说就是应用程序的主线程。渲染线程所要访问的各种变量应该做同步处理。
b.由于surface可能被销毁,它只在SurfaceHolder.Callback.surfaceCreated()和SurfaceHoledr.Callback.surfaceDestroyed()之间有效,所以要确保渲染线程访问的是合法有效地surface.

2.1.2 SurfaceView类 和View类的区别:

SurfaceView 和View的最本质的区别在于,surfaceView是在一个在新起的单独线程中可以重新绘制画面,而View必须在UI的主线程中更新画面。那么在UI的主线程中更新画面,可能会引发问题,比如你更新画面的时间过长,那么你的主UI线程会被你正在画的函数阻塞,那么将无法响应按键,触摸等消息。当使用surfaceView由于是在新的线程中更新画面所以不会阻塞你的UI主线程,但是这也会有另外一个问题,就是事件同步。比如你触屏了一下,你需要surfaceView中thread处理,一般就需要有一个event queue的设计来保存touch event,这样就会有点复杂了。
View:必须在UI的主线程中更新画面,用于被动更新画面。
surfaceView:UI线程和子线程中都可以。在一个新启动的线程中重新绘制画面,主动更新画面。
所以在游戏的应用上,根据游戏的特点,一般分为两类:
a. 被动更新画面的。比如棋类,这种用view就好。因为画面的跟新依赖于onTouch来更新,可以直接使用invalidate.因为这种情况下,这一次Touch和下一次Touch需要的时间比较长些,不会产生
影响。
b.主动更新:比如一个人在一直跑动。这就需要一个单独的thread不停地重绘人的转台,避免阻塞mian UI Thread 。所以显然view 不适合,需要surfaceView来控制。

  • 2.2理解Builder模式

其实在我们在编写程序的很多时候,都会使用Builder模式,如v7包自带的AlertDialog的实现、OkHttpClient的参数配置等等。

Builder模式也就是建造者模式,主要用于将一个复杂的对象分离,通过不同的构造(不同的参数值)去构建不同的对象,在使用的时候隐藏构造过程和细节,用户不需要知道内部实现过程,方便用户创建复杂的对象

2.2.1 优缺点:
  • 优点
    1.易于解耦
    将产品本身与产品创建过程进行解耦,可以使用相同的创建过程来得到不同的产品。也就说细节依赖抽象。
    易于精确控制对象的创建
    将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰
    2.易于拓展
    增加新的具体建造者无需修改原有类库的代码,易于拓展,符合“开闭原则“。
    每一个具体建造者都相对独立,而与其他的具体建造者无关,因此可以很方便地替换具体建造者或增加新的具体建造者,用户使用不同的具体建造者即可得到不同的产品对象。
  • 缺点
    建造者模式所创建的产品一般具有较多的共同点,其组成部分相似;如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。
    如果产品的内部变化复杂,可能会导致需要定义很多具体建造者类来实现这种变化,导致系统变得很庞大。

3.编码

  • 3.1 自定义SurfaceView的实现和设计

    3.1.1 自定义SurfaceView实现

    编写一个类CameraSurfaceView继承surfaceView并实现SurfaceHolder.Callback接口,实现方法中包含了surfaceView生命周期的几个方法:创建时候调用(surfaceCreated)、页面更新时候调用(surfaceChanged)、surfaceView销毁时候调用(surfaceDestroyed)。

    由于我的需求事在直接使用cameraSufaceView时候就需要链式配置所有的参数,所以我们将要在cameraSufaceView中写一个Builder的静态内部类。
    然后考虑到解耦性,我们单独写一个零件类(需要灵活配置的参数),包含了我们一开始提到的拍摄方式、质量、保存地址等等参数
    在Builder内部类中,把所有的零件配置和获取暴露提供给外部,最后调用某个方法(项目中是startCamera())开始组装零件变成一个完整的产品。

  • 3.2 辅助类的编写思路

    3.2.1 编写前的思考

    我们编写这个类的主要目的是区别与SurfaceView内部代码,把所有逻辑代码都分离出来,各司其职,这样以后逻辑有改动不会过多的牵扯到view层,这和mvp的优点类似。
    那么,这个辅助类应该具备什么样的功能呢?
    当然首先会有一个方法去绑定SurfaceView用于初始化数据,然后会有方法去一一对应SurfaceView生命周期的几个方法来创建camera、适配屏幕预览、销毁camera等。其中camera的创建应该是一个单例,因为系统同时只能同时存在一个可操作的camera,除了这些,还有一系列的其他辅助方法,如矫正拍照角度、自适应预览画面、录制配置、拍照配置等等
    这个辅助类应该有些什么特征呢?
    首先,由于我们会在SurfaceView内部的生命周期方法里面和Activity/Fragment中使用到这个操作逻辑的辅助类,所以,我打算把它写成单例,在任何位置操作都可以控制。
    其次,辅助类中应有对应SurfaceView生命周期逻辑的方法去控制camera对象实例,如在SurfaceView创建(surfaceCreated)的时候去创建Camera对象,绑定SurfaceView的Holder并开始预览,在SurfaceView更新的时候(surfaceChanged)去适应相机方向和预览方位防止变形和方向错乱,在SurfaceView销毁(surfaceDestroyed)的时候去释放Camera实例。

    3.2.2 处理异常

    在我们编写过程中,某些地方可能会出现不可预知的错误,这个时候我们要通知到View层去提示用户异常信息,所以这里我们要用到一个接口去供View层去实现,通过这个接口去通知View层出现了某些异常。

  • 3.3 运行时权限的处理

    在Android6.0(API级别 23)中,在使用到部分危险权限时候,会向系统申请权限才能正常使用某些功能,所以我们要针对权限进行适配,这里我推荐PermissionsDispatcher,该库还针对xiaomi做了专门的适配。

    3.3.1 PermissionsDispatcher介绍

    PermissionsDispatcher是一个基于注解、帮助开发者简单处理Android 6.0系统中的运行时权限的开源库。避免了开发者编写大量繁琐的样板代码。
    开源地址:https://github.com/hotchemi/PermissionsDispatcher
    文档介绍:http://hotchemi.github.io/PermissionsDispatcher/

    使用方法可以参见github地址给出的步骤。

4.遇到的问题

5.结语

Android随笔
Web note ad 1