ios開發(fā)策略模式,iOS策略

零基礎如何學習ios開發(fā)？

oc已全部翻譯完成視頻總4個視頻免費下載

公司主營業(yè)務：網(wǎng)站建設、成都做網(wǎng)站、移動網(wǎng)站開發(fā)等業(yè)務。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出錫林郭勒盟免費做網(wǎng)站回饋大家。

鏈接:

提取碼:64s9

oc已全部翻譯完成視頻總4個視頻|OC教程04：速建+講解.mp4|OC教程03：如何給機器人添加紋理與著色.mp4|OC教程02：場景管理.mp4|OC教程01：涂鴉的投射原理與應用.mp4

iOS中的KVC簡介

Key-Value Coding 俗稱"鍵值編碼"，蘋果官方簡稱這個模式為KVC編碼模式，也就是說可以通過一個Key去訪問某一個屬性，或者給對象去賦值，而不需要去明確存取方法，這樣就可以動態(tài)的訪問和修改對象的屬性，而不是在編譯的時候去確定，這也是iOS開發(fā)中的一大便利，其實有很多的框架和功能是用KVC去實現(xiàn)的，這個技術存在已經(jīng)很長時間了，在網(wǎng)上也有很多相關的教程去教童鞋們?nèi)绾稳ナ褂肒VC，在這里，我們就只是簡單的介紹一下KVC的底層實現(xiàn)和使用方法。

從蘋果官方對KVC的解釋來看，其實KVC在Fundation框架中占有很高的地位，諸如Core-Data之類的框架都使用到了KVC技術，我們在開發(fā)中可能常見的API有：

NSKeyValueCoding類別中還有其他的一些比較重要方法，如下:

說起KVC的執(zhí)行流程，我們有很多初級工程師都不大清楚，只知道KVC是如何使用的，而不知道KVC是怎么Key的尋找策略的。下圖我們借鑒了MJ老師的兩幅PPT來解釋

上圖我們可以看到

簡單說KVC機制在設值的時候會按照 setKey: 》_setKey 》_key 》_isKey 》key 》 isKey 順序搜索成員并進行賦值操作，但是如果開發(fā)者重寫了類方法+ (BOOL)accessInstanceVarialbesDirectly并且讓其返回NO，這樣在搜索的時候會直接從步驟 1跳轉到步驟5 。

舉一個例子,我們先創(chuàng)建一個Person類

然后用KVC賦值

最終在控制臺打印的結果是

當調(diào)用valueForKey:方法時，KVC對key的搜索順序有點不同于setValue:forKey:方法，大致步驟如下：

如

最終打印為

上述可以看出，當Key查找不到值的時候會走 valueForUndefinedKey 方法中拋出異常

類的成員變量有可能是自定義類或其他復雜數(shù)據(jù)類型，對這種成員變量可以先用KVC獲取該屬性，然后再用KVC來獲取這個自定義類的屬性，這樣一層層去獲取，但這樣比較繁瑣。對此KVC提供一個解決方案，就是鍵路徑keyPath，顧名思義就是按照路徑尋找key。主要有兩個以下兩個方法：

在上述Person中我們創(chuàng)建一個Cat類

在Cat類中我們創(chuàng)建一個屬性 name

我們?nèi)绻枰肒VC對Person對象中Cat對象賦值的話，我們就必須用到KeyPath了

KVC對于keyPath的搜索機制第一步就是分離key，用小數(shù)點.來分割key，然后再像普通key一樣按照上面介紹的順序搜索。

使用KVC過程中最常見的異常就是不小心使用了錯誤的key，或者在設值中不小心傳了nil的值，KVC有專門的方法處理這些異常。

該方法返回一個可變有序數(shù)組。對于無序的容器，可以用以下方法：

該方法返回一個可變的無序集合。同時他們也有對應的keyPath版本：

