ios電臺(tái)開(kāi)發(fā),ios 電臺(tái)

手機(jī)端ios和android瀏覽器 如何實(shí)現(xiàn)mms廣播電臺(tái)在線音頻播放？

從軟件的功能角度來(lái)講，Mms分為對(duì)話(huà)列表，消息列表，短信編輯，彩信編輯，短信顯示，彩信顯示和配置。

十余年的寧陽(yáng)網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營(yíng)銷(xiāo)的優(yōu)勢(shì)是能夠根據(jù)用戶(hù)設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整寧陽(yáng)建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“寧陽(yáng)網(wǎng)站設(shè)計(jì)”,“寧陽(yáng)網(wǎng)站推廣”以來(lái)，每個(gè)客戶(hù)項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

從實(shí)現(xiàn)的角度來(lái)看，它分為GUI展示層，發(fā)送/接收，彩信解析，彩信附件，信息數(shù)據(jù)等，這些分類(lèi)對(duì)應(yīng)著源碼中的各種包。

源碼導(dǎo)航

Mms的源碼的位置在于android/packages/apps/Mms

其中Mms/src/com/android/mms里面都是Mms相關(guān)的代碼，而Mms/src/org/w3c/dom里面是一個(gè)類(lèi)庫(kù)，主要用于彩信格式的解析和顯示。這里主要講一下Mms/src/com/android/mms下面的一些包和類(lèi)的主要用途。

ui---GUI展示層，用于展示對(duì)話(huà)列表，消息列表，消息編輯頁(yè)，彩信附件編輯，彩信展示，播放幻燈片。負(fù)責(zé)直接與用戶(hù)交互。

?ConversationListAdapter.java---對(duì)話(huà)列表的Adapter用于給顯示層ConversationList綁定數(shù)據(jù)。

?ConversationListItemData.java---代表對(duì)話(huà)列表中的每一項(xiàng)的數(shù)據(jù)結(jié)構(gòu)，里面含有要在對(duì)話(huà)列表中展示的信息。

?ConversationList.java------這是對(duì)話(huà)列表的顯示窗口Activity，它是一個(gè)ListActivity，這幾個(gè)類(lèi)都是對(duì)話(huà)列表的相關(guān)類(lèi)，用于顯示，編輯和管理所有的對(duì)話(huà)。

?ComposeMessageActivity.java----這個(gè)是核心的窗口Activity，編輯信息，顯示一條對(duì)話(huà)Thread中的所有往來(lái)信息。MessageListView會(huì)加在其上面，另外，AttachmentEditor也會(huì)加在其上面。這個(gè)Activity也負(fù)責(zé)響應(yīng)外部應(yīng)用程序，發(fā)送SENDTO或SEND等請(qǐng)求Intent，比如外部應(yīng)用想要發(fā)送信息，等就由這個(gè)Activity來(lái)響應(yīng)。

?MessageItem.java---代表一個(gè)信息的抽象數(shù)據(jù)，它包含了信息相關(guān)的所有內(nèi)容，比如信息的主題，消息內(nèi)容，來(lái)信地址，附件內(nèi)容等等。它的所有數(shù)據(jù)都是公共的內(nèi)部成員，都可以直接訪問(wèn)。

?MessageListAdapter.java---用于給消息列表顯示層（由ComposeMessageActivity創(chuàng)建，綁定到MessageListView上）綁定數(shù)據(jù)。

?MessageListView.java---用于顯示消息列表，繼承自ListView，其生命周期由ComposeMessageActivity來(lái)控制，顯示與否也由它來(lái)控制。

?MessageListItem.java---是一個(gè)布局，用于顯示和控制消息列表中的每一個(gè)消息的顯示。

?AttachmentTypeSelectorAdapter.java---用于添加附件件時(shí)的一個(gè)支持的附件列表，它就是一個(gè)菜單。

?AttachmentEditor.java---用于在編輯MMS彩信信息時(shí)，顯示已添加的附件，它的生命周期由ComposeMessageActivity來(lái)控制，顯示與否也是由ComposeMessageActivity來(lái)控制，當(dāng)有彩信附件時(shí)，它就會(huì)顯示，否則就被Hide。它是一個(gè)布局管理器，管理著下面四個(gè)布局，根據(jù)附件的類(lèi)型動(dòng)態(tài)的顯示下面四個(gè)View中的某一個(gè)。

?AudioAttachmentView.java---在編輯信息器中用于顯示音頻附件，它是繼承自線性布局。并不在代碼中直接使用，而是在布局文件中來(lái)當(dāng)成布局管理器使用。

?ImageAttachmentView.java---在編輯信息器中用于顯示圖片附件，它是繼承自線性布局。并不在代碼中直接使用，而是在布局文件中來(lái)當(dāng)成布局管理器使用。

?SlideshowAttachmentView.java---在編輯信息器中用于顯示幻燈片附件，它是繼承自線性布局。并不在代碼中直接使用，而是在布局文件中來(lái)當(dāng)成布局管理器使用。

?VideoAttachmentView.java---在編輯信息器中用于顯示視頻附件，它是繼承自線性布局。并不在代碼中直接使用，而是在布局文件中來(lái)當(dāng)成布局管理器使用。

?SlideshowActivity.java—用來(lái)全屏播放幻燈片，也即幻燈片的展示，因?yàn)椴市诺膭?chuàng)建和播放都是以幻燈片的方式進(jìn)行的，也即一張一張的，每張上面可以文字，圖片，視頻和音頻，每一張有瀏覽時(shí)長(zhǎng)。

?SlideshowEditActivity.java---以列表方式管理幻燈片，也即是把所有的幻燈片用列表顯示出來(lái)，用戶(hù)可添加一頁(yè)幻燈片，也可以點(diǎn)擊進(jìn)入編輯某頁(yè)幻燈片，用于創(chuàng)建和編輯幻燈片。

?SlideshowEditor.java---用于編輯某頁(yè)幻燈片，比如添加元素，刪除元素和替換元素，這里的元素可以是圖片，視頻，音頻和文字。也可以用于編輯整頁(yè)幻燈片，比如刪除某頁(yè)幻燈片，調(diào)整這頁(yè)幻燈片在所有幻燈片中的位置等。它是一個(gè)具體操作幻燈片的封裝，SlideEditorActivity創(chuàng)建它并使用它來(lái)完成紀(jì)燈片的編輯。

?SlideshowPresenter.java---用于展示所有的幻燈片，也就是播放所有的幻燈片。由SlideshowActivity來(lái)創(chuàng)建和使用。

?SlideViewInterface.java---定義了一些用于顯示一頁(yè)幻燈片中的內(nèi)容的接口，如設(shè)置圖像，設(shè)置視頻，設(shè)置音頻，播放視頻，播放音頻，暫停，隨機(jī)定位等等。附件顯示的View：AudioAttachmentView，ImageAttachmentView，SlideshowAttachmentView和VideoAttachmentView均實(shí)現(xiàn)了此接口，這樣AttachmentEditor就可以用統(tǒng)一的接口來(lái)控制內(nèi)容的播放，而不用關(guān)心具體的內(nèi)容是什么。

