OC的理解與特性
OC作為一門面向?qū)ο蟮恼Z言蒂教,自然具有面向?qū)ο蟮恼Z言特性:封裝巍举、繼承、多態(tài)凝垛。它既具有靜態(tài)語言的特性(如C++)懊悯,又有動態(tài)語言的效率(動態(tài)綁定、動態(tài)加載等)梦皮√糠郑總體來講,OC確實是一門不錯的編程語言,
Objective-C具有相當多的動態(tài)特性沈堡,表現(xiàn)為三方面:動態(tài)類型(Dynamic typing)代芜、動態(tài)綁定(Dynamic binding)和動態(tài)加載(Dynamic loading)钉蒲。動態(tài)——必須到運行時(run time)才會做的一些事情岖妄。
動態(tài)類型:即運行時再決定對象的類型型将,這種動態(tài)特性在日常的應用中非常常見,簡單來說就是id類型荐虐。事實上七兜,由于靜態(tài)類型的固定性和可預知性,從而使用的更加廣泛福扬。靜態(tài)類型是強類型腕铸,而動態(tài)類型屬于弱類型,運行時決定接受者铛碑。
動態(tài)綁定:基于動態(tài)類型狠裹,在某個實例對象被確定后,其類型便被確定了汽烦,該對象對應的屬性和響應消息也被完全確定涛菠。
動態(tài)加載:根據(jù)需求加載所需要的資源,最基本就是不同機型的適配撇吞,例如俗冻,在Retina設備上加載@2x的圖片,而在老一些的普通蘋設備上加載原圖牍颈,讓程序在運行時添加代碼模塊以及其他資源迄薄,用戶可根據(jù)需要加載一些可執(zhí)行代碼和資源,而不是在啟動時就加載所有組件煮岁,可執(zhí)行代碼可以含有和程序運行時整合的新類讥蔽。
簡述內(nèi)存管理基本原則
之前:OC內(nèi)存管理遵循“誰創(chuàng)建,誰釋放画机,誰引用勤篮,誰管理”的機制,當創(chuàng)建或引用一個對象的時候色罚,需要向她發(fā)送alloc碰缔、copy、retain消息戳护,當釋放該對象時需要發(fā)送release消息金抡,當對象引用計數(shù)為0時,系統(tǒng)將釋放該對象腌且,這是OC的手動管理機制(MRC)梗肝。
目前:iOS 5.0之后引用自動管理機制——自動引用計數(shù)(ARC),管理機制與手動機制一樣铺董,只是不再需要調(diào)用retain巫击、release禀晓、autorelease;它編譯時的特性坝锰,當你使用ARC時粹懒,在適當位置插入release和autorelease;它引用strong和weak關鍵字顷级,strong修飾的指針變量指向?qū)ο髸r凫乖,當指針指向新值或者指針不復存在,相關聯(lián)的對象就會自動釋放弓颈,而weak修飾的指針變量指向?qū)ο竺毖浚攲ο蟮膿碛姓咧赶蛐轮祷蛘卟淮嬖跁rweak修飾的指針會自動置為nil。
如果使用alloc翔冀、copy(mutableCopy)或者retian一個對象時,你就有義務,向它發(fā)送一條release或者autorelease消息导街。其他方法創(chuàng)建的對象,不需要由你來管理內(nèi)存。
向一個對象發(fā)送一條autorelease消息,這個對象并不會立即銷毀, 而是將這個對象放入了自動釋放池,待池子釋放時,它會向池中每一個對象發(fā)送 一條release消息,以此來釋放對象.
向一個對象發(fā)送release消息,并不意味著這個對象被銷毀了,而是當這個對象的引用計數(shù)為0時,系統(tǒng)才會調(diào)用dealloc方法,釋放該對象和對象本身它所擁有的實例纤子。
其他注意事項
如果一個對象有一個_strong類型的指針指向著菊匿,找個對象就不會被釋放。如果一個指針指向超出了它的作用域计福,就會被指向nil。如果一個指針被指向nil徽职,那么它原來指向的對象就被釋放了象颖。當一個視圖控制器被釋放時,它內(nèi)部的全局指針會被指向nil姆钉。用法“:不管全局變量還是局部變量用_strong描述就行说订。
局部變量:出了作用域,指針會被置為nil潮瓶。
方法內(nèi)部創(chuàng)建對象陶冷,外部使用需要添加_autorelease;
連線的時候,用_weak描述毯辅。
代理使用unsafe_unretained就相當于assign埂伦;
block中為了避免循環(huán)引用問題,使用_weak描述思恐;
聲明屬性時沾谜,不要以new開頭。如果非要以new開頭命名屬性的名字胀莹,需要自己定制get方法名基跑,如
1
@property(getter=theString)?NSString?*?newString;
如果要使用自動釋放池,用@autoreleasepool{}
ARC只能管理Foundation框架的變量描焰,如果程序中把Foundation中的變量強制換成COre Foundation中的變量需要交換管理權(quán)媳否;
在非ARC工程中采用ARC去編譯某些類:-fobjc-arc。
在ARC下的工程采用非ARC去編譯某些類:-fno-fobjc-arc。
如何理解MVC設計模式
MVC是一種架構(gòu)模式篱竭,M表示MOdel力图,V表示視圖View,C表示控制器Controller:
Model負責存儲室抽、定義搪哪、操作數(shù)據(jù);
View用來展示書給用戶坪圾,和用戶進行操作交互晓折;
Controller是Model和View的協(xié)調(diào)者,Controller把Model中的數(shù)據(jù)拿過來給View用兽泄。Controller可以直接與Model和View進行通信漓概,而View不能和Controller直接通信。View與Controller通信需要利用代理協(xié)議的方式病梢,當有數(shù)據(jù)更新時胃珍,MOdel也要與Controller進行通信,這個時候就要用Notification和KVO蜓陌,這個方式就像一個廣播一樣觅彰,MOdel發(fā)信號,Controller設置監(jiān)聽接受信號钮热,當有數(shù)據(jù)更新時就發(fā)信號給Controller填抬,Model和View不能直接進行通信,這樣會違背MVC設計模式隧期。
如何理解MVVM設計模式飒责。
ViewModel層,就是View和Model層的粘合劑仆潮,他是一個放置用戶輸入驗證邏輯宏蛉,視圖顯示邏輯,發(fā)起網(wǎng)絡請求和其他各種各樣的代碼的極好的地方性置。說白了拾并,就是把原來ViewController層的業(yè)務邏輯和頁面邏輯等剝離出來放到ViewModel層。
View層鹏浅,就是ViewController層辟灰,他的任務就是從ViewModel層獲取數(shù)據(jù),然后顯示篡石。
如需了解更多芥喇,請查看這篇文章。
Objective-C 中是否支持垃圾回收機制凰萨?
OC是支持垃圾回收機制的(Garbage collection簡稱GC),但是apple的移動終端中,是不支持GC的,Mac桌面系統(tǒng)開發(fā)中是支持的.
移動終端開發(fā)是支持ARC(Automatic Reference Counting的簡稱),ARC是在IOS5之后推出的新技術,它與GC的機制是不同的继控。我們在編寫代碼時, 不需要向?qū)ο蟀l(fā)送release或者autorelease方法,也不可以調(diào)用delloc方法,編譯器會在合適的位置自動給用戶生成release消息(autorelease),ARC 的特點是自動引用技術簡化了內(nèi)存管理的難度.
協(xié)議的基本概念和協(xié)議中方法默認為什么類型械馆。
OC中的協(xié)議是一個方法列表,且多少有點相關。它的特點是可以被任何類使用(實現(xiàn)),但它并不是類(這里我們需要注意),自身不會實現(xiàn)這樣方法, 而是又其他人來實現(xiàn)協(xié)議經(jīng)常用來實現(xiàn)委托對象(委托設計模式)武通。如果一個類采用了一個協(xié)議,那么它必須實現(xiàn)協(xié)議中必須需要實現(xiàn)的方法,在協(xié)議中的方法默認是必須實現(xiàn)(@required),添加關鍵字@optional,表明一旦采用該協(xié)議,這些“可選”的方法是可以選擇不實現(xiàn)的霹崎。
簡述類目category優(yōu)點和缺點。
優(yōu)點:
不需要通過增加子類而增加現(xiàn)有類的行為(方法),且類目中的方法與原始類方法基本沒有區(qū)別;
通過類目可以將龐大一個類的方法進行劃分,從而便于代碼的日后的維護冶忱、更新以及提高代碼的閱讀性;
缺點:
無法向類目添加實例變量,如果需要添加實例變量,只能通過定義子類的方式;
類目中的方法與原始類以及父類方法相比具有更高優(yōu)先級,如果覆蓋父類的方法,可能導致super消息的斷裂尾菇。因此,最好不要覆蓋原始類中的方法。
類別的作用
給系統(tǒng)原有類添加方法囚枪,不能擴展屬性派诬。如果類別中方法的名字跟系統(tǒng)的方法名一樣,在調(diào)用的時候類別中的方法優(yōu)先級更高链沼;
分散類的實現(xiàn):如:
1
2+?(NSIndexPath?*)indexPathForRow:(NSInteger)row
inSection:(NSInteger)section
原本屬于NSIndexPath的方法默赂,但因為這個方法經(jīng)常使用的表的時候調(diào)用、跟表的關系特別密切括勺,因此把這個方法一類別的形式缆八、聲明在UITableView.h中。
聲明私有方法疾捍,某一個方法只實現(xiàn)奈辰,不聲明,相當于私有方法乱豆。
類別不能聲明變量奖恰,類別不可以直接添加屬性。property描述setter方法咙鞍,就不會報錯。
循環(huán)引用的產(chǎn)生原因趾徽,以及解決方法续滋。
產(chǎn)生原因:如下圖所示,對象A和對象B相互引用了對方作為自己的成員變量孵奶,只有自己銷毀的時候才能將成員變量的引用計數(shù)減1疲酌。對象A的銷毀依賴于對象B的銷毀,同時對象B銷毀也依賴與對象A的銷毀了袁,從而形成循環(huán)引用朗恳,此時,即使外界沒有任何指針訪問它载绿,它也無法釋放粥诫。
循環(huán)引用示例圖
多個對象間依然會存在循環(huán)引用問題,形成一個環(huán)崭庸,在編程中怀浆,形成的環(huán)越大越不容易察覺谊囚,如下圖所示:
多個對象引用示例圖
解決方法:
事先知道存在循環(huán)引用的地方,在合理的位置主動斷開一個引用执赡,是對象回收镰踏;
使用弱引用的方法。
鍵路徑(keyPath)沙合、鍵值編碼(KVC)和鍵值觀察(KVO)
鍵路徑
在一個給定的實體中,同一個屬性的所有值具有相同的數(shù)據(jù)類型奠伪。
鍵-值編碼技術用于進行這樣的查找—它是一種間接訪問對象屬性的機制。 - 鍵路徑是一個由用點作分隔符的鍵組成的字符串,用于指定一個連接在一起的對象性質(zhì)序列首懈。第一個鍵的性質(zhì)是由先前的性質(zhì)決定的,接下來每個鍵的值也是相對于其前面的性質(zhì)绊率。
鍵路徑使您可以以獨立于模型實現(xiàn)的方式指定相關對象的性質(zhì)。通過鍵路徑,您可以指定對象圖中的一個任意深度的路徑,使其指向相關對象的特定屬性猜拾。
鍵值編碼KVC
鍵值編碼是一種間接訪問對象的屬性使用字符串來標識屬性即舌,而不是通過調(diào)用存取方法,直接或通過實例變量訪問的機制挎袜,非對象類型的變量將被自動封裝或者解封成對象顽聂,很多情況下會簡化程序代碼;
KVC的缺點:一旦使用 KVC 你的編譯器無法檢查出錯誤,即不會對設置的鍵盯仪、鍵路徑進行錯誤檢查,且執(zhí)行效率要低于合成存取器方法和自定的 setter 和 getter 方法紊搪。因為使用 KVC 鍵值編碼,它必須先解析字符串,然后在設置或者訪問對象的實例變量。
鍵值觀察KVO
鍵值觀察機制是一種能使得對象獲取到其他對象屬性變化的通知 全景,極大的簡化了代碼耀石。
實現(xiàn) KVO 鍵值觀察模式,被觀察的對象必須使用 KVC 鍵值編碼來修 改它的實例變量,這樣才能被觀察者觀察到。因此,KVC是KVO的基礎爸黄。
Demo
比如我自定義的一個button
1
2
3
4
5
6
7
8[self?addObserver:self?forKeyPath:@"highlighted"options:0?context:nil];
#pragma?mark?KVO
-?(void)observeValueForKeyPath:(NSString?*)keyPath?ofObject:(id)object?change:(NSDictionary?*)change?context:(void?*)context
{
if([keyPath?isEqualToString:@"highlighted"]?)?{
[self?setNeedsDisplay];
}
}
對于系統(tǒng)是根據(jù)keypath去取的到相應的值發(fā)生改變滞伟,理論上來說是和kvc機制的道理是一樣的。
KVC機制通過key找到value的原理炕贵。
當通過KVC調(diào)用對象時梆奈,比如:[self valueForKey:@”someKey”]時,程序會自動試圖通過下面幾種不同的方式解析這個調(diào)用称开。
首先查找對象是否帶有 someKey 這個方法亩钟,如果沒找到,會繼續(xù)查找對象是否帶有someKey這個實例變量(iVar)鳖轰,如果還沒有找到清酥,程序會繼續(xù)試圖調(diào)用 -(id) valueForUndefinedKey:這個方法。如果這個方法還是沒有被實現(xiàn)的話蕴侣,程序會拋出一個NSUndefinedKeyException異常錯誤焰轻。
補充:KVC查找方法的時候,不僅僅會查找someKey這個方法昆雀,還會查找getsomeKey這個方法鹦马,前面加一個get胧谈,或者_someKey以_getsomeKey這幾種形式。同時荸频,查找實例變量的時候也會不僅僅查找someKey這個變量菱肖,也會查找_someKey這個變量是否存在。
設計valueForUndefinedKey:方法的主要目的是當你使用-(id)valueForKey方法從對象中請求值時旭从,對象能夠在錯誤發(fā)生前稳强,有最后的機會響應這個請求。
在 Objective-C 中如何實現(xiàn) KVO
注冊觀察者(注意:觀察者和被觀察者不會被保留也不會被釋放)
1
2
3-?(void)addObserver:(NSObject?*)observer?forKeyPath:(NSString?*)keyPath
options:(NSKeyValueObservingOptions)options
context:(void?*)context;
接收變更通知
1
2-?(void)observeValueForKeyPath:(NSString?*)keyPath
ofObject:(id)object?change:(NSDictionary?*)change???context:(void?*)context;
移除對象的觀察者身份
1
2-?(void)removeObserver:(NSObject?*)observer
forKeyPath:(NSString?*)keyPath;
KVO中誰要監(jiān)聽誰注冊和悦,然后對響應進行處理退疫,使得觀察者與被觀察者完全解耦。KVO只檢測類中的屬性鸽素,并且屬性名都是通過NSString來查找褒繁,編譯器不會檢錯和補全,全部取決于自己馍忽。
代理的作用
代理又叫委托棒坏,是一種設計模式,代理是對象與對象之間的通信交互遭笋,代理解除了對象之間的耦合性坝冕。
改變或傳遞控制鏈。允許一個類在某些特定時刻通知到其他類瓦呼,而不需要獲取到那些類的指針喂窟。可以減少框架復雜度央串。
另外一點磨澡,代理可以理解為java中的回調(diào)監(jiān)聽機制的一種類似。
代理的屬性常是assign的原因:防止循環(huán)引用,以至對象無法得到正確的釋放质和。
NSNotification稳摄、Block、Delegate和KVO的區(qū)別侦另。
代理是一種回調(diào)機制秩命,且是一對一的關系尉共,通知是一對多的關系褒傅,一個對向所有的觀察者提供變更通知;
效率:Delegate比NSNOtification高袄友;
Delegate和Block一般是一對一的通信殿托;
Delegate需要定義協(xié)議方法,代理對象實現(xiàn)協(xié)議方法剧蚣,并且需要建立代理關系才可以實現(xiàn)通信支竹;
Block:Block更加簡潔旋廷,不需要定義繁瑣的協(xié)議方法,但通信事件比較多的話礼搁,建議使用Delegate饶碘;
Objective-C中可修改和不可以修改類型。
可修改不可修改的集合類馒吴,就是可動態(tài)添加修改和不可動態(tài)添加修改扎运。
比如NSArray和NSMutableArray,前者在初始化后的內(nèi)存控件就是固定不可變的,后者可以添加等饮戳,可以動態(tài)申請新的內(nèi)存空間
當我們調(diào)用一個靜態(tài)方法時,需要對對象進行 release 嗎?
不需要,靜態(tài)方法(類方法)創(chuàng)建一個對象時,對象已被放入自動釋放池豪治。在自動釋放池被釋放時,很有可能被銷毀。
當我們釋放我們的對象時,為什么需要調(diào)用[super dealloc]方法,它的位置又是如何的呢?
因為子類的某些實例是繼承自父類的,因此需要調(diào)用[super dealloc]方法, 來釋放父類擁有的實例,其實也就是子類本身的扯罐。一般來說我們優(yōu)先釋放子類擁 有的實例,最后釋放父類所擁有的實例负拟。
對謂詞的認識
Cocoa 中提供了一個NSPredicate的類,該類主要用于指定過濾器的條件, 每一個對象通過謂詞進行篩選,判斷條件是否匹配。如果需要了解使用方法歹河,請看謂詞的具體使用
static掩浙、self、super關鍵字的作用
函數(shù)體內(nèi)static變量的作用范圍為該函數(shù)體启泣,不同于auto變量涣脚,該變量的內(nèi)存只被分配一次,因此其值在下次調(diào)用時仍維持上次的值.
在模塊內(nèi)的 static 全局變量可以被模塊內(nèi)所用函數(shù)訪問寥茫,但不能被模塊外其它函數(shù)訪問.
在模塊內(nèi)的static函數(shù)只可被這一模塊內(nèi)的其它函數(shù)調(diào)用遣蚀,這個函數(shù)的使用范圍被限制在聲明.
在類中的static成員變量屬于整個類所擁有,對類的所有對象只有一份拷貝.
self:當前消息的接收者纱耻。
super:向父類發(fā)送消息芭梯。
#include與#import的區(qū)別,#import 與@class 的區(qū)別
#include 和#import其效果相同,都是查詢類中定義的行為(方法);
#import不會引起交叉編譯,確保頭文件只會被導入一次弄喘;
@class 的表明,只定 義了類的名稱,而具體類的行為是未知的,一般用于.h 文件玖喘;
@class 比#import 編譯效率更高。
此外@class 和#import 的主要區(qū)別在于解決引用死鎖的問題蘑志。
@public累奈、@protected、@private 它們的含義與作用
@public:對象的實例變量的作用域在任意地方都可以被訪問 ;
@protected:對象的實例變量作用域在本類和子類都可以被訪問 ;
@private:實例變量的作用域只能在本類(自身)中訪問 .
解釋 id 類型
任意類型對象急但,程序運行時才決定對象的類型澎媒。
switch 語句 if 語句區(qū)別與聯(lián)系
均表示條件的判斷,switch語句表達式只能處理的是整型、字符型和枚舉類型,而選擇流程語句則沒有這樣的限制波桩。但switch語句比選擇流程控制語句效率更高戒努。
isMemberOfClass 和 isKindOfClass 聯(lián)系與區(qū)別
聯(lián)系:兩者都能檢測一個對象是否是某個類的成員
區(qū)別:isKindOfClass 不僅用來確定一個對象是否是一個類的成員,也可以用來確定一個對象是否派生自該類的類的成員 ,而isMemberOfClass 只能做到第一點。
舉例:如 ClassA派 生 自NSObject 類 , ClassA *a = [ClassA alloc] init];,[a isKindOfClass:[NSObject class]] 可以檢查出 a 是否是 NSObject派生類 的成員,但 isMemberOfClass 做不到镐躲。
iOS 開發(fā)中數(shù)據(jù)持久性有哪幾種?
數(shù)據(jù)存儲的核心都是寫文件储玫。
屬性列表:只有NSString侍筛、NSArray、NSDictionary撒穷、NSData可writeToFile匣椰;存儲依舊是plist文件。plist文件可以存儲的7中數(shù)據(jù)類型:array端礼、dictionary窝爪、string、bool齐媒、data蒲每、date、number喻括。
對象序列化(對象歸檔):對象序列化通過序列化的形式邀杏,鍵值關系存儲到本地,轉(zhuǎn)化成二進制流唬血。通過runtime實現(xiàn)自動化歸檔/解檔望蜡,請參考這個文章。實現(xiàn)NSCoding協(xié)議必須實現(xiàn)的兩個方法:
1.編碼(對象序列化):把不能直接存儲到plist文件中得到數(shù)據(jù)拷恨,轉(zhuǎn)化為二進制數(shù)據(jù)脖律,NSData,可以存儲到本地腕侄;
2.解碼(對象反序列化):把二進制數(shù)據(jù)轉(zhuǎn)化為本來的類型小泉。
SQLite 數(shù)據(jù)庫:大量有規(guī)律的數(shù)據(jù)使用數(shù)據(jù)庫。
CoreData :通過管理對象進行增冕杠、刪微姊、查、改操作的分预。它不是一個數(shù)據(jù)庫兢交,不僅可以使用SQLite數(shù)據(jù)庫來保持數(shù)據(jù),也可以使用其他的方式來存儲數(shù)據(jù)笼痹。如:XML配喳。
CoreData的介紹:
CoreData是面向?qū)ο蟮腁PI,CoreData是iOS中非常重要的一項技術凳干,幾乎在所有編寫的程序中晴裹,CoreData都作為數(shù)據(jù)存儲的基礎。
CoreData是蘋果官方提供的一套框架纺座,用來解決與對象聲明周期管理息拜、對象關系管理和持久化等方面相關的問題溉潭。
大多數(shù)情況下净响,我們引用CoreData作為持久化數(shù)據(jù)的解決方案少欺,并利用它作為持久化數(shù)據(jù)映射為內(nèi)存對象滤灯。提供的是對象-關系映射功能根欧,也就是說,CoreData可以將Objective-C對象轉(zhuǎn)換成數(shù)據(jù)岛琼,保存到SQL中配乓,然后將保存后的數(shù)據(jù)還原成OC對象仿滔。
CoreData的特征:
通過CoreData管理應用程序的數(shù)據(jù)模型,可以極大程度減少需要編寫的代碼數(shù)量犹芹。
將對象數(shù)據(jù)存儲在SQLite數(shù)據(jù)庫已獲得性能優(yōu)化崎页。
提供NSFetchResultsController類用于管理表視圖的數(shù)據(jù),即將Core Data的持久化存儲在表視圖中腰埂,并對這些數(shù)據(jù)進行管理:增刪查改飒焦。
管理undo/redo操縱;
檢查托管對象的屬性值是否正確屿笼。
Core Data的6成員對象
NSManageObject:被管理的數(shù)據(jù)記錄Managed Object Model是描述應用程序的數(shù)據(jù)模型牺荠,這個模型包含實體(Entity)、特性(Property)驴一、讀取請求(Fetch Request)等休雌。
NSManageObjectContext:管理對象上下文,持久性存儲模型對象肝断,參與數(shù)據(jù)對象進行各種操作的全過程杈曲,并監(jiān)測數(shù)據(jù)對象的變化,以提供對undo/redo的支持及更新綁定到數(shù)據(jù)的UI胸懈。
NSPersistentStoreCoordinator:連接數(shù)據(jù)庫的Persistent Store Coordinator相當于數(shù)據(jù)文件管理器鱼蝉,處理底層的對數(shù)據(jù)文件的讀取和寫入,一般我們與這個沒有交集箫荡。
NSManagedObjectModel:被管理的數(shù)據(jù)模型魁亦、數(shù)據(jù)結(jié)構(gòu)。
NSFetchRequest:數(shù)據(jù)請求羔挡;
NSEntityDescription:表格實體結(jié)構(gòu)洁奈,還需知道.xcdatamodel文件編譯后為.momd或者.mom文件。
Core Data的功能
對于KVC和KVO完整且自動化的支持绞灼,除了為屬性整合KVO和KVC訪問方法外利术,還整合了適當?shù)募显L問方法來處理多值關系;
自動驗證屬性(property)值低矮;
支持跟蹤修改和撤銷操作印叁;
關系維護,Core Data管理數(shù)據(jù)的關系傳播,包括維護對象間的一致性轮蜕;
在內(nèi)存上和界面上分組昨悼、過濾、組織數(shù)據(jù)跃洛;
自動支持對象存儲在外部數(shù)據(jù)倉庫的功能率触;
創(chuàng)建復雜請求:無需動手寫SQL語句,在獲取請求(fetch request)中關聯(lián)NSPredicate汇竭。NSPreadicate支持基本功能葱蝗、相關子查詢和其他高級的SQL特性。它支持正確的Unicode編碼细燎、區(qū)域感知查詢两曼、排序和正則表達式;
延遲操作:Core Data使用懶加載(lazy loading)方式減少內(nèi)存負載玻驻,還支持部分實體化延遲加載和復制對象的數(shù)據(jù)共享機制合愈;
合并策略:Core Data內(nèi)置版本跟蹤和樂觀鎖(optimistic locking)來支持多用戶寫入沖突的解決,其中击狮,樂觀鎖就是對數(shù)據(jù)沖突進行檢測佛析,若沖突就返回沖突的信息;
數(shù)據(jù)遷移:Core Data的Schema Migration工具可以簡化應對數(shù)據(jù)庫結(jié)構(gòu)變化的任務彪蓬,在某些情況允許你執(zhí)行高效率的數(shù)據(jù)庫原地遷移工作寸莫;
可選擇針對程序Controller層的集成,來支持UI的顯示同步Core Data在IPhone OS之上档冬,提供NSFetchedResultsController對象來做相關工作膘茎,在Mac OS X上我們用Cocoa提供的綁定(Binding)機制來完成的。
對象可以被copy的條件
只有實現(xiàn)了NSCopying和NSMutableCopying協(xié)議的類的對象才能被拷貝,分為不可變拷貝和可變拷貝,具體區(qū)別戳這里
NSCopying協(xié)議方法為:
1
2
3
4
5-?(id)copyWithZone:(NSZone?*)zone?{
MyObject?*copy?=?[[[self?class]?allocWithZone:?zone]?init];
copy.username?=?[self.username?copyWithZone:zone];
returncopy;
}
自動釋放池工作原理
自動釋放池是NSAutorelease類的一個實例,當向一個對象發(fā)送autorelease消息時,該對象會自動入池,待池銷毀時,將會向池中所有對象發(fā)送一條release消息,釋放對象酷誓。
[pool release]披坏、 [pool drain]表示的是池本身不會銷毀,而是池子中的臨時對象都被發(fā)送release,從而將對象銷毀。
在某個方法中 self.name = _name盐数,name = _name 它 們有區(qū)別嗎棒拂,為什么?
前者是存在內(nèi)存管理的setter方法賦值,它會對_name對象進行保留或者拷貝操作
后者是普通賦值
一般來說,在對象的方法里成員變量和方法都是可以訪問的玫氢,我們通常會重寫Setter方法來執(zhí)行某些額外的工作帚屉。比如說,外部傳一個模型過來漾峡,那么我會直接重寫Setter方法攻旦,當模型傳過來時,也就是意味著數(shù)據(jù)發(fā)生了變化生逸,那么視圖也需要更新顯示牢屋,則在賦值新模型的同時也去刷新UI且预。
解釋self = [super init]方法
容錯處理,當父類初始化失敗,會返回一個nil,表示初始化失敗。由于繼承的關系,子類是需要擁有父類的實例和行為,因此,我們必須先初始化父類,然后再初始化子類
定義屬性時烙无,什么時候用 assign锋谐、retain、copy 以及它們的之間的區(qū)別皱炉。
assign:普通賦值,一般常用于基本數(shù)據(jù)類型,常見委托設計模式, 以此來防止循環(huán)引用。(我們稱之為弱引用).
retain:保留計數(shù),獲得到了對象的所有權(quán),引用計數(shù)在原有基礎上加1.
copy:一般認為,是在內(nèi)存中重新開辟了一個新的內(nèi)存空間,用來 存儲新的對象,和原來的對象是兩個不同的地址,引用計數(shù)分別為1狮鸭。但是當copy對象為不可變對象時,那么copy 的作用相當于retain合搅。因為,這樣可以節(jié)約內(nèi)存空間
堆和棧的區(qū)別
棧區(qū)(stack)由編譯器自動分配釋放 ,存放方法(函數(shù))的參數(shù)值, 局部變量的值等,棧是向低地址擴展的數(shù)據(jù)結(jié)構(gòu)歧蕉,是一塊連續(xù)的內(nèi)存的區(qū)域灾部。即棧頂?shù)牡刂泛蜅5淖畲笕萘渴窍到y(tǒng)預先規(guī)定好的。
堆區(qū)(heap)一般由程序員分配釋放, 若程序員不釋放,程序結(jié)束時由OS回收惯退,向高地址擴展的數(shù)據(jù)結(jié)構(gòu)赌髓,是不連續(xù)的內(nèi)存區(qū)域,從而堆獲得的空間比較靈活催跪。
碎片問題:對于堆來講锁蠕,頻繁的new/delete勢必會造成內(nèi)存空間的不連續(xù),從而造成大量的碎片懊蒸,使程序效率降低荣倾。對于棧來講,則不會存在這個問題骑丸,因為棧是先進后出的隊列舌仍,他們是如此的一一對應,以至于永遠都不可能有一個內(nèi)存塊從棧中間彈出.
分配方式:堆都是動態(tài)分配的通危,沒有靜態(tài)分配的堆铸豁。棧有2種分配方式:靜態(tài)分配和動態(tài)分配。靜態(tài)分配是編譯器完成的菊碟,比如局部變量的分配节芥。動態(tài)分配由alloca函數(shù)進行分配,但是棧的動態(tài)分配和堆是不同的逆害,他的動態(tài)分配是由編譯器進行釋放藏古,無需我們手工實現(xiàn)。
分配效率:棧是機器系統(tǒng)提供的數(shù)據(jù)結(jié)構(gòu)忍燥,計算機會在底層對棧提供支持:分配專門的寄存器存放棧的地址拧晕,壓棧出棧都有專門的指令執(zhí)行,這就決定了棧的效率比較高梅垄。堆則是C/C++函數(shù)庫提供的厂捞,它的機制是很復雜的输玷。
全局區(qū)(靜態(tài)區(qū))(static),全局變量和靜態(tài)變量的存儲是放在一塊 的,初始化的全局變量和靜態(tài)變量在一塊區(qū)域, 未初始化的全局變量和未初始化的靜態(tài)變量在相鄰的另一塊區(qū)域。程序結(jié)束后有系統(tǒng)釋放靡馁。
文字常量區(qū)—常量字符串就是放在這里的欲鹏。程序結(jié)束后由系統(tǒng)釋放。
程序代碼區(qū)—存放函數(shù)體的二進制代碼
怎樣使用performSelector傳入3個以上參數(shù)臭墨,其中一個為結(jié)構(gòu)體赔嚎。
因為系統(tǒng)提供的performSelector的API中,并沒有提供三個參數(shù)胧弛。因此尤误,我們只能傳數(shù)組或者字典,但是數(shù)組或者字典只有存入對象類型结缚,而結(jié)構(gòu)體并不是對象類型,我們只能通過對象放入結(jié)構(gòu)作為屬性來傳過去了.
1
2
3
4-?(id)performSelector:(SEL)aSelector;
-?(id)performSelector:(SEL)aSelector?withObject:(id)object;
-?(id)performSelector:(SEL)aSelector?withObject:
(id)object1?withObject:(id)object2;
具體實現(xiàn)如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20typedef?struct?HYBStruct?{
int?a;
int?b;
}?*my_struct;
@interface?HYBObject?:?NSObject
@property?(nonatomic,?assign)?my_struct?arg3;
@property?(nonatomic,?copy)??NSString?*arg1;
@property?(nonatomic,?copy)?NSString?*arg2;
@end
@implementation?HYBObject
损晤。
//?在堆上分配的內(nèi)存,我們要手動釋放掉
-?(void)dealloc?{
free(self.arg3);
}
@end
測試:
1
2
3
4
5
6
7
8
9
10
11
12my_struct?str?=?(my_struct)(malloc(sizeof(my_struct)));
str->a?=?1;
str->b?=?2;
HYBObject?*obj?=?[[HYBObject?alloc]?init];
obj.arg1?=?@"arg1";
obj.arg2?=?@"arg2";
obj.arg3?=?str;
[self?performSelector:@selector(call:)?withObject:obj];
//?在回調(diào)時得到正確的數(shù)據(jù)的
-?(void)call:(HYBObject?*)obj?{
NSLog(@"%d?%d",?obj.arg3->a,?obj.arg3->b);
}
UITableViewCell上有個UILabel红竭,顯示NSTimer實現(xiàn)的秒表時間尤勋,手指滾動cell過程中,label是否刷新茵宪,為什么最冰?
這是否刷新取決于timer加入到Run Loop中的Mode是什么。Mode主要是用來指定事件在運行循環(huán)中的優(yōu)先級的稀火,分為:
NSDefaultRunLoopMode(kCFRunLoopDefaultMode):默認锌奴,空閑狀態(tài)
UITrackingRunLoopMode:ScrollView滑動時會切換到該Mode
UIInitializationRunLoopMode:run loop啟動時,會切換到該mode
NSRunLoopCommonModes(kCFRunLoopCommonModes):Mode集合
蘋果公開提供的Mode有兩個:
NSDefaultRunLoopMode(kCFRunLoopDefaultMode)
NSRunLoopCommonModes(kCFRunLoopCommonModes)
在編程中:如果我們把一個NSTimer對象以NSDefaultRunLoopMode(kCFRunLoopDefaultMode)添加到主運行循環(huán)中的時候, ScrollView滾動過程中會因為mode的切換憾股,而導致NSTimer將不再被調(diào)度鹿蜀。當我們滾動的時候,也希望不調(diào)度服球,那就應該使用默認模式茴恰。但是,如果希望在滾動時斩熊,定時器也要回調(diào)往枣,那就應該使用common mode。
對于單元格重用的理解
當屏幕上滑出屏幕時粉渠,系統(tǒng)會把這個單元格添加到重用隊列中分冈,等待被重用,當有新單元從屏幕外滑入屏幕內(nèi)時霸株,從重用隊列中找看有沒有可以重用的單元格雕沉,若有,就直接用去件,沒有就重新創(chuàng)建一個坡椒。
解決cell重用的問題
UITableView通過重用單元格來達到節(jié)省內(nèi)存的目的扰路,通過為每個單元格指定一個重用標示(reuseidentifier),即指定了單元格的種類倔叼,以及當單元格滾出屏幕時汗唱,允許恢復單元格以便復用。對于不同種類的單元格使用不同的ID丈攒,對于簡單的表格哩罪,一個標示符就夠了。
如一個TableView中有10個單元格巡验,但屏幕最多顯示4個际插,實際上iPhone只為其分配4個單元格的內(nèi)存,沒有分配10個深碱,當滾動單元格時腹鹉,屏幕內(nèi)顯示的單元格重復使用這4個內(nèi)存藏畅。實際上分配的cell的個數(shù)為屏幕最大顯示數(shù)敷硅,當有新的cell進入屏幕時,會隨機調(diào)用已經(jīng)滾出屏幕的Cell所占的內(nèi)存愉阎,這就是Cell的重用绞蹦。
對于多變的自定義Cell,這種重用機制會導致內(nèi)容出錯榜旦,為解決這種出錯的方法幽七,把原來的
1
2UITableViewCell?*cell?=?[tableview?dequeueReusableCellWithIdentifier:defineString]
修改為:UITableViewCell?*cell?=?[tableview?cellForRowAtIndexPath:indexPath];
這樣就解決掉cell重用機制導致的問題。
有a溅呢、b澡屡、c、d 4個異步請求咐旧,如何判斷a驶鹉、b、c铣墨、d都完成執(zhí)行室埋?如果需要a、b伊约、c姚淆、d順序執(zhí)行,該如何實現(xiàn)屡律?
對于這四個異步請求腌逢,要判斷都執(zhí)行完成最簡單的方式就是通過GCD的group來實現(xiàn):
1
2
3
4
5
6
7
8
9dispatch_queue_t?queue?=?dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,?0);
dispatch_group_t?group?=?dispatch_group_create();
dispatch_group_async(group,?queue,?^{/*任務a?*/});
dispatch_group_async(group,?queue,?^{/*任務b?*/});
dispatch_group_async(group,?queue,?^{/*任務c?*/});
dispatch_group_async(group,?queue,?^{/*任務d?*/});
dispatch_group_notify(group,dispatch_get_main_queue(),?^{
//?在a、b超埋、c上忍、d異步執(zhí)行完成后骤肛,會回調(diào)這里
});
當然,我們還可以使用非常老套的方法來處理窍蓝,通過四個變量來標識a腋颠、b、c吓笙、d四個任務是否完成淑玫,然后在runloop中讓其等待,當完成時才退出runloop面睛。但是這樣做會讓后面的代碼得不到執(zhí)行絮蒿,直到Run loop執(zhí)行完畢。
解釋:要求順序執(zhí)行叁鉴,那么可以將任務放到串行隊列中土涝,自然就是按順序來異步執(zhí)行了。
使用block有什么好處幌墓?使用NSTimer寫出一個使用block顯示(在UILabel上)秒表的代碼但壮。
代碼緊湊,傳值常侣、回調(diào)都很方便蜡饵,省去了寫代理的很多代碼。
NSTimer封裝成的block胳施,具體實現(xiàn)溯祸。
實現(xiàn)方法:
1
2
3
4
5
6NSTimer?*timer?=?[NSTimer?scheduledTimerWithTimeInterval:1.0
repeats:YES
callback:^()?{
weakSelf.secondsLabel.text?=?...
}
[[NSRunLoop?currentRunLoop]?addTimer:timer?forMode:NSRunLoopCommonModes];
一個view已經(jīng)初始化完畢,view上面添加了n個button舞肆,除用view的tag之外焦辅,還可以采用什么辦法來找到自己想要的button來修改button的值。
有2種方法解決:
第一種:如果是點擊某個按鈕后椿胯,才會刷新它的值筷登,其它不用修改,那么不用引用任何按鈕压状,直接在回調(diào)時仆抵,就已經(jīng)將接收響應的按鈕給傳過來了,直接通過它修改即可种冬。
第二種:點擊某個按鈕后镣丑,所有與之同類型的按鈕都要修改值,那么可以通過在創(chuàng)建按鈕時將按鈕存入到數(shù)組中娱两,在需要的時候遍歷查找莺匠。
線程與進程的區(qū)別和聯(lián)系?
一個程序至少要有進城,一個進程至少要有一個線程。
進程:資源分配的最小獨立單元,進程是具有一定獨立功能的程序關于某個數(shù)據(jù)集合上的一次運行活動,進程是系統(tǒng)進行資源分配和調(diào)度的一個獨立單位十兢。
線程:進程下的一個分支,是進程的實體,是CPU調(diào)度和分派的基本單元,它是比進程更小的能獨立運行的基本單位,線程自己基本不擁有系統(tǒng)資源,只擁有一點在運行中必不可少的資源(程序計數(shù)器趣竣、一組寄存器摇庙、棧),但是它可與同屬一個進程的其他線程共享進程所擁有的全部資源遥缕。
進程和線程都是由操作系統(tǒng)所體會的程序運行的基本單元卫袒,系統(tǒng)利用該基本單元實現(xiàn)系統(tǒng)對應用的并發(fā)性。
進程和線程的主要差別在于它們是不同的操作系統(tǒng)資源管理方式单匣。進程有獨立的地址空間夕凝,一個進程崩潰后,在保護模式下不會對其它進程產(chǎn)生影響户秤,而線程只是一個進程中的不同執(zhí)行路徑码秉。線程有自己的堆棧和局部變量,但線程之間沒有單獨的地址空間鸡号,一個線程死掉就等于整個進程死掉转砖,所以多進程的程序要比多線程的程序健壯,但在進程切換時鲸伴,耗費資源較大府蔗,效率要差一些。
但對于一些要求同時進行并且又要共享某些變量的并發(fā)操作挑围,只能用線程礁竞,不能用進程糖荒。
多線程編程
NSThread:當需要進行一些耗時操作時會把耗時的操作放到線程中杉辙。線程同步:多個線程同時訪問一個數(shù)據(jù)會出問題,NSlock捶朵、線程同步塊蜘矢、@synchronized(self){}。
NSOperationQueue操作隊列(不需考慮線程同步問題)综看。編程的重點都放在main里面品腹,NSInvocationOperation、BSBlockOperation红碑、自定義Operation舞吭。創(chuàng)建一個操作綁定相應的方法,當把操作添加到操作隊列中時析珊,操作綁定的方法就會自動執(zhí)行了羡鸥,當把操作添加到操作隊列中時,默認會調(diào)用main方法忠寻。
GCD(`Grand Central Dispatch)宏大的中央調(diào)度惧浴,串行隊列、并發(fā)隊列奕剃、主線程隊列衷旅;
同步和異步:同步指第一個任務不執(zhí)行完捐腿,不會開始第二個,異步是不管第一個有沒有執(zhí)行完柿顶,都開始第二個茄袖。
串行和并行:串行是多個任務按一定順序執(zhí)行,并行是多個任務同時執(zhí)行嘁锯;
代碼是在分線程執(zhí)行绞佩,在主線程嘟列中刷新UI。
多線程編程是防止主線程堵塞猪钮、增加運行效率的最佳方法品山。
Apple提供了NSOperation這個類,提供了一個優(yōu)秀的多線程編程方法烤低;
一個NSOperationQueue操作隊列肘交,相當于一個線程管理器,而非一個線程扑馁,因為你可以設置這個線程管理器內(nèi)可以并行運行的線程數(shù)量等涯呻。
多線程是一個比較輕量級的方法來實現(xiàn)單個應用程序內(nèi)多個代碼執(zhí)行路徑。
iPhoneOS下的主線程的堆棧大小是1M腻要。第二個線程開始就是512KB复罐,并且該值不能通過編譯器開關或線程API函數(shù)來更改,只有主線程有直接修改UI的能力雄家。
定時器與線程的區(qū)別
定時器;可以執(zhí)行多次效诅,默認在主線程中。
線程:只能執(zhí)行一次趟济。
Apple設備尺寸和編程尺寸
iPhone設備
iPod設備
iPad設備
TCP和UDP的區(qū)別于聯(lián)系
TCP為傳輸控制層協(xié)議乱投,為面向連接、可靠的顷编、點到點的通信戚炫;
UDP為用戶數(shù)據(jù)報協(xié)議,非連接的不可靠的點到多點的通信媳纬;
TCP側(cè)重可靠傳輸双肤,UDP側(cè)重快速傳輸。
TCP連接的三次握手
第一次握手:客戶端發(fā)送syn包(syn=j)到服務器钮惠,并進入SYN_SEND狀態(tài)茅糜,等待服務器確認;
第二次握手:服務器收到syn包萌腿,必須確認客戶的SYN(ack=j+1)限匣,同時自己也發(fā)送一個SYN包,即SYN+ACK包,此時服務器進入SYN+RECV狀態(tài)米死;
第三次握手:客戶端收到服務器的SYN+ACK包锌历,向服務器發(fā)送確認包ACK(ack=k+1),此發(fā)送完畢峦筒,客戶端和服務器進入ESTABLISHED狀態(tài)究西,完成三次狀態(tài)。
Scoket連接和HTTP連接的區(qū)別
HTTP協(xié)議是基于TCP連接的物喷,是應用層協(xié)議卤材,主要解決如何包裝數(shù)據(jù)。Socket是對TCP/IP協(xié)議的封裝峦失,Socket本身并不是協(xié)議扇丛,而是一個調(diào)用接口(API),通過Socket尉辑,我們才能使用TCP/IP協(xié)議帆精。
HTTP連接:短連接,客戶端向服務器發(fā)送一次請求隧魄,服務器響應后連接斷開卓练,節(jié)省資源。服務器不能主動給客戶端響應(除非采用HTTP長連接技術)购啄,iPhone主要使用類NSURLConnection襟企。
Socket連接:長連接,客戶端跟服務器端直接使用Socket進行連接狮含,沒有規(guī)定連接后斷開顽悼,因此客戶端和服務器段保持連接通道,雙方可以主動發(fā)送數(shù)據(jù)辉川,一般多用于游戲.Socket默認連接超時時間是30秒表蝙,默認大小是8K(理解為一個數(shù)據(jù)包大兴┎狻)乓旗。
HTTP協(xié)議的特點,關于HTTP請求GET和POST的區(qū)別
GET和POST的區(qū)別:
HTTP超文本傳輸協(xié)議集索,是短連接屿愚,是客戶端主動發(fā)送請求,服務器做出響應务荆,服務器響應之后妆距,鏈接斷開。HTTP是一個屬于應用層面向?qū)ο蟮膮f(xié)議函匕,HTTP有兩類報文:請求報文和響應報文娱据。
HTTP請求報文:一個HTTP請求報文由請求行、請求頭部盅惜、空行和請求數(shù)據(jù)4部分組成中剩。
HTTP響應報文:由三部分組成:狀態(tài)行忌穿、消息報頭姓蜂、響應正文辜伟。
GET請求:參數(shù)在地址后拼接船殉,沒有請求數(shù)據(jù)思灰,不安全(因為所有參數(shù)都拼接在地址后面)策严,不適合傳輸大量數(shù)據(jù)(長度有限制晓铆,為1024個字節(jié))坏快。
GET提交草巡、請求的數(shù)據(jù)會附在URL之后属铁,即把數(shù)據(jù)放置在HTTP協(xié)議頭中眠寿。
以?分割URL和傳輸數(shù)據(jù)焦蘑,多個參數(shù)用&連接澜公。如果數(shù)據(jù)是英文字母或數(shù)字,原樣發(fā)送喇肋,
如果是空格坟乾,轉(zhuǎn)換為+,如果是中文/其他字符蝶防,則直接把字符串用BASE64加密甚侣。
POST請求:參數(shù)在請求數(shù)據(jù)區(qū)放著,相對GET請求更安全间学,并且數(shù)據(jù)大小沒有限制殷费。把提交的數(shù)據(jù)放置在HTTP包的包體中.
GET提交的數(shù)據(jù)會在地址欄顯示出來,而POST提交低葫,地址欄不會改變详羡。
傳輸數(shù)據(jù)的大小:
GET提交時嘿悬,傳輸數(shù)據(jù)就會受到URL長度限制实柠,POST由于不是通過URL傳值,理論上書不受限善涨。
安全性:
POST的安全性要比GET的安全性高窒盐;
通過GET提交數(shù)據(jù),用戶名和密碼將明文出現(xiàn)在URL上钢拧,比如登陸界面有可能被瀏覽器緩存蟹漓。
HTTPS:安全超文本傳輸協(xié)議(Secure Hypertext Transfer Protocol),它是一個安全通信通道源内,基于HTTP開發(fā)葡粒,用于客戶計算機和服務器之間交換信息,使用安全套結(jié)字層(SSI)進行信息交換,即HTTP的安全版嗽交。
ASIHttpRequest伯铣、AFNetWorking之間的區(qū)別
ASIHttpRequest功能強大,主要是在MRC下實現(xiàn)的轮纫,是對系統(tǒng)CFNetwork API進行了封裝腔寡,支持HTTP協(xié)議的CFHTTP,配置比較復雜掌唾,并且ASIHttpRequest框架默認不會幫你監(jiān)聽網(wǎng)絡改變放前,如果需要讓ASIHttpRequest幫你監(jiān)聽網(wǎng)絡狀態(tài)改變,并且手動開始這個功能糯彬。
AFNetWorking構(gòu)建于NSURLConnection凭语、NSOperation以及其他熟悉的Foundation技術之上。擁有良好的架構(gòu)撩扒,豐富的API及模塊構(gòu)建方式似扔,使用起來非常輕松。它基于NSOperation封裝的搓谆,AFURLConnectionOperation子類炒辉。
ASIHttpRequest是直接操作對象ASIHttpRequest是一個實現(xiàn)了NSCoding協(xié)議的NSOperation子類;AFNetWorking直接操作對象的AFHttpClient泉手,是一個實現(xiàn)NSCoding和NSCopying協(xié)議的NSObject子類黔寇。
同步請求:ASIHttpRequest直接通過調(diào)用一個startSynchronous方法;AFNetWorking默認沒有封裝同步請求斩萌,如果開發(fā)者需要使用同步請求缝裤,則需要重寫getPath:paraments:success:failures方法,對于AFHttpRequestOperation進行同步處理颊郎。
性能對比:AFNetworking請求優(yōu)于ASIHttpRequest憋飞;
XML數(shù)據(jù)解析方式各有什么不同,JSON解析有哪些框架姆吭?
XML數(shù)據(jù)解析的兩種解析方式:DOM解析和SAX解析榛做;
DOM解析必須完成DOM樹的構(gòu)造,在處理規(guī)模較大的XML文檔時就很耗內(nèi)存猾编,占用資源較多瘤睹,讀入整個XML文檔并構(gòu)建一個駐留內(nèi)存的樹結(jié)構(gòu)(節(jié)點樹),通過遍歷樹結(jié)構(gòu)可以檢索任意XML節(jié)點答倡,讀取它的屬性和值,通常情況下驴党,可以借助XPath查詢XML節(jié)點瘪撇;
SAX與DOM不同,它是事件驅(qū)動模型,解析XML文檔時每遇到一個開始或者結(jié)束標簽倔既、屬性或者一條指令時恕曲,程序就產(chǎn)生一個事件進行相應的處理,一邊讀取XML文檔一邊處理渤涌,不必等整個文檔加載完才采取措施佩谣,當在讀取解析過程中遇到需要處理的對象,會發(fā)出通知進行處理实蓬。因此茸俭,SAX相對于DOM來說更適合操作大的XML文檔。
JSON解析:性能比較好的主要是第三方的JSONKIT和iOS自帶的JSON解析類安皱,其中自帶的JSON解析性能最高调鬓,但只能用于iOS5之后。
如何進行真機調(diào)試酌伊?
1.首先需要用鑰匙串創(chuàng)建一個鑰匙(key)腾窝;
2.將鑰匙串上傳到官網(wǎng),獲取iOS Development證書居砖;
3.創(chuàng)建App ID即我們應用程序中的Boundle ID虹脯;
4.添加Device ID即UDID;
5.通過勾選前面所創(chuàng)建的證書:App ID奏候、Device ID归形;
6.生成mobileprovision文件;
7.先決條件:申請開發(fā)者賬號 99美刀
APP發(fā)布的上架流程
1.登錄應用發(fā)布網(wǎng)站添加應用信息鼻由;
2.下載安裝發(fā)布證書暇榴;
3.選擇發(fā)布證書,使用Archive編譯發(fā)布包蕉世,用Xcode將代碼(發(fā)布包)上傳到服務器蔼紧;
4.等待審核通過;
5.生成IPA:菜單欄->Product->Archive.
SVN的使用
SVN=版本控制+備份服務器,可以把SVN當成備份服務器狠轻,并且可以幫助你記住每次上服務器的檔案內(nèi)容奸例,并自動賦予每次變更的版本;
SVN的版本控制:所有上傳版本都會幫您記錄下來向楼,也有版本分支及合并等功能查吊。SVN可以讓不同的開發(fā)者存取同樣的檔案,并且利用SVN Server作為檔案同步的機制湖蜕,即您有檔案更新時逻卖,無需將檔案寄送給您的開發(fā)成員。SVN的存放檔案方式是采用差異備份的方式昭抒,即會備份到不同的地方评也,節(jié)省硬盤空間炼杖,也可以對非文字文件進行差異備份。
SVN的重要性:備份工作檔案的重要性盗迟、版本控管的重要性坤邪、伙伴間的數(shù)據(jù)同步的重要性、備份不同版本是很耗費硬盤空間的罚缕;
防止沖突:
1.防止代碼沖突:不要多人同時修改同一文件艇纺,例如:A、B都修改同一個文件邮弹,先讓A修改黔衡,然后提交到服務器,然后B更新下來肠鲫,再進行修改员帮;
2.服務器上的項目文件Xcodeproj,僅讓一個人管理提交导饲,其他人只更新捞高,防止文件發(fā)生沖突。
如何進行網(wǎng)絡消息推送
一種是Apple自己提供的通知服務(APNS服務器)渣锦、一種是用第三方推送機制硝岗。
首先應用發(fā)送通知,系統(tǒng)彈出提示框詢問用戶是否允許袋毙,當用戶允許后向蘋果服務器(APNS)請求deviceToken型檀,并由蘋果服務器發(fā)送給自己的應用,自己的應用將DeviceToken發(fā)送自己的服務器听盖,自己服務器想要發(fā)送網(wǎng)絡推送時將deviceToken以及想要推送的信息發(fā)送給蘋果服務器胀溺,蘋果服務器將信息發(fā)送給應用。
推送信息內(nèi)容皆看,總?cè)萘坎怀^256個字節(jié)仓坞;
iOS SDK本身提供的APNS服務器推送,它可以直接推送給目標用戶并根據(jù)您的方式彈出提示腰吟。
優(yōu)點:不論應用是否開啟无埃,都會發(fā)送到手機端;
缺點:消息推送機制是蘋果服務端控制毛雇,個別時候可能會有延遲嫉称,因為蘋果服務器也有隊列來處理所有的消息請求;
第三方推送機制灵疮,普遍使用Socket機制來實現(xiàn)织阅,幾乎可以達到即時的發(fā)送到目標用戶手機端,適用于即時通訊類應用始藕。
優(yōu)點:實時的蒲稳,取決于心跳包的節(jié)奏氮趋;
缺點:iOS系統(tǒng)的限制伍派,應用不能長時間的后臺運行江耀,所以應用關閉的情況下這種推送機制不可用。
網(wǎng)絡七層協(xié)議
應用層:
1.用戶接口诉植、應用程序祥国;
2.Application典型設備:網(wǎng)關;
3.典型協(xié)議晾腔、標準和應用:TELNET舌稀、FTP、HTTP
表示層:
1.數(shù)據(jù)表示灼擂、壓縮和加密presentation
2.典型設備:網(wǎng)關
3.典型協(xié)議壁查、標準和應用:ASCLL、PICT剔应、TIFF睡腿、JPEG|MPEG
4.表示層相當于一個東西的表示,表示的一些協(xié)議峻贮,比如圖片席怪、聲音和視頻MPEG。
會話層:
1.會話的建立和結(jié)束纤控;
2.典型設備:網(wǎng)關挂捻;
3.典型協(xié)議、標準和應用:RPC船万、SQL刻撒、NFS、X WINDOWS耿导、ASP
傳輸層:
1.主要功能:端到端控制Transport声怔;
2.典型設備:網(wǎng)關;
3.典型協(xié)議碎节、標準和應用:TCP捧搞、UDP、SPX
網(wǎng)絡層:
1.主要功能:路由狮荔、尋址Network胎撇;
2.典型設備:路由器;
3.典型協(xié)議殖氏、標準和應用:IP晚树、IPX、APPLETALK雅采、ICMP爵憎;
數(shù)據(jù)鏈路層:
1.主要功能:保證無差錯的疏忽鏈路的data link慨亲;
2.典型設備:交換機、網(wǎng)橋宝鼓、網(wǎng)卡刑棵;
3.典型協(xié)議、標準和應用:802.2愚铡、802.3ATM蛉签、HDLC、FRAME RELAY沥寥;
物理層:
1.主要功能:傳輸比特流Physical碍舍;
2.典型設備:集線器、中繼器
3.典型協(xié)議邑雅、標準和應用:V.35片橡、EIA/TIA-232.
對NSUserDefaults的理解
NSUserDefaults:系統(tǒng)提供的一種存儲數(shù)據(jù)的方式,主要用于保存少量的數(shù)據(jù)淮野,默認存儲到library下的Preferences文件夾捧书。
SDWebImage原理
調(diào)用類別的方法:
從內(nèi)存中(字典)找圖片(當這個圖片在本次程序加載過),找到直接使用录煤;
從沙盒中找鳄厌,找到直接使用,緩存到內(nèi)存妈踊。
從網(wǎng)絡上獲取了嚎,使用,緩存到內(nèi)存廊营,緩存到沙盒歪泳。
OC中是否有二維數(shù)組,如何實現(xiàn)二維數(shù)組露筒?
OC中沒有二維數(shù)組呐伞,可通過嵌套數(shù)組實現(xiàn)二維數(shù)組。
LayoutSubViews在什么時候被調(diào)用慎式?
當View本身的frame改變時伶氢,會調(diào)用這個方法。
深拷貝和淺拷貝
如果對象有個指針型成員變量指向內(nèi)存中的某個資源瘪吏,那么如何復制這個對象呢癣防?你會只是復制指針的值傳給副本的新對象嗎?指針只是存儲內(nèi)存中資源地址的占位符掌眠。在復制操作中蕾盯,如果只是將指針復制給新對象,那么底層的資源實際上仍然由兩個實例在共享蓝丙。
示例圖1
淺復制:兩個實例的指針仍指向內(nèi)存中的同一資源级遭,只復制指針值而不是實際資源望拖;
深復制:不僅復制指針值,還復制指向指針所指向的資源挫鸽。如下圖:
示例圖2
單例模式理解與使用
單例模式是一種常用設計模式说敏,單例模式是一個類在系統(tǒng)中只有一個實例對象。通過全局的一個入口點對這個實例對象進行訪問掠兄;
iOS中單例模式的實現(xiàn)方式一般分為兩種:非ARC和ARC+GCD像云。
對沙盒的理解
每個iOS應用都被限制在“沙盒”中锌雀,沙盒相當于一個加了僅主人可見權(quán)限的文件夾蚂夕,及時在應用程序安裝過程中,系統(tǒng)為每個單獨的應用程序生成它的主目錄和一些關鍵的子目錄腋逆。蘋果對沙盒有幾條限制:
1.應用程序在自己的沙盒中運作婿牍,但是不能訪問任何其他應用程序的沙盒;
2.應用之間不能共享數(shù)據(jù)惩歉,沙盒里的文件不能被復制到其他應用程序的文件夾中等脂,也不能把其他應用文件夾復制到沙盒中;
3.蘋果禁止任何讀寫沙盒以外的文件撑蚌,禁止應用程序?qū)?nèi)容寫到沙盒以外的文件夾中上遥;
4.沙盒目錄里有三個文件夾:Documents——存儲;應用程序的數(shù)據(jù)文件争涌,存儲用戶數(shù)據(jù)或其他定期備份的信息粉楚;Library下有兩個文件夾,Caches存儲應用程序再次啟動所需的信息亮垫,
Preferences包含應用程序的偏好設置文件模软,不可在這更改偏好設置;temp存放臨時文件即應用程序再次啟動不需要的文件饮潦。
獲取沙盒根目錄的方法燃异,有幾種方法:用NSHomeDirectory獲取。
獲取Document路徑:NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,NSUserDomainMask,YES).
對瀑布流的理解
首先圖片的寬度都是一樣的继蜡,1.將圖片等比例壓縮回俐,讓圖片不變形;2.計算圖片最低應該擺放的位置稀并,哪一列低就放在哪仅颇;3.進行最優(yōu)排列,在ScrollView的基礎上添加兩個tableView稻轨,然后將之前所計算的scrollView的高度通過tableView展示出來灵莲。
如何使用兩個TableView產(chǎn)生聯(lián)動:將兩個tableView的滾動事件禁止掉,最外層scrollView滾動時將兩個TableView跟著滾動殴俱,并且更改contentOffset政冻,這樣產(chǎn)生效果滾動的兩個tableView枚抵。
ViewController 的 loadView、viewDidLoad明场、viewDidUnload 分別是在什么時候調(diào)用的汽摹?
viewDidLoad在view從nib文件初始化時調(diào)用,loadView在controller的view為nil時調(diào)用苦锨。
此方法在編程實現(xiàn)view時調(diào)用,view控制器默認會注冊memory warning notification,當view controller的任何view沒有用的時候逼泣,viewDidUnload會被調(diào)用,在這里實現(xiàn)將retain的view release,如果是retain的IBOutlet view 屬性則不要在這里release,IBOutlet會負責release 舟舒。
關鍵字volatile有什么含意?并給出三個不同的例子:
一個定義為volatile的變量是說這變量可能會被意想不到地改變拉庶,這樣,編譯器就不會去假設這個變量的值了秃励。精確地說就是氏仗,優(yōu)化器在用到這個變量時必須每次都小心地重新讀取這個變量的值,而不是使用保存在寄存器里的備份夺鲜。下面是volatile變量的幾個例子:
1.并行設備的硬件寄存器(如:狀態(tài)寄存器)皆尔;
2.一個中斷服務子程序中會訪問到的非自動變量(Non-automatic variables);
3.多線程應用中被幾個任務共享的變量币励。
@synthesize慷蠕、@dynamic的理解
@synthesize是系統(tǒng)自動生成getter和setter屬性聲明;@synthesize的意思是,除非開發(fā)人員已經(jīng)做了食呻,否則由編譯器生成相應的代碼流炕,以滿足屬性聲明;
@dynamic是開發(fā)者自已提供相應的屬性聲明,@dynamic意思是由開發(fā)人員提供相應的代碼:對于只讀屬性需要提供setter搁进,對于讀寫屬性需要提供 setter 和getter浪感。查閱了一些資料確定@dynamic的意思是告訴編譯器,屬性的獲取與賦值方法由用戶自己實現(xiàn), 不自動生成。
frame和bounds有什么不同饼问?
frame指的是:該view在父view坐標系統(tǒng)中的位置和大小影兽。(參照點是父親的坐標系統(tǒng))
bounds指的是:該view在本身坐標系統(tǒng)中的位置和大小。(參照點是本身坐標系統(tǒng))
view的touch事件有哪些莱革?
1
2
3
4-?(void)touchesBegan:(NSSet?*)touches?withEvent:(UIEvent?*)event;
-?(void)touchesMoved:(NSSet?*)touches?withEvent:(UIEvent?*)event;
-?(void)touchesEnded:(NSSet?*)touches?withEvent:(UIEvent?*)event;
-?(void)touchesCancelled:(NSSet?*)touches?withEvent:(UIEvent?*)event;
自定義實現(xiàn)UITabbarController的原理
運用字典峻堰,點擊五個按鈕的一個可以從字典里選擇一個控制器對象,將其View顯示到主控制器視圖上盅视。
iOS中的響應者鏈的工作原理
每一個應用有一個響應者鏈捐名,我們的視圖結(jié)構(gòu)是一個N叉樹(一個視圖可以有多個子視圖,一個子視圖同一時刻只有一個父視圖),而每一個繼承UIResponder的對象都可以在這個N叉樹中扮演一個節(jié)點闹击。
當葉節(jié)點成為最高響應者的時候镶蹋,從這個葉節(jié)點開始往其父節(jié)點開始追朔出一條鏈,那么對于這一個葉節(jié)點來講,這一條鏈就是當前的響應者鏈贺归。響應者鏈將系統(tǒng)捕獲到的UIEvent與UITouch從葉節(jié)點開始層層向下分發(fā)淆两,期間可以選擇停止分發(fā),也可以選擇繼續(xù)向下分發(fā)拂酣。
如需了解更多細節(jié)秋冰,請讀這篇文章。
View和View之間傳值方式
對象的property屬性傳值婶熬;
方法參數(shù)傳值剑勾;
NSUserDefault傳值;
塊傳值赵颅。
property屬性的修飾符的作用
getter=getName虽另、setter=setName:設置setter與getter的方法名;
readwrite性含、readonly:設置可供訪問級別洲赵;
assign:方法直接賦值,不進行任何retain操作商蕴,為了解決原類型與環(huán)循引用問題;
retain:其setter方法對參數(shù)進行release舊值再retain新值芝发,所有實現(xiàn)都是這個順序绪商;
copy:其setter方法進行copy操作,與retain處理流程一樣辅鲸,先對舊值release格郁,再copy出新的對象,retainCount為1独悴。這是為了減少對上下文的依賴而引入的機制例书。
nonatomic:非原子性訪問,不加同步刻炒, 多線程并發(fā)訪問會提高性能决采。注意,如果不加此屬性坟奥,則默認是兩個訪問方法都為原子型事務訪問树瞭。
對于Run Loop的理解
RunLoop,是多線程的法寶爱谁,即一個線程一次只能執(zhí)行一個任務晒喷,執(zhí)行完任務后就會退出線程。主線程執(zhí)行完即時任務時會繼續(xù)等待接收事件而不退出访敌。非主線程通常來說就是為了執(zhí)行某一任務的凉敲,執(zhí)行完畢就需要歸還資源,因此默認是不運行RunLoop的;
每一個線程都有其對應的RunLoop爷抓,只是默認只有主線程的RunLoop是啟動的雨效,其它子線程的RunLoop默認是不啟動的,若要啟動則需要手動啟動废赞;
在一個單獨的線程中徽龟,如果需要在處理完某個任務后不退出,繼續(xù)等待接收事件唉地,則需要啟用RunLoop据悔;
NSRunLoop提供了一個添加NSTimer的方法,可以指定Mode耘沼,如果要讓任何情況下都回調(diào)极颓,則需要設置Mode為Common模式;
實質(zhì)上群嗤,對于子線程的runloop默認是不存在的菠隆,因為蘋果采用了懶加載的方式。如果我們沒有手動調(diào)用[NSRunLoop currentRunLoop]的話狂秘,就不會去查詢是否存在當前線程的RunLoop骇径,也就不會去加載,更不會創(chuàng)建者春。
SQLite中常用的SQL語句
創(chuàng)建表:creat table 表名 (字段名 字段數(shù)據(jù)類型 是否為主鍵, 字段名 字段數(shù)據(jù)類型, 字段名 字段數(shù)據(jù)類型...)破衔;
增: insert into 表名 (字段1, 字段2...) values (值1, 值2...);
刪: delete from 表名 where 字段 = 值钱烟;
XIB與Storyboards的優(yōu)缺點
優(yōu)點:
XIB:在編譯前就提供了可視化界面晰筛,可以直接拖控件,也可以直接給控件添加約束拴袭,更直觀一些读第,而且類文件中就少了創(chuàng)建控件的代碼,確實簡化不少拥刻,通常每個XIB對應一個類怜瞒。
Storyboard:在編譯前提供了可視化界面,可拖控件泰佳,可加約束盼砍,在開發(fā)時比較直觀,而且一個storyboard可以有很多的界面逝她,每個界面對應一個類文件浇坐,通過storybard,可以直觀地看出整個App的結(jié)構(gòu)黔宛。
缺點:
XIB:需求變動時近刘,需要修改XIB很大,有時候甚至需要重新添加約束,導致開發(fā)周期變長觉渴。XIB載入相比純代碼自然要慢一些介劫。對于比較復雜邏輯控制不同狀態(tài)下顯示不同內(nèi)容時,使用XIB是比較困難的案淋。當多人團隊或者多團隊開發(fā)時饲梭,如果XIB文件被發(fā)動蔽氨,極易導致沖突商模,而且解決沖突相對要困難很多哺呜。
Storyboard:需求變動時,需要修改storyboard上對應的界面的約束瓣距,與XIB一樣可能要重新添加約束黔帕,或者添加約束會造成大量的沖突,尤其是多團隊開發(fā)蹈丸。對于復雜邏輯控制不同顯示內(nèi)容時成黄,比較困難。當多人團隊或者多團隊開發(fā)時逻杖,大家會同時修改一個storyboard奋岁,導致大量沖突,解決起來相當困難弧腥。
將字符串“2015-04-10”格式化日期轉(zhuǎn)為NSDate類型
1
2
3
4
5
6
7NSString?*timeStr?=?@"2015-04-10";
NSDateFormatter?*formatter?=?[[NSDateFormatter?alloc]?init];
formatter.dateFormat?=?@"yyyy-MM-dd";
formatter.timeZone?=?[NSTimeZone?defaultTimeZone];
NSDate?*date?=?[formatter?dateFromString:timeStr];
//?2015-04-09?16:00:00?+0000
NSLog(@"%@",?date);
隊列和多線程的使用原理
在iOS中隊列分為以下幾種:
串行隊列:隊列中的任務只會順序執(zhí)行厦取;
1
dispatch_queue_t?q?=?dispatch_queue_create("...",?DISPATCH_QUEUE_SERIAL);
并行隊列: 隊列中的任務通常會并發(fā)執(zhí)行;
1
dispatch_queue_t?q?=?dispatch_queue_create("......",DISPATCH_QUEUE_CONCURRENT);
全局隊列:是系統(tǒng)的管搪,直接拿過來(GET)用就可以;與并行隊列類似铡买;
1
dispatch_queue_t?q?=?dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,?0);
主隊列:每一個應用程序?qū)ㄒ恢麝犃懈常苯覩ET即可;在多線程開發(fā)中奇钞,使用主隊列更新UI澡为;
1
dispatch_queue_t?q?=?dispatch_get_main_queue();
更多細節(jié)見下圖:
內(nèi)存的使用和優(yōu)化的注意事項
重用問題:如UITableViewCells、UICollectionViewCells景埃、UITableViewHeaderFooterViews設置正確的reuseIdentifier媒至,充分重用;
盡量把views設置為不透明:當opque為NO的時候谷徙,圖層的半透明取決于圖片和其本身合成的圖層為結(jié)果拒啰,可提高性能;
不要使用太復雜的XIB/Storyboard:載入時就會將XIB/storyboard需要的所有資源完慧,包括圖片全部載入內(nèi)存谋旦,即使未來很久才會使用。那些相比純代碼寫的延遲加載,性能及內(nèi)存就差了很多册着;
選擇正確的數(shù)據(jù)結(jié)構(gòu):學會選擇對業(yè)務場景最合適的數(shù)組結(jié)構(gòu)是寫出高效代碼的基礎拴孤。比如,數(shù)組: 有序的一組值甲捏。使用索引來查詢很快演熟,使用值查詢很慢,插入/刪除很慢司顿。字典: 存儲鍵值對芒粹,用鍵來查找比較快。集合: 無序的一組值免猾,用值來查找很快是辕,插入/刪除很快。
gzip/zip壓縮:當從服務端下載相關附件時猎提,可以通過gzip/zip壓縮后再下載获三,使得內(nèi)存更小,下載速度也更快锨苏。
延遲加載:對于不應該使用的數(shù)據(jù)疙教,使用延遲加載方式。對于不需要馬上顯示的視圖伞租,使用延遲加載方式贞谓。比如,網(wǎng)絡請求失敗時顯示的提示界面葵诈,可能一直都不會使用到裸弦,因此應該使用延遲加載。
數(shù)據(jù)緩存:對于cell的行高要緩存起來作喘,使得reload數(shù)據(jù)時理疙,效率也極高。而對于那些網(wǎng)絡數(shù)據(jù)泞坦,不需要每次都請求的窖贤,應該緩存起來,可以寫入數(shù)據(jù)庫贰锁,也可以通過plist文件存儲赃梧。
處理內(nèi)存警告:一般在基類統(tǒng)一處理內(nèi)存警告,將相關不用資源立即釋放掉
重用大開銷對象:一些objects的初始化很慢豌熄,比如NSDateFormatter和NSCalendar授嘀,但又不可避免地需要使用它們。通常是作為屬性存儲起來房轿,防止反復創(chuàng)建粤攒。
避免反復處理數(shù)據(jù):許多應用需要從服務器加載功能所需的常為JSON或者XML格式的數(shù)據(jù)所森。在服務器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要;
使用Autorelease Pool:在某些循環(huán)創(chuàng)建臨時變量處理數(shù)據(jù)時,自動釋放池以保證能及時釋放內(nèi)存;
正確選擇圖片加載方式:詳情閱讀細讀UIImage加載方式
UIViewController的完整生命周期
1
2
3
4
5
6
7
8-[ViewController?initWithNibName:bundle:]夯接;
-[ViewController?init]焕济;
-[ViewController?loadView];
-[ViewController?viewDidLoad]盔几;
-[ViewController?viewWillDisappear:]晴弃;
-[ViewController?viewWillAppear:];
-[ViewController?viewDidAppear:]逊拍;
-[ViewController?viewDidDisappear:]上鞠;
UIImageView添加圓角
最直接的方法就是使用如下屬性設置:
1
2
3imgView.layer.cornerRadius?=?10;
//?這一行代碼是很消耗性能的
imgView.clipsToBounds?=?YES;
**這是離屏渲染(off-screen-rendering),消耗性能的**
給UIImage添加生成圓角圖片的擴展API:這是on-screen-rendering
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15-?(UIImage?*)imageWithCornerRadius:(CGFloat)radius?{
CGRect?rect?=?(CGRect){0.f,?0.f,?self.size};
UIGraphicsBeginImageContextWithOptions(self.size,?NO,?UIScreen.mainScreen.scale);
CGContextAddPath(UIGraphicsGetCurrentContext(),
[UIBezierPath?bezierPathWithRoundedRect:rect?cornerRadius:radius].CGPath);
CGContextClip(UIGraphicsGetCurrentContext());
[self?drawInRect:rect];
UIImage?*image?=?UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
returnimage;
}