當NSDictionary對象使用KVC時，valueForKey:的表現(xiàn)行為和objectForKey:一樣，使用valueForKeyPath:可訪問多層嵌套的字典會方便點，在KVC中有兩個關于NSDictionary的方法：

當開發(fā)者需要驗證能不能用KVC設定某個值時，就需要在進行KVC賦值前驗證值value的有效性，API文檔里面提供下面的方法進行判斷值的有效性。

該方法的工作原理：先找一下你的類中是否實現(xiàn)了方法-(BOOL)validateKey:error:，如果實現(xiàn)了就會根據(jù)實現(xiàn)方法里面的自定義邏輯返回NO或者YES，如果沒有實現(xiàn)這個方法，則系統(tǒng)默認返回就是YES。

輸出結果為

這里首先調(diào)用方法 [self validateValue:value forKey:key error:error] ;，這里，由于我實現(xiàn)了方法- (BOOL)validatePersonName:(id *)value error:(out NSError * _Nullable __autoreleasing *)outError ，所以就在這里進行值value有效性的判斷，這里 [name isEqualToString:@"小明"] 我就給返回YES，否則就返回NO。

KVC在iOS開發(fā)中非常的靈活，提供了開發(fā)者更多的賦值和取值操作的選擇，它的有點明顯，缺點也有，如果key只寫錯，編寫的時候不會報錯，但是運行的時候會報錯，在實際開發(fā)中需要開發(fā)者時刻小心自己輸入的鍵值，也時刻提醒著開發(fā)者一旦使用KVC就要做容錯處理。

ios開發(fā)的設計模式有哪些

iOS開發(fā)就是為裝有iOS系統(tǒng)的設備完成應用軟件或游戲軟件的開發(fā)，ios開發(fā)的設計模式有代理模式、觀察者模式、MVC模式、單例模式、策略模式和工廠模式。

ios開發(fā) nslock怎么用