?SlideEditorActivity.java---用于編輯某頁(yè)幻燈片，比如添加音頻，添加視頻，添加圖像，添加文字等。它只是提供用戶(hù)界面，讓用戶(hù)來(lái)操作各種按扭以達(dá)到添加元素，替換元素或是刪除元素。而對(duì)具體的幻燈片的操作是通過(guò)SlideshowEditor來(lái)完成的，它主要負(fù)責(zé)與用戶(hù)交互。

?SlideListItemView.java--- SlideshowEditActivity中列表的每一項(xiàng)的布局管理，繼承自LinearLayout。

?MmsThumbnailPresenter.java---用于在消息列表中，顯示彩信的縮略圖，因?yàn)椴市诺膬?nèi)容不固定，可能是圖片，可能是音頻，可能是視頻也可能是幻燈片，所以用這個(gè)類(lèi)來(lái)處理并顯示彩信的縮略圖。

?MessagingPreferenceActivity.java---Mms的配置信息編輯器，用來(lái)編輯和更改配置信息，繼承息PreferenceActivity。它負(fù)責(zé)與用戶(hù)交互，顯示和更改配置。在Mms啟動(dòng)時(shí)，MmsConfig會(huì)從SharedPreference中讀出配置信息，在運(yùn)行時(shí)其他的類(lèi)的配置信息都是從MmsConfig中獲取的，MmsConfig提供了很多Get方法以獲取配置信息。

?Presenter.java---用來(lái)展示附件的一個(gè)抽象類(lèi)。

?PresenterFactory.java---工廠方法。

?RecipientsAdapter.java

?RecipientsEditor.java---用于顯示信息編輯頁(yè)面上面的收信人的編輯框，它可以有自動(dòng)補(bǔ)全的功能，補(bǔ)全的數(shù)據(jù)由RecipientsAdapter來(lái)提供。

?ViewInterface.java---代表一個(gè)View的基類(lèi)，用于Slideshow顯示內(nèi)容或是取縮略圖?？梢匀iew的長(zhǎng)寬高等。

?BasicSlideEditorView.java---編輯某一頁(yè)幻燈片時(shí)所用的布局，也就是在SlideEditorActivity.java中使用。

?EditSlideDurationActivity.java---顧名思義，用于編輯某一頁(yè)幻燈片的瀏覽時(shí)長(zhǎng)。

?ManageSimMessages.java---這個(gè)是在設(shè)置中使用的，用來(lái)管理SIM里的消息。在設(shè)置中有一項(xiàng)是管理SIM卡上面的消息。在Mms的設(shè)置Settings中有一個(gè)選項(xiàng)可以設(shè)置是把信息存儲(chǔ)在SIM卡，還是存儲(chǔ)在手機(jī)里。在收信時(shí)SmsReceiverService會(huì)查看這個(gè)設(shè)置然后把收到的信息寫(xiě)到相應(yīng)的地址。ManageSimMessages也是以列表方式顯示SIM里面的信息，提供了二個(gè)菜單：把信息存入手機(jī)和刪除。

?NumberPickerButton.java---用于顯示選擇數(shù)字的按扭，在配置里面用。

?NumberPickerDialog.java---用于顯示選擇數(shù)字的對(duì)話(huà)框，在配置里面用。

?NumberPicker.java---用于在配置的時(shí)候選擇數(shù)字。這幾個(gè)NumerPicker主要是用于Settings中的。

?DeliveryReportActivity.java---信息發(fā)送情況報(bào)告。以列表的方式來(lái)顯示

?DeliveryReportAdapter.java---相應(yīng)的Adapter

?DeliveryReportItem.java---相應(yīng)的數(shù)據(jù)，每一項(xiàng)的數(shù)據(jù)

?DeliveryReportListItem.java---相應(yīng)每一項(xiàng)的布局。

data---用于操作當(dāng)前正在編輯的信息的相關(guān)數(shù)據(jù)，比如聯(lián)系人列表，比如當(dāng)前對(duì)話(huà)，比如當(dāng)前消息。負(fù)責(zé)管理當(dāng)前正在編輯的信息和當(dāng)前所處的對(duì)話(huà)以及當(dāng)前信息用到的聯(lián)系人。這些類(lèi)都是在編輯信息的時(shí)候使用，由于這些多半都是用來(lái)管理數(shù)據(jù)的，而又無(wú)法直接做為對(duì)象傳遞給編輯器。所以它們的很多方法都是靜態(tài)的，也就是這些類(lèi)都近似單鍵。

?WorkingMessage.java---用來(lái)管理當(dāng)前正在編輯的消息，它從創(chuàng)建，草稿到發(fā)送完成后一直存在，只要打開(kāi)了編輯信息的頁(yè)面就會(huì)創(chuàng)建一個(gè)WorkingMessage，直到退出編輯頁(yè)面。

?Conversation.java---用來(lái)管理對(duì)話(huà)Threads，通常用來(lái)管理當(dāng)前的對(duì)話(huà)，也就是進(jìn)入的對(duì)話(huà)和正在進(jìn)行操作的對(duì)話(huà)，它也用來(lái)管理對(duì)話(huà)列表，比如查詢(xún)對(duì)話(huà)列表。

?Contact.java---用來(lái)代表一個(gè)聯(lián)系人的信息，和管理聯(lián)系人，加載聯(lián)系人信息，其中還有相應(yīng)的Cache。因?yàn)橐粋€(gè)聯(lián)系人的數(shù)據(jù)是比較多的包含名字，名，姓，各種電話(huà)號(hào)碼，各種地址等等。因?yàn)镸ms中直接使用Contact來(lái)作為聯(lián)系人，所有信息都是直接從其中獲取。另外，由于信息交互中也會(huì)涉及到聯(lián)系人，因?yàn)槭瞻l(fā)信時(shí)可以直接使用一串電話(huà)號(hào)碼，這時(shí)就需要有如添加聯(lián)系人的功能。Contact中有很多異步的操作，比如加載聯(lián)系人信息的時(shí)候或者更新Cache的時(shí)候都需要異步操作以不阻塞調(diào)用者。

?ContactList.java---是一個(gè)Contact的List列表它繼承自ArrayListContact。用來(lái)管理一個(gè)Contact列表，或管理多個(gè)Contact。因?yàn)槊總€(gè)信息可以發(fā)送給多個(gè)聯(lián)系人，這時(shí)就需要用到ContactList來(lái)管理這些收信人。也提供了一些方便存儲(chǔ)和傳遞Contact的方法，比如把多個(gè)Contact轉(zhuǎn)成String，或者轉(zhuǎn)成String數(shù)組等。

?RecipientIdCache.java---用于保存所用到的Contact的Id和地址（電話(huà)）。每次WorkingMessage會(huì)更新這個(gè)Cache，然后ContactList會(huì)優(yōu)先從這個(gè)Cache中查詢(xún)聯(lián)絡(luò)人。

dom---用于解析彩信內(nèi)容smil的工具包

drm---用于處理DRM的媒體文件的工具包

layout---為了滿(mǎn)足特殊需要而改寫(xiě)的布局元素

