iOS開發(fā)之WebRTC和SIP(轉(zhuǎn)載)

1.SIP概念理解

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名注冊(cè)、網(wǎng)站空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、榆次網(wǎng)站維護(hù)、網(wǎng)站推廣。

2.【協(xié)議學(xué)習(xí)】SIP基本場(chǎng)景分析

3.企業(yè)開源SIP項(xiàng)目

4.SIP常見問(wèn)題及處理

5.SIP基礎(chǔ)入門

6.我的IOS端SIP電話開發(fā)歷程

7.我的SIP開發(fā)之路

8.SIP協(xié)議開源SIP服務(wù)器搭建和客戶端安裝

1.WebRTC官網(wǎng)

2.大佬的筆記

3.WebRTC中文網(wǎng)

4.RTC.Blacker -Android IOS WebRTC

5.iOS下音視頻通信-基于WebRTC

6.第六章 Webrtc服務(wù)器搭建

7.webrtc學(xué)習(xí): 部署stun和turn服務(wù)器

8.webrtc編譯全過(guò)程

9.iOS下WebRTC音視頻通話（一）

10.iOS下WebRTC音視頻通話（二）-局域網(wǎng)內(nèi)音視頻通話

11.WebRTC樣本

12.iOS下音視頻通信的實(shí)現(xiàn)-基于WebRTC

1. WebRTC簡(jiǎn)介及其與SIP互通

2.SIP和WebRTC有什么不同？

iOS藍(lán)牙開發(fā)相關(guān)知識(shí)點(diǎn)和注意事項(xiàng)

總結(jié)一下藍(lán)牙開發(fā)相關(guān)的知識(shí)點(diǎn)和注意事項(xiàng)，做個(gè)筆記，也希望你們能少踩坑

(公司部分藍(lán)牙項(xiàng)目為混編項(xiàng)目，藍(lán)牙相關(guān)處理均采用了Objective-C，故本文????均采用OC，Swift處理相同)

藍(lán)牙4.0包含兩個(gè)藍(lán)牙標(biāo)準(zhǔn)，它是一個(gè)是 雙模 的標(biāo)準(zhǔn)，它包含 傳統(tǒng)藍(lán)牙部分(也稱經(jīng)典藍(lán)牙) 和 低功耗藍(lán)牙部分(BLE) , 二者適用于不同的應(yīng)用場(chǎng)景和應(yīng)用條件。他們的特點(diǎn)如下

所以藍(lán)牙4.0是集成了傳統(tǒng)藍(lán)牙和低功耗藍(lán)牙兩個(gè)標(biāo)準(zhǔn)的，并不只是低功耗藍(lán)牙

藍(lán)牙4.0支持兩種部署方式： 雙模式 和 單模式 ，雙模同時(shí)支持經(jīng)典藍(lán)牙和低功耗藍(lán)牙，而單模則只支持其中一種。

二者更多細(xì)節(jié)詳見： 傳統(tǒng)藍(lán)牙和低功耗藍(lán)牙的區(qū)別

iOS中藍(lán)牙相關(guān)功能都封裝進(jìn)了 CoreBluetooth 類中,其中有幾個(gè)常見的參數(shù)和概念

具體API參考 CoreBluetooth藍(lán)牙開發(fā)

保存到數(shù)組中的設(shè)備可通過(guò) UUID 來(lái)進(jìn)行區(qū)分。從 iOS7之后蘋果不提供外設(shè)的mac地址，外設(shè)的唯一標(biāo)識(shí)換成了由mac封裝加密后的UUID，需要注意的是不同的手機(jī)獲取同一個(gè)外設(shè)的UUID是不同的，所以在不同手機(jī)之間UUID不是唯一的，但在本機(jī)上可以作為唯一標(biāo)識(shí)(特殊情況手機(jī)刷機(jī)后也會(huì)改變UUID)。

如何獲取Mac地址

一般使用場(chǎng)景是根據(jù)Mac地址區(qū)分某個(gè)外設(shè)

注意點(diǎn)：

寫入數(shù)據(jù)時(shí)可能會(huì)遇到需要分包發(fā)送的情況，我們可以通過(guò)下面的API或許當(dāng)前特征支持的最大的單條寫入長(zhǎng)度