先來看看官方的文檔，是這樣寫的：In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself.翻譯過來是：在多線程應用中，Notification在哪個線程中post，就在哪個線程中被轉發(fā)，而不一定是在注冊觀察者的那個線程中。也就是說，Notification的發(fā)送與接收處理都是在同一個線程中。為了說明這一點，我們先來看一個示例：代碼清單1：Notification的發(fā)送與處理@implementation ViewController- (void)viewDidLoad {[super viewDidLoad];NSLog(@"current thread = %@", [NSThread currentThread]);[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil];dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{[[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil];});}- (void)handleNotification:(NSNotification *)notification{NSLog(@"current thread = %@", [NSThread currentThread]);NSLog(@"test notification");}@end其輸出結果如下：2015-03-11 22:05:12.856 test[865:45102] current thread = {number = 1, name = main}2015-03-11 22:05:12.857 test[865:45174] current thread = {number = 2, name = (null)}2015-03-11 22:05:12.857 test[865:45174] test notification可以看到，雖然我們在主線程中注冊了通知的觀察者，但在全局隊列中post的Notification，并不是在主線程處理的。所以，這時候就需要注意，如果我們想在回調(diào)中處理與UI相關的操作，需要確保是在主線程中執(zhí)行回調(diào)。這時，就有一個問題了，如果我們的Notification是在二級線程中post的，如何能在主線程中對這個Notification進行處理呢?或者換個提法，如果我們希望一個Notification的post線程與轉發(fā)線程不是同一個線程，應該怎么辦呢?我們看看官方文檔是怎么說的：For example, if an object running in a background thread is listening for notifications from the user interface, such as a window closing, you would like to receive the notifications in the background thread instead of the main thread. In these cases, you must capture the notifications as they are delivered on the default thread and redirect them to the appropriate thread.這里講到了“重定向”，就是我們在Notification所在的默認線程中捕獲這些分發(fā)的通知，然后將其重定向到指定的線程中。一種重定向的實現(xiàn)思路是自定義一個通知隊列(注意，不是NSNotificationQueue對象，而是一個數(shù)組)，讓這個隊列去維護那些我們需要重定向的Notification。我們?nèi)匀皇窍衿匠Ｒ粯尤プ砸粋€通知的觀察者，當Notification來了時，先看看post這個Notification的線程是不是我們所期望的線程，如果不是，則將這個Notification存儲到我們的隊列中，并發(fā)送一個信號(signal)到期望的線程中，來告訴這個線程需要處理一個Notification。指定的線程在收到信號后，將Notification從隊列中移除，并進行處理。官方文檔已經(jīng)給出了示例代碼，在此借用一下，以測試實際結果：代碼清單2：在不同線程中post和轉發(fā)一個Notification@interface ViewController ()@property (nonatomic) NSMutableArray *notifications; // 通知隊列@property (nonatomic) NSThread *notificationThread; // 期望線程@property (nonatomic) NSLock *notificationLock; // 用于對通知隊列加鎖的鎖對象，避免線程沖突@property (nonatomic) NSMachPort *notificationPort; // 用于向期望線程發(fā)送信號的通信端口@end@implementation ViewController- (void)viewDidLoad {[super viewDidLoad];NSLog(@"current thread = %@", [NSThread currentThread]);// 初始化self.notifications = [[NSMutableArray alloc] init];self.notificationLock = [[NSLock alloc] init];self.notificationThread = [NSThread currentThread];self.notificationPort = [[NSMachPort alloc] init];self.notificationPort.delegate = self;// 往當前線程的run loop添加端口源// 當Mach消息到達而接收線程的run loop沒有運行時，則內(nèi)核會保存這條消息，直到下一次進入run loop[[NSRunLoop currentRunLoop] addPort:self.notificationPortforMode:(__bridge NSString *)kCFRunLoopCommonModes];[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(processNotification:) name:@"TestNotification" object:nil];dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{[[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil];});}- (void)handleMachMessage:(void *)msg {[self.notificationLock lock];while ([self.notifications count]) {NSNotification *notification = [self.notifications objectAtIndex:0];[self.notifications removeObjectAtIndex:0];[self.notificationLock unlock];[self processNotification:notification];[self.notificationLock lock];};[self.notificationLock unlock];}- (void)processNotification:(NSNotification *)notification {if ([NSThread currentThread] != _notificationThread) {// Forward the notification to the correct thread.[self.notificationLock lock];[self.notifications addObject:notification];[self.notificationLock unlock];[self.notificationPort sendBeforeDate:[NSDate date]components:nilfrom:nilreserved:0];}else {// Process the notification here;NSLog(@"current thread = %@", [NSThread currentThread]);NSLog(@"process notification");}}@end運行后，其輸出如下：2015-03-11 23:38:31.637 test[1474:92483] current thread = {number = 1, name = main}2015-03-11 23:38:31.663 test[1474:92483] current thread = {number = 1, name = main}2015-03-11 23:38:31.663 test[1474:92483] process notification可以看到，我們在全局dispatch隊列中拋出的Notification，如愿地在主線程中接收到了。這種實現(xiàn)方式的具體解析及其局限性大家可以參考官方文檔Delivering Notifications To Particular Threads，在此不多做解釋。當然，更好的方法可能是我們自己去子類化一個NSNotificationCenter，或者單獨寫一個類來處理這種轉發(fā)。NSNotificationCenter的線程安全性蘋果之所以采取通知中心在同一個線程中post和轉發(fā)同一消息這一策略，應該是出于線程安全的角度來考量的。官方文檔告訴我們，NSNotificationCenter是一個線程安全類，我們可以在多線程環(huán)境下使用同一個NSNotificationCenter對象而不需要加鎖。原文在Threading Programming Guide中，具體如下：The following classes and functions are generally considered to be thread-safe. You can use the same instance from multiple threads without first acquiring a lock.NSArray...NSNotificationNSNotificationCenter我們可以在任何線程中添加/刪除通知的觀察者，也可以在任何線程中post一個通知。NSNotificationCenter在線程安全性方面已經(jīng)做了不少工作了，那是否意味著我們可以高枕無憂了呢?再回過頭來看看第一個例子，我們稍微改造一下，一點一點來：代碼清單3：NSNotificationCenter的通用模式@interface Observer : NSObject@end@implementation Observer- (instancetype)init{self = [super init];if (self){_poster = [[Poster alloc] init];[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil]}return self;}- (void)handleNotification:(NSNotification *)notification{NSLog(@"handle notification ");}- (void)dealloc{[[NSNotificationCenter defaultCenter] removeObserver:self];}@end// 其它地方[[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil];上面的代碼就是我們通常所做的事情：添加一個通知監(jiān)聽者，定義一個回調(diào)，并在所屬對象釋放時移除監(jiān)聽者;然后在程序的某個地方post一個通知。簡單明了，如果這一切都是發(fā)生在一個線程里面，或者至少dealloc方法是在-postNotificationName:的線程中運行的(注意：NSNotification的post和轉發(fā)是同步的)，那么都OK，沒有線程安全問題。但如果dealloc方法和-postNotificationName:方法不在同一個線程中運行時，會出現(xiàn)什么問題呢?我們再改造一下上面的代碼：代碼清單4：NSNotificationCenter引發(fā)的線程安全問題#pragma mark - Poster@interface Poster : NSObject@end@implementation Poster- (instancetype)init{self = [super init];if (self){[self performSelectorInBackground:@selector(postNotification) withObject:nil];}return self;}- (void)postNotification{[[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil];}@end#pragma mark - Observer@interface Observer : NSObject{Poster *_poster;}@property (nonatomic, assign) NSInteger i;@end@implementation Observer- (instancetype)init{self = [super init];if (self){_poster = [[Poster alloc] init];[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil];}return self;}- (void)handleNotification:(NSNotification *)notification{NSLog(@"handle notification begin");sleep(1);NSLog(@"handle notification end");self.i = 10;}- (void)dealloc{[[NSNotificationCenter defaultCenter] removeObserver:self];NSLog(@"Observer dealloc");}@end#pragma mark - ViewController@implementation ViewController- (void)viewDidLoad {[super viewDidLoad];__autoreleasing Observer *observer = [[Observer alloc] init];}@end這段代碼是在主線程添加了一個TEST_NOTIFICATION通知的監(jiān)聽者，并在主線程中將其移除，而我們的NSNotification是在后臺線程中post的。在通知處理函數(shù)中，我們讓回調(diào)所在的線程睡眠1秒鐘，然后再去設置屬性i值。這時會發(fā)生什么呢?我們先來看看輸出結果：2015-03-14 00:31:41.286 SKTest[932:88791] handle notification begin2015-03-14 00:31:41.291 SKTest[932:88713] Observer dealloc2015-03-14 00:31:42.361 SKTest[932:88791] handle notification end(lldb)// 程序在self.i = 10處拋出了"Thread 6: EXC_BAD_ACCESS(code=EXC_I386_GPFLT)"經(jīng)典的內(nèi)存錯誤，程序崩潰了。其實從輸出結果中，我們就可以看到到底是發(fā)生了什么事。我們簡要描述一下：當我們注冊一個觀察者是，通知中心會持有觀察者的一個弱引用，來確保觀察者是可用的。主線程調(diào)用dealloc操作會讓Observer對象的引用計數(shù)減為0，這時對象會被釋放掉。后臺線程發(fā)送一個通知，如果此時Observer還未被釋放，則會向其轉發(fā)消息，并執(zhí)行回調(diào)方法。而如果在回調(diào)執(zhí)行的過程中對象被釋放了，就會出現(xiàn)上面的問題。當然，上面這個例子是故意而為之，但不排除在實際編碼中會遇到類似的問題。雖然NSNotificationCenter是線程安全的，但并不意味著我們在使用時就可以保證線程安全的，如果稍不注意，還是會出現(xiàn)線程問題。那我們該怎么做呢?這里有一些好的建議：盡量在一個線程中處理通知相關的操作，大部分情況下，這樣做都能確保通知的正常工作。不過，我們無法確定到底會在哪個線程中調(diào)用dealloc方法，所以這一點還是比較困難。注冊監(jiān)聽都時，使用基于block的API。這樣我們在block還要繼續(xù)調(diào)用self的屬性或方法，就可以通過weak-strong的方式來處理。具體大家可以改造下上面的代碼試試是什么效果。使用帶有安全生命周期的對象，這一點對象單例對象來說再合適不過了，在應用的整個生命周期都不會被釋放。使用代理。