model---這里面定義了彩信支持的附件數(shù)據(jù)結(jié)構(gòu)和附件的組織方式。彩信可包含的內(nèi)容有圖片，視頻，音頻和文字。這些內(nèi)容可以單獨(dú)存在，也可以組合在一起。如果組合在一起就變成了幻燈片。用戶(hù)可以用幻燈片的方式來(lái)創(chuàng)建含有多個(gè)媒體的附件，圖文并茂的展示。每張幻燈片上面可以加視頻，音頻，圖片和文字，但通常一張幻燈片上面只允許加一個(gè)圖片或視頻，文字是都可以添加的，音頻在沒(méi)有視頻的情況下只可以添加的。播放的時(shí)候可以設(shè)置每張幻燈片的播放時(shí)長(zhǎng)，以及文字的滾動(dòng)速度等等。

?CarrierContentRestriction.java---是具體的彩信附件檢查站，對(duì)于不支持的附件，或者附件大小超出限制，或者圖像分辨率不對(duì)，或者圖像超出尺寸，會(huì)拋出異常：UnsupportedContentTypeException，ResolutionException，ExceedMessageSizeException，ContentRestrictionException。

?ContentRestriction.java是用于檢查附件的接口，外部直接使用這相接口，而具體實(shí)現(xiàn)是CarrierContentRestriction

?ContentRestrictionFactory.java是創(chuàng)建附件檢查的工廠方法。外部通過(guò)這個(gè)工廠來(lái)創(chuàng)建一個(gè)ContentRestriction對(duì)象，然后使用其中定義的檢查方法來(lái)進(jìn)行附件內(nèi)部檢查。

?SmilHelper.java用于解析和處理附件中的Smil的工具類(lèi)。

?IModelChangedObserver.java接口，用于監(jiān)聽(tīng)附件內(nèi)容有變化。

?Model.java---彩信附件的數(shù)據(jù)組織方式和管理方式是每一個(gè)附件都是一個(gè)Model的子類(lèi)，它不但用于管理附件的具體數(shù)據(jù)，比如Uri，大小，文件名，位置等，也可以用于在GUI顯示附件和查看附件。

?LayoutModel.java---繼承自Model用于管理可視的附件的布局的類(lèi)。它用來(lái)管理RegionModel等的基本元素。它就好比ViewGroup或LinearLayout，RelativeLayout等一些布局管理器，用來(lái)組織并管理布局基本元素也就是RegionModel的子類(lèi)ImageModel，TextModel和VideoModel。

?RegionModel.java---繼承自Model用于管理可視附件和布局，比如圖像，視頻和文字。特別是在顯示可視附件的時(shí)候，用于控制可視附件在屏幕中的位置。一個(gè)RegionModel代表著一張幻燈片上的一塊區(qū)域，它是幻燈片上的布局基本元素。好比UI元素中的View，但多在使用時(shí)都是使用它的子類(lèi)，也就是ImageModel，TextModel和VideoModel。

?RegionMediaModel.java---繼承自MediaModel，是用于多媒體附件中的可視部分的布局控制，主要用在附件的顯示和播放幻燈片時(shí)的控制。它的子類(lèi)是ImageModel，TextModel和VideoModel。

?MediaModel.java---繼承自Model，代表媒體的數(shù)據(jù)結(jié)構(gòu)，管理具體的附件數(shù)據(jù)，同時(shí)也用于管理附件的顯示控制，比如圖像的顯示，音頻和視頻的播放控制等。

?MediaModelFactory.java---用于從一個(gè)Pdu附件中解析出來(lái)MediaModel，也就是把Pdu轉(zhuǎn)化為Mms內(nèi)部的附件數(shù)據(jù)。

?ImageModel.java—繼承自RegionMediaModel用于管理圖像附件和控制圖像附件的顯示。

?VideoModel.java---繼承自RegionMediaModel用于管理視頻附件和控制視頻附件的播放。

?AudioModel.java----繼承自MediaModel用于管理音頻附件和控制音頻附件的播放

?SlideModel.java----繼承自Model用于管理一組附件，這些附件同一次顯示給用戶(hù)。就好像幻燈片的一片一樣，每一個(gè)SlideModel里面有一個(gè)可以存儲(chǔ)Model的列表，可以包含文字，音頻，圖像或視頻，其上面的附件同時(shí)顯示出來(lái)。

?SlideshowModel.java---繼承自Model，用于管理一個(gè)彩信中的所有附件。其內(nèi)含有一個(gè)存儲(chǔ)SlideModel的列表，用于保存和控制一條彩信中的所有附件。另外它也負(fù)責(zé)顯示這些附件，把一個(gè)個(gè)SlideModel組織起來(lái)，播放。它也負(fù)責(zé)著把這些Mms形式的附件（各種Model）轉(zhuǎn)化為Android的附件Pdu，和從Pdu提出各自Model，因?yàn)镾lideshow是應(yīng)用程序?qū)拥牟市盘幚矸绞?，而能發(fā)送和接收的彩信數(shù)據(jù)是Pdu。

?TextModel.java---繼承自RegionMediaModel用于管理文字附件和控制文字附件的顯示，比如按時(shí)間來(lái)滾動(dòng)

util---這里面是整個(gè)Mms共享的工具類(lèi)，其中全部都是單鍵或是直接使用類(lèi)，不可以創(chuàng)建對(duì)象和以對(duì)象方式來(lái)使用

?AddressUtils.java---關(guān)于地址的工具類(lèi)，目前只有一個(gè)getFrom()方法，用于獲取發(fā)信人地址。

?DraftCache.java---用于標(biāo)識(shí)哪些對(duì)話(huà)Thread有Draft，哪些沒(méi)有，也就是用于管理和查詢(xún)對(duì)話(huà)的草稿狀態(tài)，有草稿還是沒(méi)有。它里面維護(hù)了一個(gè)HashSet，里面包含了所有含有草稿的Thread Id。它里面也有一個(gè)HashSet用于存儲(chǔ)OnDraftChangedListener，即當(dāng)Thread的Draft狀態(tài)有變化時(shí)，DraftCache會(huì)調(diào)用相應(yīng)的Listener以告知相應(yīng)模塊，這個(gè)對(duì)話(huà)的草稿狀態(tài)有所變化。可以通過(guò)DraftCache.setDraftState(threadId, state)來(lái)設(shè)置某個(gè)對(duì)話(huà)的草稿狀態(tài); 可以通過(guò)DraftCache.hasDraft(threadId)來(lái)查詢(xún)某個(gè)對(duì)話(huà)是否含有草稿。

?Recycler.java---是一個(gè)抽象的工具類(lèi)，里面定義了SmsRecycler和MmsRecycler，用于刪除陳舊的消息，或者刪除超過(guò)信息數(shù)量限制的信息。使用方法都是Recycler.getSmsRecycler.deleteOldMessages(context) 或者Recycler.getMmsRecycler.deleteOldMessages(context)

?SmileyParser.java---把標(biāo)點(diǎn)式的表情符號(hào)轉(zhuǎn)化為圖形的表情，比如把?用圖標(biāo)笑臉來(lái)代替。

