99热在线精品一区二区三区_国产伦精品一区二区三区女破破_亚洲一区二区三区无码_精品国产欧美日韩另类一区

ios開發(fā)之uitableview優(yōu)化機制有哪些

iOS開發(fā)UI篇—UITableviewcell的性能問題

創(chuàng)新互聯(lián)公司自2013年創(chuàng)立以來，先為施甸等服務(wù)建站，施甸等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為施甸企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

一、UITableviewcell的一些介紹

UITableView的每一行都是一個UITableViewCell,通過dataSource的 tableView:cellForRowAtIndexPath:方法來初始化每?行

UITableViewCell內(nèi)部有個默認的子視圖:contentView,contentView是UITableViewCell所顯示內(nèi)容的父視圖,可顯示一些輔助指示視圖

輔助指示視圖的作?是顯示一個表示動作的圖標,可以通過設(shè)置UITableViewCell的 accessoryType來顯示,默認是UITableViewCellAccessoryNone(不顯?示輔助指?示視圖), 其他值如下:

UITableViewCellAccessoryDisclosureIndicator

UITableViewCellAccessoryDetailDisclosureButton

UITableViewCellAccessoryCheckmark

還可以通過cell的accessoryView屬性來自定義輔助指示視圖(?如往右邊放一個開關(guān))

二、問題

cell的工作：在程序執(zhí)行的時候，能看到多少條，它就創(chuàng)建多少條數(shù)據(jù)，如果視圖滾動那么再創(chuàng)建新顯示的內(nèi)容。（系統(tǒng)自動調(diào)用）。即當(dāng)一個cell出現(xiàn)在視野范圍內(nèi)的時候，就會調(diào)用創(chuàng)建一個cell。這樣的邏輯看上去沒有什么問題，但是真的沒有任何問題嗎？

當(dāng)創(chuàng)建調(diào)用的時候，我們使用nslog打印消息，并打印創(chuàng)建的cell的地址。我們發(fā)現(xiàn)如果數(shù)據(jù)量非常大，用戶在短時間內(nèi)來回滾動的話，那么會創(chuàng)建大量的cell,一直開辟空間，且如果是往回滾，通過打印地址，我們會發(fā)現(xiàn)它并沒有重用之前已經(jīng)創(chuàng)建的cell，而是重新創(chuàng)建，開辟新的存儲空間。

那有沒有什么好的解決辦法呢？

三、cell的重用原理

（1） iOS設(shè)備的內(nèi)存有限,如果用UITableView顯示成千上萬條數(shù)據(jù),就需要成千上萬 個UITableViewCell對象的話,那將會耗盡iOS設(shè)備的內(nèi)存。要解決該問題,需要重用UITableViewCell對象

（2）重?原理:當(dāng)滾動列表時,部分UITableViewCell會移出窗口,UITableView會將窗口外的UITableViewCell放入一個對象池中,等待重用。當(dāng)UITableView要求dataSource返回 UITableViewCell時,dataSource會先查看這個對象池,如果池中有未使用的UITableViewCell,dataSource則會用新的數(shù)據(jù)來配置這個UITableViewCell,然后返回給 UITableView,重新顯示到窗口中,從而避免創(chuàng)建新對象 。這樣可以讓創(chuàng)建的cell的數(shù)量維持在很低的水平，如果一個窗口中只能顯示5個cell，那么cell重用之后，只需要創(chuàng)建6個cell就夠了。

（3）注意點：還有?個非常重要的問題:有時候需要自定義UITableViewCell(用?個子類繼 承UITableViewCell),而且每?行?的不一定是同一種UITableViewCell,所以一 個UITableView可能擁有不同類型的UITableViewCell,對象池中也會有很多不同類型的 UITableViewCell,那么UITableView在重?用UITableViewCell時可能會得到錯誤類型的 UITableViewCell