【轉】一套iOS平臺設計稿，搞定界面適配

加上Android生態(tài)中紛繁復雜的各種奇葩尺寸，現(xiàn)在APP設計開發(fā)必須考慮適配大、中、小三種屏幕。所以如何做到交付一套設計稿解決適配大中小三屏的問題？設計和開發(fā)之間采用什么協(xié)作模式？一個基本思路是：

1、選擇一種尺寸作為設計和開發(fā)基準；

2、定義一套適配規(guī)則，自動適配剩下兩種尺寸；

3、特殊適配效果給出設計效果。

手機淘寶的iPhone 6/iPhone 6 Plus適配版本即將提交App store審核。先曬一下我們采用的協(xié)作模式，再慢慢說明原委。

第一步，視覺設計階段，設計師按寬度750px（iPhone 6）做設計稿，除圖片外所有設計元素用矢量路徑來做。設計定稿后在750px的設計稿上做標注，輸出標注圖。同時等比放大1.5倍生成寬度1125px的設計稿，在1125px的稿子里切圖。

第二步，輸出兩個交付物給開發(fā)工程師：一個是程序用到的@3x切圖資源，另一個是寬度750px的設計標注圖。

第三步，開發(fā)工程師拿到750px標注圖和@3x切圖資源，完成iPhone 6（375pt）的界面開發(fā)。此階段不能用固定寬度的方式開發(fā)界面，得用自動布局（auto layout），方便后續(xù)適配到其它尺寸。