?DownloadManager.java---不要被名字騙到，它并不是真正意義上的下載管理器，因?yàn)樗⒉回?fù)責(zé)任何與下載文件過(guò)程或下載文件的管理。它是用于管理與下載相關(guān)的配置信息，比如是否是自動(dòng)下載，以及下載過(guò)程的各種通知，比如Notification Bar和Toast提示等。

?RateController.java

?SendingProgressTokenManager.java

transaction---對(duì)于Mms來(lái)講是最底層的一個(gè)包，用戶(hù)不可見(jiàn)，它負(fù)責(zé)發(fā)信息的最后處理和收信息的最初處理。主要是負(fù)責(zé)發(fā)送信息和接收信息。它并不是真正的發(fā)送和接收信息。是由系統(tǒng)Frameworks里面來(lái)負(fù)責(zé)接收和發(fā)送信息。這個(gè)包只是對(duì)于Mms應(yīng)用層來(lái)講是發(fā)送和接收。

?AbstractRetryScheme.java

?DefaultRetryScheme.java—這二個(gè)類(lèi)是實(shí)現(xiàn)一種Retry機(jī)制，因?yàn)樾畔⒌陌l(fā)送與接收會(huì)受到環(huán)境的限制，比如現(xiàn)在手機(jī)沒(méi)信號(hào)，或是網(wǎng)絡(luò)連接不成功，那么就會(huì)把信息放到Pending隊(duì)列里面，等一段時(shí)間再重新嘗試發(fā)送與接收。這里的二個(gè)類(lèi)就是為了實(shí)現(xiàn)此Retry機(jī)制。

?HttpUtils.java—彩信發(fā)送與接收的最底層實(shí)現(xiàn)者，它負(fù)責(zé)用HTTP協(xié)議接收和發(fā)送彩信到MMSC彩信服務(wù)中心。

?MessageSender.java—像其名字所預(yù)示的那樣，它是為了發(fā)送信息而封裝的一個(gè)接口，它里面只有一個(gè)方法sendMessage()，UI層只需要調(diào)用實(shí)現(xiàn)了這個(gè)接口的類(lèi)即可發(fā)送信息。

?MessagingNotification.java—專(zhuān)門(mén)負(fù)責(zé)在Status Bar上面做Notification，比如新接收到了信息，或是信息發(fā)送失敗，或是接收失敗等。它被UI層，和底邏輯層共用著。

?MmsMessageSender.java—繼承自MessageSender，專(zhuān)門(mén)用于發(fā)送彩信。它并不是做發(fā)送的事情，而是做一些錯(cuò)誤檢查和前期準(zhǔn)備工作，然后啟動(dòng)TransactionService來(lái)做發(fā)送相關(guān)的事情。

?NotificationTransaction.java—繼承自Transaction，負(fù)責(zé)接收彩信和更新通知(Notification)。當(dāng)有一個(gè)新彩信時(shí)，F(xiàn)rameworks會(huì)先發(fā)出一個(gè)短信，稱(chēng)作彩信通知(NotificationIndication)，其內(nèi)含有彩信相關(guān)的信息(MMSC, 彩信的ContentLocation(URL)等)，之后是由應(yīng)用程序自己去MMSC用ContentLocation取彩信。這個(gè)NotificationTransaction就是專(zhuān)門(mén)用于處理彩信通知的，它會(huì)從MMSC上取出彩信數(shù)據(jù)（Pdu），把它寫(xiě)入數(shù)據(jù)庫(kù)中，然后更新Notification。需要注意的是，只有彩信的設(shè)置是自動(dòng)獲取(“auto retrieve”)時(shí)，它才會(huì)去下載彩信，否則，它只處理彩信通知(Notification Indication)，而不去下載彩信。

?Observable.java—里面定義了觀察對(duì)象，Transaction是它的一個(gè)子類(lèi)，其他的實(shí)體Transaction都是觀察對(duì)象，里面有一個(gè)列表保存著觀察者的引用，當(dāng)一個(gè)Transaction完成時(shí)，或是有異常時(shí)就會(huì)調(diào)用notifyObservers()方法來(lái)把狀態(tài)通知給觀察者。

?Observer.java—觀察者，TransactionService實(shí)現(xiàn)了這個(gè)接口。它是所有Transaction的觀察者，以監(jiān)聽(tīng)他們的狀態(tài)和處理結(jié)果，因?yàn)樗械腡ransaction都 是異步的，所以才用觀察模式來(lái)通知Transaction的處理結(jié)果。

?PrivilegedSmsReceiver.java—繼承自SmsReceiver短信收信的事件監(jiān)聽(tīng)者，負(fù)責(zé)監(jiān)聽(tīng)新短信事件android.provider.Telephony.Intents.SMS_RECEIVED_ACTION(“android.provider.Telephony.SMS_RECEIVED”);當(dāng)接收到這個(gè)Intent時(shí)表明有一個(gè)新短信。它會(huì)喚起SmsReceiverServier來(lái)處理短信。

?ProgressCallbackEntity.java

?PushReceiver.java—一個(gè)BroadcastReceiver專(zhuān)門(mén)用于接收彩信事件android.provider.Telephony.WAP_PUSH_RECEIVED_ACTION(“android.provider.Telephony.WAP_PUSH_RECEIVED”)，它會(huì)先做一些預(yù)處理，然后啟動(dòng)TransactionService，TransactionService又會(huì)創(chuàng)建NotificationTransaction來(lái)處理這個(gè)彩信通知。

?ReadRecTransaction.java

?RetrieveTransaction.java—繼承自Transaction，用于主動(dòng)獲取彩信數(shù)據(jù)。當(dāng)彩信設(shè)置為非自動(dòng)獲取時(shí)，需要用戶(hù)觸發(fā)獲取，TransactionService會(huì)創(chuàng)建一個(gè)RetrieveTransaction來(lái)獲取彩信數(shù)據(jù)(Pdu)，存入數(shù)據(jù)庫(kù)，更新Notification等。

?RetryScheduler.java

?SendTransaction.java—繼承自Transaction，用于發(fā)送彩信數(shù)據(jù)。

?SimFullReceiver.java

?SmsMessageSender.java—發(fā)送短信的封裝，繼承自MessageSender。它會(huì)啟動(dòng)SmsReceiverService來(lái)發(fā)送。

?SmsReceiver.java—是一個(gè)BroadcastReceiver，不要被其名字唬到，它并不負(fù)責(zé)接收新短信通知，相反，它用于發(fā)送信息，接收發(fā)送信息請(qǐng)求，并喚起SmsReceiverService來(lái)處理發(fā)送。這里可能是Android命名規(guī)則的原因，Android里的四大組件都喜歡把其組件的名字加上，比如ComposeMessageActivity，是一個(gè)Activity，TransactionService是一個(gè)Service，而這里SmsReceiver是一個(gè)BroadcastReceiver，它與接收短信(receiving Sms)沒(méi)有關(guān)系。當(dāng)然了，這完全是一個(gè)糟糕的命名。

