陈登吉教授.docx

陈登吉教授.docx

《陈登吉教授.docx》由会员分享，可在线阅读，更多相关《陈登吉教授.docx（14页珍藏版）》请在冰豆网上搜索。

陈登吉教授

MultimediaApplicaitiononMobilePhone

陳登吉教授

資訊工程系

分機54755

辦公室EC520

洪啟彰

8917084

資訊工程系四年級

巫祈賢

8917096

資訊工程系四年級

洪秉竹

8917076

資訊工程系四年級

引言

手機是現代人不可或缺的一項工具，而多媒體的應用程式在手機上更是明日之星。

在跨平台的考量之下，我們選擇用JAVA語言來實作。

「DigitalStudio」是以前學長的專題，能夠編輯互動式的網頁，並輸出到HTML格式；我們的應用程式就是修改「DigitalStudio」，使其輸出到Java格式，再編譯成手機上能夠執行的class檔。

由執行結果看來相當的成功，但因為解晰度的問題，在手機上看起來較不清晰，只能等待手機未來的發展了。

I.Introduction

在這一段中要介紹的是軟體的基本功能及背景，首先要介紹的當然是手機。

全台灣使用手機的人數越來越多，從以前的黑金剛，現在的GSM和GPRS，到未來的第三代行動電話。

大多數人使用手機以通話為主，但在第三代行動電話發展後，這個趨勢恐怕要改變了。

未來的手機將是多媒體的時代，內建相機、掌上型電腦、GlobalPositionSystem的手機已不再是夢想。

在這樣一個時代，手機應用程式的地位也水漲船高。

要在手機上寫程式，有很多種語言可以使用，如：

AssemblyLanguage、NativeC及JAVA。

在這些語言之中，我們選擇了JAVA，主要有兩個原因。

第一，是跨平台。

手機晶片數十種，我們沒有時間也沒有精力一家一家學，即使用NativeC也有移植性的問題。

第二，在2003年全球支援JAVA的手機已超過4億支，2006更可能突破11億支，支援性絕對沒問題。

雖然JAVA由於使用bytecode，效率一直令人失望，但是隨著未來手機的進步，這種效率的影響也會越來越小，想想Writeonce,RunEverywhere的好處，我們還是決定用JAVA。

JAVA在微型裝置上有專屬的版本，稱為J2ME（Java2Platform,MicroEdition），適用於行動電話或PDA等微型裝置。

MIDP定義了手機的基本性能，包含螢幕大小、記憶體大小、按鍵……等等特性，只要符合MIDP的手機，就能夠保證J2ME可以正常執行，因此我們的開發工具，使用Sun公司提供的J2MEWirelessToolkit。

現在越來越多人注意手機上的程式發展了，但是只處於發展階段，距離要進入商業市場還有一段距離。

而且JAVA手機普及度也不夠高，對消費者來說，仍算是貴族產品，因此在J2ME的領域很少參考資料，除了少數幾本中文書外，就是Sun網頁上的Toturial了。

“DigitalStudio”這套軟體，是以前學長的專題成果，用途是製作多媒體互動式的網頁。

DigitalStudio會將編輯好的網頁，輸出到Script中，再用Compiler技術寫了轉檔程式，將Script輸出到HTML網頁。

我們所要開發的程式，就是DigitalStudio的後端軟體，稱為WebView，這個程式能夠將Script檔案輸出到JAVA原始檔，再經過J2MEWirelessToolkit的編譯，就成為了能在手機上執行的class檔了。

WebView最大的突破，是在多媒體和互動性上。

DigitalStudio支援各種圖檔，包括AnimateGIF，這些GIF放到手機上同樣也要有動畫的功能，因此我們用好幾張PNG來模擬出GIF的動畫。

在音樂和音效上，我們使用了MIDP2.0的MultimediaAPI，能夠播放WAV和MID，但目前尚無手機支援到MIDP2.0。

在互動性上，我們模擬出了HyperLink的功能，讓手機上也能有瀏覽WWW的感覺。

