ios開發ibeacon,iOs開發判斷勾股數

iOS iBeacon 使用

最近做一個店鋪簽到獲取積分的App，用到了iBeacon，蠻好玩的一個小玩意，簡單來說iBeacon這個小設備，可以被手機通過藍牙搜索到，并能比較精確的顯示距離，和拿到該iBeacon的uuid，major，minor。其中uuid 是一個區域內的唯一標識符，用它可以區別一個公司的iBeacon，而用major和minor 來區別店鋪和具體哪臺設備。

創新互聯IDC提供業務:眉山服務器托管,成都服務器租用,眉山服務器托管,重慶服務器租用等四川省內主機托管與主機租用業務;數據中心含:雙線機房,BGP機房,電信機房,移動機房,聯通機房。

項目源碼地址感謝作者的分享

同時可以參考蘋果官方源碼，里面有設計多個uuid同時檢測

蘋果官方提供demo

在IOS 的開發中iBeacon和BLE的區別

在ios中ibeacon是基于地理位置的微定位技術（從這句話中可以得出Introduced in iOS 7, iBeacon is an exciting technology enabling new location awareness possibilities for apps.），雖然借助手機藍牙進行接收Majro、Minor，但是他們在開發工程中沒有任何關系。

ibeacon使用蘋果提供CoreLocation庫，然而在BLE在開發過程中使用CoreBluetooth庫。從上面提供的庫來看就很清楚了，特別是在IOS8之上的時候如果想使用ibeacon，必須讓用戶點擊是否允許“App使用地理位置”。如果在第一次使用ios app掃描ibeacon的時候沒有提示這句話是不可能接收到ibeacon的信號（除非ios 8.0之下）。如果是BLE則的開發過程中之需要提示用戶打開藍牙，并不要求其他的地理位置任何信息。

第一：在ios中所有的數據都是通過API獲取的，也就是說在IOS中不會看到藍牙模塊的裸數據（在這里的裸數據就代表藍牙模塊發送的16進制的數據），只能拿到蘋果公司提供的極個別的API中的數據。

第二：ble、ibeacon各使用各自的API，他們之間沒有任何對應關系。如果想使用ble就不可能獲取到ibeacon的major、minor、uuid等信息，如果使用ibeacon，沒有辦法發起鏈接請求獲取服務。

第三：在ios中ibeacon通信數據只有

這個六個屬性，其分別含義是“ proximityUUID major、minor表示ibeacon的uuid，major、minor；proximity就是蘋果提供的幾個表示距離的屬性CLProximityUnknown（沒有數據）,CLProximityImmediate（十厘米以內）,CLProximityNear（一米以內）,CLProximityFar（一米以外）”。

“在很多硬件人員的眼中認為，ibeacon和ble沒有區別啊，我們都是在同一個模塊上面開發的，只是發送的數據格式不一樣，ibeacon應該和ble沒有區別，ios可以獲取數據按照我們給的通信協議進行解析就可以啊。”這個就犯了我剛才所說的一個錯誤，在ios的開發過程中ibeacon和ble是兩個不同的東西，所有的數據都被蘋果攔截了，只給開發者特定的api可以調用。雖然從硬件上面來看沒有任何區別但是在開發過程中確實兩個不同的東西。但是有很多的廠商又想讓ble具有ibeacon的類似的功能，比如可以讓app獲取到major、minor這個又怎么辦？讓ios的app獲取ble的MAC地址等等功能（說明一下，ios是不能直接獲取ble的mac地址的）？在這里（只是我個人的意見也是我在工作中得到的一些方法）是我的建議，一般很多ble正在發送發現廣播的時候攜帶了“kCBAdvDataServiceData”信息，可以把ibeacon的major、minor放在kCBAdvDataServiceData的數據區域，然后讓app根據協議截取響應的信息。也可以放到其他的信息中，這要看公司的策略。

如果有一款iOSble的巡檢App（非ibeacon的App）可以用BLE掃描出ibeacon的信息，他的App肯定不是直接掃描ibeacon，這一點可以從兩個方面進行驗證第一：是否使用用戶的地理位置，第二：拿一個其他廠家的標準ibeacon，（ibeacon的uuid一定不要一樣，因為ios在掃描ibeacon的時候一定要指定需要掃描的uuid，換一個uuid

app都不可能掃描到）。通過上面兩點可以很好的判定app是巡檢ble還是ibeacon。

總結上面所有的觀點，如果想使用ios的app巡檢ble又能巡檢ibeacon，一定要在藍牙模塊的廣播數據中做文章。怎么做文章需要各廠商自己權衡。

iPhone用戶可以在未打開App情況下（App被用戶開啟過，并且授權使用藍牙以及定位，并且藍牙處于開啟狀態），收到IBeacon設備（藍牙外設設備）廣播的信息，并短暫的激活該App （約10秒）去執行一些方法。

根據IBeacon設備的發射范圍，確定用戶當前的狀態：進入、持續監聽、離開。然后做出不同的響應

藍牙掃一掃；區域推送；活動現場互動（配對，尋寶等）；簽到，藍牙鎖（應用內手動簽到、開鎖或者點亮屏幕即可簽到、開鎖）。

藍牙連接打印機

iOS開發中iBeacon和BLE的區別

iBeacon

在ios 中ibeacon是基于地理位置的微定位技術，雖然借助手機藍牙進行接收Majro、Minor，但是在開發工程中沒有任何關系。

ios 在ble、ibeacon 開發過程中與Android 的區別

在ios 中所有的數據都是通過API獲取的，也就是說在IOS中不會看到藍牙模塊的裸數據，只能拿到蘋果公司提供的極個別的API中的數據。