?SmsReceiverService.java—它是一個(gè)Service，專(zhuān)門(mén)用于處理短信的發(fā)送與接收。它是由SmsReceiver和PrivilegedSmsReceiver監(jiān)聽(tīng)事件，然后啟動(dòng)它的，自己并不會(huì)監(jiān)聽(tīng)I(yíng)ntent事件。

?SmsRejectedReceiver.java

?SmsSingleRecipientSender.java—繼承自SmsMessageSender，它針對(duì)一個(gè)收信人，調(diào)用Frameworks層接口發(fā)送信息，對(duì)于Mms應(yīng)用來(lái)說(shuō)，這是發(fā)送短信的最后一站，對(duì)就是說(shuō)對(duì)于應(yīng)用來(lái)說(shuō)，它會(huì)把短信發(fā)送出去。

?TransactionBundle.java—Transaction所用的一個(gè)數(shù)據(jù)結(jié)構(gòu)，用于給Transaction傳送數(shù)據(jù)。

?Transaction.java—各種Transaction的基類(lèi)，它里面定義了二個(gè)方法getPdu()，sendPdu()這二個(gè)方法是從MMSC取彩信數(shù)據(jù)，和向MMSC發(fā)送數(shù)據(jù)。它是對(duì)HttpUtils的一層包裝。

?TransactionService.java—是一個(gè)Service，接收各種Transaction請(qǐng)求，然后處理Transaction。每個(gè)Transaction都 會(huì)開(kāi)啟新的線程異步的處理，所以當(dāng)處理完成時(shí)又會(huì)通過(guò)Observer來(lái)通知TransactionService。

?TransactionSettings.java—彩信相關(guān)配置信息的數(shù)據(jù)結(jié)構(gòu)，比如MMSC，Proxy，Port等。請(qǐng)求方可能會(huì)提供這些數(shù)據(jù)，如果提供就使用；否則就會(huì)從Telephony數(shù)據(jù)庫(kù)加載默認(rèn)的數(shù)據(jù)，這些數(shù)據(jù)與運(yùn)營(yíng)商和APN的設(shè)置有關(guān)。

?TransactionState.java—標(biāo)識(shí)每一個(gè)Transaction處理情況的數(shù)據(jù)結(jié)構(gòu)，很簡(jiǎn)單，只是標(biāo)明處理成功還是失敗，用于Transaction回調(diào)Observer(TransactionService)時(shí)用。

還有com/android/mms根目錄下面的一些文件，其中絕大多數(shù)是定義的基類(lèi)異常和一些公共的類(lèi)。

?MmsApp.java---Mms Application會(huì)在應(yīng)用進(jìn)程啟動(dòng)的時(shí)候做一些必要的初始化工作，比如配置，下載，聯(lián)系人，對(duì)話(huà)，Smiley解析器和通知等。

?MmsConfig.java---管理Mms的一些常用配置，比如彩信大小上限，彩信圖片尺寸上限，收信人的個(gè)數(shù)上限等等。這些配置信息是保存在在res/xml/mms_config.xml里面。MmsApp在初始化時(shí)會(huì)調(diào)用MmsConfig.init()，在這里面會(huì)調(diào)用loadMmsSettings來(lái)解析mms_config.xml從而得到所需要的配置信息。其他的模塊只通過(guò)MmsConfig來(lái)訪問(wèn)這些配置信息。

?LogTag.java---有關(guān)日志跟蹤信息的控制。它可以方便的控制日志輸出級(jí)別。但是實(shí)際上整個(gè)Mms代碼中使用這個(gè)LogTag的地方并不多。

IOS開(kāi)發(fā)要學(xué)習(xí)哪些方面的知識(shí)？

第一步：編程入門(mén)課

時(shí)間預(yù)計(jì)：4個(gè)星期

推薦看公開(kāi)課，Udacity也行，網(wǎng)易公開(kāi)課也行，自己找一個(gè)面對(duì)對(duì)象語(yǔ)言（一般是JAVA, C++, Python）的課。我是在網(wǎng)易公開(kāi)課看的斯坦福的CS106A，學(xué)的JAVA。

如果你純粹學(xué)iOS開(kāi)發(fā)，不推薦看哈佛CS50，CS50是給CS系的學(xué)生介紹整個(gè)計(jì)算機(jī)世界的框架，講的內(nèi)容比較多，進(jìn)度比較快，對(duì)iOS開(kāi)發(fā)其實(shí)有點(diǎn)累贅了。（臣妾有點(diǎn)跟不上?。。。?/p>

計(jì)劃安排是一天一課，看課程要求的書(shū)（至少看完一本）及大部分作業(yè)。這一階段重點(diǎn)不是語(yǔ)法，而是以下3個(gè)目標(biāo)。

目標(biāo)：

1. 讓自己對(duì)編程這件事感到適應(yīng)。

寫(xiě)hello world。

怎么寫(xiě)function, 怎么調(diào)用function。

全局變量，局部變量這類(lèi)基本知識(shí)點(diǎn)。

都是基本的東西?？纯磿?shū)，寫(xiě)多兩個(gè)程序就歐啦。

2. 掌握編程語(yǔ)言的基本要素。

編程語(yǔ)言4個(gè)要素：

a. 基本的數(shù)據(jù)類(lèi)型：整數(shù)，實(shí)數(shù)，character, string, boolean

b. 基本的運(yùn)算符號(hào)：+-×/++--那啥的

c. 怎樣輸入輸出

d. 怎樣控制程序：sequence，selection，loop

3. 了解編程范式

面對(duì)過(guò)程編程。

面向?qū)ο缶幊獭?/p>

第二步：上手iOS!

時(shí)間預(yù)計(jì)：2星期

強(qiáng)烈推薦CS193P，老頭子講的超級(jí)好！我的很多東西（對(duì)象思維啥的）是在這里跟著做練習(xí)的時(shí)候才真正明白的（好啦，也可能是上一堂課練習(xí)做得少的原因）。如果等到9月應(yīng)該itunes U上會(huì)開(kāi)始教iOS 7了。網(wǎng)易公開(kāi)課的是2010年iOS 5版的，前10堂課，也行。（iTunes U上有完整的課）

CS193P說(shuō)有prerequisite，一開(kāi)始被嚇到，事實(shí)證明還是可以學(xué)下去的。頭兩節(jié)課一頭霧水，沒(méi)關(guān)系，把itunes U上的課件下載下來(lái)，把所有代碼打出來(lái)，然后一個(gè)個(gè)元素對(duì)應(yīng)之前學(xué)的語(yǔ)言匹配，再不懂先放著，繼續(xù)學(xué)后邊的，過(guò)幾天打多點(diǎn)代碼就懂了。

感覺(jué)學(xué)5、6堂課，一個(gè)星期左右就可以開(kāi)始進(jìn)入下一階段自己做東西了。之后用啥學(xué)啥，每堂課都有主題的。速度慢點(diǎn)的同學(xué)們，這階段跟我一樣準(zhǔn)備兩個(gè)星期吧！

第三步：開(kāi)發(fā)app!

時(shí)間預(yù)計(jì)：2星期（本人...1個(gè)半月，實(shí)在不好意思說(shuō)出口）

