【正文】 ForRowAtIndexPath再次被調(diào)用的時(shí) 候,tableView dequeueReusableCellWithIdentifier:CellIdentifier,返回cell1。cell2移出 visiableCells,cell2加入到reusableTableCells。程序最開始顯示TableView的情況是: [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] 創(chuàng)建10次cell,并給cell指定同樣的重用標(biāo)識(shí)(當(dāng)然,可以為不同顯示類型的cell指定不同的標(biāo)識(shí))。,當(dāng)cell1完全移出屏幕,并且 cell11(它也是alloc出來的,原因同上)完全顯示出來的時(shí)候。,因?yàn)閞eusableTableCells中已 經(jīng)有值,所以,當(dāng)需要顯示新的cell, cellForRowAtIndexPath再次被調(diào)用的時(shí) 候,tableView dequeueReusableCellWithIdentifier:CellIdentifier,返回cell1。cell2移出 visiableCells,cell2加入到reusableTableCells。實(shí)際上針對(duì)性地優(yōu)化一下就可以解決tableView滑動(dòng)的時(shí)候卡頓的問題, 在iOS應(yīng)用中，UITableView應(yīng)該是使用率最高的視圖之一了。然而在使用第三方應(yīng)用時(shí)，卻經(jīng)常遇到性能上的問題，普遍表現(xiàn)在滾動(dòng)時(shí)比較卡，特別是table cell中包含圖片的情況時(shí)。UITableView是UIScrollView的子類，因此它可以自動(dòng)響應(yīng)滾動(dòng)事件（一般為上下滾動(dòng)）。當(dāng)新cell需要被顯示時(shí)，就會(huì)調(diào)用tableView:cellForRowAtIndexPath:方法來獲取或創(chuàng)建一個(gè) cell；而不可視時(shí)，它又會(huì)被釋放。此 外，UITableView還可以分為多個(gè)sections，每個(gè)區(qū)段都可以有自己的head、foot和cells。這在iOS SDK中是用NSIndexPath來表述的，UIKit為其添加了indexPathForRow:inSection:這個(gè)創(chuàng)建方法。介紹完原理，接下來就開始優(yōu)化吧。不透明的視圖可以極大地提高渲染的速度。其中的特例包括背景色，它的alpha值應(yīng)該為1（例如不要使用clearColor）；圖像的alpha值也應(yīng)該為1，或者在畫圖時(shí)設(shè)為不透明。前面說了，UITableView只需要一屏幕的UITableViewCell對(duì)象即可。而UITableView也提供了這種機(jī)制，只需要簡(jiǎn)單地設(shè)置一個(gè)identifier即可：static NSString *CellIdentifier = “xxx”。if(cell == nil){ cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease]。此 外，在添加table cell的時(shí)候，如果不需要?jiǎng)赢嬓Ч?，最好不要使用insertRowsAtIndexPaths:withRowAnimation:方法，而是直接調(diào) 用reloadData方法?？闭`：只是在模擬器上測(cè)試如此，真機(jī)調(diào)試時(shí)沒有這種bug。UITableViewCell包含了textLabel、detailTextLabel和imageView等view，而你還可以自定義一些視圖放在它的contentView里。如果你的table cell包含圖片，且數(shù)目較多，使用默認(rèn)的UITableViewCell會(huì)非常影響性能。當(dāng)然，最佳的解決辦法還是繼承UITableViewCell，并在其drawRect:中自行繪制：(void)drawRect:(CGRect)rect { if(image){ [image drawAtPoint:imagePoint]。} else { [placeHolder drawAtPoint:imagePoint]。} 不過這樣一來，你會(huì)發(fā)現(xiàn)選中一行后，這個(gè)cell就變藍(lán)了，其中的內(nèi)容就被擋住了。此外還可以創(chuàng)建CALayer，將內(nèi)容繪制到layer上，:方法。解決辦法可參見后面的預(yù)渲染圖像。在實(shí)現(xiàn)drawRect:的時(shí)候，它的rect參數(shù)就是需要繪制的區(qū)域，這個(gè)區(qū)域之外的不需要進(jìn)行繪制。預(yù)渲染圖像。解決的辦法就是在bitmap context里先將其畫一遍，導(dǎo)出成UIImage對(duì)象，然后再繪制到屏幕，詳細(xì)做法可見《利用預(yù)渲染加速iOS設(shè)備的圖像顯示》。做到前幾點(diǎn)后，你的table view滾動(dòng)時(shí)應(yīng)該足夠流暢了，不過你仍可能讓用戶感到不爽。出現(xiàn)這種現(xiàn)象的原因就是主線程執(zhí)行了耗時(shí)很長(zhǎng)的函數(shù)或方法，在其執(zhí)行完畢前，無法繪制屏幕和響應(yīng)用戶請(qǐng)求。解決辦法就是使用多線程，讓子線程去執(zhí)行這些函數(shù)或方法。因此在使用 ASIHTTPRequest時(shí)，可以用一個(gè)NSOperationQueue來維護(hù)下載請(qǐng)求，并將其maxConcurrentOperationCount設(shè)為2。當(dāng)然，在不需要響應(yīng)用戶請(qǐng)求時(shí)，也可以增加下載線程數(shù)，以加快下載速度：(void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate { if(!decelerate){ = 5。} 此外，自動(dòng)載入更新數(shù)據(jù)對(duì)用戶來說也很友好，這減少了用戶等待下載的時(shí)間。amp。[self update]。for(NSIndexPath *visibleIndexPath in indexPaths){ if(indexPath == visibleIndexPath){ MyTableViewCell *cell =(MyTableViewCell *)[ cellForRowAtIndexPath:indexPath]。[cell setNeedsDisplayInRect:imageRect]。} }// 也可不遍歷，直接與頭尾相比較，看是否在中間即可。而換成reloadData方法的話，瞬間就處理完了。雖然SQLite是一款輕型數(shù)據(jù)庫，但是其功能也絕不亞于很多大型關(guān)系數(shù)據(jù)庫。和其他數(shù)據(jù)庫相比，SQLite中的SQL語法并沒有太大的差別，因此這里對(duì)于SQL語句的內(nèi)容不會(huì)過多贅述，大家可以參考SQLite中其他SQL相關(guān)的內(nèi)容，這里還是重點(diǎn)講解iOS中如何使用SQLite構(gòu)建應(yīng)用程序。打開數(shù)據(jù)庫會(huì)得到一個(gè)sqlite3類型的對(duì)象，后面需要借助這個(gè)對(duì)象進(jìn)行其他操作。（如增加、刪除、修改等）直接通過sqlite3_exec()函數(shù)執(zhí)行；()進(jìn)行sql語句評(píng)估（語法檢測(cè)），然后通過sqlite3_step()依次取出查詢結(jié)果的每一行數(shù)據(jù)，對(duì)于每行數(shù)據(jù)都可以通過對(duì)應(yīng)的sqlite3_column_類型()方法獲得對(duì)應(yīng)列的數(shù)據(jù)，如此反復(fù)循環(huán)直到遍歷完成。說一說你對(duì)FMDB的認(rèn)識(shí)FMDB是一個(gè)處理數(shù)據(jù)存儲(chǔ)的第三方框架，框架是對(duì)sqlite的封裝，整個(gè)框架非常輕量級(jí)但又不失靈活性，而且更加面向?qū)ο蟆＿@里FMDB引入了一個(gè)MFDatabase對(duì)象來表示數(shù)據(jù)庫，打開數(shù)據(jù)庫和后面的數(shù)據(jù)庫操作全部依賴此對(duì)象。當(dāng)然這兩個(gè)方法有很多的重載這里就不詳細(xì)解釋了。，如果遇到多個(gè)線程同時(shí)操作一個(gè)表的時(shí)候可能會(huì)發(fā)生意想不到的結(jié)果。，而是因?yàn)镕MDB將其封裝成了幾個(gè)方法來調(diào)用，不用自己寫對(duì)應(yīng)的sql而已?！眻?zhí)行完之后執(zhí)行“mit transaction?！边M(jìn)行提交或回滾即可。在FMDB中FMDatabase有beginTransaction、mit、rollback三個(gè)方法進(jìn)行開啟事務(wù)、提交事務(wù)和回滾事務(wù)。經(jīng)過這幾個(gè)步驟之后可以得到管理對(duì)象上下文NSManagedObjectContext，以后所有的數(shù)據(jù)操作都由此對(duì)象負(fù)責(zé)。對(duì)于有條件的查詢，在Core Data中是通過謂詞來實(shí)現(xiàn)的。插入數(shù)據(jù)需要調(diào)用實(shí)體描述對(duì)象NSEntityDescription返回一個(gè)實(shí)體對(duì)象，然后設(shè)置對(duì)象屬性，最后保存當(dāng)前上下文即可。刪除數(shù)據(jù)可以直接調(diào)用管理對(duì)象上下文的deleteObject方法，刪除完保存上下文即可。修改數(shù)據(jù)首先也是取出對(duì)應(yīng)的實(shí)體對(duì)象，然后通過修改對(duì)象的屬性，最后保存上下文。SQLite擅長(zhǎng)處理的數(shù)據(jù)類型其實(shí)與NSUserDefaults差不多,也是基礎(chǔ)類型的小數(shù)據(jù),只是從組織形式上不同。一般來說應(yīng)用中的格式化的文本類數(shù)據(jù)可以存放在數(shù)據(jù)庫中,尤其是類似聊天記錄、Timeline等這些具有條件查詢和排序需求的數(shù)據(jù)。它可以把整個(gè)應(yīng)用中的對(duì)象建模并進(jìn)行自動(dòng)化的管理。框架會(huì)自動(dòng)控制這個(gè)過程,從而達(dá)到控制內(nèi)存消耗,避免浪費(fèi)。因此,如果僅僅是考慮緩存數(shù)據(jù)這個(gè)需求,CoreData絕對(duì)不是一個(gè)優(yōu)選方案。使用基本對(duì)象類型定制的個(gè)性化緩存方案:從需求出發(fā)分析緩存數(shù)據(jù)有哪些要求:按Key查找,快速讀取,寫入不影響正常操作,不浪費(fèi)內(nèi)存,支持歸檔。數(shù)據(jù)存儲(chǔ)這一塊,面試常問, 你常用哪一種數(shù)據(jù)存儲(chǔ)?什么是序列化?sqlite是直接用它還是用封裝了它的第三方庫?尤其是會(huì)問sqlite和core data的區(qū)別?IOS平臺(tái)怎么做數(shù)據(jù)的持久化?coredata和sqlite有無必然聯(lián)系?coredata是一個(gè)關(guān)系型數(shù)據(jù)庫嗎?iOS中可以有四種持久化數(shù)據(jù)的方式: 屬性列表、對(duì)象歸檔、SQLite3和Core Data coredata可以使你以圖形界面的方式快速的定義app的數(shù)據(jù)模型,同時(shí)在你的代碼中容易獲取到它。在使用coredata的時(shí)候,你不用安裝額外的數(shù)據(jù)庫系統(tǒng),因?yàn)閏oredata使用內(nèi)置的sqlite數(shù)據(jù)庫。coredata會(huì)追蹤這些對(duì)象的改變,同時(shí)可以根據(jù)需要做相應(yīng)的改變,例如用戶執(zhí)行撤銷命令。mac os x中sqlite庫,它是一個(gè)輕量級(jí)功能強(qiáng)大的關(guān)系數(shù)據(jù)引擎,也很容易嵌入到應(yīng)用程序。與coredata框架不同的是,sqlite是使用程序式的,sql的主要的API來直接操作數(shù)據(jù)表。雖然Core Dta支持SQLite作為一種存儲(chǔ)類型, 但它不能使用任意的SQLite數(shù)據(jù)庫。Core Data支持對(duì)一、對(duì)多的關(guān)系。? 刪除表字段ALTER TABLE 表名 DROP COLUMN 字段名。SQLite數(shù)據(jù)存儲(chǔ)是怎么用？添加SQLite動(dòng)態(tài)庫：導(dǎo)入主頭文件：import 利用C語言函數(shù)創(chuàng)建打開數(shù)據(jù)庫，編寫SQL語句簡(jiǎn)單描述下客戶端的緩存機(jī)制？1緩存可以分為：內(nèi)存數(shù)據(jù)緩存、數(shù)據(jù)庫緩存、文件緩存 2每次想獲取數(shù)據(jù)的時(shí)候 3先檢測(cè)內(nèi)存中有無緩存4再檢測(cè)本地有無緩存(數(shù)據(jù)庫文件)5最終發(fā)送網(wǎng)絡(luò)請(qǐng)求6將服務(wù)器返回的網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行緩存（內(nèi)存、數(shù)據(jù)庫、文件），以便下次讀取你實(shí)現(xiàn)過多線程的Core Data么？NSPersistentStoreCoordinator，NSManagedObjectContext和NSManagedObject中的哪些需要在線程中創(chuàng)建或者傳遞？你是用什么樣的策略來實(shí)現(xiàn)的？1CoreData是對(duì)SQLite數(shù)據(jù)庫的封裝2CoreData中的NSManagedObjectContext在多線程中不安全3如果想要多線程訪問CoreData的話，最好的方法是一個(gè)線程一個(gè)NSManagedObjectContext 4每個(gè)NSManagedObjectContext對(duì)象實(shí)例都可以使用同一個(gè)NSPersistentStoreCoordinator實(shí)例，這是因?yàn)镹SManagedObjectContext會(huì)在便用NSPersistentStoreCoordinator前上鎖core data數(shù)據(jù)遷移博客地址: 1FMDB的使用和對(duì)多張表的處理博客地址: 1說說數(shù)據(jù)庫的左連接和右連接的區(qū)別數(shù)據(jù)庫左連接和右連接的區(qū)別：主表不一樣通過左連接和右連接，最小條數(shù)為3（記錄條數(shù)較小的記錄數(shù)），最大條數(shù)為12（34）技術(shù)博客的地址 : ://