AppKit Release Notes for OS X v10.10의 "점진적 중단 NSCell에의"절은 말합니다 :NSCell은 왜 더 이상 사용되지 않고 왜 처음 도입 되었습니까?
이맥 OS X 10.10 세포의 최종 중단을 향한 또 다른 단계 걸립니다.
나는 성능상의 이유로 NSCell
가 소개되었다고 들었습니다. 그런데 왜 비추천입니까?
AppKit Release Notes for OS X v10.10의 "점진적 중단 NSCell에의"절은 말합니다 :NSCell은 왜 더 이상 사용되지 않고 왜 처음 도입 되었습니까?
이맥 OS X 10.10 세포의 최종 중단을 향한 또 다른 단계 걸립니다.
나는 성능상의 이유로 NSCell
가 소개되었다고 들었습니다. 그런데 왜 비추천입니까?
NSCell
은 메모리가 수십 메가 인 머신에서 성능상의 이유로 NeXTSTEP 시절에 도입되었습니다. 모든 테이블 셀에 대해 전체 NSView
을 사용하는 것은 그리 쓸모가 없었습니다. iOS에서 테이블 뷰는 셀보다는 뷰를 사용하여 극적으로 단순화되었습니다. OS X 10.7에서, 애플은 OS X을 같은 방향으로 움직이기 시작했고 마침내 거기에 도달했다.
NSCell
은 항상 OS X에서 큰 번거 로움을 겪었습니다. 최소한 NSCopyObject()
, one of the most annoying functions NeXT ever wrote을 사용했기 때문에 가장 중요한 문제였습니다. 또한 모든 텍스트 입력보기간에 공유되는 단일 텍스트 편집기 (NSText
)도 제공합니다. 조심하지 않으면 뷰가이 공유 객체를 통해 서로 간섭 할 때 혼란스러운 버그가 발생할 수 있습니다. 컨트롤과 셀 사이의 분리와 복제는 항상 OS X 개발자 사이에 혼란의 원인이되고 있습니다.
옛날 옛적에 그것은 필요했지만 그 시절은 오래되었습니다. 대다수의 경우 "전체 NSView 서브 클래스의 오버 헤드"에 대해 더 이상 걱정할 필요가 없습니다. 특히 CALayer
을 추가 한 이후로 더욱 빠르게 그려졌습니다.