maxLength 一般取決于藍(lán)牙模塊內(nèi)部接收 緩沖區(qū) 的大小，很多硬件設(shè)備這個(gè)緩沖區(qū)的大小是 20 字節(jié), 這個(gè)大小也和特征的寫入權(quán)限有關(guān)，像具有寫入權(quán)限 withResponse 類的特征其大小一般為 512 字節(jié)，當(dāng)然這些都是取決于設(shè)備測(cè)的設(shè)置；

當(dāng)我們單次發(fā)送的數(shù)據(jù)字節(jié)長(zhǎng)度大于 maxLength 時(shí)，我們就需要采用分包的方式來(lái)發(fā)送數(shù)據(jù)了,

分包發(fā)送的邏輯類似于下面

這邊延時(shí)主要是設(shè)備側(cè)的接收模塊接收數(shù)據(jù)以及處理能力有限

外圍設(shè)備測(cè)和中心設(shè)備(大部分情況下是手機(jī))保持藍(lán)牙連接的狀態(tài)下，如果長(zhǎng)時(shí)間不產(chǎn)生交互，藍(lán)牙就會(huì)斷開，所以為了保持兩者持續(xù)的連接狀態(tài)，需要做?；钐幚?，也就是需要持續(xù)的發(fā)送心跳包(watchdog)。相應(yīng)的處理是使用一個(gè)定時(shí)器定時(shí)向設(shè)備側(cè)發(fā)送符合設(shè)備協(xié)議格式的心跳包。

斷開連接很簡(jiǎn)單，只需要調(diào)用 [self.centralManager cancelPeripheralConnection:peripheral] 傳入需要斷開連接的設(shè)備對(duì)象就行了。斷開連接時(shí)會(huì)自動(dòng)調(diào)用 centralManager:didDisconnectPeripheral:error: 代理方法。

按照之前的慣例，當(dāng)error為nil時(shí)表示斷開成功，error不為nil時(shí)斷開失敗。這種理解是錯(cuò)誤的。

當(dāng)你調(diào)用 cancelPeripheralConnection: 方法（主動(dòng)斷開）斷開連接時(shí)error為nil ; 沒有調(diào)用這個(gè)方法（異常斷開）而斷開時(shí)error返回的是異常斷開的原因。也可以理解為主動(dòng)調(diào)用斷開連接方法一定會(huì)斷開

接下來(lái)就是斷開重連的問(wèn)題了，對(duì)藍(lán)牙功能進(jìn)行封裝時(shí)肯定少不了斷開重連。首先斷開時(shí)可通過(guò)上面的代理方法的error是否為nil判斷是否是異常斷開，一般情況下異常斷開時(shí)是需要重連的

原因就是當(dāng)設(shè)備斷開連接后 peripheral.services 為nil了，當(dāng)然 service.characteristics 也是nil，所以需要在斷開連接時(shí)把保存這個(gè)設(shè)備對(duì)應(yīng)的服務(wù)和特征全部清除，然后在連接成功時(shí)重新過(guò)一遍發(fā)現(xiàn)服務(wù)和發(fā)現(xiàn)特征的流程就好了。

iOS7 開始，Apple加入了Beacon圍欄檢測(cè)的API, ( iBeacon-維基百科 ), 其工作方式是，配備有低功耗藍(lán)牙（BLE）通信功能的設(shè)備使用 BLE 技術(shù)向周圍發(fā)送自己特有的 ID，接收到該 ID 的應(yīng)用軟件會(huì)根據(jù)該 ID 采取一些行動(dòng)。比如，在店鋪里設(shè)置 iBeacon 通信模塊的話，便可讓 iPhone 和 iPad 上運(yùn)行一資訊告知服務(wù)器，或者由服務(wù)器向顧客發(fā)送折扣券及進(jìn)店積分, 或者公司的手機(jī)打卡，只要手機(jī)靠近打卡器一定范圍，手機(jī)測(cè)就向打開器發(fā)送打卡信息，從而自動(dòng)打卡。這種場(chǎng)景還有很多。 其中一個(gè)最重要的功能就是App的喚醒功能(殺死后也能喚醒)