解決?方案:UITableViewCell有個NSString *reuseIdentifier屬性,可以在初始化UITableViewCell的時候傳入一個特定的字符串標識來設(shè)置reuseIdentifier(一般用UITableViewCell的類名)。當(dāng)UITableView要求dataSource返回UITableViewCell時,先 通過一個字符串標識到對象池中查找對應(yīng)類型的UITableViewCell對象,如果有,就重用,如果沒有,就傳入這個字符串標識來初始化?一個UITableViewCell對象。

圖片示例：

說明：一個窗口放得下（可視）三個cell，整個程序只需要創(chuàng)建4個該類型的cell即可。

四、cell的優(yōu)化代碼

代碼示例：

1 #import "NJViewController.h"

2 #import "NJHero.h"

3

4 // #define ID @"ABC"

5

6 @interface NJViewController ()UITableViewDataSource, UITableViewDelegate

7 /**

8 * 保存所有的英雄數(shù)據(jù)

9 */

10 @property (nonatomic, strong) NSArray *heros;

11 @property (weak, nonatomic) IBOutlet UITableView *tableView;

12

13 @end

14

15 @implementation NJViewController

16

17 #pragma mark - 懶加載

18 - (NSArray *)heros

19 {

20 if (_heros == nil) {

21 // 1.獲得全路徑

22 NSString *fullPath = [[NSBundle mainBundle] pathForResource:@"heros" ofType:@"plist"];

23 // 2.更具全路徑加載數(shù)據(jù)

24 NSArray *dictArray = [NSArray arrayWithContentsOfFile:fullPath];

25 // 3.字典轉(zhuǎn)模型

26 NSMutableArray *models = [NSMutableArray arrayWithCapacity:dictArray.count];

27 for (NSDictionary *dict in dictArray) {

28 NJHero *hero = [NJHero heroWithDict:dict];

29 [models addObject:hero];

30 }

31 // 4.賦值數(shù)據(jù)

32 _heros = [models copy];

33 }

34 // 4.返回數(shù)據(jù)

35 return _heros;

36 }

37

38 - (void)viewDidLoad

39 {

40 [super viewDidLoad];

41 // 設(shè)置Cell的高度

42 // 當(dāng)每一行的cell高度一致的時候使用屬性設(shè)置cell的高度

43 self.tableView.rowHeight = 160;

44 }

45

46 #pragma mark - UITableViewDataSource

47 // 返回多少組

48 - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

49 {

50 return 1;

51 }

52 // 返回每一組有多少行

53 - (NSInteger) tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

54 {

55 return self.heros.count;

56 }

57 // 當(dāng)一個cell出現(xiàn)視野范圍內(nèi)的時候就會調(diào)用

58 // 返回哪一組的哪一行顯示什么內(nèi)容

59 - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

60 {

61 // 定義變量保存重用標記的值

62 static NSString *identifier = @"hero";

63

64 // 1.先去緩存池中查找是否有滿足條件的Cell

65 UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];

66 // 2.如果緩存池中沒有符合條件的cell,就自己創(chuàng)建一個Cell

67 if (cell == nil) {

68 // 3.創(chuàng)建Cell, 并且設(shè)置一個唯一的標記

69 cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:identifier];

70 NSLog(@"創(chuàng)建一個新的Cell");

71 }

72 // 4.給cell設(shè)置數(shù)據(jù)

73 NJHero *hero = self.heros[indexPath.row];

74 cell.textLabel.text = hero.name;

75 cell.detailTextLabel.text = hero.intro;

76 cell.imageView.image = [UIImage imageNamed:hero.icon];

77

78 // NSLog(@"%@ - %d - %p", hero.name, indexPath.row, cell);

79

80 // 3.返回cell

81 return cell;

82 }

83

84 #pragma mark - 控制狀態(tài)欄是否顯示

85 /**

86 * 返回YES代表隱藏狀態(tài)欄, NO相反

87 */

88 - (BOOL)prefersStatusBarHidden

89 {

90 return YES;

91 }

92 @end

描述一下ios的內(nèi)存管理，在開發(fā)中對于內(nèi)存的使用和優(yōu)化包含哪些方面

