淺談設(shè)計模式在Android代碼重構(gòu)中的應(yīng)用

陳禹樵，隋 浩

（中移互聯(lián)網(wǎng)有限公司云產(chǎn)品事業(yè)部 廣東 廣州 510000）

1 引言

截至2021年2月，全球約70.46%的手機和平板搭載了Android操作系統(tǒng)，在Google Play商店中，可以下載到的Android應(yīng)用數(shù)量達(dá)到295萬個。為了獲得更多的用戶，Android應(yīng)用開發(fā)市場面臨著激烈的競爭。許多企業(yè)和開發(fā)者為了快速實現(xiàn)功能，忽視了架構(gòu)的設(shè)計，隨著版本的迭代，功能添加和修改，應(yīng)用越做越復(fù)雜，開發(fā)和維護(hù)的效率降低，應(yīng)用質(zhì)量也出現(xiàn)下滑。為了提升代碼的質(zhì)量，提高應(yīng)用的運行效率，代碼重構(gòu)成為開發(fā)者面臨的現(xiàn)實問題。本文從設(shè)計模式的角度出發(fā)，結(jié)合案例討論其在代碼重構(gòu)過程中的應(yīng)用。

2 代碼重構(gòu)

重構(gòu)是指在不改變軟件可觀察行為的前提下，對軟件內(nèi)部結(jié)構(gòu)進(jìn)行修改，使得軟件更容易理解，更容易修改[1]。在軟件開發(fā)的迭代過程中，基于以下因素，代碼重構(gòu)過程是必不可少的：（1）代碼架構(gòu)設(shè)計的不足；（2）軟件功能的疊加和修改；（3）開發(fā)技術(shù)的發(fā)展和進(jìn)步；（4）開發(fā)規(guī)范的執(zhí)行和變化。人們不可能實現(xiàn)一份適配所有變化的系統(tǒng)，保證后續(xù)的需求都不偏離最初的設(shè)計。代碼重構(gòu)是糾正這些偏離，實現(xiàn)架構(gòu)進(jìn)步的一種手段。

代碼重構(gòu)的主要目的包括：（1）優(yōu)化代碼結(jié)構(gòu)，降低軟件結(jié)構(gòu)的復(fù)雜性，使得代碼結(jié)構(gòu)清晰，閱讀、維護(hù)和拓展簡單；（2）提升軟件運行的效率，通過重構(gòu)簡化復(fù)雜的邏輯判斷、重復(fù)的執(zhí)行過程、過時的方法架構(gòu)，優(yōu)化速度；（3）提高軟件的健壯性，解決軟件迭代過程中積累的潛在問題；（4）控制代碼規(guī)范，統(tǒng)一不同人員的代碼風(fēng)格和習(xí)慣，適配行業(yè)和企業(yè)制定的規(guī)范等。

代碼重構(gòu)的主要方法有：（1）不良代碼的識別與監(jiān)測；（2）基于搜索的重構(gòu)方法；（3）基于UML模型的重構(gòu)方法；（4）基于代碼異味的重構(gòu)方法；（5）基于測試驅(qū)動的重構(gòu)方法；（6）自動化重構(gòu)工具[2]。

代碼重構(gòu)的時機選擇：（1）添加新功能時一并重構(gòu)；（2）修補錯誤時一并重構(gòu)；（3）代碼審查時進(jìn)行重構(gòu)；（4）代碼設(shè)計完全錯誤時，應(yīng)當(dāng)重寫；（5）重構(gòu)工作應(yīng)安排入主版本發(fā)布計劃，有序?qū)嵤?/p>

3 設(shè)計模式

設(shè)計模式是指經(jīng)過眾多的軟件開發(fā)人員在長期的開發(fā)工作中，總結(jié)出的解決軟件開發(fā)過程中面臨的一般性問題的模板化的設(shè)計方法。這些方法通常為了更簡單方便的改進(jìn)或者復(fù)用以往成功的設(shè)計和體系機構(gòu)，又能有效地處理需求的變更，某些模式可以減少類之間的耦合與依賴[3]。這些設(shè)計模式被軟件開發(fā)人員在后續(xù)的代碼設(shè)計過程中反復(fù)實踐和驗證。

Gamma等[4]于1995年出版的《設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書中收錄了23種設(shè)計模式。這些設(shè)計模式在 Java、C++、Object-C、Kotlin等多種面向?qū)ο蟮木幊陶Z言都得到了實現(xiàn)，成為不同語言共用的模板方式。近年來，在解決復(fù)雜的軟件架構(gòu)設(shè)計問題上，MVC、MVP、MVVM等設(shè)計模式在Android軟件開發(fā)過程中，也得到了廣泛的應(yīng)用。