ble、ibeacon各使用各自的API，之間沒有任何對應關系。如果想使用ble就不可能獲取到ibeacon的major、minor、uuid 等信息，如果使用ibeacon，沒有辦法發起鏈接請求獲取服務。

在ios中ibeacon通信數據只有六個屬性，就是蘋果提供的幾個表示距離的屬性，是一個float類型數據。

iOS藍牙開發相關知識點和注意事項

總結一下藍牙開發相關的知識點和注意事項，做個筆記，也希望你們能少踩坑

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

藍牙4.0包含兩個藍牙標準，它是一個是雙模的標準，它包含傳統藍牙部分(也稱經典藍牙) 和低功耗藍牙部分(BLE) , 二者適用于不同的應用場景和應用條件。他們的特點如下

所以藍牙4.0是集成了傳統藍牙和低功耗藍牙兩個標準的，并不只是低功耗藍牙

藍牙4.0支持兩種部署方式：雙模式和單模式，雙模同時支持經典藍牙和低功耗藍牙，而單模則只支持其中一種。

二者更多細節詳見：傳統藍牙和低功耗藍牙的區別

iOS中藍牙相關功能都封裝進了 CoreBluetooth 類中,其中有幾個常見的參數和概念

具體API參考 CoreBluetooth藍牙開發

保存到數組中的設備可通過 UUID 來進行區分。從 iOS7之后蘋果不提供外設的mac地址，外設的唯一標識換成了由mac封裝加密后的UUID，需要注意的是不同的手機獲取同一個外設的UUID是不同的，所以在不同手機之間UUID不是唯一的，但在本機上可以作為唯一標識(特殊情況手機刷機后也會改變UUID)。

如何獲取Mac地址

一般使用場景是根據Mac地址區分某個外設

注意點：

寫入數據時可能會遇到需要分包發送的情況，我們可以通過下面的API或許當前特征支持的最大的單條寫入長度

maxLength 一般取決于藍牙模塊內部接收緩沖區的大小，很多硬件設備這個緩沖區的大小是 20 字節, 這個大小也和特征的寫入權限有關，像具有寫入權限 withResponse 類的特征其大小一般為 512 字節，當然這些都是取決于設備測的設置；

當我們單次發送的數據字節長度大于 maxLength 時，我們就需要采用分包的方式來發送數據了,

分包發送的邏輯類似于下面

這邊延時主要是設備側的接收模塊接收數據以及處理能力有限

外圍設備測和中心設備(大部分情況下是手機)保持藍牙連接的狀態下，如果長時間不產生交互，藍牙就會斷開，所以為了保持兩者持續的連接狀態，需要做保活處理，也就是需要持續的發送心跳包(watchdog)。相應的處理是使用一個定時器定時向設備側發送符合設備協議格式的心跳包。

斷開連接很簡單，只需要調用 [self.centralManager cancelPeripheralConnection:peripheral] 傳入需要斷開連接的設備對象就行了。斷開連接時會自動調用 centralManager:didDisconnectPeripheral:error: 代理方法。

按照之前的慣例，當error為nil時表示斷開成功，error不為nil時斷開失敗。這種理解是錯誤的。

當你調用 cancelPeripheralConnection: 方法（主動斷開）斷開連接時error為nil ; 沒有調用這個方法（異常斷開）而斷開時error返回的是異常斷開的原因。也可以理解為主動調用斷開連接方法一定會斷開

接下來就是斷開重連的問題了，對藍牙功能進行封裝時肯定少不了斷開重連。首先斷開時可通過上面的代理方法的error是否為nil判斷是否是異常斷開，一般情況下異常斷開時是需要重連的

原因就是當設備斷開連接后 peripheral.services 為nil了，當然 service.characteristics 也是nil，所以需要在斷開連接時把保存這個設備對應的服務和特征全部清除，然后在連接成功時重新過一遍發現服務和發現特征的流程就好了。

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

舉一個我們的例子，我們的產品業務場景就是在進入車輛以后，需要使用藍牙連接我們的后裝車載設備以采集車輛信息和駕駛行為行程等，這里有一個問題就是在App被殺死的情況下如何喚醒App, 因為不可能要求用戶每次都主動去打開App，這樣體驗太差。我們的做法是通過iBeacon，當我們的車輛點火以后，設備測通電，發出 iBeacon廣播，App實現監聽iBeacon相關功能后就可以喚醒我們App，然后在相應的回調的處理一些事情，比如通過藍牙連接設備。這里的前提條件是我們的硬件設備測包含iBeacon模塊，具有iBeacon功能，而且對iBeacon的廣播頻率也有一定的要求，長了可能喚醒的功能會不穩定，官方建議的好像是100ms，頻率超高越耗電，但可以讓手機或其它監聽設備越快地發現iBeacon。標準的BLE廣播距離是100m，這使Beacon在室內位置跟蹤場景下的效果更理想。

關于iBeacon更多的使用及介紹請參考

蘋果核 - iOS端近場圍欄檢測（一） ——iBeacon

iBeacon技術初探

BLE藍牙ios簡介（一）

隨著藍牙低功耗技術BLE（Bluetooth Low Energy）的發展，藍牙技術正在一步步成熟，如今的大部分移動設備都配備有藍牙4.0，相比之前的藍牙技術耗電量大大降低。從iOS的發展史也不難看出蘋果目前對藍牙技術也是越來越關注，例如蘋果于2013年9月發布的iOS7就配備了iBeacon技術，這項技術完全基于藍牙傳輸。但是眾所周知蘋果的設備對于權限要求也是比較高的，因此在iOS中并不能像Android一樣隨意使用藍牙進行文件傳輸（除非你已經越獄）。知道什么是藍牙之后,那么在iOS中進行藍牙傳輸應用開發常用的框架有哪幾種呢?

1、GameKit的

在ios 的開發中iBeacon和BLE的區別