开源框架那些事

前言

标题原本叫 《KtArmor-MVVM 前传》,但是这样显得太过局限,所以我站着更高点来说(标题党),我承认我有赌的成分 :)

回归正题,这篇文章,我主要想要写给的对象是 想要开源,但是害怕,亦或者已经 ”开源的朋友“的开发者, 分享一些 我个人对 开发框架的 心得体会 和建议 ,希望大家喜欢~

尝试

自从知道全球 最大 ** 交友网站—— Github 后,看了一下大佬们写的框架,那叫个

  • 优雅

  • 简洁

  • 易用

  • 方便

  • 牛逼

    ....

再看看自己的代码,突然不香了。

面试时,被问到有 开源或参与 过框架开发吗,还在为此发愁?

看见别人写的代码那么好,那么实用,难道你不想自己徒手撸一个属于自己的吗?

喜欢哪种被人叫大佬(滑稽)的感觉吗?

如果满足以上一点, 还不赶紧动起来!

可能你会觉得自己菜,造不出轮子,但是好的框架,往往是经历长时间的迭代更新,才会有今天的框架,先迈出第一步,开发属于自己的框架,让 ”时间去优化“ 吧(持续迭代)。

选型

撸一款什么 类型 框架呢? 网络(OkHttp)图片加载(Glide)数据库(LitePal) 选哪一种呢?

醒醒!别做梦了,这种 "类型" 框架,新手还是别想到了(大佬除外),一上来挑个 硬柿子捏,似不似傻。

我们可以尝试从简单框架入手,如

  • 常用工具类库 (通用方法封装)

  • Android 简单 UI 框架(Loading,Dialog等)

  • 脚手架 (整合多种主流框架集合)

    ....

这些框架实现起来相对简单,先入个门,尝试一下。大概了解一下框架发布,更新,迭代的流程。

等熟悉了框架流程,技术到家了,在搞一波大的(大型框架),会更加得心应手。

取名

选型好了之后,我们可以为 自己框架取一个 有意思 的 名字,当然见名知意的框架名,是正常人的选择。如 SpringBoot-XXXOkHttp-XXX , Image-XXX.

但是我个人 建议,可以是 来福旺财 这种(滑稽),有 寓意 的,哈哈,这里是举例(切勿直接使用),当然 需要在 文档补充 说明一下 框架名称 由来。

这样会显得框架更有意思,有故事,有内味 :)

三部曲

在实际开发框架中,我们应该站在 “用户的角度” 思考 (这里 “用户” 是指 使用框架的开发者

用户怎样才能方便使用框架呢?

框架设计,我大致总结了如下 “三部曲” ,这里我们以 Glide 为例。

全局配置

import com.bumptech.glide.annotation.GlideModule;
import com.bumptech.glide.module.AppGlideModule;

@GlideModule
public final class MyAppGlideModule extends AppGlideModule {}

在这里,我们进行了全局添加有 @GlideModule 注解,继承自 AppGlideModule 的类。此类可生成出一个流式 API。方便后续使用的时候,可以直接链式调用。

默认配置

Glide.with(fragment)
    .load(myUrl)
    .into(imageView);

短短几行代码,包含了 Glide框架 精华 所在,默认实现三层缓存机制, 内存缓存磁盘缓存网络缓存。图片解码,绑定生命周期等等默认实现(详细的可以参考 Glide 源码实现)。大大简化开发者编码实现。

自己用起来是不是很爽吗?一行代码实现这么丰富的功能,实在是

局部配置

// 局部配置
RequestOptions sharedOptions = 
    new RequestOptions()
      .placeholder(placeholder)
      .fitCenter();

Glide.with(fragment)
  .load(myUrl)
  .apply(sharedOptions)
  .into(imageView1);

总会有一些特殊的需求,如大图加载,占位布局,错误图片等等定制化配置,这时候 局部配置 就派上用场了。

由此可见 Glide 框架,是多么强大啊!

我们自己在开发框架的时候,也可以尝试往这 三部曲 靠(学习的意思),高度的 自定义配置,这样子的框架,肯定深得人心,那么离 优秀框架 也就不远了。

文档

一份 简而全, 优而雅 的 使用说明文档:

  • 会大大加大使用者对该框架 好感度
  • 同时也帮助使用者更好 理解 框架,上手 框架。

注释

有了文档后,我们还需要养成 编写注释的习惯

  • 方便他人阅读源码时,能够读懂开发者的想法
  • 同时也方便自己 日后理解代码,规范代码

开源的魅力

在尝试开源后,并尝试推广 (chui)一波后,然后你就会:

  • 可以收到热情的小伙伴提的意见(Issues
  • 可以收到热情的小伙伴提的代码 “优化” (Pull Requests
  • 可以收到热情的小伙伴的认可 (star

有的朋友可能会说,我推广了没人用了怎么办? 我的答案是——持续迭代。

持续迭代

好的框架,总会有 “发光” 的一天。我们能做的是:

  • 修复已知 Bug

  • 添加注释

  • 丰富功能

  • 丰富文档

  • 更新版本,寻找更好的实现方式

    ....

一款好的框架,往往需要持续迭代,而不是不了了之。

最后

以上是我个人开源框架后的 心得体会和建议,如有不妥,欢迎大家一起交流学习。