【畢業(yè)學(xué)位論文】(Word原稿)基于Java技術(shù)的音頻播放軟件的設(shè)計與實現(xiàn)-電子信息科學(xué)與技術(shù)

1 畢 業(yè) 設(shè) 計 基于 術(shù)的音頻播放軟件的設(shè)計與實現(xiàn) 李鴻青 200730800113 指導(dǎo)教師 戴占海 講師 學(xué)院名稱 理學(xué)院 專業(yè)名稱 光信息科學(xué)與技術(shù) 論文提交日期 2011 年 4 月 論文答辯日期 年 月 答辯委員會主席 _ 評 閱 人 _ 2 摘 要 隨著計算機系統(tǒng)的日趨復(fù)雜，人們逐漸感覺到舊有軟件設(shè)計 體系的局限性。由此，對舊有軟件設(shè)計體系的變革也應(yīng)運而生。在面向過程的軟件設(shè)計方法中，人們漸漸感受到將系統(tǒng)模塊化這樣的設(shè)計方法可以讓系統(tǒng)更富有可用性、可伸縮性、可靠性、可維護性，從而在不斷變化的需求中獲得較為理想、較為適應(yīng)的解決方案。但是這顯然是不夠的，因為由面向過程的程序設(shè)計語言所帶來的局限性始終無法更大程度地解放人們的大腦，所以面向?qū)ο蟮木幊陶Z言開始誕生。 本文設(shè)計基于 E 平臺，使用 構(gòu)設(shè)計，以模塊化為設(shè)計指導(dǎo)。 本文設(shè)計的 放器主要由以下幾個模塊組 成： （ 1） 插件系統(tǒng) ： 主要包括對于整個系統(tǒng)的初始化，加載播放核心，加載插件，插件管理等功能。 （ 2） 日志記錄模塊：使用成熟的 決方案。 線程池：用于多線程操作時避免線程初始化 /銷毀等操作所帶來的高資源消耗。 （ 3） 播放核心 ： 使用 構(gòu)，實現(xiàn)基本的播放控制邏輯，實現(xiàn)對 持的接口 。 （ 4） 控制臺模塊 ： 簡單的控制臺程序，實現(xiàn)對播放器的控制，作為插件被插件系統(tǒng)加載。 （ 5） 塊 ： 簡單的 面，實現(xiàn)對播放控制的可視操作，作為插件被插件系統(tǒng)加載 。 本文 基于 臺 架設(shè)計并開發(fā)實現(xiàn)了音頻播放軟件的基本功能以及其插件系統(tǒng)。盡管這個音頻播放軟件還十分粗糙，還僅僅只是個原型。但這些不足以及沒有實現(xiàn)的功能都可以通過延續(xù)本文的設(shè)計思路，設(shè)計相關(guān)的插件來完善。 關(guān)鍵詞 頻播放 面向?qū)ο?面向接口編程 插件系統(tǒng) 3 目 錄 1 引言 . 5 軟件開發(fā)的困難 . 5 復(fù)雜性是軟件開發(fā)過程中所故有的特質(zhì) . 5 計算機表達能力的局限性 . 5 軟件開發(fā)困難的解決方法 . 5 面向?qū)ο蟮木幊谭椒?. 5 言 . 6 2 面向?qū)ο蟮能浖_發(fā) . 6 軟件需求 . 6 可行性分析 . 7 系統(tǒng)概要設(shè)計 . 8 使用技術(shù)簡介 . 9 采樣音頻 . 9 . 10 . 12 . 12 . 12 3 關(guān)鍵模塊設(shè)計 . 13 插件系統(tǒng) . 13 . 13 . 15 . 16 . 17 配置管理 器 . 18 日志記錄系統(tǒng) . 19 線程池 . 20 已實現(xiàn)插件 . 21 . 21 4 . 22 4 結(jié)論 . 22 致謝 . 24 參考文獻 . 25 . 26 5 1 引言 軟 件開發(fā)的困難 復(fù)雜性是軟件開發(fā)過程中所故有的特質(zhì) 1 在 70 年代，軟件系統(tǒng)已經(jīng)變得極其復(fù)雜，無論是開發(fā)還是維護都是一項成本高昂的工作。而隨著軟件系統(tǒng)的越來越龐大，其復(fù)雜度也以更大的比率增長著。 復(fù)雜度的提高，這就要求人們要有更好的管理方法、開發(fā)方法讓軟件開發(fā)變得更加可控。 計算機表達能力的局限性 軟件系統(tǒng)的開發(fā)本身就是在將人類大腦中的虛擬印象表達出來。而計算機系統(tǒng)與人類的溝通途徑就是通過各種各樣的編程語言來實現(xiàn)。通過編程語言這樣的媒介，人們可以把要實現(xiàn)的東西告訴計算機。這樣計算 機才知道怎么去做。 這就引出了一個問題，編程語言這種媒介在人們與計算機之間的溝通橋梁是否有效，是否高效？這就是計算機表達能力的局限性。而隨著時代在發(fā)展，計算機編程語言也在不斷進步。從一開始的二進制指令到匯編語言、從匯編語言到面向過程的編程語言、再到面向?qū)ο蟮木幊陶Z言。這一切都是在降低溝通的消耗。 而另一方面，人類大腦的想象力、創(chuàng)新能力是無窮的，但是計算機系統(tǒng)的能力確實有限的。如何在有限的能力里將無窮的可能給創(chuàng)造出來，這也是一門科學(xué)。 軟件開發(fā)困難的解決方法 軟件開發(fā)的困難一方面是軟件開發(fā)本身所具有 的復(fù)雜性。另一方面則是人們與計算機系統(tǒng)之間溝通工具的可用性及計算機系統(tǒng)本身能力的局限性。 而人們在面對這些問題的時候，很大程度上是通過改進編程語言與設(shè)計模式來解決的。而這種方式也可以歸納為：抽象。 將需要設(shè)計的系統(tǒng)進行抽象可以讓人們在人腦有限的控制力中盡可能的管理更多的變化。抽象可以從復(fù)雜的事物中抽象出共性和特性，使得事物更容易被管理。另一方面，抽象出共性和特性意味著事物可以被模塊化，以更合理的方式模塊化，實現(xiàn)更低的耦合性。人們都知道，低耦合對于軟件系統(tǒng)來說是十分有利的，這將使得軟件變得可靠，且更容易維護。 面向?qū)ο蟮木幊谭椒?2 面向?qū)ο蟪绦蛟O(shè)計（ 一種起源于六十年代，發(fā)展已6 經(jīng)將近三十年的程序設(shè)計思想。其自身理論已十分完善，并被多種面向?qū)ο蟪绦蛟O(shè)計語言（ 下簡稱 現(xiàn)。 面向?qū)ο蟪绦蛟O(shè)計就是在對于事物進行抽象。在面向?qū)ο蟮氖澜缋?，一切皆是對?。對象是對現(xiàn)實世界實體的模擬，由現(xiàn)實實體的過程或信息牲來定義。一個對象可被認(rèn)為是一個把數(shù)據(jù)（屬性）和程序（方法）封 裝在一起的實體，這個程序產(chǎn)生該對象的動作或?qū)λ邮艿降耐饨缧盘柕姆磻?yīng)。這些對象操作有時稱為方法。 面向?qū)ο蟮某绦蛟O(shè)計可以比面向過程的程序設(shè)計更好的表達物理世界中的實體，從而以一種更加適宜人們思考方式的方法來實現(xiàn)程序 。 言 由 司于 1995 年 5 月推出的 序設(shè)計語言和 現(xiàn)的 覽器（支持 示了 魅力：跨平臺、動態(tài)的 算。從此， 廣泛接受 并推動了 迅速發(fā)展，常用的瀏覽器現(xiàn)在均支持 。 一種簡單的，面向?qū)ο蟮?，分布式的，解釋型的，健壯安全的，結(jié)構(gòu)中立的，可移植的，性能優(yōu)異、多線程的動態(tài)語言 5。 言提供類、接口和繼承等原語。 掉了 C+中經(jīng)常令人費解的多重繼承，只支持類之間的單繼承，而以接口這種更加符合 想的方式來替代多繼承。 言全面支持動態(tài)綁定，而 C+ 語言只對虛函數(shù)使用動態(tài)綁定。另外，與其他編程語言不同的是， 言內(nèi)置支持多線程，并且對網(wǎng)絡(luò)的支持非常的完善 ，這使得類似分布式計算這樣的場景在 言中更加容易實現(xiàn) 6?？傊?言是一個純的面向?qū)ο蟪绦蛟O(shè)計語言。 2 面向?qū)ο蟮能浖_發(fā) 本文利用面向?qū)ο蟮能浖_發(fā)方法來設(shè)計開發(fā)一個簡單的音頻播放軟件。 本音頻播放系統(tǒng)采用 言作為開發(fā)編程語言。系統(tǒng)基于 用 為日志記錄模塊，實現(xiàn)了基本播放控制邏輯與一個基本的插件系統(tǒng)。 軟件需求 7 每一個軟件項目的開始都是因為需求。只有先確定了需求，才能在接下來的設(shè)計、實現(xiàn)階段能夠?qū)ο到y(tǒng)有 個明確的認(rèn)識。 7 本系統(tǒng)的需求如下。 表 1 音頻播放系統(tǒng)需求列表 序號 輸入 輸出 實現(xiàn)優(yōu)先級 1 音頻文件 音樂 必須，最高 2 無 插件系統(tǒng) 必須，最高 3 歌詞文件 歌詞顯示 必須，中 4 音頻文件 歌詞聯(lián)網(wǎng)查找 必須，中 5 音頻文件 列表管理 必須，中 6 音頻流 音頻控制與調(diào)整 必須，高 7 所有相關(guān)模塊 日志系統(tǒng) 必須，高 8 多種音頻文件 音樂 可選，中 9 無 皮膚系統(tǒng) 可選，中 10 歌詞文件 歌詞編輯 可選，中 11 音頻文件 格式轉(zhuǎn)換 可選，低 可行性分析 需求是項目開始的原動力，但這并不意味著項目便會開始。因為這涉及到項目是否具有可行性。可行性包含多個方面，而同時會有多個元素會影響到。比如說時間、經(jīng)濟允許度等等因素的影響。 首先從需求實現(xiàn)的技術(shù)可行性上來分析。表格 1 所列出來的絕大多數(shù)需求都可以通過 言所提供的 架來實現(xiàn)，所以從技術(shù)上來說是可行的。但對于需求8 所提及的多種音頻格式支持這樣的需求，則是無法完全實現(xiàn)。比如說微軟的 式，因為微軟將 式閉源，且當(dāng)前尚未有人以純 方式實現(xiàn)從 獲得音頻流 ，所以對 件的播放支持是不現(xiàn)實的。 其次，從時間可行性上面來分析。因為本項目只是作為畢業(yè)設(shè)計時的程序示例之用，且作者并沒有很多的時間精力保持在該項目中，所以需求列表中優(yōu)先級在“高”以下的大部分功能都需要刪減。 8 系統(tǒng)概要設(shè)計 在可行性分析確定了項目所需要實現(xiàn)的功能后，就應(yīng)當(dāng)開始系統(tǒng)的設(shè)計階段。 軟件的模塊化給軟件開發(fā)帶來了很多的好處，所以本系統(tǒng)也將以模塊化的方式進行設(shè)計。其具體表現(xiàn)方式為：使用插件系統(tǒng)的方式現(xiàn)實各個功能模塊。 本系統(tǒng)借鑒 插件概念，通過 現(xiàn)播放器自 己的插件系統(tǒng)。通過插件系統(tǒng)，可以使得除了播放核心之外的所有東西全面插件化。比如說歌詞功能，開發(fā)者可以把歌詞功能封裝成一個插件，然后通過插件系統(tǒng)訪問到播放核心等系統(tǒng)資源來實現(xiàn)歌詞與播放同步的目的，同時也能很容易便改變歌詞功能的具體實現(xiàn)。通過這種方式，我們可以大大降低系統(tǒng)的耦合度，也可以提高系統(tǒng)的定制靈活性。 而因為本系統(tǒng)的核心功能為音頻播放和插件系統(tǒng)，所以抽象出來的實體就應(yīng)當(dāng)有代表播放核心的對象和代表插件系統(tǒng)的示例。在這里，其設(shè)計為類 類 圖 1 系統(tǒng)核心類圖 系統(tǒng)的核心類圖如圖 1 所示。通過該圖我們可以看到系統(tǒng)主要分為幾大模塊：9 系統(tǒng)用例圖則如圖 2 所示。 圖 2 系統(tǒng)用例圖 使用技術(shù)簡介 采樣音頻 對音頻而言，信號就是一段聲波。麥克風(fēng)把原始信號轉(zhuǎn)化為相關(guān)模擬電信號，然后換器把該模擬信號轉(zhuǎn)化為一種采樣的數(shù)字信號。圖 3 為一小段時間的聲音波形。 該圖在縱軸上畫出了聲波的幅度，水平軸為時間。該模擬聲波的 幅度在某個頻率下等間隔的被測量，最后形成的離散采樣點（圖中的紅色數(shù)據(jù)點）組成了數(shù)字音頻信號。圖中中間的水平線代表幅度為 0；線上的點為正值采樣點，線下的為負(fù)值。數(shù)字信號逼近某個模擬信號的精度取決于其在時間上的分辨率（采樣頻率）和其量化標(biāo)準(zhǔn)（幅度上的分辨率，每個采樣點用幾位數(shù)字來表示）。作為一個例子， 存儲的音頻數(shù)據(jù)是每秒采樣 44100 個點、用 16 位的數(shù)字來表示每個采樣點的數(shù)值。 “采樣音頻”（ 個術(shù)語在這里比較寬泛。一個聲波可以按照一個離散間隔來采樣但仍然保留其模擬信號的形式。 然而在 里，“采樣音頻”的意思就是“數(shù)字音頻”（ 特別需要注意的是，電腦上的采樣音頻來自于聲音錄制，但是相應(yīng)的聲音也可以由10 各種其他聲音信號合成的（例如合成一個撥號電話的聲音）?！安蓸右纛l”在這兒指的就是這種合成性的聲音，而不是原始的聲音信號。 圖 3 音頻采樣信號 一個小巧的低層 持?jǐn)?shù)字音頻和 據(jù)的記錄 /回放。在 之前， 一個 標(biāo)準(zhǔn)的 展 從 的 開始， 于 作系統(tǒng)、硬件平臺）的特點，基于 括本文的程序）能夠在任何實現(xiàn)了 更高版本的系統(tǒng)上運行，無須加裝任何支持軟件。 含在 中，分別用以處理數(shù)字音頻 含在 義了第三方實現(xiàn)的擴展接口。 音頻的輸入和輸出需要分別使用類 別代表了輸入和輸出的設(shè)備，它們都實現(xiàn)了 口。 口用來關(guān)閉 /打開設(shè)備、注冊事件監(jiān)聽器，以及提供一些用來調(diào)整聲音效果的對象，例如調(diào)整音量大小的對象。 系中起著一個工廠（ 的作用，提供了一系列的靜態(tài)方法，我們通過這些靜態(tài)方法來獲取 統(tǒng)默認(rèn)配置的資源。它們之 間的關(guān)系如圖 4 所示。 在處理輸入音頻時，對于來自各種音頻輸入端口的信號，例如麥克風(fēng)、 放器、磁帶播放器等，可以在它們到達 前，利用混頻器控制輸入混頻，最后在11 程序中通過 得數(shù)字化的音頻輸入流。 圖 4 類關(guān)系圖 類似地，在處理輸出音頻時，混頻器用來對一系列來自 數(shù)據(jù)進行混頻處理，經(jīng)處理后的信號可輸出到各種輸出端口，例如揚聲器、耳機等。 如，我們可以從一個 件讀取內(nèi)容寫入到后再通過揚聲器輸出。 音頻數(shù)據(jù) 就是從 入或從 出的數(shù)據(jù)，必須符合音頻格式的標(biāo)準(zhǔn)。音頻數(shù)據(jù)的格式選項由 封裝，主要選項包括：編碼方式（可以是 沖編碼調(diào)制）、 ）、通道數(shù)量、取樣率、幀速率等。 而播放音頻數(shù)據(jù)的過程需要如下的 5 步。 （ 1）取得輸出設(shè)備信息 2） 取得輸出設(shè)備 3）打開輸出設(shè)備 12 （ 4）開始播放 ; （ 5）循環(huán)讀取 入源中的音頻數(shù)據(jù)，對于讀取到的數(shù)據(jù) 接寫入 象即可播出聲音了。 的 的是 單的說，就是一種服務(wù)提供規(guī)范。 在 言中 ，人們可以定義服務(wù)接口，即 后通過 言提供的服務(wù)加載機制加載所有符合這一服務(wù)接口的類來實現(xiàn)程序的擴展功能。打個比方，比如 言中的 ，在該包下定義了 口。該 口的作用即是實現(xiàn)字符集擴展功能。任何第三方的開發(fā)者均可以通過該 口實現(xiàn)自己的字符集擴展，從而支持任何新增的字符集。 同樣的， 言在很多地方也用到了 架，比如輸入方法框架 架 本處理庫 等。 縮寫，中文為 地調(diào)用。從 始， 準(zhǔn)成為 臺的一部分，它允許 碼和其他語言寫的代碼進行交互。 開始是為了本地已編譯語言，尤其是 C 和 C+而設(shè)計的，但是它并不妨礙你使用其他語言，只要調(diào)用約定受支持就可以了。 是 縮寫。 供一組 具類用于在運行期動態(tài)訪問系統(tǒng)本地庫（ 不需要編寫任何 碼。開發(fā)人員只要在一個 口中描述目標(biāo) 自動實現(xiàn) 口到 映射。 實現(xiàn)原理其實是通過 射機制獲得描述的接口信息，再根據(jù)該接口信息動態(tài)編譯出代理 樣的功能。換句話說，其底層實現(xiàn)依舊是 出現(xiàn)是為了解決多變成語言共開發(fā)的問題。因為標(biāo)準(zhǔn)的 庫可能不 支持你的程序所需的特性。或許你已經(jīng)有了一個用其他語言寫成的庫或程序，而你希望在 序中使用它。又或者你可能就需要用底層語言實現(xiàn)一個小型的時間敏感代碼，比如匯編，然后在你的 序中調(diào)用這些功能。而這些問題都涉及到如何在 言中使用其他編程語言。所以 出現(xiàn)可以說是必然的。 3 一個用于開發(fā) 用程序用戶界面的開發(fā)工具包。它以抽象窗口工具包（ 基礎(chǔ)使跨平臺應(yīng)用程序可以使用任何可插拔的外觀風(fēng)格。 發(fā)人員只用很少的代碼就可以利用 富、靈活的功能和模塊化組件來創(chuàng)建優(yōu)雅的用戶界面。 工具包中所有的包都是以 為名稱，例如 3 關(guān)鍵模塊設(shè)計 插件系統(tǒng) 插件系統(tǒng)是一個全局的核心，所以這里將其設(shè)計為單例，采用工程模式獲得其實例。 因為插件系統(tǒng)這一實例本身僅實現(xiàn)其作為一個插件系統(tǒng)所應(yīng)當(dāng)具有的功能：管理插件。所以本系統(tǒng)又設(shè)計了一個 代理類 作為曝露給插件的接口。 實現(xiàn)了一個插件系統(tǒng)所應(yīng)當(dāng)具有的基本功能，包括其工程模式接口、配置管理器接口、日志組件接口、播放核心接口、插件加載、插件管理等功能。 在 中可以通過 ; 這一工程方法獲得其單例。在這里加上 鍵字是為了避免多個插件在初始化時訪問 得單例時可能出現(xiàn)的多線程同步問題。獲得單例時會先判斷是否已存 在可用實例，若有則返回之。若無，那么新建一個實例并緩存起來。 新建一個實例時，插件系統(tǒng)首先會先初始化日志記錄模塊。然后開始加載配置管理器、播放核心實例等資源，并通過日志記錄模塊將信息記錄下來。當(dāng)資源都加載完畢后就會開始做插件加載操作。 而在插件本身看來，得到單例后便可以通過 法獲得播放核心引用、配置管理器 引用、日志記錄模塊 引用等多個很有用的工具。 同時，作為一個插件系統(tǒng)， 同樣提供了管理插件的接口。比如 該方法用于禁用插件 插件。 這個方法則用于啟用插件。 14 還提供了獲得啟用插件列表、禁用插件列表的接口。這樣任何獲得實例的插件都獲得其他已注冊插件的引用，從而實現(xiàn)插件之間的協(xié)同工作。 插件的加載機制采用 架，即 一接口的插件。在加載插件的代碼邏輯里，有這樣一段： ; /如果失敗的列表長度一直不變，那么表示有些插件根本無法初始化，表明應(yīng)當(dāng)完成插件加載工作了。 /因為第一次加載插件的失敗列表長度肯定為 0，所以加以判斷第一次 | = ) ; !) & !) , be ); ) ); ) ); 15 其中的啟用插件 函數(shù)定義為 != ) ); ; 在插件加載的該 段代碼里，解決了插件的依賴問題。這里通過一個死循環(huán)對插件進行加載，當(dāng)判斷條件（上一次加載完插件的失敗插件列表長度與這次的長度一致）為真時，那么退出該死循環(huán)。也就是說，當(dāng)剩余所有的插件因為依賴關(guān)系而一直無法被加載時，那么退出加載循環(huán)，完成加載工作。在這里，并不考慮循環(huán)依賴問題。 在這里也可以看得出插件本身也是單例的，該單例由 成，在線程池中由始化。并由插件系統(tǒng)統(tǒng)一管理維護。 代理 例作為插件 持有的插件系統(tǒng)引用。 這么做的好處是，插件系統(tǒng) 需要完成其所必須完成的必須任務(wù)即可，16 而不用管對插件訪問插件系統(tǒng)的鑒權(quán)等額外的行為。當(dāng)插件系統(tǒng)初始化一個插件時，插件系統(tǒng)將同時生成一個擁有自身引用的代理 這一代理授予插件。這一意義就可以把可以分離的業(yè)務(wù)邏輯從插件系統(tǒng)中分離開來，同時保障了插件系統(tǒng)不會失去對插件的約束控制。 插件系統(tǒng)生成代理 ， 先從程序目錄的 件中獲得信任插件列表，只有存在于信任插件列表的插件才能獲得禁用、啟用其他插件等高級功能。 同樣是整個插件系統(tǒng)的關(guān)鍵。所有繼承于 現(xiàn)其定義接口的子類都可以被插件系統(tǒng) 加載。因為是 口，所以按照 言的慣例將其歸入 下面。 因為插件接口需要提供給插件本身一些系統(tǒng)資源，但又不希望這些資源引用可以在插件中修改，所以這里將插件接口 計為抽象類。該抽象類在構(gòu)造時由插件系統(tǒng)賦予插件系統(tǒng)的代理引用。 插件接口定義了一個插件所應(yīng)當(dāng)具有的一系列行為和屬性。 插件初始化 /開啟 /禁用等事件接口、插件服務(wù)方法 /銷毀方法等行為。 ; ; ; ; ; 插件名稱、插件類型、插件描述、插件依賴等屬性。 ; ; ; ; 同時插件接口提供給插件一個只讀的插件系統(tǒng)代理引用，插件可以通過這個引用獲得插件系統(tǒng)提供的資 源，比如播放核心、日志組件、配置管理器等等。 ; 17 因為插件可能具有依賴關(guān)系，所以這里定義了一個抽象接口 ; 所有插件都應(yīng)提供其所依賴其他插件的 樣插件系統(tǒng)才能有序的初始化各個插件。 樣設(shè)計為單例 。 播放核心至少需要提供一系 列的 、 等等方法來支持播放的控制和調(diào)節(jié)。 同時還需要提供對播放核心當(dāng)前狀態(tài)的描述接口，這樣插件便可以通過該接口獲得播放核心的相關(guān)狀態(tài)。 除此之外，播放核心還應(yīng)當(dāng)支持事件監(jiān)聽機制。只有完整的事件監(jiān)聽機制才能使多線程的插件結(jié)構(gòu)能夠以更合理的方式來實現(xiàn)相關(guān)功能。即基于事件驅(qū)動模型。 基于事件驅(qū)動在 到打印驅(qū)動庫 其中都有事件監(jiān)聽機制?？梢哉f，在多線程響應(yīng)中，事件監(jiān)聽機制是一個非常不錯的選擇 。 所以，這里 放事件放事件監(jiān)聽器接口 件可以在播放核心中注冊監(jiān)聽器來監(jiān)聽播放事件的發(fā)生。 如 些狀態(tài)描述了播放器可能存在的播放狀態(tài)，即停止、需停止、開始、暫停、繼續(xù)、播放中、跳轉(zhuǎn)、跳轉(zhuǎn)完畢、出錯。 的狀態(tài)呈現(xiàn)于播放事件 其方法原型為 其中第二個參數(shù)即播放狀態(tài)，而第一個參數(shù)則為當(dāng)前的播放位置，以毫秒計。 這樣就是說每個播放事件會告訴監(jiān)聽者事件的類型以及事件發(fā)生時播放器的當(dāng)前播放位置。 顯然，事件監(jiān)聽者需要實現(xiàn) 接口只提供一個方法，即 發(fā)生事 件時，事件處理機制會通過該接口告訴監(jiān)聽者所發(fā)生18 的時間 另一方面，我們知道事件觸發(fā)后的分發(fā)可能會有堵塞。也就是說監(jiān)聽者本身可能會因為某些運行時異常而堵塞 方法，從而影響到其他插件對于事件的接受。所以這里事件的分發(fā)以新線程的方法來分發(fā)。即通過本系統(tǒng)定義的 關(guān)代碼如后文所示。 ); 配置管理器 在本設(shè)計中，配置管理器作為系統(tǒng)的配置保存器，通過與插件系統(tǒng) 定來確保其唯一性。 配置管理提供了 等方法作為配置管理接口，每個對象可以將自己傳遞給配置管理器來獲得上次保存著的配置。 另外，本配置管理器還定義了若干使用方法，包括 這些方法的主要功能是將所有的配置保持到流和文件。 配置管理器中還維護著一個 定時保存配置，維護數(shù)據(jù)的持久性。但是我們知道， 一個程序可能會非正常終止，所以這里注冊了 閉鉤子來保證程序被非正常終止時能夠保證數(shù)據(jù)的完整性。 閉鉤子是 帶來的新特性。即當(dāng) 要求終止時，會通知這一鉤19 子，從而允許 序可以在非正常關(guān)閉時進行額外操作。該鉤子通過 添加。 因為該關(guān)閉鉤子只是屬于配置管理器的內(nèi)部處理機制，所以就以內(nèi)部私有類的方式定義該鉤子。其代碼為 ; 日志記錄系統(tǒng) 在軟件開發(fā)中，日志記錄系統(tǒng)是十分重要的一環(huán)。一個好的日志記錄系統(tǒng)可以幫助人們監(jiān)視系統(tǒng)是否運行正常，甚至于快速定位故障原因。 在本設(shè)計前期，原 本的設(shè)計是使用 來就有的 是最終發(fā)現(xiàn)這個日志記錄系統(tǒng)確實不夠完善，不利于系統(tǒng)擴展和靈活控制。所以后期將其替代為 件。 一個開放源代碼項目，通過使用 們可以控制日志信息輸送的目的地是控制臺、文件、 件、甚至是套接口服務(wù)器、 事件記錄器、護進程等；我們也可以控制每一條日志的輸出格式；通過定義每一條日志信息的級別，我們能夠更加細(xì)致地控制日志的生成過程。最令人感興趣的就是，這 些可以通過一個配置文件來靈活地進行配置，而不需要修改應(yīng)用的代碼。 在 ，只需要如下配置便可以將日志記錄到文件 ，且實現(xiàn)日增日志獨立文件命名保存。 =%t %C.%M(%L) -