這個(gè)時(shí)間就可長(zhǎng)可短啦，還包括美工，交互啥的。堅(jiān)持要用啥學(xué)啥的原則，其實(shí)就是知道iOS SDK都有什么組件，每個(gè)組件有什么function而已。stackoverflow, Github, apple sample code多上，搜索引擎多用。如果有個(gè)師傅，這個(gè)階段真的是進(jìn)步神速。

好的！不出意外，你的第一個(gè)app就這么新鮮出爐了！從今天開(kāi)始，成為一個(gè)冷艷逼格高尚的iOS開(kāi)發(fā)者吧！

ios故事軟件開(kāi)發(fā)需要多少費(fèi)用

IOS故事類(lèi)軟件開(kāi)發(fā)成本及人員：

一、IOS開(kāi)發(fā)者會(huì)員年費(fèi)：600元（要發(fā)布軟件必須擁有開(kāi)發(fā)者會(huì)員）。

二、研發(fā)人員，費(fèi)用至少需要2~5萬(wàn)。

1、故事編劇、導(dǎo)演各1名。

2、插畫(huà)師1名。

3、程序腳本編寫(xiě)人員（初級(jí)OC程序員）2~3名。

4、程序調(diào)整及BUG修復(fù)人員1~2名。

三、應(yīng)用推廣、營(yíng)銷(xiāo)費(fèi)用至少需要1~3萬(wàn)，如果要求效果更好的至少需要5萬(wàn)。

四、后期維護(hù)費(fèi)用：依據(jù)軟件運(yùn)營(yíng)時(shí)間，時(shí)間越長(zhǎng)單次維護(hù)費(fèi)用越低，但綜合維護(hù)費(fèi)用越高。

開(kāi)發(fā)使用storyboard和xib的區(qū)別

縱觀iOS發(fā)展歷程， 不管是哪種技術(shù)，都有其歷史的必然性，最終總會(huì)被一種新技術(shù)所取代。 apple 一直在引領(lǐng)科技的潮流，立足于浪潮之巔。

nib apps 代表了 iOS的過(guò)去， 而 storyboard apps 代表了iOS的現(xiàn)在和未來(lái)。 作為iOS開(kāi)發(fā)者，我們既要腳踏實(shí)地，不忘過(guò)去，同時(shí)也得仰望星空，不斷地自我創(chuàng)新。

1. nib apps 的回顧

nib apps 中，有一個(gè)必不可少的文件： MainWindow.xib 。 app運(yùn)行時(shí)，呈現(xiàn)在你面前的第一個(gè)畫(huà)面，就是UIWindow 對(duì)象。 而UIWindows 就是包含在 MainWindow.xib 中。

具體來(lái)講， MainWindow.xib ，UIWindow， App Delegate，root view controller ，這四者是密切關(guān)聯(lián)的。 我們要理解這四者之間的關(guān)系，方能更好地明白 storyboard apps 的運(yùn)行機(jī)制。

2. storyboard apps 運(yùn)行邏輯圖

在storybord apps 中， MainWindow.xib 是不存在的。 取而代之的是 main.storyboard 文件。既然如此，那么storybord又是如何加載的呢？

在創(chuàng)建storyboard apps 時(shí)，會(huì)自動(dòng)生成幾個(gè)默認(rèn)的文件， AppDelegate.h 便是其中之一。 示意如下：

import UIKit/UIKit.h

@interface AppDelegate : UIResponder UIApplicationDelegate

@property (strong, nonatomic) UIWindow *window;

@end

這些默認(rèn)生成的文件， 我們要特別關(guān)注下， 弄清來(lái)龍去脈。

AppDelegate 繼承于 UIResponder，并且擁有一個(gè) UIWindow property。 聲明的方式很簡(jiǎn)潔。

再打開(kāi)默認(rèn)生成的 AppDelegate.m 文件，你會(huì)感到很詫異， AppDelegate.m 所展示的代碼幾乎為空。 所有的method 都是空的。 即使 application:didFinishLaunc hingWithOptions: ， 僅僅是返回 YES， 也沒(méi)有其他代碼可言。

這就是說(shuō)，不管是 AppDelegate.h 還是AppDelegate.m ， 都沒(méi)看到什么玄機(jī)。 貌似龐然大物的storyboard，究竟是怎么玩的？

常言說(shuō)的好，一個(gè)好漢三個(gè)幫。 僅僅查看AppDelegate.h/m ，還是遠(yuǎn)遠(yuǎn)不夠的， storybord 還有三個(gè)好漢。

storyboard 幫手： info.plist 文件。 如下：

nib apps VS. storyboard apps - 悠悠電臺(tái) - 悠悠電臺(tái)iOS客戶(hù)端：幾千個(gè)國(guó)內(nèi)外電臺(tái)

當(dāng)storyboard apps 啟動(dòng)時(shí)， 它怎么知道從哪里加載main.storyboard 文件呢？ 秘密就在info.plist上。 你會(huì)看到， UIMainStoryboardFile 或 “Main storyboard file base name” 的鍵值設(shè)為了 Main。當(dāng)app 啟動(dòng)時(shí)，UIApplicaiton 會(huì)自動(dòng)加載main.storyboard 文件。 同時(shí)，會(huì)自動(dòng)加載 main.storyboard 上的第一個(gè)視圖控制器 （view controller），并且，將該 view controller 所對(duì)應(yīng)的 View 加載到UIWindow 對(duì)象中。

也許你已經(jīng)注意到了， app 啟動(dòng)時(shí)，做了這么的工作，但我們還沒(méi)有編寫(xiě)一行代碼。 storyboard技術(shù)的引進(jìn)，其最大的意義在于， 大大減少與 UI相關(guān)的 代碼量。

storyboard 幫手：Deployment Info 的設(shè)置。 如下：

nib apps VS. storyboard apps - 悠悠電臺(tái) - 悠悠電臺(tái)iOS客戶(hù)端：幾千個(gè)國(guó)內(nèi)外電臺(tái)

點(diǎn)擊 Project settings， 可以看到Deployment Info。 你會(huì)注意到， Main Interface 也設(shè)為了 Main。 其實(shí)，這里的 Main 所指的就是 main.storyboard。

為了徹底理解 storyboard 的加載過(guò)程， 我們?cè)賮?lái)打探另一個(gè)重要的幫手。

storyboard 幫手：main.m 文件， 代碼如下：

#import UIKit/UIKit.h

#import "AppDelegate.h"

int main(int argc, char *argv[])

{

@autoreleasepool {

return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

}

}

在main.m 中， 雖然語(yǔ)句不多，但這個(gè)語(yǔ)句直接決定了app 的生命周期。 這行代碼的作用是，將app delegate class 傳給 UIApplicationMain。 因?yàn)檎麄€(gè)App 啟動(dòng)和運(yùn)行的入口，就在UIApplicationMain中。

iOS開(kāi)發(fā) - 語(yǔ)音播報(bào)功能的實(shí)現(xiàn)

近期項(xiàng)目中有個(gè)需求就是要實(shí)現(xiàn)類(lèi)似微信或者支付寶的收款時(shí)的語(yǔ)音播報(bào)功能，于是筆者就開(kāi)始了漫長(zhǎng)的踩坑之路。

