開發(fā)背景
最近是在做一個與健身相關(guān)的APP，里面有訓(xùn)練器模塊基本功能是按照特點動作的演示和描述來引導(dǎo)用戶完成訓(xùn)練。在第一個版本時由于沒接觸過些類項目與功能花了幾周的時間大概1500行代碼才完成這個功能，
當時雖然我已經(jīng)盡量讓代碼表現(xiàn)的清晰，但是可以想像到當一個Activity中包含這么多代碼是什么感覺。自己維護起來都難受。

先談設(shè)計
有了前一次設(shè)計經(jīng)驗此次開發(fā)使用MVP、模塊化、面向接口等概念，將整個訓(xùn)練器分為控制器、數(shù)據(jù)模型、音頻、視圖、可訓(xùn)練對象五個模塊分別用以下接口表示：

• ITrainerController
• ITrainerModel
• IAudioFlow
• ITrainerView
• ITrainable
  

去掉一些抽象類后接口圖如下：

設(shè)計以上接口后引入MVP概念使用ITrainerController做為Presenter，ITrainerModel做Model,ITrainerView做View下面介紹主要模塊。

控制器
可以用在MVC和MVP中這取決于用哪種開發(fā)模式，在我開發(fā)的項目控制器用來控制訓(xùn)練器的運行管理訓(xùn)練器的生命周期如訓(xùn)練、暫停、休息、完成等狀態(tài)協(xié)調(diào)ITrainerModel、ITrainerView、IAudioFlow等各個模塊。
在使用過程中控制器并不止一個這也是抽象出一個接口的原因，ITrainerController接口繼承IPresenter接口使其能做為Presenter使用。

數(shù)據(jù)模型
數(shù)據(jù)模型中包含大量的ITrainable對象，對內(nèi)組織數(shù)據(jù)對外提供數(shù)據(jù)支持。對數(shù)據(jù)的組織方式主要分兩種：

• 從本地數(shù)據(jù)庫
• 從網(wǎng)絡(luò)獲取

在訓(xùn)練器中可能是正常的訓(xùn)練或是一次訓(xùn)練測試而訓(xùn)練數(shù)據(jù)和測試數(shù)據(jù)又有一些差異但它們的數(shù)據(jù)都被當做ITrainable，測試數(shù)據(jù)是不需要保存的只需要從服務(wù)器拉取后按要求完成就行而訓(xùn)練是會產(chǎn)生本地記錄的。
針對不同數(shù)據(jù)組織方式提供不同的數(shù)據(jù)模型這是有必要的。

音頻
音頻比較多樣化像訓(xùn)練過程中包含動作名、時間、單位詞、提醒等音頻這些音頻都是分開的不同的音頻文件。Android主要有兩種實現(xiàn)方式：

• SoundPool
  
• MediaPlayer
  

首先說SoundPool優(yōu)點自然就是免去了加載、管理音頻等過程但是它并不適應(yīng)我們的訓(xùn)練器，主要原因是缺少準備、完成后的一些回調(diào)而在訓(xùn)練器運行過程中這些過程必不可少比如在播放完一段預(yù)備開始后音頻這時我們才能進行正式的訓(xùn)練。
最后是采用MediaPlayer，但是在使用過程又要考慮到音頻的集中管理與資源的釋放免不了多封裝一次。設(shè)計時我將全部音頻邏輯放在Android Service中Activity通過bind AudioService來使用音頻，將音頻邏輯放入AudioService這樣可以音頻完
全獨立起來使其能在后臺播放并且也可以提高進程優(yōu)先級。

在設(shè)計中AudioService僅僅播放與管理音頻和資源并不具備音頻播放的邏輯功能。由于不同的訓(xùn)練方式音頻的播放邏輯也有不同之處所以在此設(shè)計IAudioFlow接口來負責音頻邏輯。

訓(xùn)練視圖
Android常用Activity作為視圖，通過實現(xiàn)ITrainerView接口來完成訓(xùn)練視圖的顯示。視圖中不包含任何業(yè)務(wù)邏輯代碼。

再談實現(xiàn)
說到實現(xiàn)其實這并不是最需要關(guān)注的內(nèi)容，因為上面提供了很全面的接口而我們的模塊又是使用的接口所以不管如何實現(xiàn)那些功能并不會對各個模塊之間產(chǎn)生大的影響除非功能實現(xiàn)與實際要求相差太多。這里我只詳細說一下音頻模塊的實現(xiàn)。

音頻實現(xiàn)
音頻模塊又可分為音頻管理與音頻業(yè)務(wù)邏輯。音頻管理就是加載、播放、回收資源等功能，音頻業(yè)務(wù)邏輯主要處理在正確的狀態(tài)下應(yīng)該播放什么樣的音頻。將整個音頻管理模塊放在Android Service中與業(yè)務(wù)邏輯完全分離。音頻模塊涉及以下類與接口：

• AudioService: 音頻服務(wù)器繼承Android Service
• IAudioService: 音頻抽象接口包含播放、暫停等事件
• MediaPlayerHolder: 持有MediaPlayer管理MediaPlayer生命同期
• IAudioFlow: 為不同的訓(xùn)練內(nèi)容提供音頻邏輯
• AudioServiceImpl: 實現(xiàn)IAudioService
  

基本使用流程是首先通過綁定AudioService的onBind方法返回IAudioService的實現(xiàn)類供IAudioFlow使用，IAudioFlow持有IAudioService實現(xiàn)后加載訓(xùn)練音頻然后供ITrainerController使用。在AudioServiceImpl中會維持一個音頻優(yōu)化級隊列，
上面提到因為音頻都是不在一個文件中的所有需要在使用時將它們連接起來形成一段音頻。通過優(yōu)先級隊列結(jié)合MediaPlayer播放完成時回調(diào)可以將多個音頻組合在一起形成需要的音頻。由于音頻的播放越來越多MediaPlayer的回收利用特別重
要在AudioServiceImpl同樣也具備MediaPlayer的回收與利用功能。這個功能實現(xiàn)是通過MediaPlayerHolder來處理的，通過MediaPlayerHolder的靜態(tài)get方法獲取MediaPlayerHolder如果回收池中有空閑的MediaPlayerHolder則拿來用沒有時則
新建一個，同樣也在一個音頻播放完成后調(diào)用MediaPlayerHolder的recycle來進行回收利用。

模塊整合
為減少依賴模塊之間的整合需提供管理或幫助類，新建TrainerHelper來創(chuàng)建模塊實現(xiàn)類其中包含一個Mode枚舉來列舉訓(xùn)練模式。

public class TrainerHelper {

  public enum Mode{TEST, TRAINING, EXAM}

  private static Mode mode;

  public static void setMode(Mode m){
    mode = m;
  }

  public static ITrainerController createPresenter(ITrainerView view, Bundle createArgs){
    return new TrainerPresenter(view,createArgs);
  }

  public static ITrainerModel createTrainerModel(ITrainerController controller){
    return = new DefaultTrainerModel(bundle);;
  }

  public static IAudioFlow createTrainerAudioFlow(ITrainerController controller){
    return new DefaultAudioFlow(controller);
  }

}

總結(jié)
成功的設(shè)計與架構(gòu)能減少大量的工作時間，利用接口可讓開發(fā)人員更加注重功能上的實現(xiàn)同時隔離各個模塊之間的依賴。下次產(chǎn)品經(jīng)理再改需求或再整出個訓(xùn)練模式時咱也能從容應(yīng)對。

由于本人水平有限如有錯誤，請大家諒解。

最新評論