內(nèi)存管理準則：誰強引用過，誰就在不再使用時使引用計數(shù)減一。

對于內(nèi)存的使用和優(yōu)化常見的有以下方面：

重用問題：如UITableViewCells、UICollectionViewCells、UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier，充分重用。

盡量把views設(shè)置為透明：如果你有透明的Views你應(yīng)該設(shè)置它們的opaque屬性為YES。opaque這個屬性給渲染系統(tǒng)提供了一個如何處理這個view的提示。如果設(shè)為YES，渲染系統(tǒng)就認為這個view是完全不透明的，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能。如果設(shè)置為NO，渲染系統(tǒng)正常地和其它內(nèi)容組成這個View。默認值是YES。

不要使用太復(fù)雜的XIB/Storyboard：載入時就會將XIB/storyboard需要的所有資源，包括圖片全部載入內(nèi)存，即使未來很久才會使用。那些相比純代碼寫的延遲加載，性能及內(nèi)存就差了很多。

選擇正確的數(shù)據(jù)結(jié)構(gòu)：學(xué)會選擇對業(yè)務(wù)場景最合適的數(shù)組結(jié)構(gòu)是寫出高效代碼的基礎(chǔ)。比如，數(shù)組: 有序的一組值。使用索引來查詢很快，使用值查詢很慢，插入/刪除很慢。字典: 存儲鍵值對，用鍵來查找比較快。集合: 無序的一組值，用值來查找很快，插入/刪除很快。

gzip/zip壓縮：當(dāng)從服務(wù)端下載相關(guān)附件時，可以通過gzip/zip壓縮后再下載，使得內(nèi)存更小，下載速度也更快。

延遲加載：對于不應(yīng)該使用的數(shù)據(jù)，使用延遲加載方式。對于不需要馬上顯示的視圖，使用延遲加載方式。比如，網(wǎng)絡(luò)請求失敗時顯示的提示界面，可能一直都不會使用到，因此應(yīng)該使用延遲加載。

數(shù)據(jù)緩存：對于cell的行高要緩存起來，使得reload數(shù)據(jù)時，效率也極高。而對于那些網(wǎng)絡(luò)數(shù)據(jù)，不需要每次都請求的，應(yīng)該緩存起來，可以寫入數(shù)據(jù)庫，也可以通過plist文件存儲。

處理內(nèi)存警告：一般在基類統(tǒng)一處理內(nèi)存警告，將相關(guān)不用資源立即釋放掉

重用大開銷對象：一些objects的初始化很慢，比如NSDateFormatter和NSCalendar，但又不可避免地需要使用它們。通常是作為屬性存儲起來，防止反復(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ù)據(jù)時，自動釋放池以保證能及時釋放內(nèi)存。

正確選擇圖片加載方式：詳情閱讀細讀UIImage加載方式

ios app性能優(yōu)化有哪些方面

一、優(yōu)先級別不同：iOS最先響應(yīng)屏幕

當(dāng)我們使用iOS或者是Android手機時，第一步就是滑屏解鎖找到相應(yīng)程序點擊進入。而這個時候往往是所有操控開始的第一步驟，iOS系統(tǒng)產(chǎn)品就表現(xiàn)出來了流暢的一面，但Android產(chǎn)品卻給人一種卡頓的現(xiàn)象，更別說后續(xù)深入玩游戲或者進行其它操控了。這是為什么？

其實這與兩個系統(tǒng)的優(yōu)先級有關(guān)，iOS對屏幕反應(yīng)的優(yōu)先級是最高的，它的響應(yīng)順序依次為Touch--Media--Service--Core架構(gòu)，換句話說當(dāng)用戶只要觸摸接觸了屏幕之后，系統(tǒng)就會最優(yōu)先去處理屏幕顯示也就是Touch這個層級，然后才是媒體（Media），服務(wù)（Service）以及Core架構(gòu)。而Android系統(tǒng)的優(yōu)先級響應(yīng)層級則是Application--Framework--Library--Kernal架構(gòu)，和顯示相關(guān)的圖形圖像處理這一部分屬于Library，你可以看到到第三位才是它，當(dāng)你觸摸屏幕之后Android系統(tǒng)首先會激活應(yīng)用，框架然后才是屏幕最后是核心架構(gòu)。