將設(shè)計模式思想應(yīng)用于軟件重構(gòu)中，可以解決提升代碼復(fù)用率，降低代碼耦合度，使得代碼結(jié)構(gòu)更加清晰，進(jìn)而提高代碼的可維護(hù)性，提高軟件健壯性、擴(kuò)展性和規(guī)范化。

4 設(shè)計模式在Android代碼重構(gòu)中的應(yīng)用

不同的設(shè)計模式面向解決不同場景下的設(shè)計問題。在軟件重構(gòu)過程中，應(yīng)當(dāng)根據(jù)問題選擇最優(yōu)的設(shè)計模式，保證重構(gòu)效果。在Android應(yīng)用開發(fā)和Android系統(tǒng)源碼中，常用的設(shè)計模式約有7～8種，這些設(shè)計模式有著不同的變體，但其基本思想是一致的。熟悉這些常用的設(shè)計模式，可以解決重構(gòu)過程中的大部分問題。下面將結(jié)合具體問題，討論5種常用設(shè)計模式在代碼重構(gòu)工作中的應(yīng)用。

4.1 單例模式

單例模式適合用于內(nèi)存常駐、信息配置、公用方法或者全局管理等職責(zé)單一的任務(wù)。例如：Android應(yīng)用經(jīng)常會使用到設(shè)備信息，作為運行設(shè)備的唯一標(biāo)識，對于設(shè)備信息的獲取和管理，在重構(gòu)過程中可以構(gòu)建DeviceInfo Manager單例對象，實現(xiàn)一次獲取，多次使用的目的。Android應(yīng)用開發(fā)常會用到多線程技術(shù)，對于子線程和線程池的管理，可以在重構(gòu)過程中構(gòu)建Common Executor單例對象，統(tǒng)一管理子線程數(shù)量，管控子線程的運行、同步和結(jié)束。需要注意的是，在單例對象實例化時，需要注意線程同步問題，可采用雙重鎖的方式，避免異步線程產(chǎn)生空指針異常。單例模式不利于擴(kuò)展，對象常常需要常駐內(nèi)存，因此也不可濫用。

4.2 觀察者模式

觀察者模式適用于消息通知和事件傳遞等場景，在Android源碼和一些優(yōu)秀的Android開源框架中，例如：ListView、RecyclerView、RxJava、OKHttp等，有著廣泛的應(yīng)用。近兩年發(fā)展的ViewModel、LiveData等框架也是由觀察者模式思想發(fā)展而來。在重構(gòu)過程中，可以應(yīng)用于以下場景，例如：Android應(yīng)用常會用到推送功能，在與服務(wù)端交互的過程中，新消息的到達(dá)會導(dǎo)致數(shù)據(jù)和狀態(tài)的改變。此類場景的重構(gòu)，可以用Observable定義消息數(shù)據(jù)的更新與處理，將視圖層定義為Observer，訂閱數(shù)據(jù)處理類，在數(shù)據(jù)處理后，通過Observer通知視圖的刷新，解耦數(shù)據(jù)與視圖代碼的耦合。

4.3 代理模式

在開發(fā)過程中，經(jīng)常會遇到這樣的場景：產(chǎn)品經(jīng)理要求在某些行為函數(shù)前加入功能、日志或者數(shù)據(jù)統(tǒng)計。在不改變現(xiàn)有設(shè)計的情況下，代理模式是一種友好的選擇。代理模式可以控制對象的間接訪問，修飾和操作對象的輸入輸出。例如：對于數(shù)據(jù)訪問的權(quán)限判斷重構(gòu)場景中，可以隱藏數(shù)據(jù)訪問類的visit方法，加入VisitorProxy類，在調(diào)用visit函數(shù)時，通過VisitorProxy類先調(diào)起權(quán)限判斷功能，根據(jù)其返回結(jié)果判斷是否繼續(xù)調(diào)用visit方法。這樣可以將權(quán)限判斷和數(shù)據(jù)訪問的代碼有效解耦，降低代碼混亂。

4.4 責(zé)任鏈模式