因為J2ME算是較新的領域，我們的程式並沒有和其他同類型的軟體比較過。

但是在執行效率方面，我們在寫程式碼的時侯，非常注重新增物件之後的釋放，因此在記憶體使用效率上，也有著不俗的表現。

底下是我們的分工表：

A.DivisionofLabor

洪啟彰：

程式設計、資料收集、報告撰寫

巫祈賢：

資料收集、報告撰寫、問題討論

洪秉竹：

資料收集、報告撰寫、協助除錯

II.ProposedScheme

第二部分的主要內容是關於我們的研究過程，但是在介紹研究過程前，會先介紹一些我們在之後的文章會用到的名詞。

場景（Scene）：

一個網頁是由許多場景組成，簡單說一個場景就是一個子頁，但在製作場景時會留意不要超過一頁，這樣才不會有換頁的問題。

在實作中，每個場景繼承自Canvas，要切換場景，只需用Display.setCurrent（）來指定目前的Canvas就可切換。

演員（Actor）：

演員是一段文字、一張圖片，或其他類型的物件。

演員和一般物件不同處是演員可以設定互動功能，也就是超連結。

在實作中，關於演員物件的資訊定義在Actor中。

事件（Event）：

當演員被選擇並按下按鍵時，就發生了事件。

在實作中，事件在ketPressed方法中被處理。

1）MIDP背景

在MIDP中，關於顯示方面的class有兩個是我們會用到的，一個是Display，一個是Displayable。

Display代表目前螢幕的物件，因此只存在一個instant。

Displayable則是代表目前顯示的內容，只要用Display.setCurrent就可以在各個Displayable物件中切換。

Displayable物件有兩個subclass，一是Screen，適用於高階的畫面處理，二是Canvas，適合較低階的畫面處理，我們的程式就是用Canvas。

2）MIDlet的生命週期

每一個在手機上執行的程式，都必須繼承自MIDlet這個class，這個class定義好了手機程式的基本架構及生命周期。

程式由startApp（）開始，手機模擬器會呼叫startApp（）以啟動MIDlet，中途隨時可以呼叫pauseApp（）來暫停，最後則是由程式自己呼叫destoryApp（）來結束程式。

3）

程式架構

前面說過，不同的場景有不同的演員、背景、事件。

因此，我們將每個場景定義成一個不同的class，當然，一個class只會存在一個instant。

每個Scene都是extendDisplayable的class，在切換時只需要將場景指定給Display物件就行了。

下面是看起來的樣子：

publicclassWebViewerextendsMIDletimplementsCommandListener

{

privateDisplaydisplay;//Display物件只有一個instant

publicWebViewer（）{}//Constructor

publicvoidstartApp（）{//所有的MIDlet程式都由此開始

view=newsc000（display）;//把Display傳給page1

view.pthread.start（）;//開始執行Thread

display.setCurrent（第一個場景）;//切換場景

}

publicvoiddestroyApp（Booleanuncon）{}

publicvoidcommandAction（Commandc,Displayables）{}

}

4）演員部分

當初設法由PC上的網頁移到手機上時，最大的困難不在秀圖，而是動畫GIF和移動路徑的處理。

在PC上，DigitalStudio有提供移動路徑的功能，能使圖片照著提供好的路徑移動，如果是AnimateGIF，在移動的同時也會有動畫的效果。

但是在手機上，支援的圖形格式只有PNG，因此我們得用好幾張PNG來模擬AnimateGIF。

當AnimateGIF的問題解決後，還有一個問題就是如何移動？

如果用Thread來作，恐怕記憶體使用量會大增，因此我們用J2ME提供的一項記時工具：

TimerTask。

這個class有定時功能，能夠讓圖片每隔一段時間換一個位置，於是就解決了這個問題。

在演員的顯示方面，有兩個class來負責，一個是Actor，一個是AniImage。

每一張圖片都是一個ActorInstant，每一個Instant都包含了一個AniImageinstant。

下面是Actor及AniImage的程式碼：

publicclassAcotor