第四步，適配調(diào)試階段，基于iPhone 6的界面效果，分別向上向下調(diào)試iPhone 6 plus（414pt）和iPhone 5S及以下（320pt）的界面效果。由此完成大中小三屏適配。

為什么選擇iPhone 6作為基準尺寸？

當面對大中小三種屏幕需要適配的時候，很容易想到先做好一種屏幕，再去適配剩下兩種屏幕。第一個決定是到底以哪種屏幕作為設計和開發(fā)的基準尺寸。我們選擇中間尺寸的iPhone 6（750px/375pt）作為基準，基于幾個原因：

1、從中間尺寸向上和向下適配的時候界面調(diào)整的幅度最小。375pt下的設計效果適配到414pt和320pt偏差不會太大。假設以414pt為基準做出很優(yōu)雅的設計，到320pt可能元素之間比例就不是那么回事了，比如圖片和文字之間視覺比例可能失調(diào)。

2、iPhone 6 plus有兩種顯示模式，標準模式分辨率為1242x2208，放大模式分辨率為1125x2001（即iPhone 6的1.5倍）。可見官方系統(tǒng)里iPhone 6和iPhone 6 plus分辨率之間就存在1.5倍的倍率關系。很多情況下這兩種尺寸可以用1.5倍直接等比適配。

3、1242x2208這個奇葩的數(shù)值是蘋果官方都不愿意公開宣傳的一個分辨率，不便于記憶和計算柵格。640x1136雖然是廣泛應用的一個分辨率，但是大屏時代依然以小尺寸為設計基準顯然不合時宜，設計師會停留在小屏的視角做設計。

所以，iPhone6的750x1334是最適合基準尺寸。

只交付一套設計稿，默認用什么規(guī)則來適配？