優(yōu)先級的不同導(dǎo)致了iOS產(chǎn)品以及Android手機在操控過程中的表現(xiàn)差異，當(dāng)你滑動屏幕進行操控的時候，iOS系統(tǒng)會優(yōu)先處理Touch層級，而Android系統(tǒng)則是第三個才響應(yīng)Library層級，這是造成它們流暢度不同的因素之一。

二、硬件工作配置不同：iOS基于GPU加速

目前智能手機硬件裝備競賽當(dāng)中，其實處理器等配置已經(jīng)達到了一個瓶頸期，各大旗艦產(chǎn)品在硬件比拼當(dāng)中基本上沒有太大的區(qū)別，而這時候GPU就成為了一個凸顯差異的重要因素。一些大型軟件像是3D游戲?qū)PU性能要求都會比較高，蘋果iPhone產(chǎn)品采用的Power VR SGX系列GPU在當(dāng)下來說非常的主流，跑分測試數(shù)據(jù)證明了它并不會比一些旗艦級別的Android產(chǎn)品差勁。

而iOS系統(tǒng)對圖形的各種特效處理基本上正好都是基于GPU硬件進行加速的，它可以不用完全借助CPU或者程序本身，而是通過GPU進行渲染以達到更流暢的操控表現(xiàn)。但是Android系統(tǒng)產(chǎn)品則并非如此，因為Android需要適應(yīng)不同的手機硬件，需要滿足各種差異配置，所以很多圖形特效大多都要靠程序本身進行加速和渲染，并嚴重依賴CPU運算的操作自然會加大處理器的負荷，從而出現(xiàn)卡頓的問題。雖然Android 4.0以及4.1等更高版本中進行了改進將硬件加速設(shè)為默認開啟，但依舊無法做到所有特效全部都靠GPU進行加速。在很多Android手機里面都自帶有“是否開啟GPU渲染”這個功能選項，不過開啟之后的改善也是微乎其微。

屏幕最先響應(yīng)的優(yōu)先級關(guān)系，再加上iSO本身GPU加速程序的特性，使得大家在操控過程中感覺iOS手機擁有著不錯的流暢性。因為它本身的整個流程都是在為最大化的流暢做服務(wù)，不管是第一印象的滑動接觸屏幕，還是你進一步使用程序之后的更深層操作都是如此。而GPU加速這點特性，應(yīng)該是它優(yōu)于Android系統(tǒng)流暢性的又一個因素。

三、開發(fā)機制不同：安卓機制效率低

Android的編程語言是JAVA，而iOS的則為Objective-C，不過要是說Android系統(tǒng)之所以有些卡頓是因為JAVA開發(fā)語言的關(guān)系，或者是拿它和Objective-C對比肯定會有人提出質(zhì)疑。Objective-C的優(yōu)勢是效率高但比較“唯一”，而JAVA的優(yōu)勢則是跨平臺不過運行效率相對偏低，其實這兩個編程語言所帶來的機制不同，就已經(jīng)造成了各自系統(tǒng)之間的流暢性差異化。

iOS的Objective-C，編譯器gcc，而這個gcc編譯出來的代碼又被蘋果專為iOS架構(gòu)優(yōu)化到了極致，運行過程中也不需要虛擬機在中間插手，執(zhí)行效率自然很高。這一段話應(yīng)該是iOS系統(tǒng)本身運行程序的執(zhí)行過程，而Android是通過JAVA虛擬機來執(zhí)行，并且系統(tǒng)需要占用大量內(nèi)存來換取執(zhí)行速度，再加上不定期的內(nèi)存自動回收機制，從而直接導(dǎo)致了卡頓現(xiàn)象的出現(xiàn)。

