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

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

• ITrainerController
• ITrainerModel
• IAudioFlow
• ITrainerView
• ITrainable
  

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

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

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

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

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

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

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

• SoundPool
  
• MediaPlayer
  

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

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

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

再談實(shí)現(xiàn)
說到實(shí)現(xiàn)其實(shí)這并不是最需要關(guān)注的內(nèi)容，因?yàn)樯厦嫣峁┝撕苋娴慕涌诙覀兊哪K又是使用的接口所以不管如何實(shí)現(xiàn)那些功能并不會對各個(gè)模塊之間產(chǎn)生大的影響除非功能實(shí)現(xiàn)與實(shí)際要求相差太多。這里我只詳細(xì)說一下音頻模塊的實(shí)現(xiàn)。

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

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

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

模塊整合
為減少依賴模塊之間的整合需提供管理或幫助類，新建TrainerHelper來創(chuàng)建模塊實(shí)現(xiàn)類其中包含一個(gè)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è)計(jì)與架構(gòu)能減少大量的工作時(shí)間，利用接口可讓開發(fā)人員更加注重功能上的實(shí)現(xiàn)同時(shí)隔離各個(gè)模塊之間的依賴。下次產(chǎn)品經(jīng)理再改需求或再整出個(gè)訓(xùn)練模式時(shí)咱也能從容應(yīng)對。

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

最新評論