舉一個(gè)我們的例子，我們的產(chǎn)品業(yè)務(wù)場(chǎng)景就是在進(jìn)入車輛以后，需要使用藍(lán)牙連接我們的后裝車載設(shè)備以采集車輛信息和駕駛行為行程等，這里有一個(gè)問(wèn)題就是在App被殺死的情況下如何喚醒App, 因?yàn)椴豢赡芤笥脩裘看味贾鲃?dòng)去打開App，這樣體驗(yàn)太差。我們的做法是通過(guò)iBeacon，當(dāng)我們的車輛點(diǎn)火以后，設(shè)備測(cè)通電，發(fā)出 iBeacon廣播 ，App實(shí)現(xiàn)監(jiān)聽iBeacon相關(guān)功能后就可以喚醒我們App，然后在相應(yīng)的回調(diào)的處理一些事情，比如通過(guò)藍(lán)牙連接設(shè)備。這里的前提條件是我們的硬件設(shè)備測(cè)包含iBeacon模塊，具有iBeacon功能，而且對(duì)iBeacon的廣播頻率也有一定的要求，長(zhǎng)了可能喚醒的功能會(huì)不穩(wěn)定，官方建議的好像是100ms，頻率超高越耗電，但可以讓手機(jī)或其它監(jiān)聽設(shè)備越快地發(fā)現(xiàn)iBeacon。標(biāo)準(zhǔn)的BLE廣播距離是100m，這使Beacon在室內(nèi)位置跟蹤場(chǎng)景下的效果更理想。

關(guān)于iBeacon更多的使用及介紹請(qǐng)參考

蘋果核 - iOS端近場(chǎng)圍欄檢測(cè)（一） ——iBeacon

iBeacon技術(shù)初探

iOS 開發(fā)中的 MVVM 模式——實(shí)用進(jìn)階篇（整理）

這篇文章主要介紹了實(shí)際應(yīng)用 MVVM 的過(guò)程中的一些問(wèn)題和解決方案

MVVM（Model View ViewModel）是一種 MVC（Model View Controller）的一種變型，來(lái)解決 MVC 中龐大復(fù)雜的 Controller 難以維護(hù)的問(wèn)題。大致上講 MVVM 有幾個(gè)要求：

MVVM 和 MVC 有很多類似的特點(diǎn)，主要的不同有：

另外一點(diǎn)，MVVM 默認(rèn) View 和 View Controller 有一個(gè)一對(duì)一的關(guān)系，一般我們把這兩個(gè)看做一個(gè)整體，會(huì)以 .swift 文件 和 Storyboard 的形式出現(xiàn)。

View Model 的工作是處理所有的展示數(shù)據(jù)的邏輯。如果一個(gè) model 中有一個(gè) NSDate 對(duì)象， NSDateFormatter 就會(huì)在 View Model 中用來(lái)設(shè)置日期的展示形式。

View Model 不能接觸任何用戶界面的部分，View Model 文件中不應(yīng)該 import UIKit ，View Controller 會(huì)觀察 View Model 去了解什么時(shí)候顯示新的數(shù)據(jù)（通過(guò) KVO 或者 FRP（Functional Reactive Programming））

MVVM 和 MVC 有一個(gè)共同的弱點(diǎn)：沒有清楚的定義應(yīng)該把網(wǎng)絡(luò)請(qǐng)求部分放在哪里。在實(shí)際操作過(guò)程中，我會(huì)把網(wǎng)絡(luò)請(qǐng)求放在 View Model 文件里面，但之后我打算把網(wǎng)絡(luò)請(qǐng)求放在自己獨(dú)立的一個(gè)類中，View Model 文件會(huì)擁有這個(gè)對(duì)象。

下面我們主要談一談實(shí)際應(yīng)用 MVVM 過(guò)程中一些挑戰(zhàn)：

例如你想構(gòu)造這樣一個(gè)常用的界面，有一個(gè) segment control 在屏幕頂部，屏幕的其他部分是一個(gè) collection view，選擇不同的 segment，就會(huì)展示不同樣式的 collection view，元素的排列順序。我們定義了一個(gè) enum 來(lái)枚舉所有的排列樣式：

那么這個(gè) enum 在 MVVM 模式中應(yīng)該放在哪里呢？因?yàn)檫@個(gè) enum 決定了數(shù)據(jù)排列的順序，每個(gè) cell 中的文字和按鈕的 title，這些都屬于展示的邏輯，所以這個(gè) enum 看起來(lái)應(yīng)該放在 view model 中。

然而，這些 layout 并不改變要展示的數(shù)據(jù)，只是決定了要呈現(xiàn)的數(shù)據(jù)的排列方式和排列順序，從這個(gè)角度上來(lái)說(shuō) enum 又應(yīng)該放在 view controller 中。