Android的JAVA編程本身運行效率比Objective-C低一些，而且再加上內(nèi)存自動回收的機制，所以造成了一些卡頓不流暢的現(xiàn)象出現(xiàn)。但根據(jù)技術(shù)人員講解，現(xiàn)代的JAVA虛擬機效率已經(jīng)不再是最大的瓶頸，Android 4.0系統(tǒng)版本之后的卡頓現(xiàn)象明顯得到了改善，所以這也是有用戶并沒有發(fā)現(xiàn)自己新買的Android手機出現(xiàn)太多卡頓現(xiàn)象的原因。看來編程語言和機制已經(jīng)被Android進行了改善，這同樣也不是造成它與iOS流暢性偏差的唯一因素，不過影響卻是實實在在存在著。

三、系統(tǒng)設(shè)計不同：安卓APP無法統(tǒng)一

因為iOS產(chǎn)品的封閉性，所以所有的APP運行對象都比較單一，因為每個應(yīng)用程序都是被運行在iPhone，iPad等iOS產(chǎn)品當(dāng)中，它們有著很高的硬件利用效率。因為iOS系統(tǒng)的配件供應(yīng)商只有那么幾家，CPU也是一年換一次，這點不像Android終端年年變月月變，開發(fā)者很難遇見未來終端分辨率會包含多少種，GPU驅(qū)動會包含哪些等等，所以相對來說Android應(yīng)用開發(fā)成本較高且收益較慢。而iOS應(yīng)用開發(fā)則因為軟硬件垂直整合而受益，這樣一來蘋果自然就保證了應(yīng)用本身其與硬件產(chǎn)品之間的完美結(jié)合程度。

其實Android和iOS兩大系統(tǒng)APP開發(fā)情況的不同，也正是它們開發(fā)和不開放的特性所造成的。如果要是拿旗艦Android手機加上一個專為這款旗艦產(chǎn)品設(shè)計的游戲，來和蘋果iPhone運行對比的話，你真的不會遇到Android旗艦機出現(xiàn)卡頓延遲的問題，為什么因為這款游戲針對這款手機設(shè)計，在軟硬等方面都達到了最大化的兼容和優(yōu)化，自然就不會出現(xiàn)停滯的現(xiàn)象。

而Android系統(tǒng)程序要被安裝在各種符合要求的手機上面，開發(fā)者也不可能針對所有的機器型號進行開發(fā)，只能在比較主流的機器上進行測試并保證運行效果，所以他們?yōu)榱思骖櫿麄€產(chǎn)品線只能不得不降低游戲體驗以達到高中低產(chǎn)品可以共用的效果。最后那些占據(jù)了Android終端份額的大量大眾用戶們由于自己的手機不是旗艦產(chǎn)品而得不到流暢的使用體驗，自然而然就會產(chǎn)生Android產(chǎn)品不如iOS流暢的抱怨。

不管是iOS產(chǎn)品感覺比Android流暢還是真的比它流暢，其實說到底原因很簡單。蘋果會花費一年甚至兩年的時間去開發(fā)一個桌面icon，一種字體，并去測試屏幕點位，而Android終端中除了Nexus系列之外似乎沒有太多產(chǎn)品可以做到用這么長的時間去做這么細致的事情。有網(wǎng)友說得好，Android做的更多的是“讓系統(tǒng)跑起來”，而iOS擁有著蘋果做的更多的則是“讓系統(tǒng)以最高的效率跑起來”，或許這就是iOS產(chǎn)品比Android更流暢的原因吧。但更好的一面的是，隨著谷歌對Android的持續(xù)升級以及各廠商對自家產(chǎn)品的循序改進，使得越來越多的Android終端正在擺脫卡頓不流暢的束縛，未來安卓用戶的期待同樣有望得到更好的滿足。

標題名稱：ios開發(fā)代碼優(yōu)化,ios編譯優(yōu)化
文章網(wǎng)址：http://www.ef60e0e.cn/article/phcsds.html