前文提到適配策略是先選擇iPhone 6作為基準設計尺寸，然后通過一套適配規(guī)則自動適配到另外兩種尺寸。這套適配規(guī)則總結起來就一句話：文字流式，控件彈性，圖片等比縮放。

控件彈性指的是，navigation、cell、bar等適配過程中垂直方向上高度不變；水平方向?qū)挾茸兓瘯r，通過調(diào)整元素間距或元素右對齊的方式實現(xiàn)自適應。這樣屏幕越大，在垂直方向上可以顯示更多內(nèi)容，發(fā)揮大屏幕的優(yōu)勢。

按照上述默認適配規(guī)則，大中小三種屏幕顯示效果均相同。有時候想在大屏幕顯示更多內(nèi)容，需要設計出特殊適配效果。比如App store首頁焦點圖，從iPhone 6適配到iPhone 6 plus時焦點圖尺寸和排版做了特殊處理。底下應用列表也從一排3+個變成一排4+個，真正實現(xiàn)了大屏幕顯示更多內(nèi)容的理念。這些就需要設計師給出相應設計稿。

iOS 低功耗藍牙4.0開發(fā)指南。

1.什么是藍牙4.0，藍牙其它標準又是什么？

詳細描述：低功耗藍牙(Low Energy; LE)，又視為Bluetooth Smart或藍牙核心規(guī)格4.0版本。其特點具備節(jié)能、便于采用，是藍牙技術專為物聯(lián)網(wǎng)(Internet of Things; IOT)開發(fā)的技術版本。所以它最主要的特點是低功耗，普及率高。現(xiàn)在所說的藍牙設備，大部分都是在說4.0設備，ble也特指4.0設備。在4.0之前重要的版本有 2.1版本-基本速率／增強數(shù)據(jù)率(BR/EDR) 和 3.0 高速藍牙版本，這些統(tǒng)稱為經(jīng)典藍牙。4.0還有4.1和4.2的小版本，其中4.2版本對傳輸速率做了進一步他提升，提高了2.5倍，蘋果從iphone6開始使用4.2，最新的藍牙標準為藍牙5.0，其中最大的特點連接范圍擴大了4倍，速度又提高了2倍，無連接數(shù)據(jù)廣播能力提高了8倍，增加了藍牙組網(wǎng)的能力。

2.藍牙開發(fā)必須知道的概念。

2.1.1 central和peripheral：

藍牙應用開發(fā)中，存在兩種角色，分別是central和peripheral(p?’r?f?r?l) ,中文就是中心和外設。比如手機去連接智能設備，那手機就是central，智能設備就是peripheral。大多時候都是central去連接peripheral的場景。

2.1.2 廣播和連接:

peripheral會發(fā)出廣播,central掃描到廣播后，可以對設備進行連接，發(fā)出connect請求，peripheral接收到請求后，同意連接后，central和peripheral就建立了連接。

2.1.3?連接后的操作:

write，read，notify，indecate， response or not …

indecate和notify的區(qū)別就在于，indecate是一定會收到數(shù)據(jù)，notify有可能會丟失數(shù)據(jù)（不會有central收到數(shù)據(jù)的回應），write也分為response和noresponse，如果是response，那么write成功回收到peripheral的確認消息，但是會降低寫入的速率。

2.1.4 協(xié)議:

每個具體的智能設備，都約定了一組數(shù)據(jù)格式，這個就是數(shù)據(jù)協(xié)議，例如手環(huán)中獲取到數(shù)據(jù)0X001023，其中第2位到第5位表示步數(shù)，那么就2310就是步數(shù)的16進制的數(shù)據(jù)，轉換成10進制就是8976步，需要注意的是，設備端都是小端模式，所以取4位時候，高字節(jié)在前低字節(jié)在后。

3. iOS藍牙應用的一般開發(fā)流程。

4. 藍牙的數(shù)據(jù)交互。

write，read，notify，indecate， response or not … 都是容易理解的，indecate和notify對應的是長連接，建立indecate后，peripheral可以隨時往central發(fā)送數(shù)據(jù)。