{

publicAniImageImg;//演員的image都存在裡面

publicintPath[];//演員的移動路徑

publicintLoop;//路徑要移動幾次

publicBooleanisEvent;//是否為一個事件處理

publicStringtype;//演員的型態

publicStringnextScene;//按下演員會跳到那一個場景

publicActor（）{}//constructor

publicBooleanisMovig（）{

}//演員的另一個重要的function，用以判斷目前是否正在演出

}

publicclassAniImageextendsTimerTask

{

privateCanvascanvas；//存取parent的canvas

publicImage[]images；//如果是AnimateGIF就會有很多張圖

intx,y,w,h；//定義image的座標、長、寬

publicAniImage（）{}

pulbicvoiddraw（Graphicsg）

{//畫出現在是哪一個imageframe}

publicvoidrun（）

{//TimerTask會定時的去執行此方塊，以達成動畫的效果}

}

5）場景部分

publicclassSc000extendsCanvasimplementsRunnable

{

privatePlayerbackgroundmusic;//背景音樂

privateDisplaydisplay;

privateTimertimer=newTimer（）;

privateVectorActorSpace=newVector（）;//儲存所有actor

publicThreadpthred;

publicSc000（）{}//constructor

publicvoidrun（）

{

while（）

{

//使演員根據路徑移動

repaint（）;

}

}

priavateImage[]loadFrames（Stringname,intframe_cnt）

{

//載入動畫圖片

}

privatevoidsetupActors（）

{

//設定所有演員，包括圖檔名稱、位置、路徑

//演員型態、演出次數、事件處理

//下步驟以達到定時去更新動畫圖

timer.schedule（actor.Img,1000,800）；

//最後把actor加入vector

ActorSpace.add（actor）;

}

publicvoidpaint（Graphicsg）{}//畫出所有演員

publicvoidkeyPressed（intkeyCode）

{

//事件的觸發處理，包括了切換場景、

//選擇演員、使用者跟演員的interactive

}

}

6）CodeGeneration

（圖1）Compiler流程圖

在了解了整個JAVA程式之後，這部要看的是如何產生這些JAVA程式，因為JAVA並不是我們自己寫的，而是設定好產生的方式，由DigitalStudio輸出成java，才compiler成class檔。

那麼為什麼DigitalStudio能夠輸出成HTML又能輸出成JAVA呢？

圖1就是DigitalStudio的原理，DigitalStudio利用Compiler的技術，在編輯完網頁後，儲存的並不是HTML，而是作為中繼檔的Script。

這個script的格式定義在lexer.l及parser.y之中，利用Flex及Bison兩項工具，產生yyparse（）這個函式，能夠解析ScriptFile成樹狀結構。

每次DigitalStudio開啟ScriptFile時，就能由這個樹狀結構輸出到各種想要的格式，例如JAVA、HTML、C、Perl等等，只是目前的功能只有HTML及JAVA。

7）

（圖2）演員的屬性解譯

演員顯示過程

在顯示每一個演員時，會parse演員的所有屬性，並依序處理這些屬性，如果是簡單的屬性像是name，就直接指定；如果是複雜的屬性像是position，就會處理座標，例如重新計算x、y之類的工作。

8）

（圖3）由場景讀入到顯示的流程

顯示過程

將以上部分綜合起來，就是圖3所顯示的流程。

讀入Story.ebp這個網頁的Script檔後，會parse成walkingtree。

Parse完Story後，會去尋找各場景的script（*.ebs），每個script都被parse成一棵tree，再由tree去找到各演員的function，最後才是呼叫各演員的function。

9）CompilerTools

9.1）Flex（FastLexicalAnalyzerGeneratorVersion）

Flex是由VernPaxson發展的lex，速度比原先的lex快，用途是將文字檔切成一個一個的token。

下面是Flex的定義格式，第一部分是定義一些公用變數及所需的資訊；第二部分rules可以用regularexpression定義Flex要分析那些token，當flex找到符合expression的token，就會執行相對應的動作；第三部分usercode是使用者自定的程式碼，用來處理token。

definition

%%

rules

%%

usercode

9.2）Bison（parsergenerator）

這是GNU寫出來取代yacc的parsergenerator，只要定義parsingtree，Bison就能夠分析文件，好像一棵tree一般。

一開始Cdeclaration的部分定義Ccode所需的include及常數；第二部分定義基本的token及這些token的優先權；第三部分grammerrules定義了tree的結構．由大到小如何解析；第四部分是重點，就是使用者如何處理這些解析出來的token。

DigitalStudio的parse就是用這套軟體產生的。

%{

Cdeclarations

%}

Bisondeclarations

%%

Grammarrules

%%

AdditionalCcode

10）ScriptFileDefinition

ScriptFile是儲存資料的重心，因此定義要越詳細越好，絕對不能有未定義的情況發生。

其中會有一個主要的scriptfile：

Story.ebp他定義了有哪些場景名稱，以下是一個例子：

"[Scenes]"

"00000001"="@Sc000"//場景名

"00000002"="@Sc797"

"00000003"="@Sc183"

"00000004"="@Sc010"

除了主要的scriptfile之外，每個場景都有它的scriptfile，它的檔名都是場景名加上".ebs"，定的內容就比較繁雜，因它包含了所有演員的所有必要資訊，底下是某場景中一段文字的範例：

[CAST]MCText

Begin

Name=Actor000

NowValue=0

Key=0

Position=22158127

Size=183180

Visible=1

DragMode=2

FontName="標楷體"

FontSize=36

FontStyle=100000255

//粗體斜體底線刪除線紅綠藍→代表藍色粗體

LineCount=3

Lines=

"小提琴"

"與"

"小天使"

ArtWordStyle=0

SegmentCount=1

Segment0=-1-1115""0

SegmentIndex=0

PlayWhenStart=0

End

11）

（圖4）輸出到JAVA的過程

事實上，在先前已經探討如何寫出j2me的code出來了，似乎只要把那些javacode寫到檔案中即可，但是我們面對的是另一個問題，因為原本那些scriptfile的definition是設計給dhtml來使用的，有些資訊必須要resize或重新計算得以求得，像是位置、路徑，此外圖形的size也必須重新更改，手機的螢幕不比電腦上的螢幕，而j2me的圖片通用格式均採用png圖檔，所以我們也就把所有非png圖檔格式轉成適合於手機上dimension的png圖檔，至於對那些像gif動畫圖檔，也得去分析切成好幾個png圖檔構成。

這些操作都得在codegeneration完成。

有些圖檔libraryBorlandC++Builder有提供，有些則套用opensourcelibrary去對圖形作修改。

III.Results

本段將提出執行的結果以及效能報告。

在結果方面，我們測試了好幾次，無論是音效、音樂，或是超連結都是一切正常，是一個功能正常的網頁瀏覽器。

在效能方面，由於我們沒有手機可以實地操作，因此我們只能就記憶體表現方面提出效能報告。

1）

（圖5）DigitalStudio的執行畫面

（圖6）在一般瀏覽器上觀看

DigitalStudio產生的網頁

在執行結果方面，圖5是DigitalStudio這套軟體的執行畫面，可以看到畫面上除了放物件，還可以為物件編輯移動的路徑。

圖6是用PC上的瀏覽器觀看DigitalStudio編輯後的成果。

圖7則是用模擬器來執行輸出後的class檔。

可以看的出來，和PC上的執行結果幾乎沒有差距，除了解析度較差之外。

（圖7）在手機摸擬器上執行

我們這裡用的模擬器是WTK2.0所提供的DefaultColorPhone。

2）

（圖8）記憶體不足的畫面

在執行效能方面，我們格外注重記憶體的使用效率。

在WTK2.0中有提供了Monitor的功能，可以監視記憶體的使用狀況。

圖8就是記憶體監視器的畫面，展示程式的記憶體使用狀。

況可以注意到記憶體的使用有數次劇烈的升高，那代表場景切換的時刻，因為開新場景需要配置許多物件，需要大量的記憶體，所以會增加。

那為什麼增加後不會減少呢?

因為要讓大家了解記憶體配置不當的嚴重性，特定寫了這個版本，把釋放記憶體的code都拿掉，結果只開了五次畫面就會導致記憶體的不足。

3）

（圖9）記憶體正常釋放的畫面

圖9是記憶體正常釋放的畫面，可以看到雖然每次開新場景都會增加使用量，但是GarbageCollection很快的將不要的記憶體釋放出來，因此使用量不會增加太多。

Conclusion/Discussion

在這將近一學年的專題實驗裡，我們做過很多的嚐試，從最初的手機上WMF、HP-GL向量圖檔支援，到現在的手機上多媒體的支援。

其中我們遇到蠻多的挫折，就以向量圖檔部分來說，當我們實作出手機上向量圖檔的支援時，才發現他執行的效果很差，光是圖檔下載及播放就要花掉將近一分鐘的時間！

後來經過大家一起討論，才決定依舊使用手機上原本就支援的png圖檔來呈現在個人pc上播放的各種圖檔而且使之不失真。

或許我們多走了很多冤枉路，但也因此，我們思考出把gif檔拆成好幾張png檔及紀錄其運動的軌跡，讓它能生動的在手機上表現出來；我們也用png圖檔的方式來取代原本pc上的文字，使其能不侷限於手機上僅有的三種字體大小；最重要的便是我們運用了lex、yacc的技術把學長之前script轉html的功能轉變成由script轉到J2ME檔，而這也是我們這次專題重點所在。

總之，我們學了很多，而這些正是再寶貴不過的經驗了！

在這次的專題中，我們為J2ME吃了好多苦頭，讓我們感覺到同樣是Java體系的語言，但由於放到手機上而變得很侷限，不管是函數庫的支援或字型、顏色等外觀的選擇都變少了，甚至礙於手機的不同，雖然有很多現行已經有在支援的技術，但是支援的程度卻往往因手機而異，這是讓我們感到比較挫折的部分！

明明就可以用的函式庫，我們卻只能眼巴巴的望著它而不敢用，只因怕在不同手機就無法表現出它的成效，這讓我們必須多花一點時間來設計與實作在大部分手機上都能運作的函數，這是多麼令人扼腕的一件事阿！

而另一樣限制的最大問題莫過於memory跟處理速度了，在模擬的過程中，一直出現outofmemory的現象。

因而必須仔細trace整個程式，alloc的resoucre最後一定要被釋放回去，否則memory一定會暴增，當中我們就去討論如何減少memory使用率的問題，使其達到最佳化，而效率又能提升。

但也因為這樣麻煩的經驗，使我們深深感受到，未來我們一定要訂定一個好的J2ME語言，讓它能在每隻手機上都能運作的很好，這樣才不會讓往後設計程式的人遭遇同樣的情形，而一再重複做著這樣既費時又費力的事情！

而這個專題未來還有很多延伸的空間，例如：

結合聲音、影像、及與使用者互動或是傳送e-card的功能，讓手機不只是通訊的工具，更能提供娛樂、生活資訊的功能，而這些可能就得依靠下一屆的學弟來完成了！

Reference

[1]江義華“JavaPhone完美經典”金禾資訊,2002

[2]P.J.DeitelandH.M.Deitel“JAVA:

HowToProgram3/e”PrenticeHallRegents,1999

[3]雷邵辰“BorlandC++5物件導向程式設計應用”松崗民86

[4]林俊杰“BorlandC++5.X視窗程式設計著OWL5.X實務篇”波全民85

[5]米川英樹“J2MEMIDP手機遊戲程式設計”博碩2003

[6]微型爪哇人“Java手機程式開發J2ME-CLDC/MIDP”學貫行銷2002

[7]Kay,DavidC.&Levine,JohnR.“Graphicsfileformats”New

York/Windcrest/McGraw-Hill1995

[8]李元泰“Windows字型.圖形檔案格式深入解析“儒林1996