한 번에 이렇게 많은 데이터를 보유하는 것은 확실히 불가능합니다. tableview는 scrollview에서 상속되고 콘텐츠 크기를 얻으려면 이를 계산해야 하기 때문에 데이터 소스로 사용되는 데이터 조각 수, 행 높이를 몇 번 계산하면 매우 멈춰 있거나 처음으로 기다리는 데 오랜 시간이 걸립니다.
권장사항: 처음에는 항목 10개 또는 20개 등 적은 양의 데이터만 로드하세요. 그런 다음 높이를 캐시하므로 항목이 10,000개라도 높이가 캐시된 후에는 중단 현상이 발생하지 않습니다(서식 있는 텍스트가 많은 항목 제외).
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
먼저 시스템 tableView의 셀에는 재사용 메커니즘이 있습니다. 표준 루틴에 따라 작성하면 셀의 레이아웃이 모두 동일한 경우 10,000개의 셀을 한 번에 초기화하지 않습니다. 내용이 일관되지 않습니다.
의 해당 셀은 화면 표시 범위에만 존재합니다.로컬 데이터를 사용해 볼 수 있습니다
서버 측을 수정해야 하며 각 요청마다 약 30~40개의 데이터를 로드합니다.
프런트엔드 테이블뷰에서는 드롭다운 로딩을 통해 여러 데이터가 한 번에 로딩됩니다.
질문 19번과 20번을 살펴보세요: http://www.henishuo.com/ios-interview-middle-two/
한 번에 이렇게 많은 데이터를 보유하는 것은 확실히 불가능합니다. tableview는 scrollview에서 상속되고 콘텐츠 크기를 얻으려면 이를 계산해야 하기 때문에 데이터 소스로 사용되는 데이터 조각 수, 행 높이를 몇 번 계산하면 매우 멈춰 있거나 처음으로 기다리는 데 오랜 시간이 걸립니다.
권장사항: 처음에는 항목 10개 또는 20개 등 적은 양의 데이터만 로드하세요. 그런 다음 높이를 캐시하므로 항목이 10,000개라도 높이가 캐시된 후에는 중단 현상이 발생하지 않습니다(서식 있는 텍스트가 많은 항목 제외).
글에서 행 높이를 자동으로 계산하고 캐시하는 방법을 살펴보겠습니다!
tableviewcell의 재사용 메커니즘에 따르면 이 부분은 고려되지 않는 것 같은데요? 실행해서 메모리를 얼마나 차지하는지 확인해 보세요...
셀 재사용 메커니즘에서는 이 문제를 고려할 필요가 없습니다