我的解決方法是把 enum 放在 view model 中，然后在 view model 中加一個(gè)對(duì)外的 Observable 或者 Signal 來(lái)表示使用了哪個(gè) layout，基于用戶選擇的 segment，view model 更新這個(gè)值，然后在 view controller 中根據(jù)相應(yīng)的 layout 改變 collection view 的樣式，view controller 也可以根據(jù)這個(gè)值來(lái)決定用哪個(gè) cell reuse identifier

iOS 開發(fā)者在用 MVVM 和 FRP 寫應(yīng)用的時(shí)候最常見的問(wèn)題可能就是 ViewModel 怎么把數(shù)據(jù)展現(xiàn)給 ViewController。當(dāng) Model 層的數(shù)據(jù)發(fā)生變化更新的時(shí)候，ViewController 需要得到通知然后做出相應(yīng)的 UI 更新，我們一般會(huì)用到兩種機(jī)制：

第一個(gè)選項(xiàng)很吸引人，因?yàn)榭梢栽?View Controller 中決定怎么選擇觀察那些 property。然而，我不推薦在 Swift 中使用第一個(gè)選項(xiàng)，因?yàn)?Swift 在 KVO 中沒有類型檢查，你需要對(duì) AnyObject 強(qiáng)制轉(zhuǎn)換類型很多次。

第二個(gè)選項(xiàng)是比較 Swift 的方式，基于 Swift 的 generics 特性，signals，sequences，observables 可以支持編譯過(guò)程中的類型檢查。

但有時(shí)候在 view model 增加這些 Signals 或者 Observables 有些困難。Swift 的初始化方法對(duì)于什么時(shí)候?qū)?property 賦值有非常明確的規(guī)定。Signals 或者 Observables 需要使用 view model 內(nèi)部的狀態(tài)，所以它們必須在 super.init() 之后才能創(chuàng)建，但是另一方面，我們?cè)谡{(diào)用 super.init() 之前保證所有 property 已經(jīng)被賦值了，包括那些 Signal/Observable property。

這是個(gè)先有雞還是先有蛋的問(wèn)題。

我采用比較簡(jiǎn)單的解決方法：定義成 var 的隱式可選類型，這樣就可以在 super.init() 之后才給 property 賦值。這不是一個(gè)完美的解決辦法。我們可以用 lazy var property 的閉包賦值來(lái)代替上面的方法。在 Swift 不斷完善和更新的過(guò)程中，大家也可以探索其他更好的辦法。

舉一個(gè)很常用的例子，用戶點(diǎn)擊 collection view 中的一個(gè) cell，跳轉(zhuǎn)到詳情頁(yè)面。用戶點(diǎn)擊的操作應(yīng)該在 view controller 中處理，具體內(nèi)容是展現(xiàn)一個(gè)新的詳情頁(yè)面。但是 view controller 不能直接接觸 models，我們要如何用 MVVM 模式實(shí)現(xiàn)這樣的用戶交互呢？

我的解決方案是利用 Swift 的閉包。首先在 view model 中定義一個(gè)閉包：

然后在 view model 中添加一個(gè) property：

接著我需要調(diào)用閉包，在 view model 中定義一個(gè)view controller 可以調(diào)用的函數(shù)，這個(gè)函數(shù)的參數(shù)是可以決定使用什么數(shù)據(jù)，一般情況下常用 index path：

現(xiàn)在當(dāng)用戶選中一個(gè) cell，會(huì)調(diào)用 view model 中的這個(gè)函數(shù)，并且傳入 index path 參數(shù)，view model 決定使用哪個(gè)數(shù)據(jù)，并調(diào)用在 view controller 中定義的閉包，例如：

最后一個(gè)問(wèn)題是怎么創(chuàng)建這個(gè) view model。我們需要傳遞一個(gè)閉包給view model 的初始化函數(shù)，然后用 lazy loading 來(lái)調(diào)用 view model 的初始化函數(shù)。

iOS項(xiàng)目常見的崩潰原因有哪些

隨著項(xiàng)目的開發(fā)進(jìn)行，對(duì)于ios程序崩潰及解決方法有一定的認(rèn)識(shí),現(xiàn)總結(jié)如下：

1：@selector提供的選擇器未定義，運(yùn)行時(shí)造成程序崩潰。

2：程序中父類對(duì)象已銷毀，但后續(xù)操作還在使用其子對(duì)象。

3：多次release，造成對(duì)象引用技術(shù)為負(fù)數(shù), 然后后續(xù)還使用。

4：在程序的聲明處指定使用assign屬性，然而在dealloc的時(shí)候卻對(duì)其進(jìn)行release。

對(duì)于崩潰問(wèn)題可以嘗試使用 Project-Profile, 連上真機(jī)，選擇Devices, 然后彈出的instruments－》Zombie. 運(yùn)行程序，直到程序崩潰。

這時(shí)候工具就會(huì)捕獲到崩潰代碼同時(shí)提供引用基數(shù)產(chǎn)生及釋放的全部過(guò)程。

如果你是通過(guò)xCode來(lái)查看崩潰的位置，有時(shí)候會(huì)不正確。這個(gè)要多加注意

iOS-UITableviewCell的重用機(jī)制和常見問(wèn)題

UITableViewCell的重用機(jī)制體現(xiàn)在-(UITableViewCell)dequeueReusableCellWithIdentifier:(NSString)identifier這個(gè)方法中，他的基本意思就是在創(chuàng)建cell的時(shí)候?yàn)槊恳粋€(gè)cell都綁定一個(gè)identifier的標(biāo)識(shí)。當(dāng)cell從我們的視覺范圍中消失的時(shí)候，這個(gè)綁定了cell的標(biāo)識(shí)就會(huì)被放到緩存池中。當(dāng)tableView需要新的cell的時(shí)候，直接先去緩存池中尋找有沒有攜帶identifier的cell，若有的話直接復(fù)用；沒有的話，才去創(chuàng)建新的cell，并綁定標(biāo)識(shí)identifier。所以從理論上講，倘若一屏最多顯示的cell個(gè)數(shù)為n個(gè)，那么需要攜帶identifier表示的cell最少只需n+1個(gè)。

