背景
相信很多同學(xué)對于祖?zhèn)鞔a都有極其恐怖的體驗猛们，不改他難以維護起便、難以支撐新業(yè)務(wù)棚贾，改了又會冒出一堆莫名其妙的 bug，而且榆综，當這些代碼以模塊的形式大量的出現(xiàn)在工程中時妙痹，估計想死的心都有了。
湊巧的是鼻疮，在我們的項目里就充斥著這樣的代碼怯伊，在我接手這個項目的時候這個項目已經(jīng)傳了4代了，并且第一代寫這個項目的程序員不是寫 Android 的判沟，他們寫的很多代碼還仍被當做核心模塊留在工程中耿芹，可能也是前幾代開發(fā)者對祖?zhèn)鞔a充滿恐懼，所以一有新業(yè)務(wù)就僅是在其基礎(chǔ)上不斷添加代碼挪哄，從而導(dǎo)致項目越來越臃腫吧秕，很多模塊都難以讀懂。
因為我是一個對代碼有潔癖的人迹炼，并且在項目正常維護（開發(fā)新內(nèi)容砸彬、bugfix）的時候颠毙，這些祖?zhèn)鞔a已經(jīng)難以再支撐下去，于是當我負責 Android 端整個項目的時候砂碉，我就決定大刀闊斧的對這些內(nèi)容進行整體的重構(gòu)蛀蜜，也是為后來想在項目中做出更多創(chuàng)新打下基礎(chǔ)。
分享一個模塊的重構(gòu) - 數(shù)據(jù)庫模塊
因為我們項目的特殊性增蹭，大量的用戶數(shù)據(jù)都被存儲在本地的 SQLite 數(shù)據(jù)庫中滴某，所以數(shù)據(jù)庫模塊成為了我們重點維護的核心模塊，這次分享也以這個模塊的重構(gòu)為基礎(chǔ)沪铭。
老數(shù)據(jù)庫模塊存在的問題：
一. 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計混亂
用戶主要在我們的項目中通過做任務(wù)去獲取獎勵壮池，任務(wù)有多個類型，用戶所做的任務(wù)都會存儲在數(shù)據(jù)庫中等待上傳杀怠，因為數(shù)據(jù)庫的結(jié)構(gòu)設(shè)計問題（也可能是前幾代同學(xué)在合作的時候沒有溝通好），導(dǎo)致出現(xiàn)了任務(wù)1厅克、2赔退、3存儲在表1，任務(wù)4存儲在表2证舟，任務(wù)5存儲在表3的情況（如下圖）硕旗，并且因為 SQLite 不支持字段刪除，很多表的字段數(shù)多達 20 多個女责。
二. 數(shù)據(jù)庫操作框架 bug
我們項目中之前一直使用的是 OrmLite 框架進行數(shù)據(jù)庫操作漆枚，這個框架提供了很好的數(shù)據(jù)庫管理模式，帶來了很大的方便抵知，但是卻存在一個致命問題就是數(shù)據(jù)庫并行操作會導(dǎo)致 Crash（好像作者已經(jīng)不維護這個框架了...）墙基，雖然并發(fā)在客戶端上并不是很高頻，但是在我們的項目中確實存在很多這樣的情況刷喜，如用戶邊后臺上傳任務(wù)邊編輯任務(wù)等残制。
三. 數(shù)據(jù)庫操作層代碼混亂
原數(shù)據(jù)庫模塊在 OrmLite 框架的基礎(chǔ)上，針對每張表封裝了 Table 類進行數(shù)據(jù)庫操作掖疮，再在 Table 層下封裝了 Service 層對外暴露靜態(tài)接口方便調(diào)用初茶，雖然這個設(shè)計看起來很好，也有分層的概念浊闪，但是還是存在幾個問題：
- 因為表 1 中存儲了多個任務(wù)恼布，導(dǎo)致表 1 對應(yīng)的 Table 類代碼爆炸，達到了幾千行;
- Service 層僅作為方便調(diào)用的中轉(zhuǎn)搁宾，“工作量” 不夠折汞，且徒增代碼量;
- Table 層每個接口做的事情不夠 “單一”，摻雜了業(yè)務(wù)邏輯在里面猛铅，眾多接口不方便復(fù)用字支。
重構(gòu)方案
一. 重新設(shè)計模塊結(jié)構(gòu)
通過對業(yè)務(wù)的分析，每個數(shù)據(jù)庫操作實際都是對應(yīng)每一種 “任務(wù)” 的查詢操作，所以每種 "任務(wù)" 是我們需要直接面向的對象堕伪，而不應(yīng)該是真實的數(shù)據(jù)庫表揖庄，并且真實的數(shù)據(jù)庫表可能包含多種任務(wù)類型，如果直接對表進行操作欠雌，就會出現(xiàn)一張表對應(yīng)的 Table 類里出現(xiàn)多個任務(wù)的業(yè)務(wù)邏輯代碼蹄梢，于是基于這個思路重新設(shè)計模塊結(jié)構(gòu)，如下圖：
基本的設(shè)計思路是：
既然數(shù)據(jù)表沒有很好的對任務(wù)進行劃分富俄，那我們就抽象一個虛擬的任務(wù)表層出來禁炒，每個任務(wù)表只負責自己對應(yīng)任務(wù)的數(shù)據(jù)庫操作，并把真實的數(shù)據(jù)表層 Abstract 化霍比，只對外暴露我們?nèi)蝿?wù)表幕袱，這樣我們之后就只需要關(guān)心對應(yīng)任務(wù)的操作了，每個任務(wù)的 Table 類也不會代碼量膨脹悠瞬，便于維護们豌。可能會有同學(xué)疑問為什么不直接對數(shù)據(jù)庫結(jié)構(gòu)進行調(diào)整浅妆，主要是因為代價太大望迎，需要用戶強制升級，并大量遷移數(shù)據(jù)凌外，當然這一步在后續(xù)合適的時機也一定是回去做的辩尊。
對于虛擬的任務(wù) Table 類的每個接口，我們只提供最基本的增康辑、刪摄欲、改、查操作晾捏，事務(wù)操作轉(zhuǎn)由 Helper 層提供, 這樣便于 Helper 層針對不同的業(yè)務(wù)邏輯來組合這些接口蒿涎，達到代碼復(fù)用，并且因為單條查詢粒度較小惦辛，對于數(shù)據(jù)庫并發(fā)框架提供的讀寫鎖來說劳秋，可以提升很大的效率。
Helper 層則通過 AbstractHelper 基類向下層提供的數(shù)據(jù)庫并發(fā)處理框架和虛擬任務(wù)表單例胖齐，針對不同的業(yè)務(wù)提供接口玻淑，對于需要“跨表”（這里也包括跨虛擬任務(wù)表，雖然它們實際在一張真實表里）的操作呀伙，提供 UnionQueryHelper 工具類來組合各 TaskHelper 提供查詢补履，這樣做到模塊間代碼界限清晰，不至于隨著后面的不斷維護剿另，各個 Helper 層之間代碼界限又變的混亂不堪箫锤。
整體來說贬蛙，就是抽象出一個虛擬表層來表示每種任務(wù)表，徹底將混亂不堪的 SQLite 的真實表層徹底屏蔽掉谚攒。
二. 解決數(shù)據(jù)庫框架的 bug
值得慶幸的是老的數(shù)據(jù)庫框架采用了分層的思想阳准，不管分層做的好不好，但是對在日常需求開發(fā)中穿插的代碼重構(gòu)來說馏臭，確實節(jié)省了很多的時間, 在解決并發(fā)問題的時候我們就是在原 Table 層上添加一層并發(fā)處理層野蝇，很快的解決了這個問題并融合到將要發(fā)版的版本進行正常發(fā)版。
之前的同學(xué)就是在這個基礎(chǔ)上提供了一個解決并發(fā)問題的小框架括儒，借鑒了一些成熟框架的思想绕沈，采用了任務(wù)隊列的方式，雖然解決了并發(fā)問題帮寻，但是并不十分適合我們的實際場景乍狐，也引入了一些其他的bug，比如對于用戶大量的任務(wù)數(shù)據(jù)固逗，當我們進行全量讀取的時候澜躺，會消耗大量的時間，此時其他的任何數(shù)據(jù)庫操作都需要等待抒蚜，效率比較低。
針對客戶端并發(fā)量低耘戚、讀操作多嗡髓、操作耗時基本較端的特性，我認為依靠讀寫鎖進行數(shù)據(jù)庫并發(fā)限制就可以很好的解決問題收津，并且執(zhí)行效率較高饿这，也便于維護，并發(fā)操作限制中轉(zhuǎn)層代碼如下：
/**
* 提供給所有 Helper 子類使用的數(shù)據(jù)庫表操作加鎖工具類撞秋，不對外暴露
*/
protected object Executor {
const val INSERT = 0L
const val DELETE = 1L
const val UPDATE = 2L
const val QUERY = 3L
private const val TRANSACTION = 4L
private val mLock = ReentrantReadWriteLock()
@IntDef(INSERT, DELETE, UPDATE, QUERY, TRANSACTION)
@Retention(AnnotationRetention.SOURCE)
annotation class ActionType
class TransactionResult<out T_DATA>(val success: Boolean, val data: T_DATA)
fun transaction(action: () -> Unit, catcher: ((Exception) -> Unit)? = null): Boolean {
var success = true
val lock = getAdaptiveLock(TRANSACTION)
lock.lock()
try {
LocalDatabase.instance.inTransaction { action() }
} catch (e: Exception) {
handleException(e, catcher)
success = false
} finally {
lock.unlock()
}
return success
}
fun <T_RESULT> transactionResult(action: () -> T_RESULT, defaultVal: T_RESULT): TransactionResult<T_RESULT> {
return transactionResult(action, null, defaultVal)
}
fun <T_RESULT> transactionResult(action: () -> T_RESULT,
catcher: ((Exception) -> Unit)? = null, defaultVal: T_RESULT): TransactionResult<T_RESULT> {
var success = true
val resultHolder = arrayOfNulls<Any>(1).apply { this@apply[0] = defaultVal }
val lock = getAdaptiveLock(TRANSACTION)
lock.lock()
try {
LocalDatabase.instance.inTransaction { resultHolder[0] = action() }
} catch (e: Exception) {
handleException(e, catcher)
success = false
} finally {
lock.unlock()
}
@Suppress("UNCHECKED_CAST")
return TransactionResult(success, resultHolder[0] as T_RESULT)
}
fun execute(@ActionType actionType: Long, action: () -> Unit,
catcher: ((Exception) -> Unit)? = null) {
val lock = getAdaptiveLock(actionType)
lock.lock()
try {
action()
} catch (e: Exception) {
handleException(e, catcher)
} finally {
lock.unlock()
}
}
fun <T_RESULT> executeResult(@ActionType actionType: Long,
action: () -> T_RESULT, defaultVal: T_RESULT): T_RESULT {
return executeResult(actionType, action, null, defaultVal)
}
fun <T_RESULT> executeResult(@ActionType actionType: Long,
action: () -> T_RESULT,
catcher: ((Exception) -> Unit)?, defaultVal: T_RESULT): T_RESULT {
var result = defaultVal
val lock = getAdaptiveLock(actionType)
lock.lock()
try {
result = action()
} catch (e: Exception) {
handleException(e, catcher)
} finally {
lock.unlock()
}
return result
}
private fun getAdaptiveLock(@ActionType actionType: Long): Lock =
if (actionType == QUERY) mLock.readLock() else mLock.writeLock()
private fun handleException(ex: Exception, catcher: ((Exception) -> Unit)?) {
if (BuildConfig.DEBUG) {
throw ex
}
CrabSDK.uploadException(ex)
catcher?.invoke(ex)
}
}
使用過程可以參考如下：
fun getAllData() =
Executor.executeResult(Executor.QUERY, Table.Task1Table::getAllData, safeEmptyList())
不用調(diào)整原先工程中對 Service 層和 Table 層的調(diào)用长捧，就可以將并發(fā)控制層插入，使用也很方便吻贿，安全性也都有保證串结。
總結(jié)
對于這些不是很好的祖?zhèn)鞔a，如果有機會我認為一定是要改一改舅列，一是對自己的提升肌割，二也是降低日后維護的成本，便于開發(fā)帐要，雖然可能帶來一些問題把敞，但是問題總是可以解決的。即使不能重構(gòu)榨惠，我覺得也可以在其上層封裝一層奋早，徹底屏蔽它的實現(xiàn)盛霎，日后的維護過程中就可以再也不用關(guān)心它了，并且有機會的時候也可以利用這層中轉(zhuǎn)的便利性直接把它替換掉耽装。
