iPhone-dequeueReusableCellWithIdentifier 사용법
웹에서 가져온 데이터가 포함 된 매우 큰 UITableView가있는 iPhone 앱에서 작업 중이므로 생성 및 사용을 최적화하려고합니다.
그 발견 dequeueReusableCellWithIdentifier
꽤 유용하지만, 나는이 기능의 확인 사용량이 좋은 하나 인 경우이를 사용하여 많은 소스 코드를보고 난 후에, 궁금하네요.
사람들이 일반적으로하는 일은 다음과 같습니다.
UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"Cell"];
if (cell == nil) {
cell = [[UITableViewCell alloc] initWithFrame:CGRectZero reuseIdentifier:@"Cell"];
// Add elements to the cell
return cell;
그리고 내가 한 방법은 다음과 같습니다.
// The cell row
NSString identifier = [NSString stringWithFormat:@"Cell %d", indexPath.row];
UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:identifier];
if (cell != nil)
return cell;
cell = [[UITableViewCell alloc] initWithFrame:CGRectZero reuseIdentifier:identifier];
// Add elements to the cell
return cell;
차이점은 사람들이 모든 셀에 대해 동일한 식별자를 사용하므로 하나를 대기열에서 빼면 새 식별자를 할당하는 것을 피할 수 있다는 것입니다.
저에게 큐잉의 요점은 각 셀에 고유 한 식별자를 부여하는 것이기 때문에 앱이 이미 표시된 셀을 요청할 때 할당이나 요소 추가를 수행 할 필요가 없습니다.
좋은에서 내가 가장 적합한 알고하지 마십시오 "일반적인"방법은 방법 I의 사용은 모든 계산 세포를 유지으로 속도를 선호하는 것 같다 동안, 그것은 표시 세포의 정확한 수와 테이블의 메모리 사용량을 셀들과,하지만 큰 일으킬 수 있습니다 메모리 소비 (큐에 내부 제한이없는 경우).
이런 식으로 사용하는 것이 잘못입니까? 아니면 필요에 따라 개발자에게 달려 있습니까?
의 목적은 dequeueReusableCellWithIdentifier
더 적은 메모리를 사용 하는 것입니다 . 화면이 4 개 또는 5 개의 테이블 셀에 맞을 수있는 경우 재사용을 통해 테이블에 1000 개의 항목이 있더라도 메모리에 4 개 또는 5 개의 테이블 셀만 할당하면됩니다.
두 번째 방법으로 재사용이 없습니다. 두 번째 방법은 테이블 셀 배열을 사용하는 것보다 이점이 없습니다. 테이블에 1000 개의 항목이 있으면 메모리에 1000 개의 셀이 할당됩니다. 그렇게하려면 배열에 넣고 행 번호로 배열을 인덱싱하고 셀을 반환합니다. 합리적인 솔루션이 될 수있는 고정 셀이있는 작은 테이블의 경우 동적 또는 큰 테이블의 경우 좋은 생각이 아닙니다.
셀 식별자의 경우-식별자에 "셀"을 사용하는 대신 OP와 같은 고유 식별자를 사용하는 대신 "유형 식별자"를 사용할 수 있습니까? 예를 들어, 내 테이블은 매우 복잡 하위 레이아웃 세포 - 하나의 3 종류, 단지 하나 있었다 Style1
, 그리고 하나를 Style2
내가 모두 개별적으로 그 세를 식별하고 디큐가 오면 다음 단지 그들을 다시 작성해야합니다 nil
.
예를 들면 :
-(UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath{
NSString* ident = @"";
if(indexPath.section == 0) ident= @"complicated";
if(indexPath.section == 1) ident= @"style1";
if(indexPath.section == 2) ident = @"style2";
UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:ident];
if(cell == nil){
if(ident == @"complicated"){
cell = [[[UITableViewCell alloc] initWithFrame:CGRectZero reuseIdentifier:ident] autorelease];
// do excessive subview building
}
if(ident == @"style1"){
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyle1 reuseIdentifier:ident] autorelease];
}
if(ident == @"style2"){
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyle2 reuseIdentifier:ident] autorelease];
}
}
if(ident == @"complicated"){
// change the text/etc (unique values) of our many subviews
}
if(ident == @"style1"){
[[cell textLabel] setText:@"Whatever"];
}
if(ident == @"style2"){
[[cell textLabel] setText:@"Whateverelse"];
}
return cell;
}
(이 코드는 여기에 작성했기 때문에 실행되지 않을 수 있지만 아이디어를 얻으 셨으면합니다.)
나는 그들이 모든 식별자를 원했다면 애플이 식별자로 전체 재사용 가능한 셀 아이디어를 만들지 않았을 것이라고 생각 "cell"
하지 않습니까?
The documentation that helped me understand why the idiomatic way (the one you described first) works best was UITableViewCell class reference section on the initWithStyle:reuseIdentifier:
method.
The reuseIdentifier
subsection reads:
You should use the same reuse identifier for all cells of the same form.
And the "Discussion" subsection reads:
The reuse identifier is associated with those cells (rows) of a table view that have the same general configuration, minus cell content.
These statements make it clear to me that the idiomatic way to use dequeueReusableCellWithIdentifier
inside of your implementation of tableView:cellForRowAtIndexPath:
for your UITableViewDataSource
creates one cell object for each visible row regardless of the total number of rows available.
I think the first one is the best (and as you said common) way to implement a UITableView
. With your second way there will be memory allocated for every new cell which is displayed and no memory will be reused.
UITableView
internally uses a cell with an identifier as a "Template". So the next time you (read as table) try to deque, it just creates a new cell but using the stored object as template. Hence you still have to update its UI to reflect the cell contents as per context.
This also means that the UITableView
is doing the memory management of the cells for us, per se. In theory, there will be only so many UITableViewCell
objects as many as the visible cells. But practically, there might be a couple more waiting to be memory released.
This basically saves memory big time, esp in scenarios where you have 1000 cells.
On any portable device where memory is at a premium, we should defer the allocation of any memory to the last possible moment and release it the moment its job is done. dequeAndReusing
a cell achieves this and does it pretty well.
On the other hand, if your cell is a customized cell, then we might most probably load a nib and extract from it. If this is the case, you can either use an identifier to deque OR you can load it from the nib. There is no difference in the procedure.
The only difference could be in the load time. Allowing the Table view to create a new cell using the identifier cell as template could be slightly faster than loading from nib but it is hardly noticeable and depends on the context.
To distinguish cell from other cells you can use tag property of the cell or if you are using the custom cell then its very easy through introducing any new property to custom cell while subclassing UITableViewCell
.
Even though after all these you are stuck and still need to get cell, then you can try following code
UITableViewCell *cell = [self cellForRowAtIndexPath:indexPath]
whereas it should be avoided upto extent since it produces the copy of cell but do not return the existing cell whereas the contents will be of same values.
참고URL : https://stackoverflow.com/questions/2928873/iphone-dequeuereusablecellwithidentifier-usage
'program story' 카테고리의 다른 글
.dll, .lib, .h 파일의 차이점은 무엇입니까? (0) | 2020.12.01 |
---|---|
JavaScript의 날짜 차이 (0) | 2020.12.01 |
Pip을 사용하여 Python 패키지를 설치할 때 MinGW의 gcc 컴파일러를 사용하는 방법은 무엇입니까? (0) | 2020.12.01 |
모든 vim 창을 한 번에 어떻게 다시로드합니까? (0) | 2020.12.01 |
루비에서 많은 심볼을 동적으로 만드는 것이 좋은 생각이 아닌 이유는 무엇입니까? (0) | 2020.12.01 |