剛開(kāi)始討論實(shí)現(xiàn)方案時(shí)，安卓的小伙伴說(shuō)可以使用WebSocket + 訊飛語(yǔ)音在線合成實(shí)現(xiàn)。于是最初的幾天筆者自己也一直在這條路上走了很久，基本功能都已經(jīng)實(shí)現(xiàn)了，項(xiàng)目在前臺(tái)的時(shí)候，基本沒(méi)問(wèn)題。但是項(xiàng)目一進(jìn)入后臺(tái)大概半分鐘的時(shí)間，就無(wú)法播報(bào)了。原因是iOS項(xiàng)目如果不做任何處理的話(huà)，在進(jìn)入后臺(tái)大概30s之后，程序就會(huì)進(jìn)入類(lèi)似休眠的狀態(tài)，然后就不會(huì)再進(jìn)行任何操作了

跟安卓的同事討論之后，發(fā)現(xiàn)安卓有方法可以讓程序一直在后臺(tái)處于活躍狀態(tài)，于是筆者也開(kāi)始找尋保持項(xiàng)目后臺(tái)運(yùn)行的方法，大概有兩種

在這里我們并沒(méi)有發(fā)現(xiàn)，程序在后臺(tái)收到推送時(shí)，作相應(yīng)處理的方法，哪到底能不能收到推送后就進(jìn)行處理呢？

iOS 10 之后 iOS推出了Notification Service Extension，我們可以在收到推送之后，通過(guò)這個(gè)Extension 我們可以有三十秒的時(shí)間來(lái)對(duì)這個(gè)推送進(jìn)行處理

完成之后長(zhǎng)這樣

然后我們配置一下NotificationService

然后我們看下NotificationService.swift文件

在完成上述操作之后，再次收到推送的話(huà)，就會(huì)走NotificationService的邏輯了，可以打斷點(diǎn)或者Log測(cè)試一下

需要注意的是 在推送的內(nèi)容中 必須配置mutable-content字段，結(jié)構(gòu)大致如下

做完上邊的操作之后，我們可以知道什么時(shí)候去播報(bào)語(yǔ)音了，但是語(yǔ)音又要怎么去播報(bào)呢？

筆者這邊也是試過(guò)幾個(gè)方案，下邊一一說(shuō)來(lái)

筆者剛開(kāi)始使用訊飛發(fā)現(xiàn)不行，然后又測(cè)試了系統(tǒng)自帶的AVSpeech，發(fā)現(xiàn)也不好用，查資料才知道，蘋(píng)果在近期的版本中，停用的在NotificationService中播放語(yǔ)音的功能，之前的某個(gè)版本應(yīng)該可以這么操作。好吧，此方案Pass

既然不讓我播，那我存起來(lái)總可以了吧，測(cè)試發(fā)現(xiàn)訊飛在線生成是可以的，也可以存到本地，但。。。是，UNMutableNotificationContent的sound好像只支持提前添加到項(xiàng)目中的文件，并不支持立即生成之后存到本地，然后再設(shè)置的功能。。。

筆者在項(xiàng)目中預(yù)先生成的文件如下（語(yǔ)音包通過(guò)百度語(yǔ)音開(kāi)放平臺(tái)在線生成 百度語(yǔ)音在下生成（拉到中間就有了） ）

比如說(shuō)我要播放“支付寶到賬100元”，我就會(huì)發(fā)放多個(gè)通知，依次播放wx-pre,1,bai,yuan這幾個(gè)語(yǔ)音，連貫起來(lái)就能達(dá)到要求

筆者能力有限，暫時(shí)想到的方法就是這個(gè)，有好的方法可以多多分享，溝通

iOS 音頻系列之一：Core Audio簡(jiǎn)介

任何吸引人的游戲都少不了聲音。iOS開(kāi)發(fā)者在游戲中需要使用聲音時(shí)有多種選擇，取決于對(duì)游戲中音頻的控制需求，可以選擇簡(jiǎn)單的內(nèi)置服務(wù)，也可以選擇更高級(jí)的API（比如OpenAL）。

通過(guò)音頻API，可以實(shí)現(xiàn)流式音頻，播放簡(jiǎn)短音效，甚至模擬3d空間的音頻。有些游戲可以通過(guò)音軌讓玩家沉浸在特定的心境中玩游戲，設(shè)置鼓勵(lì)用戶(hù)使用耳機(jī)來(lái)獲得更完美的體驗(yàn)。

本系列文章中，會(huì)陸續(xù)整理近幾年來(lái)在工作中涉及到的音頻的相關(guān)知識(shí)，以算做對(duì)自己知識(shí)體系的一次梳理吧，大體包括Core Audio、OpenAL 以及Cocos2d引擎中的音效部分等三個(gè)方面。

? Core Audio 是什么?

? Core Audio 中提供的音頻服務(wù)

? Core Audio 中的有關(guān)音頻框架

? 有關(guān) Core Audio 的變化及更新

Core Audio 是什么？

Core Audio 是iOS和 MAC 的關(guān)于數(shù)字音頻處理的基礎(chǔ)，它提供應(yīng)用程序用來(lái)處理音頻的一組軟件框架，所有關(guān)于IOS音頻開(kāi)發(fā)的接口都是由Core Audio來(lái)提供或者經(jīng)過(guò)它提供的接口來(lái)進(jìn)行封裝的，按照官方的說(shuō)法是集播放、音頻處理、錄制為一體的專(zhuān)業(yè)技術(shù)，通過(guò)它我們的程序可以同時(shí)錄制，播放一個(gè)或者多個(gè)音頻流，自動(dòng)適應(yīng)耳機(jī)，藍(lán)牙耳機(jī)等硬件，響應(yīng)各種電話(huà)中斷，靜音，震動(dòng)等，甚至提供3D效果的音樂(lè)播放。

相關(guān)鏈接:

Core Audio Overview

Audio Video Starting Point

Core Audio Glossary

Core Audio中提供的音頻服務(wù)

Core Audio 本身是一個(gè)很龐大的話(huà)題，涉及到多個(gè)領(lǐng)域中的不同服務(wù)，為了更方便的使用Core Audio，通?？梢詫⑵浞指顬楦〉哪K。圖一展示了根據(jù)應(yīng)用程序服務(wù)層分解的示意圖。構(gòu)建在應(yīng)用程序棧最下面的是底層硬件。接下來(lái)往上是驅(qū)動(dòng)程序?qū)?。?gòu)建在驅(qū)動(dòng)層之上的每一層都是蘋(píng)果提供給開(kāi)發(fā)人員的應(yīng)用層服務(wù)，包括各類(lèi)音頻API和框架。

主要的幾類(lèi)服務(wù)：

Audio Unit

Audio Unit 是Core Audio 在應(yīng)用層中最底層的服務(wù)。在使用其他音頻API時(shí)，最終在底層都會(huì)調(diào)用到Audio Unit。在所有的API中，Audio Unit 是延遲最短且最靈活的，但代價(jià)就是它的使用相當(dāng)?shù)膹?fù)雜，幸運(yùn)的是在實(shí)際使用中，我們很少直接使用Audio Unit。

