致敬Glide-借用其思想设计一个拍照选图控件-CSDN博客

本文链接：https://blog.csdn.net/2401_84004078/article/details/138690028

/**

自己特有的方法。。。。。

public <Y extends Target> Y downloadOnly(Y target) {

///

}

调用asBitmap 之后又返回 BitmapTypeRequest 对象，同样也是Builder：

//简化了继承关系，只为了展示清楚核心代码

public class BitmapTypeRequest extends GenericRequestBuilder<ModelType, Bitmap> {

/**

自己特有的方法。。。。。

public BitmapRequestBuilder<ModelType, byte[]> toBytes() {

///

}

但是它们都继承自最终基类 GenericRequestBuilder，这个类中就包含了我们常用的into 方法：

public class GenericRequestBuilder<ModelType, DataType, ResourceType, TranscodeType> implements Cloneable { /**

基类共有的方法。。。。。

public <Y extends Target> Y into(Y target) {

}

通过上述设计即可以保证每个子功能模块在Builder中维护自己特有的方法，又可以最终调用到父类的公用方法，一来比较符合面向对象的单一职责的设计原则，二来可以提高代码可读性，让使用者在使用的时候便于理解。

总结一下 Glide的核心思想就一行代码完成

在哪里？
做什么？
结果是？

//在哪里

Glide.with(this@MainActivity)

//干嘛

.load(“https://xxxxx.com.sxx.jpg”)

//结果是

.into(iv_image)

需求分析

我需要实现调用系统的相机、相册、裁剪、无非都需要通过intent来启动Activity，如果我采用Fragment的方式一来可以将其作为载体去启动Activity和重写onActivityResult接收返回的数据的方法，从而无须在业务层重写，从而减少代码入侵解决第一个痛点、而来可以借鉴Glide模拟生命周期的方式在后期处理图片比如压缩、旋转等异步操作的时候自动感知外部容器生命周期，从而减少业务代码
Glide的功能对应基类Builder提供基本方法、然后在子类拓展其特有功能的方法可以借鉴到这个场景下：执行每个功能产生相关的功能特性Builder、然后在父类方法中收拢，最终拿到结果，所以设计了如下UML图：

UML 分析：

CoCo.with 方法传入当前容器,指定当前的工作场地[在哪里 Where] ，返回一个FunctionManager 对象，这个对象提供了我们当前场地能提供的基本方法，也就是我们接下来的事情[做什么 whate]拍照(take)、选图（pick）、裁剪(crop)、处理(dispose) 等功能均在此类提供和拓展。
当FunctionManager调用其中某一个操作符时候，产生其对应的Builder对象，比如调用了take功能，我们返回一个 TakerBuilder对象，因为是拍照功能，我们可以在这里提供摄像头面向(cameraFace)、拍照结果写入文件(fileToSave)等参数、同理如果你选择了pick 方法，则可以在这里拓展图片选择范围(range)等方法、而最终无论最终是哪种子功能Builder、它们都继承自BaseFunctionBuilder、而在这个父类中提供了start的方法，无论通过哪种子类拓展其方法来拼装参数、都可以通过父类的start 方法执行到下一步，即保证了一行代码的整洁性、又保证了子类之间方法的隔离，符合面向对象设计思想，便于后续拓展和维护。
通过1、2步我们完成了在哪里、干什么的封装，最终通过start的方法最终执行，拿到我们想要的结果，也就是一系列的Result

详细源码的设计与分析：

下面以选图功能作为链路详细分析整个大体设计(源码有所简化、方便理解)：

//在哪里 [activity中]

CoCo.with(this@MainActivity)

//干嘛[选图]

.pick()

//结果是 [PickResult]

.start(object : CoCoCallBack {

override fun onSuccess(data: PickResult) {

iv_image.setImageURI(data.originUri)

}

override fun onFailed(exception: Exception) {

}

})

第一步当然定义容器的场景：

object CoCo {

@JvmStatic

fun with(activity: Activity): FunctionManager {

checkStatusFirst(activity)

return FunctionManager.create(activity)

}

@JvmStatic

fun with(fragment: androidx.fragment.app.Fragment): FunctionManager {

checkStatusFirst(fragment.activity)

return FunctionManager.create(fragment)

}

@JvmStatic

fun with(fragment: Fragment): FunctionManager {

checkStatusFirst(fragment.activity)

return FunctionManager.create(fragment)

}

定义使用场景以后、返回一个FunctionManager 对象，里面提供我们所有已有的和以后可以拓展的功能：

小技巧：使用 @JvmStatic 注解可以保持Java 调用 kotlin 代码时和kotlin 自己调用提供一致性的体验

class FunctionManager(internal val container: IContainer) {

/** 拍照

take photo from system camera
@param fileToSave the result of take photo to save
@see TakeBuilder

fun take(fileToSave: File): TakeBuilder =

TakeBuilder(this).fileToSave(fileToSave)

/** 选图

select a photo from system gallery or file system
@see PickBuilder

fun pick(): PickBuilder =

PickBuilder(this)

/** 异步处理文件

dispose an file in background thread ,and will bind the lifecycle with current container
@param disposer you can also custom disposer
@see Disposer

@JvmOverloads

fun dispose(disposer: Disposer = DefaultImageDisposer.get()): DisposeBuilder =

DisposeBuilder(this)

.disposer(disposer)

//… expand other functions

}

当选用每一个功能之后，我们返回一个Builder、选图对应当就是PickBuilder，而拍照对应当就是TakeBuilder，当然这都继承自它的基类BaseFunctionBuilder：

abstract class BaseFunctionBuilder<Builder, Result>(

internal val functionManager: FunctionManager

) {

/**

开始执行

fun start(callback: CoCoCallBack) {

generateWorker(getParamsBuilder()).start(null,callback)

}

/**

获取参数Builder

internal abstract fun getParamsBuilder(): Builder

/**

生成真正干活儿的类

internal abstract fun generateWorker(builder: Builder): Worker<Builder, Result>

}

在这个基类里面定义了两个泛型参数 Builder 、Result、第一个Builder 参数的其具体实现用于封装干活时候的所有参数、一个用于承载最终完成的结果，我们来看看PickBuilder的实现：

class PickBuilder(fm: FunctionManager) :

BaseFunctionBuilder<PickBuilder, PickResult>(fm) {

internal var pickRange = Range.PICK_DICM

/**

在这里拓展选图特有的功能，比如是选择系统相册还是
@param pickRange the range you can choose
@see Range.PICK_DICM the system gallery
@see Range.PICK_CONTENT the system content file

fun range(@PickRange pickRange: Int = Range.PICK_DICM): PickBuilder {

this.pickRange = pickRange

return this

}

override fun getParamsBuilder(): PickBuilder {

return this

}

override fun generateWorker(builder: PickBuilder): Worker<PickBuilder, PickResult> {

return PickPhotoWorker(functionManager.container, builder)

}

这里生成Worker的最终实现是生成了一个 PickPhotoWorker，里面完成了选图的最终实现，所以现在设计我们的Worker类：

先设计接口抽象行为：

interface Worker<Builder, ResultData> {

fun start( callBack: CoCoCallBack)

}

再设计一个抽象类，这一层去持有容器引用(比如我们需要启动Activity去选图、也需要感知容器生命周期) 和我们构建好的Builder参数：

abstract class BaseWorker<Builder, ResultData>(val iContainer: IContainer, val mParams: Builder) :

Worker<Builder, ResultData>

再看看这个选图的最终PickPhotoWorker:

class PickPhotoWorker(iContainer: IContainer, builder: PickBuilder) :

BaseWorker<PickBuilder, PickResult>(iContainer, builder) {

override fun start(

callBack: CoCoCallBack

) {

val activity = iContainer.provideActivity()

activity ?: return

pickPhoto(activity, callBack)

}

private fun pickPhoto(activity: Activity, callBack: CoCoCallBack) {

val pickIntent = Intent(Intent.ACTION_PICK, MediaStore.Images.Media.EXTERNAL_CONTENT_URI)

if (null === pickIntent.resolveActivity(activity.packageManager)) {

callBack.onFailed(BaseException(“activity status error”))

return

}

try {

//start activity for result

iContainer.startActivityResult(

pickIntent, Constant.REQUEST_CODE_IMAGE_PICK

) { _: Int, resultCode: Int, data: Intent? ->

handleResult(resultCode, data, callBack)

}

} catch (e: Exception) {

callBack.onFailed(e)

}

private fun handleResult(

resultCode: Int,

intentData: Intent?,

callBack: CoCoCallBack

) {

if (null != intentData && null != intentData.data) {

val result = PickResult()

result.originUri = intentData.data!!

callBack.onSuccess(result)

} else {

callBack.onFailed(BaseException(“null result intentData”))

}

再看看容器的接口 iContainer：

interface IContainer {

//提供activity 判断状态、或者一些需要Context特有方法的场景

fun provideActivity(): Activity?

// startActivityResult 启动activty、拿到回调结果

fun startActivityResult(intent: Intent, requestCode: Int,

callback: (requestCode: Int, resultCode: Int, data: Intent?) -> Unit

)

//获得外部容器宿主

fun getLifecycleHost(): Host

}

再看看它的具体实现当然也就是我们实际用于承载一切的的Fragment：

class AcceptResultSupportFragment : Fragment(), IContainer,

Host {

/**

当前生命周期状态

private var current = Host.Status.INIT

private var requestCode: Int = 0

private var callback: ((requestCode: Int, resultCode: Int, data: Intent?) -> Unit)? = null

override fun startActivityResult(

intent: Intent, requestCode: Int,

callback: (requestCode: Int, resultCode: Int, data: Intent?) -> Unit

) {

this.requestCode = requestCode

this.callback = callback

startActivityForResult(intent, requestCode)

}

override fun provideActivity(): Activity? = activity

override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {

super.onActivityResult(requestCode, resultCode, data)

callback!!(requestCode, resultCode, data)

}

override fun onActivityCreated(savedInstanceState: Bundle?) {

super.onActivityCreated(savedInstanceState)

//当外部想感知容器是否销毁当时候，读取这个变量即可

current = Host.Status.LIVE

}

override fun onDestroy() {

current = Host.Status.DEAD

super.onDestroy()

callback = null

}

override fun getStatus(): Int {

return current

}

override fun getLifecycleHost(): Host {

return this

}

而这个Fragment就是在我们第一步CoCo.with 创建FunctionManager 的时候创建的。

到这里，我们最开始调用的每一个操作符内部的基本链路就分析完成了、总结一下就是：

根据当前是在Activity或者Fragment的状态创建一个功能提供器FunctionManager：
FunctionManager 选择指定功能之后产生相应功能对于的Builder 用于拼装各种参数
Builder参数拼装完成后调用父类公共方法 start 去生成相应功能对应的Worker，每个Worker去做自己的实现
Worker 做完成事情后回调给CallBack 拿到我们的Result**

所以，以上述框架思想下，我拓展出了，系统拍照、系统选图、系统裁剪、文件异步处理(压缩、旋转、等图片操作)等总共四个方法，我们只需要一行代码即可完成，比如图片处理：

CoCo.with(this)

.dispose()

.origin(imageFile.path)

.start(object : CoCoAdapter() {

override fun onSuccess(data: DisposeResult) {

iv_image.setImageBitmap(Utils.getBitmapFromFile(data.savedFile!!.absolutePath))

}

})

那么现在大家可能有疑问了：

1. 里面自己实现了LifeCycle 的感知，谷歌已经有了LifeCycle 组件了，为何还要重复造轮子？

2. 通常我们拍照之后往往还需要对图片进行压缩处理以减小大小，那按照上述的设计，先拍照再处理岂不是要在回调里面嵌套了？

So 回答第一个问题，之所以不使用谷歌自带的LifeCycle控件是因为，这套控件只提供给support包或者Androidx 的包使用，而原生的Activity、Fragment是不具备lifeCycleOwner 的能力的，我们不能保证用户传入的容器是支持lifeCycleOwner 的还是不支持的，所以自己实现以保证更好的兼容性。

第二个问题也就是接下来要重点介绍的切换操作符的设计原因了，通过设计我们的切换操作符，可以让我们一行代码组合多种操作，以满足实际业务场景，我们往往拍完照之后需要进行压缩处理，通过then操作符可以一步到位：

比如，我们选完一张图片要进行裁剪然后再压缩

CoCo.with(this@MainActivity)

//选图

.pick()

//切换操作符

.then()

//裁剪

.crop()

//切换操作符

.then()

//压缩处理

.dispose()

.start(object : CoCoAdapter() {

override fun onSuccess(data: DisposeResult) {

iv_image.setImageBitmap(data.compressBitmap)

}

})

效果图：

设计Then 操作符：

按照之前的设计，我们在调用 start的方法的时候，直接生成了其对应的Worker开始执行，那现在如果我们想串联多个功能是不是我只需要在切换其他功能的操作符的时候，直接生成Woker对象存下来，最后完成所有的功能之后再依次按顺序调用start、将上一个Woker处理的结果丢给下一个Woker即可完成功能的串联？

设计流程：

在FunctionManager中增加一个List用于保存所有要执行的Worker：

class FunctionManager(internal val container: IContainer) {

internal val workerFlows = ArrayList()

}

然后在原有BaseWorker 的位置添加then方法，当调用then 方法的时候生成Worker并添加到list中，然后返回 FunctionManager对象，保证我们完成一个工作之后，可以切换到FunctionManager的其他功能：

总结

学习技术是一条慢长而艰苦的道路，不能靠一时激情，也不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！

最后如何才能让我们在面试中对答如流呢？

答案当然是平时在工作或者学习中多提升自身实力的啦，那如何才能正确的学习，有方向的学习呢？有没有免费资料可以借鉴？为此我整理了一份Android学习资料路线：

这里是一部分我工作以来以及参与过的大大小小的面试收集总结出来的一套BAT大厂面试资料专题包，主要还是希望大家在如今大环境不好的情况下面试能够顺利一点，希望可以帮助到大家。

好了，今天的分享就到这里，如果你对在面试中遇到的问题，或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己，对于自己的未来还不够了解不知道给如何规划。来看看同行们都是如何突破现状，怎么学习的，来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。

最后，祝愿即将跳槽和已经开始求职的大家都能找到一份好的工作！

这些只是整理出来的部分面试题，后续会持续更新，希望通过这些高级面试题能够降低面试Android岗位的门槛，让更多的Android工程师理解Android系统，掌握Android系统。喜欢的话麻烦点击一个喜欢再关注一下
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
()

}

然后在原有BaseWorker 的位置添加then方法，当调用then 方法的时候生成Worker并添加到list中，然后返回 FunctionManager对象，保证我们完成一个工作之后，可以切换到FunctionManager的其他功能：

总结

学习技术是一条慢长而艰苦的道路，不能靠一时激情，也不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！

最后如何才能让我们在面试中对答如流呢？

[外链图片转存中…(img-GIGLTgRI-1715364972391)]

[外链图片转存中…(img-j3mD2FQv-1715364972392)]

最后，祝愿即将跳槽和已经开始求职的大家都能找到一份好的工作！

这些只是整理出来的部分面试题，后续会持续更新，希望通过这些高级面试题能够降低面试Android岗位的门槛，让更多的Android工程师理解Android系统，掌握Android系统。喜欢的话麻烦点击一个喜欢再关注一下
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！