致敬Glide-借用其思想设计一个拍照选图控件
内容提要
本文内容较长，包含一个功能整个重构从想法到设计以及落地的完整过程，经过阅读本文你能够收获：java
- Glide 几个关键特性的设计原理以及对它们的思考(面试可用)
- 编码从拓展性层面的考虑到面向对象编程的实践
- 相似于RxJava的工做流的设计思想以及实践
- 一些kotlin和Java 互相调用的小技巧
- 一个功能强大的调用系统相机、系统相册的库以及它是如何被设计出来的
背景
鉴于最近对原有项目进行了老的代码的重构，其中的调用系统拍照选图模块就是咱们平常遇到一个痛点，须要在调用系统相机(相册)的部分写Intent ：android
//示例代码
Intent intent = new Intent(Intent.ACTION_GET_CONTENT, null);
intent.setType("image/*");
activity.startActivityForResult(intent, getRequestCode());
复制代码
在onActivityResult中得到照片之后、异步处理(方向纠正、压缩等)得到的数据、若是有业务须要还需实现上传到后端的逻辑:git
@Override
protected void onActivityResult(int requestCode, int resultCode, @Nullable final Intent data) {
//示例代码
//异步处理图片、压缩、旋转等
File result = compressPhotoFromAlbumAsy（data）;
// 上传给后端、等业务处理
uploadAsy(result);
}
复制代码
因此梳理下来有几点痛点：github
- 处理入口分散、触发拍照行为和接收不在一个地方、依赖重写onActivityResult方法，很是不利于后期模块化组件化拆分。
- 图片须要异步处理以提升用户体验，因此此时还须要考虑容器的生命周期，须要添加不少判断代码，从而致使可读性比较差，每次梳理图片的逻辑处理曾和业务上的图片上传层都须要很多时间
重构结果：
故鉴于以上几个痛点，我借鉴Glide中的几个思想对此模块进行了重构，设计了CoCo 库->一行代码灵活完成原生系统提供的拍照、选图、压缩、裁剪等脱离业务层的操做。先随便贴两个功能：面试
- 调用系统相机拍张照：
CoCo.with(this@MainActivity)
.take(createSDCardFile())
.start(object : CoCoCallBack<TakeResult> {
override fun onSuccess(data: TakeResult) {
iv_image.setImageBitmap(Utils.getBitmapFromFile(data.savedFile!!.absolutePath))
}
})
复制代码
上述即可自动拿到原图去展现咱们的结果，固然若是你须要压缩或者处理一下原图的话，只需切换一个操做符便可：编程
CoCo.with(this@TakePictureActivity)
.take(createSDCardFile())
//切换操做符执行下一步功能
.then()
//处理图片
.dispose()
.start(object : CoCoCallBack<DisposeResult> {
override fun onSuccess(data: DisposeResult) {
iv_image.setImageBitmap(data.compressBitmap)
}
})
复制代码
用dispose 操做符能够压缩并纠正原图的转向，而且异步操做自动像Glide同样绑定with()中传入容器的生命周期，并且dispose 对于图片文件的处理方式能够自定义，按需修改策略。后端
固然、CoCo还提供了 系统相册选图、系统裁剪等的功能、而且这一系列的操做符能够组合使用，你能够选图、压缩并裁剪、选图裁剪等，按需本身组合便可。缓存
原理与设计思想：
对Glide 的致敬：
Glide 是咱们Android 经常使用的图片库，它有几个特性是咱们所熟知的：markdown
- 一行代码完成图片加载、缓存、展现过程、而且异步操做自动绑定容器生命周期
- 执行加载操做load以后、拓展了不少不一样的方法可灵活选择，好比图片大小、缓存类型等、 最终经过into 完成全部操做
1:上述使人舒服特性的原理在于在Glide 内部，本身经过添加Fragment的方式 在Fragment的生命周期中维护了个LifeCycle，所以能够感知调用容器的生命周期，从而在相关的时候作一些异步的解绑操做。app
public class RequestManagerFragment extends Fragment {
@Override
public void onStart() {
super.onStart();
lifecycle.onStart();
}
@Override
public void onDestroy() {
super.onDestroy();
lifecycle.onDestroy();
}
}
复制代码
2:而经过load操做符以后返回的对象实际上是一个 Builder对象,根据load入参数的不一样产生不一样的子类Builder对象，不一样子类封装本身特有的方法，好比load以后返回的是：DrawableTypeRequest 对象，本质也是一个Builder：
//简化了继承关系，只为了展现清楚核心代码
public class DrawableTypeRequest<ModelType> extends GenericRequestBuilder<ModelType> implements DownloadOptions {
/** * 本身特有的方法。。。。。 */
public <Y extends Target<File>> Y downloadOnly(Y target) {
///
}
}
复制代码
调用asBitmap 以后又返回 BitmapTypeRequest 对象，一样也是Builder：
//简化了继承关系，只为了展现清楚核心代码
public class BitmapTypeRequest<ModelType> extends GenericRequestBuilder<ModelType, Bitmap> {
/** * 本身特有的方法。。。。。 */
public BitmapRequestBuilder<ModelType, byte[]> toBytes() {
///
}
}
复制代码
可是它们都继承自最终基类 GenericRequestBuilder，这个类中就包含了咱们经常使用的into 方法：
public class GenericRequestBuilder<ModelType, DataType, ResourceType, TranscodeType> implements Cloneable { /** * 基类共有的方法。。。。。 */
public <Y extends Target<TranscodeType>> 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 方法执行到下一步，即保证了一行代码的整洁性、又保证了子类之间方法的隔离，符合面向对象设计思想，便于后续拓展和维护 。
- 经过一、2步 咱们完成了在哪里、干什么的封装，最终经过start的方法最终执行，拿到咱们想要的结果，也就是一系列的Result
详细源码的设计与分析：
下面以选图功能做为链路详细分析整个大致设计(源码有所简化、方便理解)：
//在哪里 [activity中]
CoCo.with(this@MainActivity)
//干吗[选图]
.pick()
//结果是 [PickResult]
.start(object : CoCoCallBack<PickResult> {
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<Result>) {
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<ResultData>)
}
复制代码
再设计一个抽象类，这一层去持有容器引用(好比咱们须要启动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<PickResult> ) {
val activity = iContainer.provideActivity()
activity ?: return
pickPhoto(activity, callBack)
}
private fun pickPhoto(activity: Activity, callBack: CoCoCallBack<PickResult>) {
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<PickResult> ) {
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<DisposeResult>() {
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<DisposeResult>() {
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<Any>()
}
复制代码
- 而后在原有BaseWorker 的位置添加then方法，当调用then 方法的时候生成Worker并添加到list中，而后返回 FunctionManager对象，保证咱们完成一个工做以后，能够切换到FunctionManager的其余功能：
fun then(): FunctionManager {
this.functionManager.workerFlows.add(generateWorker(getParamsBuilder()))
return this.functionManager
}
复制代码
- 这个时候咱们修改Worker的 start 方法，增长一个参数用于承接上一个Worker的结果：
interface Worker<Builder, ResultData> {
fun start(formerResult: Any?, callBack: CoCoCallBack<ResultData>)
}
复制代码
- 此时咱们最终BaseFunctionBuilder的star方法的实现固然就是一个递归调用了：
abstract class BaseFunctionBuilder<Builder, Result>(
internal val functionManager: FunctionManager
) {
fun then(): FunctionManager {
...
}
/** * call start to begin the workflow */
fun start(callback: CoCoCallBack<Result>) {
this.functionManager.workerFlows.add(generateWorker(getParamsBuilder()))
//循环取每个Worker
val iterator = functionManager.workerFlows.iterator()
if (!iterator.hasNext()) {
return
}
//第一次开始，第一个Worker formerResult 为null
realApply(null, iterator, callback)
}
private fun realApply( formerResult: Any?, iterator: MutableIterator<Any>, callback: CoCoCallBack<Result> ) {
val worker: Worker<Builder, Result> = iterator.next() as Worker<Builder, Result>
worker.start(formerResult, object : CoCoCallBack<Result> {
override fun onSuccess(data: Result) {
if (iterator.hasNext()) {
iterator.remove()
//若是还有下个，递归继续
realApply(data, iterator, callback)
} else {
//没有下个，结束流程、回调给最终结果
callback.onSuccess(data)
}
}
override fun onFailed(exception: Exception) {
callback.onFailed(exception)
}
})
}
}
复制代码
具体每一个子类实现就不细贴了，打击有兴趣能够看看源码，就是将上个处理的结果串联起来，最终将Result一层一层传到最终的Result中，至此咱们就完成了一行代码完成裁剪、拍照、处理、以及它们功能的任意组合的同时、还保证了代码的简洁性、可读性、易于拓展性。
总结
完整UML
CoCo 借鉴了Glide的语法和设计思想对系统经常使用功能如拍照、选图、裁剪 作了一些封装、不只能够在处理图片等异步操做时候感知外部容器，并且经过相似于RxJava工做流的思想，这几个操做能够串联流式处理，大大提升了功能的拓展性和灵活性的同时，还能保证代码的简洁可读性，能够为咱们平常开发减小不少臃肿代码，提升了开发效率，目前CoCo稳定版上线已经支持了多个应用稳定性运行。
GitHub地址：
- 1. 借鉴Glide思想二次封装Fresco
- 2. dxCameraControl控件(拍照)
- 3. HikariPool源码（二）设计思想借鉴
- 4. 海思拍照
- 5. 选择照片和拍照
- 6. 借鉴--阮一峰博客之Jquery设计思想
- 7. 拍照构图
- 8. Android7.0拍照和相册选取图片
- 9. Android 拍照、选择图片并裁剪
- 10. 向前辈致敬致敬
- 更多相关文章...
- • Web 创建设计 - 网站建设指南
- • 移动设备 统计 - 浏览器信息
- • 使用Rxjava计算圆周率
- • IntelliJ IDEA代码格式化设置
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 借鉴Glide思想二次封装Fresco
- 2. dxCameraControl控件(拍照)
- 3. HikariPool源码（二）设计思想借鉴
- 4. 海思拍照
- 5. 选择照片和拍照
- 6. 借鉴--阮一峰博客之Jquery设计思想
- 7. 拍照构图
- 8. Android7.0拍照和相册选取图片
- 9. Android 拍照、选择图片并裁剪
- 10. 向前辈致敬致敬