開源框架那些事

前言

標題本來叫 《KtArmor-MVVM 前傳》,可是這樣顯得太過侷限,因此我站着更高點來講(標題黨),我認可我有賭的成分 :)html

迴歸正題,這篇文章,我主要想要寫給的對象是 想要開源,可是懼怕,亦或者已經 」開源的朋友「的開發者, 分享一些 我我的對 開發框架的 心得體會 和建議 ,但願你們喜歡~java

嘗試

自從知道全球 最大 ** 交友網站—— Github 後,看了一下大佬們寫的框架,那叫個git

  • 優雅github

  • 簡潔面試

  • 易用數據庫

  • 方便緩存

  • 牛逼網絡

    ....app

再看看本身的代碼,忽然不香了。框架

面試時,被問到有 開源或參與 過框架開發嗎,還在爲此發愁?

看見別人寫的代碼那麼好,那麼實用,難道你不想本身徒手擼一個屬於本身的嗎?

喜歡哪一種被人叫大佬(滑稽)的感受嗎?

若是知足以上一點, 還不趕忙動起來!

可能你會以爲本身菜,造不出輪子,可是好的框架,每每是經歷長時間的迭代更新,纔會有今天的框架,先邁出第一步,開發屬於本身的框架,讓 」時間去優化「 吧(持續迭代)。

選型

擼一款什麼 類型 框架呢? 網絡(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

  • 添加註釋

  • 豐富功能

  • 豐富文檔

  • 更新版本,尋找更好的實現方式

    ....

一款好的框架,每每須要持續迭代,而不是不了了之。

最後

以上是我我的開源框架後的 心得體會和建議,若有不妥,歡迎你們一塊兒交流學習。

相關文章
相關標籤/搜索