對于一個charateristic，他的讀寫訂閱的權限是peripheral決定的，熟悉可以被同時設置，一般會根據(jù)外設的功能來決定。

5.藍牙ota DFU。

藍牙ota,DFU（Device Firmware Update）指的是藍牙設備的固件升級，其實是一整套流程，不同的藍牙芯片，ota的流程有不同之處，我這里用ti的芯片舉例。步驟為：切系統(tǒng)(bootloader mode)，重啟，傳輸數(shù)據(jù)，驗證數(shù)據(jù)，切系統(tǒng)，重啟，完成。

其中數(shù)據(jù)傳輸也會分成很多節(jié)去發(fā)送，沒法送一段數(shù)據(jù)，做一次數(shù)據(jù)校驗。

6.ota存在的問題。

每個智能設備的速率，功耗，存儲都會有很多限制，導致很多設備會自己去實現(xiàn)ota的功能，自定義流程和數(shù)據(jù)傳輸方式，導致許多設備都是有自己私有的ota模式和協(xié)議，所以在做開發(fā)的時候，要仔細閱讀設備協(xié)議中對ota的描述。

7.如何做自動重連。

只需要在設備斷開連接的委托方法中，重新調(diào)用gatt.connet或者是centralManager.connet方法就可以了，無論當時設備是否有點，是否在周圍，當設備再次開會或者連接到可連接范圍內(nèi)，都會自動被連上。

8.連接失敗處理。

分兩個平臺來說，iOS端也有連接失敗的委托，但是好像幾乎不會發(fā)生這種情況，而對于同款設備，android常常會出現(xiàn)連接失敗的情況，status != BluetoothGatt.GATT_SUCCESS，android端開發(fā)請不要把連接失敗和斷開連接放在一塊處理，因為斷開連接可以直接嘗試重新連接，而連接失敗后嘗試重新連接，需要加一些延時，并且需要gatt.close，清空一下狀態(tài)，否則會把gatt阻塞導致手機不重啟藍牙就再也無法連接任何設備的情況。

9.后臺運行。

iOS后來運行，需要設備中info.Plist權限，key:Required background modes ,value: bluetooth-central(手機作為central) , bluetooth-peripheral。

10.同時連接多個設備。

使用同一個CBCentralManager，通過進入委托的peripheral的identifier區(qū)分不同的設備，進行不同的操作和處理。

11.掃描廣播包。

所有外設，只有在發(fā)出廣播包的情況下，才能被central發(fā)現(xiàn)，絕大多數(shù)情況下，外設被連接后就不會發(fā)出廣播（也有例外），很多人遇到無法找到設備的問題，大多屬于這種情況。

12.提高藍牙連接速度。

無論是iOS，還是android，都可以通過已綁定的設備，在不開啟掃描的情況下進行快速連接，iOS需要的參數(shù)是peripheral的identifier，android需要mac地址。但android和iOS還是有一些區(qū)別的，比如iOS不能拿到已綁定的設備list，但是可以通過UUID去拿到peripheral的實例。而android可以拿到已綁定的設備list。android綁定過程需要手動調(diào)用createBond的方法，而iOS在連接成功一次后會自動綁定。 android在處理createBond時，常常會應為不同手機平臺，不同設備，會產(chǎn)生兼容性的問題，這點需要注意。

13.定向掃描。

在掃描時候可以傳入serviceUUID，這樣可以掃描到特定條件的設備，提高掃描的速度，排除干擾。

14.如何獲取mac地址。

而iOS出于蘋果的安全策略問題，無法直接獲得mac地址，只能得到一個mac地址換算出來的identifier。

本文標題：ios開發(fā)策略模式,iOS策略
標題URL：http://chinadenli.net/article35/dsgdosi.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、面包屑導航、網(wǎng)站制作、品牌網(wǎng)站制作、云服務器、品牌網(wǎng)站建設

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

猜你還喜歡下面的內(nèi)容