查看UITableView頭文件，會(huì)找到NSMutableArray* visiableCells，和NSMutableDictnery* reusableTableCells兩個(gè)結(jié)構(gòu)。visiableCells內(nèi)保存當(dāng)前顯示的cells，reusableTableCells保存可重用的cells。

UITableView顯示之初，reusableTableCells為空，那么tableView dequeueReusableCellWithIdentifier:CellIdentifier返回nil。開始的cell都是通過(guò)[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier]來(lái)創(chuàng)建，而且cellForRowAtIndexPath只是調(diào)用最大顯示cell數(shù)的次數(shù)。

比如：有100條數(shù)據(jù)，iPhone一屏最多顯示10個(gè)cell。程序最開始顯示TableView的情況是：

1. 用[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier]創(chuàng)建10次cell，并給cell指定同樣的重用標(biāo)識(shí)(當(dāng)然，可以為不同顯示類型的cell指定不同的標(biāo)識(shí))。并且10個(gè)cell全部都加入到visiableCells數(shù)組，reusableTableCells為空。

2. 向下拖動(dòng)tableView，當(dāng)cell1完全移出屏幕，并且cell11(它也是alloc出來(lái)的，原因同上)完全顯示出來(lái)的時(shí)候。cell11加入到visiableCells，cell1移出visiableCells，cell1加入到reusableTableCells。

3. 接著向下拖動(dòng)tableView，因?yàn)閞eusableTableCells中已經(jīng)有值，所以，當(dāng)需要顯示新的cell，cellForRowAtIndexPath再次被調(diào)用的時(shí)候，tableView dequeueReusableCellWithIdentifier:CellIdentifier，返回cell1。cell1加入到visiableCells，cell1移出reusableTableCells；cell2移出visiableCells，cell2加入到reusableTableCells。之后再需要顯示的Cell就可以正常重用了。

使用過(guò)程中，并不是只有拖動(dòng)超出屏幕的時(shí)候才會(huì)更新reusableTableCells表，還有：

1. reloadData，這種情況比較特殊。一般是部分?jǐn)?shù)據(jù)發(fā)生變化，需要重新刷新cell顯示的內(nèi)容時(shí)調(diào)用。在cellForRowAtIndexPath調(diào)用中，所有cell都是重用的。我估計(jì)reloadData調(diào)用后，把visiableCells中所有cell移入reusableTableCells，visiableCells清空。cellForRowAtIndexPath調(diào)用后，再把reuse的cell從reusableTableCells取出來(lái)，放入到visiableCells。