相關(guān)鏈接:

Audio Unit Framework Reference

相關(guān)項(xiàng)目工程：

Core Audio Utility Classes

Audio File Service

通過(guò)Audio File Service 提供的API可以打開(kāi)并讀取或者寫(xiě)入磁盤(pán)上存儲(chǔ)的文件。

Audio File Stream Service

它是對(duì)Audio File Service 的擴(kuò)展補(bǔ)充。Audio File Service 對(duì)存儲(chǔ)到磁盤(pán)上的音頻文件進(jìn)行操作，而Audio File Stream Service

并不一定關(guān)聯(lián)到某個(gè)文件上，它更適合基于網(wǎng)絡(luò)的音頻應(yīng)用程序。

Audio Conversion Service

通過(guò)它可以將數(shù)據(jù)轉(zhuǎn)換為PCM格式或者從PCM格式轉(zhuǎn)換成數(shù)據(jù)。

Extended Audio File Service

可以將它理解為Audio File Service 和 Audio File Service 的組合。通過(guò)這種API 可以直接加在并轉(zhuǎn)換音頻文件。

Audio Session Service

和Core Audio中的其他API不同，它的主要用于 iOS 系統(tǒng)中協(xié)調(diào)應(yīng)用程序之間的音頻播放的 API 的。例如，當(dāng)有電話(huà)打進(jìn)來(lái)時(shí)，音頻的播放就會(huì)被暫停；在用戶(hù)啟動(dòng)電影時(shí)，音樂(lè)的播放就會(huì)停止。我們需要使用這些 API 來(lái)確保一個(gè)應(yīng)用程序能夠正確響應(yīng)并處理這類(lèi)事件。

System Sound Service

它是一種允許播放短音效和警告的基本服務(wù)，還具有提供振動(dòng)功能的獨(dú)特能力，Core Audio中的其他任何服務(wù)都不能訪問(wèn)振動(dòng)系統(tǒng)。

Audio Queue Service

它可以對(duì)播放音頻進(jìn)行精細(xì)的控制，比如暫停、繼續(xù)、循環(huán)播放和音頻同步等，因此特別適合于播放和錄制持續(xù)時(shí)間很長(zhǎng)的音頻。在游戲中進(jìn)行語(yǔ)音敘述等情景時(shí)，需要音樂(lè)或者長(zhǎng)時(shí)間的播放文件，便會(huì)需要它。

AVFoundation

它是Core Audio中唯一基于Objective－C的框架。這個(gè)框架提供了AVAudioPlayer類(lèi)用于播放，AVAudioReconder類(lèi)用于錄音，以及AVAudioSession類(lèi)用于設(shè)置音頻回話(huà)。和其他高層API一樣，我們需要在易用性和功能之間做出權(quán)衡。如果在此框架中找不到我們需要的特性或者功能，那么就必須深入底層服務(wù)并直接使用底層的API。

相關(guān)鏈接：

AV Foundation Framework Reference

AV Foundation Programming Guide

Audio Session Programming Guide

相關(guān)的項(xiàng)目工程:

AVCaptureAudioDataOutput To AudioUnit iOS

OpenAL

和其他專(zhuān)用API不同，OpenAL是一個(gè)狂平臺(tái)的用于播放和捕捉音頻的工業(yè)標(biāo)準(zhǔn)。OpenAL更適合播放空間音頻（spatialized sound）或者定位音頻（positional sound）?？梢詫⒖臻g音頻理解成3D空間中的聲音，通過(guò)OpanAL可以對(duì)音效添加一些效果，比如位置屬性，這樣會(huì)使遠(yuǎn)程的聲音比近處的聲音聽(tīng)起來(lái)要弱一些。

相關(guān)鏈接：

OpenAL FAQ for iPhone OS

相關(guān)的項(xiàng)目工程：

oalTouch

Core Audio中的有關(guān)音頻框架

Core Audio 中的服務(wù)和框架并沒(méi)有一對(duì)一的對(duì)應(yīng)關(guān)系，應(yīng)用層的服務(wù)實(shí)際上分為5個(gè)不同的框架：Core Audio、Audio Toolbox、Audio Unit、AVFoundtaion、OpenAL。圖二中很好的展示了這些框架和服務(wù)之間的映射關(guān)系。

Audio Unit、AVFoundation和OpenAL的框架非常明了，和他們同名的服務(wù)直接對(duì)應(yīng)，其中AVFoundtion有三個(gè)Objective－C類(lèi)組成：AVAudioPlayer、AVAudioRecorder和AVAudioSession。

Audio Toolbox 框架提供了前面列出的其他剩下的應(yīng)用層服務(wù)，包括非常重要的Audio Session Service。

相關(guān)鏈接：

Audio Toolbox Framework Reference

其他相關(guān)框架：

Media Player Framework

它是一個(gè)用于音頻和視頻播放的高層級(jí)接口，它包含了一個(gè)可以在應(yīng)用中直接使用的默認(rèn)的用戶(hù)界面，可以使用它來(lái)播放用戶(hù)在 iPod 庫(kù)中的項(xiàng)目，或者播放本地文件以及網(wǎng)絡(luò)流。另外，這個(gè)框架也包括了查找用戶(hù)媒體庫(kù)中內(nèi)容的 API，同時(shí)還可以配置像是在鎖屏界面或者控制中心里的音頻控件。

相關(guān)鏈接：

Media Player Framework Reference

Core MIDI Framework

提供與MIDI設(shè)備通訊的標(biāo)準(zhǔn)方式，包括硬件鍵盤(pán)和合成器?？梢允褂眠@個(gè)框架來(lái)發(fā)送和接收MIDI消息以及與通過(guò)dock連接器或網(wǎng)絡(luò)連接到iOS設(shè)備的MIDI外設(shè)交互。

相關(guān)鏈接：

Core MIDI Framework Reference

OS 4.0以后的功能變化如下：

iOS 7.1

Support for External Media Players (CarPlay相關(guān)的)

iOS 7.0

新增 Inter-App Audio和 AudioCopy

強(qiáng)化 Media Player / AV Foundation Framework

棄用 Audio Toolbox framework內(nèi)的Audio Session API

iOS 6.0

新增 Audio UnitのComponent

強(qiáng)化 Media Player / Core Media / AV Foundation Framework

iOS 5.0

新增 Audio UnitのComponent

強(qiáng)化 Media Player / AV Foundation / AudioToolbox Frameworks

iOS 4.3

強(qiáng)化 AV Foundation

強(qiáng)化 Media Player / Audio Unit / Audio Toolbox Frameworks

iOS 4.2

新增 Core MIDI framework

強(qiáng)化 Media Player Framework

新增 AirPlay

iOS 4.1

強(qiáng)化 AV Foundation

iOS 4.0

新增 Core Media Framework

強(qiáng)化 AV Foundation

相關(guān)鏈接：What's New in iOS

分享標(biāo)題：ios電臺(tái)開(kāi)發(fā),ios 電臺(tái)
文章地址：http://muchs.cn/article40/pheheo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航、定制網(wǎng)站、微信小程序、網(wǎng)站營(yíng)銷(xiāo)、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)