責(zé)任鏈模式的設(shè)計起源于工廠生產(chǎn)中的流水線思想，符合面向?qū)ο笤O(shè)計的單一職責(zé)原則。責(zé)任鏈模式的設(shè)計思路為：將一項任務(wù)分解成多個子任務(wù)步驟，對于子任務(wù)設(shè)計隔離開的接口和實現(xiàn)，再將子任務(wù)銜接成完整的任務(wù)流水。責(zé)任鏈模式在開源框架Glide、OKHttp、Gson中都得到了應(yīng)用。例如：在郵箱應(yīng)用中，新郵件數(shù)據(jù)的同步和顯示，該過程包括：新郵件通知→同步郵件頭→解析郵件頭→解析郵件結(jié)構(gòu)→存儲郵件結(jié)構(gòu)→刷新郵件列表→下載郵件正文→存儲郵件正文→下載郵件附件→存儲郵件附件，在重構(gòu)過程中，可以選用責(zé)任鏈模式來實現(xiàn)。將以上過程抽象成Chain，每個階段的任務(wù)實現(xiàn)Chain中的process方法，并指定下一階段任務(wù)，依次傳遞，直到郵件同步和顯示任務(wù)處理完畢。

4.5 工廠模式

工廠模式可以歸為三類：簡單工廠模式、工廠方法模式和抽象工廠模式。簡單工廠模式通常以靜態(tài)代碼的形式，預(yù)先定義“工廠類”所能生成的“產(chǎn)品類”。工廠方法模式實現(xiàn)了對工廠角色的抽象，定義包含必須的工廠行為的接口類，在生產(chǎn)具體產(chǎn)品時，定義實現(xiàn)抽象工廠接口的具體工廠來實現(xiàn)，提高了對于產(chǎn)品生產(chǎn)行為的拓展性。抽象工廠模式，不僅工廠角色是抽象的，產(chǎn)品角色也是抽象的，適用于產(chǎn)品屬性未產(chǎn)生本質(zhì)變化的生產(chǎn)行為。例如：對于圖像的處理工作的重構(gòu)。圖像處理包括色調(diào)、飽和度、亮度、大小、旋轉(zhuǎn)等操作，這些行為可定義為抽象的Abstract Image Process Fatory，根據(jù)具體操作實現(xiàn)為Tone Process Fatory、Saturation Fatory、Brightness Fatory、Size Factory、Rotate Factory。其中Tone Process Fatory用于實例化具體的Abstract Tone Effect類。色調(diào)可能有暖色調(diào)、冷色調(diào)、懷舊效果等不同的需求，但其有著共同的抽象方法，可以定義繼承Abstract Tone Effect實現(xiàn)具體的處理邏輯。

關(guān)于Android應(yīng)用重構(gòu)過程中設(shè)計模式的選擇，應(yīng)該充分考慮軟件設(shè)計和開發(fā)過程中可能會發(fā)生的潛在變化因素，考慮實現(xiàn)設(shè)計模式對軟件運行和架構(gòu)產(chǎn)生的負(fù)擔(dān)，衡量應(yīng)用該設(shè)計模式所帶來的價值與成本負(fù)擔(dān)。其基本過程如下：（1）理解任務(wù)需求，保證產(chǎn)品需求和功能表象不發(fā)生本質(zhì)變化；（2）梳理現(xiàn)有代碼的基本框架，列出其需要重構(gòu)的原因；（3）研究當(dāng)前任務(wù)未來可能發(fā)生變化和添加的潛在需求；（4）匹配任務(wù)屬性及潛在需求與設(shè)計模式的匹配度；（5）衡量使用設(shè)計模式修改代碼的效率成本和時間成本；（6）安排分工，使用設(shè)計模式重構(gòu)現(xiàn)有代碼；（7）將重構(gòu)后的代碼使用在部分模塊，通過測試比較其于重構(gòu)前的運行差異；（8）完善重構(gòu)代碼的不足；（9）將重構(gòu)后的代碼全量應(yīng)用，移除舊代碼；（10）測試及上線。

5 結(jié)語

隨著Android應(yīng)用日益激烈的競爭，代碼重構(gòu)成為了提高其軟件質(zhì)量、可維護(hù)性、可復(fù)用性、保證軟件開發(fā)可持續(xù)發(fā)展的重要手段。本文從設(shè)計模式角度出發(fā)，探討了設(shè)計模式與代碼重構(gòu)目的的一致性，以及其在Android代碼重構(gòu)方面的應(yīng)用。代碼重構(gòu)和框架設(shè)計是彼此互補又相互聯(lián)系的環(huán)節(jié)，在軟件設(shè)計、開發(fā)及維護(hù)階段，都有必要借助科學(xué)合理的設(shè)計模式，以提升代碼的質(zhì)量，進(jìn)而加強應(yīng)用的競爭力。