2. reloadRowsAtIndex，刷新指定的IndexPath。如果調(diào)用時(shí)reusableTableCells為空，那么cellForRowAtIndexPath調(diào)用后，是新創(chuàng)建cell，新的cell加入到visiableCells。老的cell移出visiableCells，加入到reusableTableCells。于是，之后的刷新就有cell做reuse了。

1、重取出來(lái)的cell是有可能已經(jīng)捆綁過(guò)數(shù)據(jù)或者加過(guò)子視圖的，所以，如果有必要，要清除數(shù)據(jù)（比如textlabel的text）和remove掉add過(guò)的 子視圖（使用tag）

2、刪除重用的cell的所有子視圖，從而得到一個(gè)沒有特殊格式的cell，供其他cell重用。

//刪除cell的所有子視圖

while ([cell.contentView.subviews lastObject] != nil)

{

[(UIView*)[cell.contentView.subviews lastObject] removeFromSuperview];

}

3、為每個(gè)cell指定不同的重用標(biāo)識(shí)符(reuseIdentifier)來(lái)解決。重用機(jī)制是根據(jù)相同的標(biāo)識(shí)符來(lái)重用cell的，標(biāo)識(shí)符不同的cell不能彼此重用。

NSString *identifier = [NSString stringWithFormat:@"TimeLineCell%d%d",indexPath.section,indexPath.row];

if (cell == nil) {

cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:identifier];

}

4、重用機(jī)制調(diào)用的就是dequeueReusableCellWithIdentifier這個(gè)方法，方法的意思就是“出列可重用的cell”，因而只要將它換為cellForRowAtIndexPath（只從要更新的cell的那一行取出cell），就可以不使用重用機(jī)制，因而問(wèn)題就可以得到解決，但會(huì)浪費(fèi)一些空間

iOS10系統(tǒng)常見問(wèn)題有哪些

iOS10系統(tǒng)常見問(wèn)題有哪些？

1. iOS10系統(tǒng)采用了全新的鎖屏界面及解鎖方式，我可以不用按下Home鍵，只使用Touch ID直接解鎖iPhone嗎?

可以，具體設(shè)置方法為：設(shè)置 - 通用 - 輔助功能 - 主屏幕按鈕 - 把“輕觸打開”開關(guān)打開即可。

iOS10常見問(wèn)題

2. 升級(jí)iOS10之后，為什么鎖屏快捷回復(fù)不能用?

對(duì)于iMessage和信息的鎖屏快捷回復(fù)，部分網(wǎng)友表示需要重啟 iPhone 才能夠使用。

3. 為什么我的iMessage在發(fā)信息的.時(shí)候，沒有官方宣傳的那些放大、縮小等效果?

網(wǎng)友Manimal表示，這個(gè)功能在開啟著“減弱動(dòng)態(tài)效果”下不可使用。關(guān)于這個(gè)選項(xiàng)的設(shè)置方法為：設(shè)置 - 通用 - 輔助功能 - 減弱動(dòng)態(tài)效果 - “開啟”改為“關(guān)閉”。

iOS10常見問(wèn)題

4. 為什么我的壁紙變暗了?

如果在iOS9開啟過(guò)“降低白點(diǎn)值”，iOS10會(huì)默認(rèn)將該選項(xiàng)打開，所以就算在控制中心亮度調(diào)最亮也還是暗。想要更改的話，設(shè)置方法為：設(shè)置 - 通用 - 輔助功能 - 顯示調(diào)節(jié) - 把降低白點(diǎn)值選擇“關(guān)閉”就可以。

iOS10常見問(wèn)題

5. iMessage里面發(fā)送特效沒有屏幕和氣泡這兩個(gè)選項(xiàng)?

有可能是第三方輸入法沖突導(dǎo)致的。把第三方輸入法卸載了或者換另一個(gè)即可。

本文題目：ios開發(fā)常見問(wèn)題,ios開發(fā)經(jīng)常用到的代碼
本文鏈接：http://www.sd-ha.com/article2/dsecpic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營(yíng)銷、面包屑導(dǎo)航、網(wǎng)站收錄、網(wǎng)站排名、定制網(wǎng)站、自適應(yīng)網(wǎng)站

廣告

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