z 服務發佈的時間間距：依據服務的 memory 大小，需多久的發佈時間，去制 定發佈的時間間距。
z 回應時間：使用者選擇的服務，最快能在多久的時間獲得回應，獲得 5 次取 平均值當作回應時間。
z 壓縮比：當服務壓縮時，服務 memory 縮減了多少比例，就是服務的壓縮比。
z 壓縮和解壓縮時間：壓縮所花的時間，和接收壓縮資料去解壓縮的時間。
5.2 記憶體的分配和釋放
開發 J2ME 的程式時，最容易遇見 Out Of Memory 的問題，所以在這先說明 J2ME 上的記憶體(memory)相關設定、再探討系統上記憶體的分配與記憶體的釋 放。MIDP 設備的記憶體分為三種，「程式記憶體」(Program Memory)、「堆疊 記憶體」(Heap Memory)、「持久儲存記憶體」(Persistent Storage Memory) 。Program Memory 是移動資訊設備分配給 MIDlet suite 的空間；Heap memory 用來儲存程 序和本地端變數的記憶體大小為 1945.4kb；而 Persistent Storage Memory 通常用 來保存設定檔，只有 32kb 的大小，實現了手機上持久儲存的能力，RMS 是其範 例。然而，MIDP 開啟圖片時，會產生的 MIDP 內存量為寬 * 高 * 畫素 (pixel) (bytes)，Pixels 值跟行動裝置型號有關係，所以要有效減少圖片的內存量，就是 降低圖片的寬 * 高。圖片常因為內存量大於 Heap Memory，而遇到 Out Of Memory 問題，可以去更改預定的記憶體容量，以符合行動裝置越來越高的性能。
本篇系統執行分享功能時，行動裝置端記憶體使用分配為：
1. MIDP_Code：MIDP 程式碼的長度。
2. RMS 的紀錄：紀錄在 RMS 上的紀錄，例如：中繼同儕點的設定等。
3. 發佈的服務：行動裝置上提供和分享的服務。
4. 選擇的服務：使用者選擇其他人所發佈的服務。
5. 服務的執行：服務的執行時所花費的 memory 容量。
本篇系統中，當分享的服務是佔用比較大量的記憶體時，預設的 Heap Memory 經常會不夠大，例如：圖片，服務在上面的選項 3、4 和 5 會重複佔用 大量的 Heap Memory，經由評估過後，服務的記憶體最大可以是 500kb 左右。
本篇系統中，記憶體的釋放分為行動裝置的 MIDP 記憶體釋放和中繼同儕點 的中繼訊息記憶體釋放。行動裝置的 MIDP 記憶體釋放，是當開啟檔案或是繪製 圖案(Canvas)時，會隨著執行的結束把暫時的記憶體釋放；中繼同儕點的中繼訊 息記憶體釋放，是當中繼同儕點上的訊息已滿時，會開始丟棄已經使用過的訊 息，或是中繼點忙著傳送訊息時，新進來的信差(Messenger)會被關閉，並把訊息 丟到一個輸出緩衝器(Output Buffer)，等到 Output Buffer 滿了或是一段時間後，
就會把訊息中繼至中繼同儕點。但是，中繼同儕點上的中繼訊息，如果來不及釋 放，Output Buffer 就會產生阻塞(Block)的現象，此管道新進的訊息就會一直被丟 棄，導致輪詢回應時間大於 10 分鐘，系統的效能會降低許多，如圖 5.1 所示。
5.3 單機模擬網路環境
阻塞的現象，如圖 5.1 所示，Small 的藍色折線是代表 58.2kb 的資料大小，
關係為發佈的次數和第一次輪詢到服務的回應時間，而 Large 的紅色折線是資料 較大的服務，資料大小為 320.6kb，從圖中得知 Small 折線一定能輪詢的到發佈 的服務，而 Large 的折線在次數 8 的時候，會產生阻塞的現象。
圖 5.1 中繼同儕點的阻塞
為了預防中繼同儕點上管道發生阻塞的現象，拉長服務發佈的時間間距，讓 Output Buffer 有足夠的空間釋放中繼訊息，使用者才能輪詢到分享的服務。經由 實驗分析後，得知發佈的服務記憶體大小每增加 100kb，服務發佈的時間間距就 要增加 1 秒左右，呈現正比的關係，如圖 5.2 所示。服務越大使用者輪詢得到的 時間也越長，經由實驗分析後，服務大小和回應時間成正比，且 600kb 的服務在 8 秒左右就能分享完成，又得知 JXME 分享的網路速度快，服務大小和回應時間 的關係圖，如圖 5.3 所示
圖 5.2 服務每 100kb 大小拉長 1s 發佈時間間距，就能解決 Block 問題
圖 5.3 JXME 分享的網路速度，600kb 服務大小，8 秒左右完成
5.4 zlib 資料壓縮法
zlib 是提供資料壓縮之用的函式庫，此函式庫為自由軟體，而且另外提供了 Java 版本的 Jzlib，zlib 使用 DEFLATE 演算法 ，DEFLATE 是同時使用了 LZ77 演算法與霍夫曼編碼(Huffman Coding)的一個無失真壓縮演算法。zlib 是 PNG source code 官方的程式庫，幾乎只要是 PNG 相關的都會使用到 zlib，又 PNG 圖 片幾乎是 J2ME 平台上圖片格式的標準，所以 zlib 適合本篇系統的資料壓縮法。
zlib 壓縮的性能好壞可以分為兩種，服務記憶體壓縮比和壓縮與解壓縮時間 長短，當記憶體壓縮比越高，或壓縮和解壓縮時間越短，都會提昇壓縮的品質。
系統上的分析，服務記憶體的壓縮比，可以分為記憶體容量較小的文字服務和容 量較大的圖片服務，經由分析後得知，zlib 在服務很小時，產生的壓縮比只有 20%，直到服務的大小超過 4kb，就會維持 80%的高壓縮比，適合在有限頻寬的 無線網路環境下使用，文字服務和圖片服務的壓縮比圖，如圖 5.4 和圖 5.5 所示。
圖 5.4 文字服務大小和壓縮比的關係
圖 5.5 圖片服務大小和壓縮比的關係
系統上的分析，壓縮和解壓縮時間，一樣分為記憶體容量較小的文字服務和 容量較大的圖片服務，經由分析後得知，文字服務只有在小於 1kb 時，才會出現 壓縮時間大於解壓縮時間，並且，文字服務的壓縮和解壓縮時間短，跟沒有使用 zlib 所花費的時間差不多，服務較大的時候，壓縮和解壓縮時間就會拉長，會影 響系統上服務發佈的時間和系統整個效能，文字服務和圖片服務的壓縮和解壓縮 時間比圖，如圖 5.6 和圖 5.7 所示。
圖 5.6 文字服務 Size 與壓縮和解壓縮時間的關係
圖 5.7 圖片服務大小與壓縮和解壓縮時間的關係 5.5 多機模擬網路環境
在多機模擬網路環境下，發現輪詢到的服務順序並不是很固定，因為輪詢的 服務順序是，先輪詢離目前最近的尚未丟棄管道訊息，接著往後輪詢新進來的管 道訊息。每次獲得的回應時間，會根據目前時間和中繼點的中繼訊息順序，回應 時間會有時快有時慢，所以對回應時間取平均會比較公平。經由分析後，連結數 過多或是中繼訊息量過多，會讓中繼點忙著處理運算，連結 JXME 虛擬網路時
間會增加 5 秒，是影響回應時間最主要的原因，然而，服務的記憶體大小影響沒 那麼大，因為是在中繼點夠用的網路頻寬下取得中繼訊息，服務的大小和回應時 間關係圖，如圖 5.8 所示。
圖 5.8 多機模擬網路環境-服務大小和回應時間的關係
經由分析後，需要 zlib 資料壓縮的回應時間比沒壓縮的回應時間慢，因為要 花時間在資料壓縮上，但是 zlib 壓縮過的資料大大降低 80%，減少在網路上的傳 輸，適合頻寬較低的網路環境，所以依據不同的需求選擇 zlib 壓縮或是未壓縮的 方法，壓縮方法和未壓縮的方法服務的 Size 和回應時間關係圖，如圖 5.9 所示。
圖 5.9 多機模擬網路環境-壓縮和未壓縮的回應時間比較