MMS在Android Mms應用裡面的具體實現形式，或資料結構是SlideshowModel，它是一個每個節點為SlideModel的ArrayList，SlideModel是一個Model的List，也就是它可以接收任何Model的子類，Audio，Video，Image和Text都可以放到SlideModel上面。SlideModel主要用於管理其上面的各個媒體，比如它們的布局，它們的播放控制，而SlideshowModel主要用於管理所有的附件，比如把所有的附件轉化成為Android的MMS協議的資料類型Pdu，以及從Pdu轉化成為SlideshowModel。
Pdu是實現了MMS協議的標準格式，它可以直接的發送給MMSC，從MMSC取回來的也是一個Pdu格式的資料。應用程式層Mms不需要關心Pdu的具體實現方式，Android中有一個內部的包com.google.android.mms.*下面的類都是專門用於處理Android平台上的MMS。裡面提供了工作可以把應用程式層的資料，比如媒體檔案等，進行封裝成Pdu，再把Pdu分解成為媒體檔案。Pdu的資料結構包括PduBody，這個是用於存放多媒體檔案的地方，其裡面是PduPart的集合，每個PduPart代表一個檔案。PduPersister用於操作這些資料結構，包括寫入資料庫，從資料庫中讀取等。
SlideshowModel或俗稱投影片是應用程式層的MMS的實現形式，或者它是應用程式層MMS用來建立，編輯，顯示和管理多媒體的一個資料結構。建立和發送MMS的時候，就是建立一個SlideshowModel，構建MediaModel，TextModel等加入到SlideshowModel中。在發送時，SlideshowModel會把其內的媒體檔案取出來，轉化為PduPart放入PduBody中。收到資訊後從PduBody中取出PduPart，還原成媒體檔案，產生MediaModel，加入到SlideshowModel中，也就是還原為投影片。應用拿到投影片後可以做顯示和播放。
關於附件類型，Mms應用中所有的MMS都有一個投影片，其內含有所有的附件檔案。但是Mms做了一些特殊的處理，對於一個MMS資訊，它的附件類型分為IMAGE, AUDIO, VIDEO,和SLIDESHOW，這些從添加附件對話方塊的列表中可以看出，而且展現方式也有所不同。但是實際的實現上面並沒有這麼多的類型，只有一個SlideshowModel，所有的附件都在裡面。它處理的規則是這樣的，如果只添加了一個媒體(image, audio和video)時，會把類型設定為相應的媒體類型，而只有在附件對話方塊中明確選擇添加投影片時並且添加了多張投影片後，附件類型才會是投影片。這個附件類型只在給MMS添加附件時和發送MMS前有效，主要用於在訊息列表中如何展示媒體檔案，如果是具體媒體類型，就直接顯示，否則顯示為投影片，這個附件類型僅存在於應用中顯示媒體所用，並不會在發送出去的Pdu中有痕迹。當收到MMS後，也是根據轉化後的SlideshowModel裡面的內容來推測出附件類型，然後再做顯示。所以，對於一個MMS來說它始終都有一個SlideshowModel，使用者所感受到的附件類型僅是附件媒體顯示上面的一個處理而已。
與傳統手機不同，建立MMS並不需要特殊的方式。因為Mms應用對MMS和SMS並不做嚴格的區分，而是以統一的對話中的一個訊息來對待，所以MMS與SMS的區別也很簡單，就看一個訊息中只否有附件(WorkingMessage.hasAttachment())。建立MMS也十分簡單，只需點擊Composer而的Attach菜單添加媒體即可。在列表中選擇image, audio和video後就只有一個媒體檔案，都會跑到其他的Activity去選擇檔案，然後會返回其Uri給Composer，Composer會調用WorkingMessage.setAttachment()來做具體的添加，用Uri建立MediaModel然後加入到SlideshowModel中，並設定類型。另外，如果選擇了Attach投影片，就會直接進入編輯投影片的而面，可以添加刪除投影片頁，給投影片頁加媒體檔案，設定布局等，之後Composer會把SlideshowModel顯示出來，此時的附件類型也是SLIDESHOW，這些都是通過WorkingMessage.load()來完成的。
WorkingMessage在把媒體加到投影片裡以後，就會回調一個介面 onAttachmentChanged()，Composer實現了此介面，這個介面主要用於通知Composer附件已發生變化，重新整理UI以正確顯示附件。Composer會建立AttachmentEditor來顯示附件的內容，因為所有的附件都放在Slideshow裡面這個Slideshow在WorkingMessage中，可以通過WorkingMessage.getSlideshow()來擷取。AttachmentEditor會根據Slideshow裡面的內容來建立不同的View以展示不同的附件，如果Slideshow中只有一個Video，Audio或Image，就直接建立VideoAttachmentView，AudioAttachmentView或ImageAttachmentView，而對於投影片中頁數大於1時就會建立SlideshowAttachmentView。還有相應的按扭可以用來編輯，替換或刪除，對於單個媒體有查看/播放，選擇後可以查看原圖和播放音頻視頻，替換可以重新重選擇一個附件，刪除會移除掉附件；對於Slideshow有編輯和刪除，編輯會直接進入投影片的編輯頁面，那裡可以一頁一頁的對每頁投影片進行詳細的編輯，刪除會移除掉附件。
編輯完附件後有三種處理方式，一個是發送資訊，一個是儲存為草稿另一個就是放棄資訊。發送資訊和儲存草稿都會對投影片進行打包，轉成Pdu，並儲存到資料庫，之後的投影片都需要從資料庫載入並把Pdu解包成為SlidehshowModel。
要發送資訊前，或是儲存草稿時，都需要把SlideshowModel進行打包產生Pdu格式，並儲存至資料庫。這個稱為MMS的打包（Packaging），是由SlideshowModel.makePduBody()方法來完成，它會把投影片裡面的內容一個一個的取出來，轉成一個PduPart，再 放入PduBody中，以產生PduBody，一個媒體對應一個PduPart，同時還可以設定PduPart的屬性以描述媒體的檔案，比如ContentType，這是一個用於標識媒體MIME類型的字串；Filename檔案的名字；
ContentLocation檔案的路徑。這些資訊都用於描述PduPart中資料的元資訊（MetaData），也就是資料具體是什麼，以便讓解包的時候對資料進行正確的處理。
之後PduPersister會通過其persist()方法把PduBody存入到資料庫中，它會把PduPart中的描述性資訊作資料庫欄位寫入，把檔案儲存體在TelephonyProvider檔案夾下面(/data/data/android.providers.telephony/app_parts)，並把儲存後的路徑作為_data欄位寫入資料庫，這樣一條MMS的資料就都寫入了資料庫中。這以後，MMS的資料都是從資料庫中載入，所以原SlideshowModel中的資料庫不再有效，如Uri在原SlideshowModel中可能指向一個檔案，或是其他資料庫，在PduPersister.persist()之後就不再有效了。
當PduPersister.persist()之後，MMS的附件就都從資料中載入，PduPersister.load()會從資料庫把資料載入成為一個PduBody，SlideshowModel的方法createFromPduBody()就是用於把PduBody轉化成為一個SlideshowModel，從PduPart取出媒體資訊以得到正確的媒體格式，和相關資訊，可以通過Uri來擷取具體檔案（流）。
接收到的MMS過程也差不多當NotificationTransaction或RetrieveTransaction用HttpUtils從MMSC擷取到MMS資料後會用PduParser來解析資料產生Pdu，再用PduPersister.persist()把其寫入資料庫，之後會再從資料庫中載入。
對於每條MMS還有一個很重要的資料就是SMIL語言，SMIL是同步多媒體整合語言的簡稱(Synchronized Multimedia Integration Language)，它與HTML文檔很類似，是W3C(World Wide Web Consortium)組織規定的多媒體操縱標準語言。MMS也是用它來管理和播放多媒體。來看一個具體的SMIL語言執行個體：
<smil xmlns="http://www.w3.org/2000/SMIL20/CR/Language"> <head> <layout> <root-layout width="360" height="615"/> <region id="Image" width="347" height="260" top="14" left="7" fit="meet"/> <region id="Text" width="326" height="320" top="281" left="7" fit="scroll"/> </layout> </head> <body> <par dur="60s"> <img src="0.jpg" region="Image"/> <text src ="0.txt" region="Text"/> </par> <par dur="60s"> <text src ="1.txt" region="Text"/> </par> <par dur="60s"> <text src ="2.txt" region="Text"/> </par> <par dur="60s"> <text src ="3.txt" region="Text"/> </par> <par dur="60s"> <text src ="4.txt" region="Text"/> </par> </body></smil>
SMIL語言播放多媒體時通常是一頁頁的，與幻為播放十分類似，因為很多SMIL播放器都會做成投影片形式。因為MMS用SMIL來傳送多媒體，所以Mms終端應用都會以投影片的方式來播放MMS。這也就是為什麼Mms應用中會出來SlideshowModel的原因。投影片方式顯示多媒體訊息是一種常用的方法，即使某些終端應用沒有用投影片放映的方式顯示多媒體訊息，但是對於電訊廠商或多媒體訊息平台發出來多媒體訊息都有頁碼標識，另外其他的一些手機，比如非智能手機查看多媒體訊息的方式也是以投影片一頁一頁的放映。
它主要記載著用於投影片的布局資訊。這個SMIL語言就是用於投影片布局的，也就是說SMIL會像HTML文檔布局網頁那樣來說明如何布局投影片，它有這些TAG：head, layout, body, par，head是頭資訊，裡面有TAG layout用來說明這個投影片是如何布局的，具體的它用一些子TAG如root-layout, region等來說明投影片中的每一個元素如Image或Text如何布局。TAG body中列出了投影片的所有媒體元素和詳細內容，比如image, audio, text等，每一par是一頁，它的子TAG說明這一頁有哪些內容，當然SMIL語言還有很多內容可以參考Wikipedia上的講解。
當打包投影片時，也就是把SlideshowModel轉化為Pdu時，會根據SlideshowModel的內容產生一個SMIL語言，通過SmilHelper.getDocument()來產生SMIL文檔，把其加入到PduBody中並作為第一個PduPart，它的ContentType(MIME)是application/smil，它的內容就是SMIL文檔。需要注意的是SMIL文檔總是會在PduBody的第一個Part，並且它直接把文檔內容寫到PduPart中，而不是以檔案的形式存在。
當解包的時候，會先取出SMIL文檔，對其進行解析，產生投影片。
因為SMIL是一個標準的文檔，所以W3C有其相應的規範，也有相應的庫來解析和產生。在Mms應用中可以看到這樣的二個Package: org.w3c.dom.*和com.android.mms.dom.*;其中org.w3c.dom是SMIL語言的一些標準庫，而com.android.mms.dom.*;是對org.w3c.dom一些標準介面的實現，或者說是為了Mms應用而做的一些適配。那麼在com.android.mms.model.*裡面的一些類也是根據SMIL標準而寫的，比如SmilHelper就是專門用於解析SMIL文檔和產生SMIL文檔，當然它會用到前面提到的二個Package裡面的東西。還有如ImageModel，TextModel和RegionModel也都是基於SMIL標準的，比如它們分別
對應SMIL文檔中的標籤img, text和region。
當然，這都是具體的終端應用的實現，可能不同的應用會有不同的方式，但發送出去的和接收到的都應該是標準的Pdu，而SMIL文檔僅是一個其中一個PduPart而已。
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
