OC的理解與特性
OC作為一門面向?qū)ο蟮恼Z言,自然具有面向?qū)ο蟮恼Z言特性:封裝、繼承、多態(tài)。它既具有靜態(tài)語言的特性(如C++),又有動(dòng)態(tài)語言的效率(動(dòng)態(tài)綁定、動(dòng)態(tài)加載等)。總體來講,OC確實(shí)是一門不錯(cuò)的編程語言,
Objective-C具有相當(dāng)多的動(dòng)態(tài)特性,表現(xiàn)為三方面:動(dòng)態(tài)類型(Dynamic typing)、動(dòng)態(tài)綁定(Dynamic binding)和動(dòng)態(tài)加載(Dynamic loading)。動(dòng)態(tài)——必須到運(yùn)行時(shí)(run time)才會(huì)做的一些事情。
動(dòng)態(tài)類型:即運(yùn)行時(shí)再?zèng)Q定對(duì)象的類型,這種動(dòng)態(tài)特性在日常的應(yīng)用中非常常見,簡單來說就是id類型。事實(shí)上,由于靜態(tài)類型的固定性和可預(yù)知性,從而使用的更加廣泛。靜態(tài)類型是強(qiáng)類型,而動(dòng)態(tài)類型屬于弱類型,運(yùn)行時(shí)決定接受者。
動(dòng)態(tài)綁定:基于動(dòng)態(tài)類型,在某個(gè)實(shí)例對(duì)象被確定后,其類型便被確定了,該對(duì)象對(duì)應(yīng)的屬性和響應(yīng)消息也被完全確定。
動(dòng)態(tài)加載:根據(jù)需求加載所需要的資源,最基本就是不同機(jī)型的適配,例如,在Retina設(shè)備上加載@2x的圖片,而在老一些的普通蘋設(shè)備上加載原圖,讓程序在運(yùn)行時(shí)添加代碼模塊以及其他資源,用戶可根據(jù)需要加載一些可執(zhí)行代碼和資源,而不是在啟動(dòng)時(shí)就加載所有組件,可執(zhí)行代碼可以含有和程序運(yùn)行時(shí)整合的新類。
簡述內(nèi)存管理基本原則
之前:OC內(nèi)存管理遵循“誰創(chuàng)建,誰釋放,誰引用,誰管理”的機(jī)制,當(dāng)創(chuàng)建或引用一個(gè)對(duì)象的時(shí)候,需要向她發(fā)送alloc、copy、retain消息,當(dāng)釋放該對(duì)象時(shí)需要發(fā)送release消息,當(dāng)對(duì)象引用計(jì)數(shù)為0時(shí),系統(tǒng)將釋放該對(duì)象,這是OC的手動(dòng)管理機(jī)制(MRC)。
目前:iOS 5.0之后引用自動(dòng)管理機(jī)制——自動(dòng)引用計(jì)數(shù)(ARC),管理機(jī)制與手動(dòng)機(jī)制一樣,只是不再需要調(diào)用retain、release、autorelease;它編譯時(shí)的特性,當(dāng)你使用ARC時(shí),在適當(dāng)位置插入release和autorelease;它引用strong和weak關(guān)鍵字,strong修飾的指針變量指向?qū)ο髸r(shí),當(dāng)指針指向新值或者指針不復(fù)存在,相關(guān)聯(lián)的對(duì)象就會(huì)自動(dòng)釋放,而weak修飾的指針變量指向?qū)ο螅?dāng)對(duì)象的擁有者指向新值或者不存在時(shí)weak修飾的指針會(huì)自動(dòng)置為nil。
如果使用alloc、copy(mutableCopy)或者retian一個(gè)對(duì)象時(shí),你就有義務(wù),向它發(fā)送一條release或者autorelease消息。其他方法創(chuàng)建的對(duì)象,不需要由你來管理內(nèi)存。
向一個(gè)對(duì)象發(fā)送一條autorelease消息,這個(gè)對(duì)象并不會(huì)立即銷毀, 而是將這個(gè)對(duì)象放入了自動(dòng)釋放池,待池子釋放時(shí),它會(huì)向池中每一個(gè)對(duì)象發(fā)送 一條release消息,以此來釋放對(duì)象.
向一個(gè)對(duì)象發(fā)送release消息,并不意味著這個(gè)對(duì)象被銷毀了,而是當(dāng)這個(gè)對(duì)象的引用計(jì)數(shù)為0時(shí),系統(tǒng)才會(huì)調(diào)用dealloc方法,釋放該對(duì)象和對(duì)象本身它所擁有的實(shí)例。
其他注意事項(xiàng)
如果一個(gè)對(duì)象有一個(gè)_strong類型的指針指向著,找個(gè)對(duì)象就不會(huì)被釋放。如果一個(gè)指針指向超出了它的作用域,就會(huì)被指向nil。如果一個(gè)指針被指向nil,那么它原來指向的對(duì)象就被釋放了。當(dāng)一個(gè)視圖控制器被釋放時(shí),它內(nèi)部的全局指針會(huì)被指向nil。用法“:不管全局變量還是局部變量用_strong描述就行。
局部變量:出了作用域,指針會(huì)被置為nil。
方法內(nèi)部創(chuàng)建對(duì)象,外部使用需要添加_autorelease;
連線的時(shí)候,用_weak描述。
代理使用unsafe_unretained就相當(dāng)于assign;
block中為了避免循環(huán)引用問題,使用_weak描述;
聲明屬性時(shí),不要以new開頭。如果非要以new開頭命名屬性的名字,需要自己定制get方法名,如
1
@property(getter=theString) NSString * newString;
如果要使用自動(dòng)釋放池,用@autoreleasepool{}
ARC只能管理Foundation框架的變量,如果程序中把Foundation中的變量強(qiáng)制換成COre Foundation中的變量需要交換管理權(quán);
在非ARC工程中采用ARC去編譯某些類:-fobjc-arc。
在ARC下的工程采用非ARC去編譯某些類:-fno-fobjc-arc。
如何理解MVC設(shè)計(jì)模式
MVC是一種架構(gòu)模式,M表示MOdel,V表示視圖View,C表示控制器Controller:
Model負(fù)責(zé)存儲(chǔ)、定義、操作數(shù)據(jù);
View用來展示書給用戶,和用戶進(jìn)行操作交互;
Controller是Model和View的協(xié)調(diào)者,Controller把Model中的數(shù)據(jù)拿過來給View用。Controller可以直接與Model和View進(jìn)行通信,而View不能和Controller直接通信。View與Controller通信需要利用代理協(xié)議的方式,當(dāng)有數(shù)據(jù)更新時(shí),MOdel也要與Controller進(jìn)行通信,這個(gè)時(shí)候就要用Notification和KVO,這個(gè)方式就像一個(gè)廣播一樣,MOdel發(fā)信號(hào),Controller設(shè)置監(jiān)聽接受信號(hào),當(dāng)有數(shù)據(jù)更新時(shí)就發(fā)信號(hào)給Controller,Model和View不能直接進(jìn)行通信,這樣會(huì)違背MVC設(shè)計(jì)模式。
如何理解MVVM設(shè)計(jì)模式。
ViewModel層,就是View和Model層的粘合劑,他是一個(gè)放置用戶輸入驗(yàn)證邏輯,視圖顯示邏輯,發(fā)起網(wǎng)絡(luò)請(qǐng)求和其他各種各樣的代碼的極好的地方。說白了,就是把原來ViewController層的業(yè)務(wù)邏輯和頁面邏輯等剝離出來放到ViewModel層。
View層,就是ViewController層,他的任務(wù)就是從ViewModel層獲取數(shù)據(jù),然后顯示。
如需了解更多,請(qǐng)查看這篇文章。
Objective-C 中是否支持垃圾回收機(jī)制?
OC是支持垃圾回收機(jī)制的(Garbage collection簡稱GC),但是apple的移動(dòng)終端中,是不支持GC的,Mac桌面系統(tǒng)開發(fā)中是支持的.
移動(dòng)終端開發(fā)是支持ARC(Automatic Reference Counting的簡稱),ARC是在IOS5之后推出的新技術(shù),它與GC的機(jī)制是不同的。我們?cè)诰帉懘a時(shí), 不需要向?qū)ο蟀l(fā)送release或者autorelease方法,也不可以調(diào)用delloc方法,編譯器會(huì)在合適的位置自動(dòng)給用戶生成release消息(autorelease),ARC 的特點(diǎn)是自動(dòng)引用技術(shù)簡化了內(nèi)存管理的難度.
協(xié)議的基本概念和協(xié)議中方法默認(rèn)為什么類型。
OC中的協(xié)議是一個(gè)方法列表,且多少有點(diǎn)相關(guān)。它的特點(diǎn)是可以被任何類使用(實(shí)現(xiàn)),但它并不是類(這里我們需要注意),自身不會(huì)實(shí)現(xiàn)這樣方法, 而是又其他人來實(shí)現(xiàn)協(xié)議經(jīng)常用來實(shí)現(xiàn)委托對(duì)象(委托設(shè)計(jì)模式)。如果一個(gè)類采用了一個(gè)協(xié)議,那么它必須實(shí)現(xiàn)協(xié)議中必須需要實(shí)現(xiàn)的方法,在協(xié)議中的方法默認(rèn)是必須實(shí)現(xiàn)(@required),添加關(guān)鍵字@optional,表明一旦采用該協(xié)議,這些“可選”的方法是可以選擇不實(shí)現(xiàn)的。
簡述類目category優(yōu)點(diǎn)和缺點(diǎn)。
優(yōu)點(diǎn):
不需要通過增加子類而增加現(xiàn)有類的行為(方法),且類目中的方法與原始類方法基本沒有區(qū)別;
通過類目可以將龐大一個(gè)類的方法進(jìn)行劃分,從而便于代碼的日后的維護(hù)、更新以及提高代碼的閱讀性;
缺點(diǎn):
無法向類目添加實(shí)例變量,如果需要添加實(shí)例變量,只能通過定義子類的方式;
類目中的方法與原始類以及父類方法相比具有更高優(yōu)先級(jí),如果覆蓋父類的方法,可能導(dǎo)致super消息的斷裂。因此,最好不要覆蓋原始類中的方法。
類別的作用
給系統(tǒng)原有類添加方法,不能擴(kuò)展屬性。如果類別中方法的名字跟系統(tǒng)的方法名一樣,在調(diào)用的時(shí)候類別中的方法優(yōu)先級(jí)更高;
分散類的實(shí)現(xiàn):如:
- (NSIndexPath *)indexPathForRow:(NSInteger)row
inSection:(NSInteger)section
原本屬于NSIndexPath的方法,但因?yàn)檫@個(gè)方法經(jīng)常使用的表的時(shí)候調(diào)用、跟表的關(guān)系特別密切,因此把這個(gè)方法一類別的形式、聲明在UITableView.h中。
聲明私有方法,某一個(gè)方法只實(shí)現(xiàn),不聲明,相當(dāng)于私有方法。
類別不能聲明變量,類別不可以直接添加屬性。property描述setter方法,就不會(huì)報(bào)錯(cuò)。
循環(huán)引用的產(chǎn)生原因,以及解決方法。
產(chǎn)生原因:如下圖所示,對(duì)象A和對(duì)象B相互引用了對(duì)方作為自己的成員變量,只有自己銷毀的時(shí)候才能將成員變量的引用計(jì)數(shù)減1。對(duì)象A的銷毀依賴于對(duì)象B的銷毀,同時(shí)對(duì)象B銷毀也依賴與對(duì)象A的銷毀,從而形成循環(huán)引用,此時(shí),即使外界沒有任何指針訪問它,它也無法釋放。
循環(huán)引用示例圖
多個(gè)對(duì)象間依然會(huì)存在循環(huán)引用問題,形成一個(gè)環(huán),在編程中,形成的環(huán)越大越不容易察覺,如下圖所示:
多個(gè)對(duì)象引用示例圖
解決方法:
事先知道存在循環(huán)引用的地方,在合理的位置主動(dòng)斷開一個(gè)引用,是對(duì)象回收;
使用弱引用的方法。
鍵路徑(keyPath)、鍵值編碼(KVC)和鍵值觀察(KVO)
鍵路徑
在一個(gè)給定的實(shí)體中,同一個(gè)屬性的所有值具有相同的數(shù)據(jù)類型。
鍵-值編碼技術(shù)用于進(jìn)行這樣的查找—它是一種間接訪問對(duì)象屬性的機(jī)制。 - 鍵路徑是一個(gè)由用點(diǎn)作分隔符的鍵組成的字符串,用于指定一個(gè)連接在一起的對(duì)象性質(zhì)序列。第一個(gè)鍵的性質(zhì)是由先前的性質(zhì)決定的,接下來每個(gè)鍵的值也是相對(duì)于其前面的性質(zhì)。
鍵路徑使您可以以獨(dú)立于模型實(shí)現(xiàn)的方式指定相關(guān)對(duì)象的性質(zhì)。通過鍵路徑,您可以指定對(duì)象圖中的一個(gè)任意深度的路徑,使其指向相關(guān)對(duì)象的特定屬性。
鍵值編碼KVC
鍵值編碼是一種間接訪問對(duì)象的屬性使用字符串來標(biāo)識(shí)屬性,而不是通過調(diào)用存取方法,直接或通過實(shí)例變量訪問的機(jī)制,非對(duì)象類型的變量將被自動(dòng)封裝或者解封成對(duì)象,很多情況下會(huì)簡化程序代碼;
KVC的缺點(diǎn):一旦使用 KVC 你的編譯器無法檢查出錯(cuò)誤,即不會(huì)對(duì)設(shè)置的鍵、鍵路徑進(jìn)行錯(cuò)誤檢查,且執(zhí)行效率要低于合成存取器方法和自定的 setter 和 getter 方法。因?yàn)槭褂?KVC 鍵值編碼,它必須先解析字符串,然后在設(shè)置或者訪問對(duì)象的實(shí)例變量。
鍵值觀察KVO
鍵值觀察機(jī)制是一種能使得對(duì)象獲取到其他對(duì)象屬性變化的通知 ,極大的簡化了代碼。
實(shí)現(xiàn) KVO 鍵值觀察模式,被觀察的對(duì)象必須使用 KVC 鍵值編碼來修 改它的實(shí)例變量,這樣才能被觀察者觀察到。因此,KVC是KVO的基礎(chǔ)。
Demo
比如我自定義的一個(gè)button
[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];
}
}
對(duì)于系統(tǒng)是根據(jù)keypath去取的到相應(yīng)的值發(fā)生改變,理論上來說是和kvc機(jī)制的道理是一樣的。
KVC機(jī)制通過key找到value的原理。
當(dāng)通過KVC調(diào)用對(duì)象時(shí),比如:[self valueForKey:@”someKey”]時(shí),程序會(huì)自動(dòng)試圖通過下面幾種不同的方式解析這個(gè)調(diào)用。
首先查找對(duì)象是否帶有 someKey 這個(gè)方法,如果沒找到,會(huì)繼續(xù)查找對(duì)象是否帶有someKey這個(gè)實(shí)例變量(iVar),如果還沒有找到,程序會(huì)繼續(xù)試圖調(diào)用 -(id) valueForUndefinedKey:這個(gè)方法。如果這個(gè)方法還是沒有被實(shí)現(xiàn)的話,程序會(huì)拋出一個(gè)NSUndefinedKeyException異常錯(cuò)誤。
補(bǔ)充:KVC查找方法的時(shí)候,不僅僅會(huì)查找someKey這個(gè)方法,還會(huì)查找getsomeKey這個(gè)方法,前面加一個(gè)get,或者_(dá)someKey以_getsomeKey這幾種形式。同時(shí),查找實(shí)例變量的時(shí)候也會(huì)不僅僅查找someKey這個(gè)變量,也會(huì)查找_someKey這個(gè)變量是否存在。
設(shè)計(jì)valueForUndefinedKey:方法的主要目的是當(dāng)你使用-(id)valueForKey方法從對(duì)象中請(qǐng)求值時(shí),對(duì)象能夠在錯(cuò)誤發(fā)生前,有最后的機(jī)會(huì)響應(yīng)這個(gè)請(qǐng)求。
在 Objective-C 中如何實(shí)現(xiàn) KVO
注冊(cè)觀察者(注意:觀察者和被觀察者不會(huì)被保留也不會(huì)被釋放)
(void)addObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath
options:(NSKeyValueObservingOptions)options
context:(void *)context;
接收變更通知(void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object change:(NSDictionary *)change context:(void *)context;
移除對(duì)象的觀察者身份(void)removeObserver:(NSObject *)observer
forKeyPath:(NSString *)keyPath;
KVO中誰要監(jiān)聽誰注冊(cè),然后對(duì)響應(yīng)進(jìn)行處理,使得觀察者與被觀察者完全解耦。KVO只檢測(cè)類中的屬性,并且屬性名都是通過NSString來查找,編譯器不會(huì)檢錯(cuò)和補(bǔ)全,全部取決于自己。
代理的作用
代理又叫委托,是一種設(shè)計(jì)模式,代理是對(duì)象與對(duì)象之間的通信交互,代理解除了對(duì)象之間的耦合性。
改變或傳遞控制鏈。允許一個(gè)類在某些特定時(shí)刻通知到其他類,而不需要獲取到那些類的指針。可以減少框架復(fù)雜度。
另外一點(diǎn),代理可以理解為java中的回調(diào)監(jiān)聽機(jī)制的一種類似。
代理的屬性常是assign的原因:防止循環(huán)引用,以至對(duì)象無法得到正確的釋放。
NSNotification、Block、Delegate和KVO的區(qū)別。
代理是一種回調(diào)機(jī)制,且是一對(duì)一的關(guān)系,通知是一對(duì)多的關(guān)系,一個(gè)對(duì)向所有的觀察者提供變更通知;
效率:Delegate比NSNOtification高;
Delegate和Block一般是一對(duì)一的通信;
Delegate需要定義協(xié)議方法,代理對(duì)象實(shí)現(xiàn)協(xié)議方法,并且需要建立代理關(guān)系才可以實(shí)現(xiàn)通信;
Block:Block更加簡潔,不需要定義繁瑣的協(xié)議方法,但通信事件比較多的話,建議使用Delegate;
Objective-C中可修改和不可以修改類型。
可修改不可修改的集合類,就是可動(dòng)態(tài)添加修改和不可動(dòng)態(tài)添加修改。
比如NSArray和NSMutableArray,前者在初始化后的內(nèi)存控件就是固定不可變的,后者可以添加等,可以動(dòng)態(tài)申請(qǐng)新的內(nèi)存空間
當(dāng)我們調(diào)用一個(gè)靜態(tài)方法時(shí),需要對(duì)對(duì)象進(jìn)行 release 嗎?
不需要,靜態(tài)方法(類方法)創(chuàng)建一個(gè)對(duì)象時(shí),對(duì)象已被放入自動(dòng)釋放池。在自動(dòng)釋放池被釋放時(shí),很有可能被銷毀。
當(dāng)我們釋放我們的對(duì)象時(shí),為什么需要調(diào)用[super dealloc]方法,它的位置又是如何的呢?
因?yàn)樽宇惖哪承?shí)例是繼承自父類的,因此需要調(diào)用[super dealloc]方法, 來釋放父類擁有的實(shí)例,其實(shí)也就是子類本身的。一般來說我們優(yōu)先釋放子類擁 有的實(shí)例,最后釋放父類所擁有的實(shí)例。
對(duì)謂詞的認(rèn)識(shí)
Cocoa 中提供了一個(gè)NSPredicate的類,該類主要用于指定過濾器的條件, 每一個(gè)對(duì)象通過謂詞進(jìn)行篩選,判斷條件是否匹配。如果需要了解使用方法,請(qǐng)看謂詞的具體使用
static、self、super關(guān)鍵字的作用
函數(shù)體內(nèi)static變量的作用范圍為該函數(shù)體,不同于auto變量,該變量的內(nèi)存只被分配一次,因此其值在下次調(diào)用時(shí)仍維持上次的值.
在模塊內(nèi)的 static 全局變量可以被模塊內(nèi)所用函數(shù)訪問,但不能被模塊外其它函數(shù)訪問.
在模塊內(nèi)的static函數(shù)只可被這一模塊內(nèi)的其它函數(shù)調(diào)用,這個(gè)函數(shù)的使用范圍被限制在聲明.
在類中的static成員變量屬于整個(gè)類所擁有,對(duì)類的所有對(duì)象只有一份拷貝.
self:當(dāng)前消息的接收者。
super:向父類發(fā)送消息。
include與#import的區(qū)別,#import 與@class 的區(qū)別
include 和#import其效果相同,都是查詢類中定義的行為(方法);
import不會(huì)引起交叉編譯,確保頭文件只會(huì)被導(dǎo)入一次;
@class 的表明,只定 義了類的名稱,而具體類的行為是未知的,一般用于.h 文件;
@class 比#import 編譯效率更高。
此外@class 和#import 的主要區(qū)別在于解決引用死鎖的問題。
@public、@protected、@private 它們的含義與作用
@public:對(duì)象的實(shí)例變量的作用域在任意地方都可以被訪問 ;
@protected:對(duì)象的實(shí)例變量作用域在本類和子類都可以被訪問 ;
@private:實(shí)例變量的作用域只能在本類(自身)中訪問 .
解釋 id 類型
任意類型對(duì)象,程序運(yùn)行時(shí)才決定對(duì)象的類型。
switch 語句 if 語句區(qū)別與聯(lián)系
均表示條件的判斷,switch語句表達(dá)式只能處理的是整型、字符型和枚舉類型,而選擇流程語句則沒有這樣的限制。但switch語句比選擇流程控制語句效率更高。
isMemberOfClass 和 isKindOfClass 聯(lián)系與區(qū)別
聯(lián)系:兩者都能檢測(cè)一個(gè)對(duì)象是否是某個(gè)類的成員
區(qū)別:isKindOfClass 不僅用來確定一個(gè)對(duì)象是否是一個(gè)類的成員,也可以用來確定一個(gè)對(duì)象是否派生自該類的類的成員 ,而isMemberOfClass 只能做到第一點(diǎn)。
舉例:如 ClassA派 生 自NSObject 類 , ClassA *a = [ClassA alloc] init];,[a isKindOfClass:[NSObject class]] 可以檢查出 a 是否是 NSObject派生類 的成員,但 isMemberOfClass 做不到。
iOS 開發(fā)中數(shù)據(jù)持久性有哪幾種?
數(shù)據(jù)存儲(chǔ)的核心都是寫文件。
屬性列表:只有NSString、NSArray、NSDictionary、NSData可writeToFile;存儲(chǔ)依舊是plist文件。plist文件可以存儲(chǔ)的7中數(shù)據(jù)類型:array、dictionary、string、bool、data、date、number。
對(duì)象序列化(對(duì)象歸檔):對(duì)象序列化通過序列化的形式,鍵值關(guān)系存儲(chǔ)到本地,轉(zhuǎn)化成二進(jìn)制流。通過runtime實(shí)現(xiàn)自動(dòng)化歸檔/解檔,請(qǐng)參考這個(gè)文章。實(shí)現(xiàn)NSCoding協(xié)議必須實(shí)現(xiàn)的兩個(gè)方法:
1.編碼(對(duì)象序列化):把不能直接存儲(chǔ)到plist文件中得到數(shù)據(jù),轉(zhuǎn)化為二進(jìn)制數(shù)據(jù),NSData,可以存儲(chǔ)到本地;
2.解碼(對(duì)象反序列化):把二進(jìn)制數(shù)據(jù)轉(zhuǎn)化為本來的類型。
SQLite 數(shù)據(jù)庫:大量有規(guī)律的數(shù)據(jù)使用數(shù)據(jù)庫。
CoreData :通過管理對(duì)象進(jìn)行增、刪、查、改操作的。它不是一個(gè)數(shù)據(jù)庫,不僅可以使用SQLite數(shù)據(jù)庫來保持?jǐn)?shù)據(jù),也可以使用其他的方式來存儲(chǔ)數(shù)據(jù)。如:XML。
CoreData的介紹:
CoreData是面向?qū)ο蟮腁PI,CoreData是iOS中非常重要的一項(xiàng)技術(shù),幾乎在所有編寫的程序中,CoreData都作為數(shù)據(jù)存儲(chǔ)的基礎(chǔ)。
CoreData是蘋果官方提供的一套框架,用來解決與對(duì)象聲明周期管理、對(duì)象關(guān)系管理和持久化等方面相關(guān)的問題。
大多數(shù)情況下,我們引用CoreData作為持久化數(shù)據(jù)的解決方案,并利用它作為持久化數(shù)據(jù)映射為內(nèi)存對(duì)象。提供的是對(duì)象-關(guān)系映射功能,也就是說,CoreData可以將Objective-C對(duì)象轉(zhuǎn)換成數(shù)據(jù),保存到SQL中,然后將保存后的數(shù)據(jù)還原成OC對(duì)象。
CoreData的特征:
通過CoreData管理應(yīng)用程序的數(shù)據(jù)模型,可以極大程度減少需要編寫的代碼數(shù)量。
將對(duì)象數(shù)據(jù)存儲(chǔ)在SQLite數(shù)據(jù)庫已獲得性能優(yōu)化。
提供NSFetchResultsController類用于管理表視圖的數(shù)據(jù),即將Core Data的持久化存儲(chǔ)在表視圖中,并對(duì)這些數(shù)據(jù)進(jìn)行管理:增刪查改。
管理undo/redo操縱;
檢查托管對(duì)象的屬性值是否正確。
Core Data的6成員對(duì)象
NSManageObject:被管理的數(shù)據(jù)記錄Managed Object Model是描述應(yīng)用程序的數(shù)據(jù)模型,這個(gè)模型包含實(shí)體(Entity)、特性(Property)、讀取請(qǐng)求(Fetch Request)等。
NSManageObjectContext:管理對(duì)象上下文,持久性存儲(chǔ)模型對(duì)象,參與數(shù)據(jù)對(duì)象進(jìn)行各種操作的全過程,并監(jiān)測(cè)數(shù)據(jù)對(duì)象的變化,以提供對(duì)undo/redo的支持及更新綁定到數(shù)據(jù)的UI。
NSPersistentStoreCoordinator:連接數(shù)據(jù)庫的Persistent Store Coordinator相當(dāng)于數(shù)據(jù)文件管理器,處理底層的對(duì)數(shù)據(jù)文件的讀取和寫入,一般我們與這個(gè)沒有交集。
NSManagedObjectModel:被管理的數(shù)據(jù)模型、數(shù)據(jù)結(jié)構(gòu)。
NSFetchRequest:數(shù)據(jù)請(qǐng)求;
NSEntityDescription:表格實(shí)體結(jié)構(gòu),還需知道.xcdatamodel文件編譯后為.momd或者.mom文件。
Core Data的功能
對(duì)于KVC和KVO完整且自動(dòng)化的支持,除了為屬性整合KVO和KVC訪問方法外,還整合了適當(dāng)?shù)募显L問方法來處理多值關(guān)系;
自動(dòng)驗(yàn)證屬性(property)值;
支持跟蹤修改和撤銷操作;
關(guān)系維護(hù),Core Data管理數(shù)據(jù)的關(guān)系傳播,包括維護(hù)對(duì)象間的一致性;
在內(nèi)存上和界面上分組、過濾、組織數(shù)據(jù);
自動(dòng)支持對(duì)象存儲(chǔ)在外部數(shù)據(jù)倉庫的功能;
創(chuàng)建復(fù)雜請(qǐng)求:無需動(dòng)手寫SQL語句,在獲取請(qǐng)求(fetch request)中關(guān)聯(lián)NSPredicate。NSPreadicate支持基本功能、相關(guān)子查詢和其他高級(jí)的SQL特性。它支持正確的Unicode編碼、區(qū)域感知查詢、排序和正則表達(dá)式;
延遲操作:Core Data使用懶加載(lazy loading)方式減少內(nèi)存負(fù)載,還支持部分實(shí)體化延遲加載和復(fù)制對(duì)象的數(shù)據(jù)共享機(jī)制;
合并策略:Core Data內(nèi)置版本跟蹤和樂觀鎖(optimistic locking)來支持多用戶寫入沖突的解決,其中,樂觀鎖就是對(duì)數(shù)據(jù)沖突進(jìn)行檢測(cè),若沖突就返回沖突的信息;
數(shù)據(jù)遷移:Core Data的Schema Migration工具可以簡化應(yīng)對(duì)數(shù)據(jù)庫結(jié)構(gòu)變化的任務(wù),在某些情況允許你執(zhí)行高效率的數(shù)據(jù)庫原地遷移工作;
可選擇針對(duì)程序Controller層的集成,來支持UI的顯示同步Core Data在IPhone OS之上,提供NSFetchedResultsController對(duì)象來做相關(guān)工作,在Mac OS X上我們用Cocoa提供的綁定(Binding)機(jī)制來完成的。
對(duì)象可以被copy的條件
只有實(shí)現(xiàn)了NSCopying和NSMutableCopying協(xié)議的類的對(duì)象才能被拷貝,分為不可變拷貝和可變拷貝,具體區(qū)別戳這里
NSCopying協(xié)議方法為:
- (id)copyWithZone:(NSZone *)zone {
MyObject *copy = [[[self class] allocWithZone: zone] init];
copy.username = [self.username copyWithZone:zone];
return copy;
}
自動(dòng)釋放池工作原理
自動(dòng)釋放池是NSAutorelease類的一個(gè)實(shí)例,當(dāng)向一個(gè)對(duì)象發(fā)送autorelease消息時(shí),該對(duì)象會(huì)自動(dòng)入池,待池銷毀時(shí),將會(huì)向池中所有對(duì)象發(fā)送一條release消息,釋放對(duì)象。
[pool release]、 [pool drain]表示的是池本身不會(huì)銷毀,而是池子中的臨時(shí)對(duì)象都被發(fā)送release,從而將對(duì)象銷毀。
在某個(gè)方法中 self.name = _name,name = _name 它 們有區(qū)別嗎,為什么?
前者是存在內(nèi)存管理的setter方法賦值,它會(huì)對(duì)_name對(duì)象進(jìn)行保留或者拷貝操作
后者是普通賦值
一般來說,在對(duì)象的方法里成員變量和方法都是可以訪問的,我們通常會(huì)重寫Setter方法來執(zhí)行某些額外的工作。比如說,外部傳一個(gè)模型過來,那么我會(huì)直接重寫Setter方法,當(dāng)模型傳過來時(shí),也就是意味著數(shù)據(jù)發(fā)生了變化,那么視圖也需要更新顯示,則在賦值新模型的同時(shí)也去刷新UI。
解釋self = [super init]方法
容錯(cuò)處理,當(dāng)父類初始化失敗,會(huì)返回一個(gè)nil,表示初始化失敗。由于繼承的關(guān)系,子類是需要擁有父類的實(shí)例和行為,因此,我們必須先初始化父類,然后再初始化子類
定義屬性時(shí),什么時(shí)候用 assign、retain、copy 以及它們的之間的區(qū)別。
assign:普通賦值,一般常用于基本數(shù)據(jù)類型,常見委托設(shè)計(jì)模式, 以此來防止循環(huán)引用。(我們稱之為弱引用).
retain:保留計(jì)數(shù),獲得到了對(duì)象的所有權(quán),引用計(jì)數(shù)在原有基礎(chǔ)上加1.
copy:一般認(rèn)為,是在內(nèi)存中重新開辟了一個(gè)新的內(nèi)存空間,用來 存儲(chǔ)新的對(duì)象,和原來的對(duì)象是兩個(gè)不同的地址,引用計(jì)數(shù)分別為1。但是當(dāng)copy對(duì)象為不可變對(duì)象時(shí),那么copy 的作用相當(dāng)于retain。因?yàn)?這樣可以節(jié)約內(nèi)存空間
堆和棧的區(qū)別
棧區(qū)(stack)由編譯器自動(dòng)分配釋放 ,存放方法(函數(shù))的參數(shù)值, 局部變量的值等,棧是向低地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu),是一塊連續(xù)的內(nèi)存的區(qū)域。即棧頂?shù)牡刂泛蜅5淖畲笕萘渴窍到y(tǒng)預(yù)先規(guī)定好的。
堆區(qū)(heap)一般由程序員分配釋放, 若程序員不釋放,程序結(jié)束時(shí)由OS回收,向高地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu),是不連續(xù)的內(nèi)存區(qū)域,從而堆獲得的空間比較靈活。
碎片問題:對(duì)于堆來講,頻繁的new/delete勢(shì)必會(huì)造成內(nèi)存空間的不連續(xù),從而造成大量的碎片,使程序效率降低。對(duì)于棧來講,則不會(huì)存在這個(gè)問題,因?yàn)闂J窍冗M(jìn)后出的隊(duì)列,他們是如此的一一對(duì)應(yīng),以至于永遠(yuǎn)都不可能有一個(gè)內(nèi)存塊從棧中間彈出.
分配方式:堆都是動(dòng)態(tài)分配的,沒有靜態(tài)分配的堆。棧有2種分配方式:靜態(tài)分配和動(dòng)態(tài)分配。靜態(tài)分配是編譯器完成的,比如局部變量的分配。動(dòng)態(tài)分配由alloca函數(shù)進(jìn)行分配,但是棧的動(dòng)態(tài)分配和堆是不同的,他的動(dòng)態(tài)分配是由編譯器進(jìn)行釋放,無需我們手工實(shí)現(xiàn)。
分配效率:棧是機(jī)器系統(tǒng)提供的數(shù)據(jù)結(jié)構(gòu),計(jì)算機(jī)會(huì)在底層對(duì)棧提供支持:分配專門的寄存器存放棧的地址,壓棧出棧都有專門的指令執(zhí)行,這就決定了棧的效率比較高。堆則是C/C++函數(shù)庫提供的,它的機(jī)制是很復(fù)雜的。
全局區(qū)(靜態(tài)區(qū))(static),全局變量和靜態(tài)變量的存儲(chǔ)是放在一塊 的,初始化的全局變量和靜態(tài)變量在一塊區(qū)域, 未初始化的全局變量和未初始化的靜態(tài)變量在相鄰的另一塊區(qū)域。程序結(jié)束后有系統(tǒng)釋放。
文字常量區(qū)—常量字符串就是放在這里的。程序結(jié)束后由系統(tǒng)釋放。
程序代碼區(qū)—存放函數(shù)體的二進(jìn)制代碼
怎樣使用performSelector傳入3個(gè)以上參數(shù),其中一個(gè)為結(jié)構(gòu)體。
因?yàn)橄到y(tǒng)提供的performSelector的API中,并沒有提供三個(gè)參數(shù)。因此,我們只能傳數(shù)組或者字典,但是數(shù)組或者字典只有存入對(duì)象類型,而結(jié)構(gòu)體并不是對(duì)象類型,我們只能通過對(duì)象放入結(jié)構(gòu)作為屬性來傳過去了.
- (id)performSelector:(SEL)aSelector;
- (id)performSelector:(SEL)aSelector withObject:(id)object;
- (id)performSelector:(SEL)aSelector withObject:
(id)object1 withObject:(id)object2;
具體實(shí)現(xiàn)如下:
typedef 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)存,我們要手動(dòng)釋放掉
- (void)dealloc {
free(self.arg3);
}
@end
測(cè)試:
my_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í)得到正確的數(shù)據(jù)的
- (void)call:(HYBObject *)obj {
NSLog(@"%d %d", obj.arg3->a, obj.arg3->b);
}
UITableViewCell上有個(gè)UILabel,顯示NSTimer實(shí)現(xiàn)的秒表時(shí)間,手指滾動(dòng)cell過程中,label是否刷新,為什么?
這是否刷新取決于timer加入到Run Loop中的Mode是什么。Mode主要是用來指定事件在運(yùn)行循環(huán)中的優(yōu)先級(jí)的,分為:
NSDefaultRunLoopMode(kCFRunLoopDefaultMode):默認(rèn),空閑狀態(tài)
UITrackingRunLoopMode:ScrollView滑動(dòng)時(shí)會(huì)切換到該Mode
UIInitializationRunLoopMode:run loop啟動(dòng)時(shí),會(huì)切換到該mode
NSRunLoopCommonModes(kCFRunLoopCommonModes):Mode集合
蘋果公開提供的Mode有兩個(gè):
NSDefaultRunLoopMode(kCFRunLoopDefaultMode)
NSRunLoopCommonModes(kCFRunLoopCommonModes)
在編程中:如果我們把一個(gè)NSTimer對(duì)象以NSDefaultRunLoopMode(kCFRunLoopDefaultMode)添加到主運(yùn)行循環(huán)中的時(shí)候, ScrollView滾動(dòng)過程中會(huì)因?yàn)閙ode的切換,而導(dǎo)致NSTimer將不再被調(diào)度。當(dāng)我們滾動(dòng)的時(shí)候,也希望不調(diào)度,那就應(yīng)該使用默認(rèn)模式。但是,如果希望在滾動(dòng)時(shí),定時(shí)器也要回調(diào),那就應(yīng)該使用common mode。
對(duì)于單元格重用的理解
當(dāng)屏幕上滑出屏幕時(shí),系統(tǒng)會(huì)把這個(gè)單元格添加到重用隊(duì)列中,等待被重用,當(dāng)有新單元從屏幕外滑入屏幕內(nèi)時(shí),從重用隊(duì)列中找看有沒有可以重用的單元格,若有,就直接用,沒有就重新創(chuàng)建一個(gè)。
解決cell重用的問題
UITableView通過重用單元格來達(dá)到節(jié)省內(nèi)存的目的,通過為每個(gè)單元格指定一個(gè)重用標(biāo)示(reuseidentifier),即指定了單元格的種類,以及當(dāng)單元格滾出屏幕時(shí),允許恢復(fù)單元格以便復(fù)用。對(duì)于不同種類的單元格使用不同的ID,對(duì)于簡單的表格,一個(gè)標(biāo)示符就夠了。
如一個(gè)TableView中有10個(gè)單元格,但屏幕最多顯示4個(gè),實(shí)際上iPhone只為其分配4個(gè)單元格的內(nèi)存,沒有分配10個(gè),當(dāng)滾動(dòng)單元格時(shí),屏幕內(nèi)顯示的單元格重復(fù)使用這4個(gè)內(nèi)存。實(shí)際上分配的cell的個(gè)數(shù)為屏幕最大顯示數(shù),當(dāng)有新的cell進(jìn)入屏幕時(shí),會(huì)隨機(jī)調(diào)用已經(jīng)滾出屏幕的Cell所占的內(nèi)存,這就是Cell的重用。
對(duì)于多變的自定義Cell,這種重用機(jī)制會(huì)導(dǎo)致內(nèi)容出錯(cuò),為解決這種出錯(cuò)的方法,把原來的
UITableViewCell *cell = [tableview dequeueReusableCellWithIdentifier:defineString]
修改為:UITableViewCell *cell = [tableview cellForRowAtIndexPath:indexPath];
這樣就解決掉cell重用機(jī)制導(dǎo)致的問題。
有a、b、c、d 4個(gè)異步請(qǐng)求,如何判斷a、b、c、d都完成執(zhí)行?如果需要a、b、c、d順序執(zhí)行,該如何實(shí)現(xiàn)?
對(duì)于這四個(gè)異步請(qǐng)求,要判斷都執(zhí)行完成最簡單的方式就是通過GCD的group來實(shí)現(xiàn):
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_group_t group = dispatch_group_create();
dispatch_group_async(group, queue, ^{ /*任務(wù)a / });
dispatch_group_async(group, queue, ^{ /任務(wù)b / });
dispatch_group_async(group, queue, ^{ /任務(wù)c / });
dispatch_group_async(group, queue, ^{ /任務(wù)d */ });
dispatch_group_notify(group,dispatch_get_main_queue(), ^{
// 在a、b、c、d異步執(zhí)行完成后,會(huì)回調(diào)這里
});
當(dāng)然,我們還可以使用非常老套的方法來處理,通過四個(gè)變量來標(biāo)識(shí)a、b、c、d四個(gè)任務(wù)是否完成,然后在runloop中讓其等待,當(dāng)完成時(shí)才退出runloop。但是這樣做會(huì)讓后面的代碼得不到執(zhí)行,直到Run loop執(zhí)行完畢。
解釋:要求順序執(zhí)行,那么可以將任務(wù)放到串行隊(duì)列中,自然就是按順序來異步執(zhí)行了。
使用block有什么好處?使用NSTimer寫出一個(gè)使用block顯示(在UILabel上)秒表的代碼。
代碼緊湊,傳值、回調(diào)都很方便,省去了寫代理的很多代碼。
NSTimer封裝成的block,具體實(shí)現(xiàn)。
實(shí)現(xiàn)方法:
NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:1.0
repeats:YES
callback:^() {
weakSelf.secondsLabel.text = ...
}
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
一個(gè)view已經(jīng)初始化完畢,view上面添加了n個(gè)button,除用view的tag之外,還可以采用什么辦法來找到自己想要的button來修改button的值。
有2種方法解決:
第一種:如果是點(diǎn)擊某個(gè)按鈕后,才會(huì)刷新它的值,其它不用修改,那么不用引用任何按鈕,直接在回調(diào)時(shí),就已經(jīng)將接收響應(yīng)的按鈕給傳過來了,直接通過它修改即可。
第二種:點(diǎn)擊某個(gè)按鈕后,所有與之同類型的按鈕都要修改值,那么可以通過在創(chuàng)建按鈕時(shí)將按鈕存入到數(shù)組中,在需要的時(shí)候遍歷查找。
線程與進(jìn)程的區(qū)別和聯(lián)系?
一個(gè)程序至少要有進(jìn)城,一個(gè)進(jìn)程至少要有一個(gè)線程。
進(jìn)程:資源分配的最小獨(dú)立單元,進(jìn)程是具有一定獨(dú)立功能的程序關(guān)于某個(gè)數(shù)據(jù)集合上的一次運(yùn)行活動(dòng),進(jìn)程是系統(tǒng)進(jìn)行資源分配和調(diào)度的一個(gè)獨(dú)立單位。
線程:進(jìn)程下的一個(gè)分支,是進(jìn)程的實(shí)體,是CPU調(diào)度和分派的基本單元,它是比進(jìn)程更小的能獨(dú)立運(yùn)行的基本單位,線程自己基本不擁有系統(tǒng)資源,只擁有一點(diǎn)在運(yùn)行中必不可少的資源(程序計(jì)數(shù)器、一組寄存器、棧),但是它可與同屬一個(gè)進(jìn)程的其他線程共享進(jìn)程所擁有的全部資源。
進(jìn)程和線程都是由操作系統(tǒng)所體會(huì)的程序運(yùn)行的基本單元,系統(tǒng)利用該基本單元實(shí)現(xiàn)系統(tǒng)對(duì)應(yīng)用的并發(fā)性。
進(jìn)程和線程的主要差別在于它們是不同的操作系統(tǒng)資源管理方式。進(jìn)程有獨(dú)立的地址空間,一個(gè)進(jìn)程崩潰后,在保護(hù)模式下不會(huì)對(duì)其它進(jìn)程產(chǎn)生影響,而線程只是一個(gè)進(jìn)程中的不同執(zhí)行路徑。線程有自己的堆棧和局部變量,但線程之間沒有單獨(dú)的地址空間,一個(gè)線程死掉就等于整個(gè)進(jìn)程死掉,所以多進(jìn)程的程序要比多線程的程序健壯,但在進(jìn)程切換時(shí),耗費(fèi)資源較大,效率要差一些。
但對(duì)于一些要求同時(shí)進(jìn)行并且又要共享某些變量的并發(fā)操作,只能用線程,不能用進(jìn)程。
多線程編程
NSThread:當(dāng)需要進(jìn)行一些耗時(shí)操作時(shí)會(huì)把耗時(shí)的操作放到線程中。線程同步:多個(gè)線程同時(shí)訪問一個(gè)數(shù)據(jù)會(huì)出問題,NSlock、線程同步塊、@synchronized(self){}。
NSOperationQueue操作隊(duì)列(不需考慮線程同步問題)。編程的重點(diǎn)都放在main里面,NSInvocationOperation、BSBlockOperation、自定義Operation。創(chuàng)建一個(gè)操作綁定相應(yīng)的方法,當(dāng)把操作添加到操作隊(duì)列中時(shí),操作綁定的方法就會(huì)自動(dòng)執(zhí)行了,當(dāng)把操作添加到操作隊(duì)列中時(shí),默認(rèn)會(huì)調(diào)用main方法。
GCD(`Grand Central Dispatch)宏大的中央調(diào)度,串行隊(duì)列、并發(fā)隊(duì)列、主線程隊(duì)列;
同步和異步:同步指第一個(gè)任務(wù)不執(zhí)行完,不會(huì)開始第二個(gè),異步是不管第一個(gè)有沒有執(zhí)行完,都開始第二個(gè)。
串行和并行:串行是多個(gè)任務(wù)按一定順序執(zhí)行,并行是多個(gè)任務(wù)同時(shí)執(zhí)行;
代碼是在分線程執(zhí)行,在主線程嘟列中刷新UI。
多線程編程是防止主線程堵塞、增加運(yùn)行效率的最佳方法。
Apple提供了NSOperation這個(gè)類,提供了一個(gè)優(yōu)秀的多線程編程方法;
一個(gè)NSOperationQueue操作隊(duì)列,相當(dāng)于一個(gè)線程管理器,而非一個(gè)線程,因?yàn)槟憧梢栽O(shè)置這個(gè)線程管理器內(nèi)可以并行運(yùn)行的線程數(shù)量等。
多線程是一個(gè)比較輕量級(jí)的方法來實(shí)現(xiàn)單個(gè)應(yīng)用程序內(nèi)多個(gè)代碼執(zhí)行路徑。
iPhoneOS下的主線程的堆棧大小是1M。第二個(gè)線程開始就是512KB,并且該值不能通過編譯器開關(guān)或線程API函數(shù)來更改,只有主線程有直接修改UI的能力。
定時(shí)器與線程的區(qū)別
定時(shí)器;可以執(zhí)行多次,默認(rèn)在主線程中。
線程:只能執(zhí)行一次。
Apple設(shè)備尺寸和編程尺寸
iPhone設(shè)備
iPod設(shè)備
iPad設(shè)備
TCP和UDP的區(qū)別于聯(lián)系
TCP為傳輸控制層協(xié)議,為面向連接、可靠的、點(diǎn)到點(diǎn)的通信;
UDP為用戶數(shù)據(jù)報(bào)協(xié)議,非連接的不可靠的點(diǎn)到多點(diǎn)的通信;
TCP側(cè)重可靠傳輸,UDP側(cè)重快速傳輸。
TCP連接的三次握手
第一次握手:客戶端發(fā)送syn包(syn=j)到服務(wù)器,并進(jìn)入SYN_SEND狀態(tài),等待服務(wù)器確認(rèn);
第二次握手:服務(wù)器收到syn包,必須確認(rèn)客戶的SYN(ack=j+1),同時(shí)自己也發(fā)送一個(gè)SYN包,即SYN+ACK包,此時(shí)服務(wù)器進(jìn)入SYN+RECV狀態(tài);
第三次握手:客戶端收到服務(wù)器的SYN+ACK包,向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1),此發(fā)送完畢,客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài),完成三次狀態(tài)。
Scoket連接和HTTP連接的區(qū)別
HTTP協(xié)議是基于TCP連接的,是應(yīng)用層協(xié)議,主要解決如何包裝數(shù)據(jù)。Socket是對(duì)TCP/IP協(xié)議的封裝,Socket本身并不是協(xié)議,而是一個(gè)調(diào)用接口(API),通過Socket,我們才能使用TCP/IP協(xié)議。
HTTP連接:短連接,客戶端向服務(wù)器發(fā)送一次請(qǐng)求,服務(wù)器響應(yīng)后連接斷開,節(jié)省資源。服務(wù)器不能主動(dòng)給客戶端響應(yīng)(除非采用HTTP長連接技術(shù)),iPhone主要使用類NSURLConnection。
Socket連接:長連接,客戶端跟服務(wù)器端直接使用Socket進(jìn)行連接,沒有規(guī)定連接后斷開,因此客戶端和服務(wù)器段保持連接通道,雙方可以主動(dòng)發(fā)送數(shù)據(jù),一般多用于游戲.Socket默認(rèn)連接超時(shí)時(shí)間是30秒,默認(rèn)大小是8K(理解為一個(gè)數(shù)據(jù)包大小)。
HTTP協(xié)議的特點(diǎn),關(guān)于HTTP請(qǐng)求GET和POST的區(qū)別
GET和POST的區(qū)別:
HTTP超文本傳輸協(xié)議,是短連接,是客戶端主動(dòng)發(fā)送請(qǐng)求,服務(wù)器做出響應(yīng),服務(wù)器響應(yīng)之后,鏈接斷開。HTTP是一個(gè)屬于應(yīng)用層面向?qū)ο蟮膮f(xié)議,HTTP有兩類報(bào)文:請(qǐng)求報(bào)文和響應(yīng)報(bào)文。
HTTP請(qǐng)求報(bào)文:一個(gè)HTTP請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求數(shù)據(jù)4部分組成。
HTTP響應(yīng)報(bào)文:由三部分組成:狀態(tài)行、消息報(bào)頭、響應(yīng)正文。
GET請(qǐng)求:參數(shù)在地址后拼接,沒有請(qǐng)求數(shù)據(jù),不安全(因?yàn)樗袇?shù)都拼接在地址后面),不適合傳輸大量數(shù)據(jù)(長度有限制,為1024個(gè)字節(jié))。
GET提交、請(qǐng)求的數(shù)據(jù)會(huì)附在URL之后,即把數(shù)據(jù)放置在HTTP協(xié)議頭中。
以?分割URL和傳輸數(shù)據(jù),多個(gè)參數(shù)用&連接。如果數(shù)據(jù)是英文字母或數(shù)字,原樣發(fā)送,
如果是空格,轉(zhuǎn)換為+,如果是中文/其他字符,則直接把字符串用BASE64加密。
POST請(qǐng)求:參數(shù)在請(qǐng)求數(shù)據(jù)區(qū)放著,相對(duì)GET請(qǐng)求更安全,并且數(shù)據(jù)大小沒有限制。把提交的數(shù)據(jù)放置在HTTP包的包體中.
GET提交的數(shù)據(jù)會(huì)在地址欄顯示出來,而POST提交,地址欄不會(huì)改變。
傳輸數(shù)據(jù)的大小:
GET提交時(shí),傳輸數(shù)據(jù)就會(huì)受到URL長度限制,POST由于不是通過URL傳值,理論上書不受限。
安全性:
POST的安全性要比GET的安全性高;
通過GET提交數(shù)據(jù),用戶名和密碼將明文出現(xiàn)在URL上,比如登陸界面有可能被瀏覽器緩存。
HTTPS:安全超文本傳輸協(xié)議(Secure Hypertext Transfer Protocol),它是一個(gè)安全通信通道,基于HTTP開發(fā),用于客戶計(jì)算機(jī)和服務(wù)器之間交換信息,使用安全套結(jié)字層(SSI)進(jìn)行信息交換,即HTTP的安全版。
ASIHttpRequest、AFNetWorking之間的區(qū)別
ASIHttpRequest功能強(qiáng)大,主要是在MRC下實(shí)現(xiàn)的,是對(duì)系統(tǒng)CFNetwork API進(jìn)行了封裝,支持HTTP協(xié)議的CFHTTP,配置比較復(fù)雜,并且ASIHttpRequest框架默認(rèn)不會(huì)幫你監(jiān)聽網(wǎng)絡(luò)改變,如果需要讓ASIHttpRequest幫你監(jiān)聽網(wǎng)絡(luò)狀態(tài)改變,并且手動(dòng)開始這個(gè)功能。
AFNetWorking構(gòu)建于NSURLConnection、NSOperation以及其他熟悉的Foundation技術(shù)之上。擁有良好的架構(gòu),豐富的API及模塊構(gòu)建方式,使用起來非常輕松。它基于NSOperation封裝的,AFURLConnectionOperation子類。
ASIHttpRequest是直接操作對(duì)象ASIHttpRequest是一個(gè)實(shí)現(xiàn)了NSCoding協(xié)議的NSOperation子類;AFNetWorking直接操作對(duì)象的AFHttpClient,是一個(gè)實(shí)現(xiàn)NSCoding和NSCopying協(xié)議的NSObject子類。
同步請(qǐng)求:ASIHttpRequest直接通過調(diào)用一個(gè)startSynchronous方法;AFNetWorking默認(rèn)沒有封裝同步請(qǐng)求,如果開發(fā)者需要使用同步請(qǐng)求,則需要重寫getPath:paraments:success:failures方法,對(duì)于AFHttpRequestOperation進(jìn)行同步處理。
性能對(duì)比:AFNetworking請(qǐng)求優(yōu)于ASIHttpRequest;
XML數(shù)據(jù)解析方式各有什么不同,JSON解析有哪些框架?
XML數(shù)據(jù)解析的兩種解析方式:DOM解析和SAX解析;
DOM解析必須完成DOM樹的構(gòu)造,在處理規(guī)模較大的XML文檔時(shí)就很耗內(nèi)存,占用資源較多,讀入整個(gè)XML文檔并構(gòu)建一個(gè)駐留內(nèi)存的樹結(jié)構(gòu)(節(jié)點(diǎn)樹),通過遍歷樹結(jié)構(gòu)可以檢索任意XML節(jié)點(diǎn),讀取它的屬性和值,通常情況下,可以借助XPath查詢XML節(jié)點(diǎn);
SAX與DOM不同,它是事件驅(qū)動(dòng)模型,解析XML文檔時(shí)每遇到一個(gè)開始或者結(jié)束標(biāo)簽、屬性或者一條指令時(shí),程序就產(chǎn)生一個(gè)事件進(jìn)行相應(yīng)的處理,一邊讀取XML文檔一邊處理,不必等整個(gè)文檔加載完才采取措施,當(dāng)在讀取解析過程中遇到需要處理的對(duì)象,會(huì)發(fā)出通知進(jìn)行處理。因此,SAX相對(duì)于DOM來說更適合操作大的XML文檔。
JSON解析:性能比較好的主要是第三方的JSONKIT和iOS自帶的JSON解析類,其中自帶的JSON解析性能最高,但只能用于iOS5之后。
如何進(jìn)行真機(jī)調(diào)試?
1.首先需要用鑰匙串創(chuàng)建一個(gè)鑰匙(key);
2.將鑰匙串上傳到官網(wǎng),獲取iOS Development證書;
3.創(chuàng)建App ID即我們應(yīng)用程序中的Boundle ID;
4.添加Device ID即UDID;
5.通過勾選前面所創(chuàng)建的證書:App ID、Device ID;
6.生成mobileprovision文件;
7.先決條件:申請(qǐng)開發(fā)者賬號(hào) 99美刀
APP發(fā)布的上架流程
1.登錄應(yīng)用發(fā)布網(wǎng)站添加應(yīng)用信息;
2.下載安裝發(fā)布證書;
3.選擇發(fā)布證書,使用Archive編譯發(fā)布包,用Xcode將代碼(發(fā)布包)上傳到服務(wù)器;
4.等待審核通過;
5.生成IPA:菜單欄->Product->Archive.
SVN的使用
SVN=版本控制+備份服務(wù)器,可以把SVN當(dāng)成備份服務(wù)器,并且可以幫助你記住每次上服務(wù)器的檔案內(nèi)容,并自動(dòng)賦予每次變更的版本;
SVN的版本控制:所有上傳版本都會(huì)幫您記錄下來,也有版本分支及合并等功能。SVN可以讓不同的開發(fā)者存取同樣的檔案,并且利用SVN Server作為檔案同步的機(jī)制,即您有檔案更新時(shí),無需將檔案寄送給您的開發(fā)成員。SVN的存放檔案方式是采用差異備份的方式,即會(huì)備份到不同的地方,節(jié)省硬盤空間,也可以對(duì)非文字文件進(jìn)行差異備份。
SVN的重要性:備份工作檔案的重要性、版本控管的重要性、伙伴間的數(shù)據(jù)同步的重要性、備份不同版本是很耗費(fèi)硬盤空間的;
防止沖突:
1.防止代碼沖突:不要多人同時(shí)修改同一文件,例如:A、B都修改同一個(gè)文件,先讓A修改,然后提交到服務(wù)器,然后B更新下來,再進(jìn)行修改;
2.服務(wù)器上的項(xiàng)目文件Xcodeproj,僅讓一個(gè)人管理提交,其他人只更新,防止文件發(fā)生沖突。
如何進(jìn)行網(wǎng)絡(luò)消息推送
一種是Apple自己提供的通知服務(wù)(APNS服務(wù)器)、一種是用第三方推送機(jī)制。
首先應(yīng)用發(fā)送通知,系統(tǒng)彈出提示框詢問用戶是否允許,當(dāng)用戶允許后向蘋果服務(wù)器(APNS)請(qǐng)求deviceToken,并由蘋果服務(wù)器發(fā)送給自己的應(yīng)用,自己的應(yīng)用將DeviceToken發(fā)送自己的服務(wù)器,自己服務(wù)器想要發(fā)送網(wǎng)絡(luò)推送時(shí)將deviceToken以及想要推送的信息發(fā)送給蘋果服務(wù)器,蘋果服務(wù)器將信息發(fā)送給應(yīng)用。
推送信息內(nèi)容,總?cè)萘坎怀^256個(gè)字節(jié);
iOS SDK本身提供的APNS服務(wù)器推送,它可以直接推送給目標(biāo)用戶并根據(jù)您的方式彈出提示。
優(yōu)點(diǎn):不論應(yīng)用是否開啟,都會(huì)發(fā)送到手機(jī)端;
缺點(diǎn):消息推送機(jī)制是蘋果服務(wù)端控制,個(gè)別時(shí)候可能會(huì)有延遲,因?yàn)樘O果服務(wù)器也有隊(duì)列來處理所有的消息請(qǐng)求;
第三方推送機(jī)制,普遍使用Socket機(jī)制來實(shí)現(xiàn),幾乎可以達(dá)到即時(shí)的發(fā)送到目標(biāo)用戶手機(jī)端,適用于即時(shí)通訊類應(yīng)用。
優(yōu)點(diǎn):實(shí)時(shí)的,取決于心跳包的節(jié)奏;
缺點(diǎn):iOS系統(tǒng)的限制,應(yīng)用不能長時(shí)間的后臺(tái)運(yùn)行,所以應(yīng)用關(guān)閉的情況下這種推送機(jī)制不可用。
網(wǎng)絡(luò)七層協(xié)議
應(yīng)用層:
1.用戶接口、應(yīng)用程序;
2.Application典型設(shè)備:網(wǎng)關(guān);
3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用:TELNET、FTP、HTTP
表示層:
1.數(shù)據(jù)表示、壓縮和加密presentation
2.典型設(shè)備:網(wǎng)關(guān)
3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用:ASCLL、PICT、TIFF、JPEG|MPEG
4.表示層相當(dāng)于一個(gè)東西的表示,表示的一些協(xié)議,比如圖片、聲音和視頻MPEG。
會(huì)話層:
1.會(huì)話的建立和結(jié)束;
2.典型設(shè)備:網(wǎng)關(guān);
3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用:RPC、SQL、NFS、X WINDOWS、ASP
傳輸層:
1.主要功能:端到端控制Transport;
2.典型設(shè)備:網(wǎng)關(guān);
3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用:TCP、UDP、SPX
網(wǎng)絡(luò)層:
1.主要功能:路由、尋址Network;
2.典型設(shè)備:路由器;
3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用:IP、IPX、APPLETALK、ICMP;
數(shù)據(jù)鏈路層:
1.主要功能:保證無差錯(cuò)的疏忽鏈路的data link;
2.典型設(shè)備:交換機(jī)、網(wǎng)橋、網(wǎng)卡;
3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用:802.2、802.3ATM、HDLC、FRAME RELAY;
物理層:
1.主要功能:傳輸比特流Physical;
2.典型設(shè)備:集線器、中繼器
3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用:V.35、EIA/TIA-232.
對(duì)NSUserDefaults的理解
NSUserDefaults:系統(tǒng)提供的一種存儲(chǔ)數(shù)據(jù)的方式,主要用于保存少量的數(shù)據(jù),默認(rèn)存儲(chǔ)到library下的Preferences文件夾。
SDWebImage原理
調(diào)用類別的方法:
從內(nèi)存中(字典)找圖片(當(dāng)這個(gè)圖片在本次程序加載過),找到直接使用;
從沙盒中找,找到直接使用,緩存到內(nèi)存。
從網(wǎng)絡(luò)上獲取,使用,緩存到內(nèi)存,緩存到沙盒。
OC中是否有二維數(shù)組,如何實(shí)現(xiàn)二維數(shù)組?
OC中沒有二維數(shù)組,可通過嵌套數(shù)組實(shí)現(xiàn)二維數(shù)組。
LayoutSubViews在什么時(shí)候被調(diào)用?
當(dāng)View本身的frame改變時(shí),會(huì)調(diào)用這個(gè)方法。
深拷貝和淺拷貝
如果對(duì)象有個(gè)指針型成員變量指向內(nèi)存中的某個(gè)資源,那么如何復(fù)制這個(gè)對(duì)象呢?你會(huì)只是復(fù)制指針的值傳給副本的新對(duì)象嗎?指針只是存儲(chǔ)內(nèi)存中資源地址的占位符。在復(fù)制操作中,如果只是將指針復(fù)制給新對(duì)象,那么底層的資源實(shí)際上仍然由兩個(gè)實(shí)例在共享。
示例圖1
淺復(fù)制:兩個(gè)實(shí)例的指針仍指向內(nèi)存中的同一資源,只復(fù)制指針值而不是實(shí)際資源;
深復(fù)制:不僅復(fù)制指針值,還復(fù)制指向指針?biāo)赶虻馁Y源。如下圖:
示例圖2
單例模式理解與使用
單例模式是一種常用設(shè)計(jì)模式,單例模式是一個(gè)類在系統(tǒng)中只有一個(gè)實(shí)例對(duì)象。通過全局的一個(gè)入口點(diǎn)對(duì)這個(gè)實(shí)例對(duì)象進(jìn)行訪問;
iOS中單例模式的實(shí)現(xiàn)方式一般分為兩種:非ARC和ARC+GCD。
對(duì)沙盒的理解
每個(gè)iOS應(yīng)用都被限制在“沙盒”中,沙盒相當(dāng)于一個(gè)加了僅主人可見權(quán)限的文件夾,及時(shí)在應(yīng)用程序安裝過程中,系統(tǒng)為每個(gè)單獨(dú)的應(yīng)用程序生成它的主目錄和一些關(guān)鍵的子目錄。蘋果對(duì)沙盒有幾條限制:
1.應(yīng)用程序在自己的沙盒中運(yùn)作,但是不能訪問任何其他應(yīng)用程序的沙盒;
2.應(yīng)用之間不能共享數(shù)據(jù),沙盒里的文件不能被復(fù)制到其他應(yīng)用程序的文件夾中,也不能把其他應(yīng)用文件夾復(fù)制到沙盒中;
3.蘋果禁止任何讀寫沙盒以外的文件,禁止應(yīng)用程序?qū)?nèi)容寫到沙盒以外的文件夾中;
4.沙盒目錄里有三個(gè)文件夾:Documents——存儲(chǔ);應(yīng)用程序的數(shù)據(jù)文件,存儲(chǔ)用戶數(shù)據(jù)或其他定期備份的信息;Library下有兩個(gè)文件夾,Caches存儲(chǔ)應(yīng)用程序再次啟動(dòng)所需的信息,
Preferences包含應(yīng)用程序的偏好設(shè)置文件,不可在這更改偏好設(shè)置;temp存放臨時(shí)文件即應(yīng)用程序再次啟動(dòng)不需要的文件。
獲取沙盒根目錄的方法,有幾種方法:用NSHomeDirectory獲取。
獲取Document路徑:NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,NSUserDomainMask,YES).
對(duì)瀑布流的理解
首先圖片的寬度都是一樣的,1.將圖片等比例壓縮,讓圖片不變形;2.計(jì)算圖片最低應(yīng)該擺放的位置,哪一列低就放在哪;3.進(jìn)行最優(yōu)排列,在ScrollView的基礎(chǔ)上添加兩個(gè)tableView,然后將之前所計(jì)算的scrollView的高度通過tableView展示出來。
如何使用兩個(gè)TableView產(chǎn)生聯(lián)動(dòng):將兩個(gè)tableView的滾動(dòng)事件禁止掉,最外層scrollView滾動(dòng)時(shí)將兩個(gè)TableView跟著滾動(dòng),并且更改contentOffset,這樣產(chǎn)生效果滾動(dòng)的兩個(gè)tableView。
ViewController 的 loadView、viewDidLoad、viewDidUnload 分別是在什么時(shí)候調(diào)用的?
viewDidLoad在view從nib文件初始化時(shí)調(diào)用,loadView在controller的view為nil時(shí)調(diào)用。
此方法在編程實(shí)現(xiàn)view時(shí)調(diào)用,view控制器默認(rèn)會(huì)注冊(cè)memory warning notification,當(dāng)view controller的任何view沒有用的時(shí)候,viewDidUnload會(huì)被調(diào)用,在這里實(shí)現(xiàn)將retain的view release,如果是retain的IBOutlet view 屬性則不要在這里release,IBOutlet會(huì)負(fù)責(zé)release 。
關(guān)鍵字volatile有什么含意?并給出三個(gè)不同的例子:
一個(gè)定義為volatile的變量是說這變量可能會(huì)被意想不到地改變,這樣,編譯器就不會(huì)去假設(shè)這個(gè)變量的值了。精確地說就是,優(yōu)化器在用到這個(gè)變量時(shí)必須每次都小心地重新讀取這個(gè)變量的值,而不是使用保存在寄存器里的備份。下面是volatile變量的幾個(gè)例子:
1.并行設(shè)備的硬件寄存器(如:狀態(tài)寄存器);
2.一個(gè)中斷服務(wù)子程序中會(huì)訪問到的非自動(dòng)變量(Non-automatic variables);
3.多線程應(yīng)用中被幾個(gè)任務(wù)共享的變量。
@synthesize、@dynamic的理解
@synthesize是系統(tǒng)自動(dòng)生成getter和setter屬性聲明;@synthesize的意思是,除非開發(fā)人員已經(jīng)做了,否則由編譯器生成相應(yīng)的代碼,以滿足屬性聲明;
@dynamic是開發(fā)者自已提供相應(yīng)的屬性聲明,@dynamic意思是由開發(fā)人員提供相應(yīng)的代碼:對(duì)于只讀屬性需要提供setter,對(duì)于讀寫屬性需要提供 setter 和getter。查閱了一些資料確定@dynamic的意思是告訴編譯器,屬性的獲取與賦值方法由用戶自己實(shí)現(xiàn), 不自動(dòng)生成。
frame和bounds有什么不同?
frame指的是:該view在父view坐標(biāo)系統(tǒng)中的位置和大小。(參照點(diǎn)是父親的坐標(biāo)系統(tǒng))
bounds指的是:該view在本身坐標(biāo)系統(tǒng)中的位置和大小。(參照點(diǎn)是本身坐標(biāo)系統(tǒng))
view的touch事件有哪些?
- (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;
自定義實(shí)現(xiàn)UITabbarController的原理
運(yùn)用字典,點(diǎn)擊五個(gè)按鈕的一個(gè)可以從字典里選擇一個(gè)控制器對(duì)象,將其View顯示到主控制器視圖上。
iOS中的響應(yīng)者鏈的工作原理
每一個(gè)應(yīng)用有一個(gè)響應(yīng)者鏈,我們的視圖結(jié)構(gòu)是一個(gè)N叉樹(一個(gè)視圖可以有多個(gè)子視圖,一個(gè)子視圖同一時(shí)刻只有一個(gè)父視圖),而每一個(gè)繼承UIResponder的對(duì)象都可以在這個(gè)N叉樹中扮演一個(gè)節(jié)點(diǎn)。
當(dāng)葉節(jié)點(diǎn)成為最高響應(yīng)者的時(shí)候,從這個(gè)葉節(jié)點(diǎn)開始往其父節(jié)點(diǎn)開始追朔出一條鏈,那么對(duì)于這一個(gè)葉節(jié)點(diǎn)來講,這一條鏈就是當(dāng)前的響應(yīng)者鏈。響應(yīng)者鏈將系統(tǒng)捕獲到的UIEvent與UITouch從葉節(jié)點(diǎn)開始層層向下分發(fā),期間可以選擇停止分發(fā),也可以選擇繼續(xù)向下分發(fā)。
如需了解更多細(xì)節(jié),請(qǐng)讀這篇文章。
View和View之間傳值方式
對(duì)象的property屬性傳值;
方法參數(shù)傳值;
NSUserDefault傳值;
塊傳值。
property屬性的修飾符的作用
getter=getName、setter=setName:設(shè)置setter與getter的方法名;
readwrite、readonly:設(shè)置可供訪問級(jí)別;
assign:方法直接賦值,不進(jìn)行任何retain操作,為了解決原類型與環(huán)循引用問題;
retain:其setter方法對(duì)參數(shù)進(jìn)行release舊值再retain新值,所有實(shí)現(xiàn)都是這個(gè)順序;
copy:其setter方法進(jìn)行copy操作,與retain處理流程一樣,先對(duì)舊值release,再copy出新的對(duì)象,retainCount為1。這是為了減少對(duì)上下文的依賴而引入的機(jī)制。
nonatomic:非原子性訪問,不加同步, 多線程并發(fā)訪問會(huì)提高性能。注意,如果不加此屬性,則默認(rèn)是兩個(gè)訪問方法都為原子型事務(wù)訪問。
對(duì)于Run Loop的理解
RunLoop,是多線程的法寶,即一個(gè)線程一次只能執(zhí)行一個(gè)任務(wù),執(zhí)行完任務(wù)后就會(huì)退出線程。主線程執(zhí)行完即時(shí)任務(wù)時(shí)會(huì)繼續(xù)等待接收事件而不退出。非主線程通常來說就是為了執(zhí)行某一任務(wù)的,執(zhí)行完畢就需要?dú)w還資源,因此默認(rèn)是不運(yùn)行RunLoop的;
每一個(gè)線程都有其對(duì)應(yīng)的RunLoop,只是默認(rèn)只有主線程的RunLoop是啟動(dòng)的,其它子線程的RunLoop默認(rèn)是不啟動(dòng)的,若要啟動(dòng)則需要手動(dòng)啟動(dòng);
在一個(gè)單獨(dú)的線程中,如果需要在處理完某個(gè)任務(wù)后不退出,繼續(xù)等待接收事件,則需要啟用RunLoop;
NSRunLoop提供了一個(gè)添加NSTimer的方法,可以指定Mode,如果要讓任何情況下都回調(diào),則需要設(shè)置Mode為Common模式;
實(shí)質(zhì)上,對(duì)于子線程的runloop默認(rèn)是不存在的,因?yàn)樘O果采用了懶加載的方式。如果我們沒有手動(dòng)調(diào)用[NSRunLoop currentRunLoop]的話,就不會(huì)去查詢是否存在當(dāng)前線程的RunLoop,也就不會(huì)去加載,更不會(huì)創(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)缺點(diǎn)
優(yōu)點(diǎn):
XIB:在編譯前就提供了可視化界面,可以直接拖控件,也可以直接給控件添加約束,更直觀一些,而且類文件中就少了創(chuàng)建控件的代碼,確實(shí)簡化不少,通常每個(gè)XIB對(duì)應(yīng)一個(gè)類。
Storyboard:在編譯前提供了可視化界面,可拖控件,可加約束,在開發(fā)時(shí)比較直觀,而且一個(gè)storyboard可以有很多的界面,每個(gè)界面對(duì)應(yīng)一個(gè)類文件,通過storybard,可以直觀地看出整個(gè)App的結(jié)構(gòu)。
缺點(diǎn):
XIB:需求變動(dòng)時(shí),需要修改XIB很大,有時(shí)候甚至需要重新添加約束,導(dǎo)致開發(fā)周期變長。XIB載入相比純代碼自然要慢一些。對(duì)于比較復(fù)雜邏輯控制不同狀態(tài)下顯示不同內(nèi)容時(shí),使用XIB是比較困難的。當(dāng)多人團(tuán)隊(duì)或者多團(tuán)隊(duì)開發(fā)時(shí),如果XIB文件被發(fā)動(dòng),極易導(dǎo)致沖突,而且解決沖突相對(duì)要困難很多。
Storyboard:需求變動(dòng)時(shí),需要修改storyboard上對(duì)應(yīng)的界面的約束,與XIB一樣可能要重新添加約束,或者添加約束會(huì)造成大量的沖突,尤其是多團(tuán)隊(duì)開發(fā)。對(duì)于復(fù)雜邏輯控制不同顯示內(nèi)容時(shí),比較困難。當(dāng)多人團(tuán)隊(duì)或者多團(tuán)隊(duì)開發(fā)時(shí),大家會(huì)同時(shí)修改一個(gè)storyboard,導(dǎo)致大量沖突,解決起來相當(dāng)困難。
將字符串“2015-04-10”格式化日期轉(zhuǎn)為NSDate類型
NSString *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);
隊(duì)列和多線程的使用原理
在iOS中隊(duì)列分為以下幾種:
串行隊(duì)列:隊(duì)列中的任務(wù)只會(huì)順序執(zhí)行;
dispatch_queue_t q = dispatch_queue_create("...", DISPATCH_QUEUE_SERIAL);
并行隊(duì)列: 隊(duì)列中的任務(wù)通常會(huì)并發(fā)執(zhí)行;
dispatch_queue_t q = dispatch_queue_create("......",DISPATCH_QUEUE_CONCURRENT);
全局隊(duì)列:是系統(tǒng)的,直接拿過來(GET)用就可以;與并行隊(duì)列類似;
dispatch_queue_t q = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
主隊(duì)列:每一個(gè)應(yīng)用程序?qū)?yīng)唯一主隊(duì)列,直接GET即可;在多線程開發(fā)中,使用主隊(duì)列更新UI;
dispatch_queue_t q = dispatch_get_main_queue();
更多細(xì)節(jié)見下圖:
內(nèi)存的使用和優(yōu)化的注意事項(xiàng)
重用問題:如UITableViewCells、UICollectionViewCells、UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier,充分重用;
盡量把views設(shè)置為不透明:當(dāng)opque為NO的時(shí)候,圖層的半透明取決于圖片和其本身合成的圖層為結(jié)果,可提高性能;
不要使用太復(fù)雜的XIB/Storyboard:載入時(shí)就會(huì)將XIB/storyboard需要的所有資源,包括圖片全部載入內(nèi)存,即使未來很久才會(huì)使用。那些相比純代碼寫的延遲加載,性能及內(nèi)存就差了很多;
選擇正確的數(shù)據(jù)結(jié)構(gòu):學(xué)會(huì)選擇對(duì)業(yè)務(wù)場(chǎng)景最合適的數(shù)組結(jié)構(gòu)是寫出高效代碼的基礎(chǔ)。比如,數(shù)組: 有序的一組值。使用索引來查詢很快,使用值查詢很慢,插入/刪除很慢。字典: 存儲(chǔ)鍵值對(duì),用鍵來查找比較快。集合: 無序的一組值,用值來查找很快,插入/刪除很快。
gzip/zip壓縮:當(dāng)從服務(wù)端下載相關(guān)附件時(shí),可以通過gzip/zip壓縮后再下載,使得內(nèi)存更小,下載速度也更快。
延遲加載:對(duì)于不應(yīng)該使用的數(shù)據(jù),使用延遲加載方式。對(duì)于不需要馬上顯示的視圖,使用延遲加載方式。比如,網(wǎng)絡(luò)請(qǐng)求失敗時(shí)顯示的提示界面,可能一直都不會(huì)使用到,因此應(yīng)該使用延遲加載。
數(shù)據(jù)緩存:對(duì)于cell的行高要緩存起來,使得reload數(shù)據(jù)時(shí),效率也極高。而對(duì)于那些網(wǎng)絡(luò)數(shù)據(jù),不需要每次都請(qǐng)求的,應(yīng)該緩存起來,可以寫入數(shù)據(jù)庫,也可以通過plist文件存儲(chǔ)。
處理內(nèi)存警告:一般在基類統(tǒng)一處理內(nèi)存警告,將相關(guān)不用資源立即釋放掉
重用大開銷對(duì)象:一些objects的初始化很慢,比如NSDateFormatter和NSCalendar,但又不可避免地需要使用它們。通常是作為屬性存儲(chǔ)起來,防止反復(fù)創(chuàng)建。
避免反復(fù)處理數(shù)據(jù):許多應(yīng)用需要從服務(wù)器加載功能所需的常為JSON或者XML格式的數(shù)據(jù)。在服務(wù)器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要;
使用Autorelease Pool:在某些循環(huán)創(chuàng)建臨時(shí)變量處理數(shù)據(jù)時(shí),自動(dòng)釋放池以保證能及時(shí)釋放內(nèi)存;
正確選擇圖片加載方式:詳情閱讀細(xì)讀UIImage加載方式
UIViewController的完整生命周期
-[ViewController initWithNibName:bundle:];
-[ViewController init];
-[ViewController loadView];
-[ViewController viewDidLoad];
-[ViewController viewWillDisappear:];
-[ViewController viewWillAppear:];
-[ViewController viewDidAppear:];
-[ViewController viewDidDisappear:];
UIImageView添加圓角
最直接的方法就是使用如下屬性設(shè)置:
imgView.layer.cornerRadius = 10;
// 這一行代碼是很消耗性能的
imgView.clipsToBounds = YES;
這是離屏渲染(off-screen-rendering),消耗性能的
給UIImage添加生成圓角圖片的擴(kuò)展API:這是on-screen-rendering
- (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();
return image;
}