그래서 Core Plot (iOS, 버전 1.5)을 사용하여 앱에 얼마나 잘 통합되는지 살펴 보았습니다. 나는 보통 그래픽 용 기본 장치 인 iPad 3에서 테스트하고 있습니다. 대신 코드의 톤을 붙여의코어 플롯 많은 메모리 사용
, 여기에 플롯 구성의 :
- 1 그래프는 일반 화이트 테마를 사용
- 1 플롯 공간
- 이 별도의 산포도, 3 데이터 포인트 플롯 당 .
- 2 축 :
- XAxis : 2013 년 12 월, 2014 년 3 월 (NSTimeInterval) 3 개의 레이블, 3 개의 주요 틱 및 약 90 개의 작은 틱 (하루에 1 개)
- YAxis : 범위 : 0, 250.3 레이블 3 개, 주요 틱 12 개, 작은 틱 12 개. YAxis는 그래프의 오른쪽에 떠 있습니다.
- 각 축
그래서 일반적으로 내 응용 프로그램 주위 33~34메가바이트 사용에 앉아 한 제목이 있습니다. 몇 개의 이미지를 표시하는 경우 최대 50MB까지 스파이크가 발생할 수 있지만 일반적으로 33-34MB 범위 내에있게됩니다. 그러나 코어 플롯을로드하면 메모리가 약 63MB로 점프됩니다. 스케일링을 가능하게하고 그래프를 꼬집어서 크기를 조정하려는 경우 또는 그래프를 드래그하면 메모리 사용량이 ~ 143MB로 증가한 다음 다시 84MB로 고정됩니다. 그래프를 닫을 때 메모리가 약 22MB로 떨어졌습니다. 메모리 압력으로 인해 다른 캐시가 삭제 되었기 때문입니다.
또한, 그래프를 꼬집거나 끌면 관련성이있을 수 있습니다. 2 SPF (프레임 당 초 ... 심각하게)로 떨어지는 평균 2-3 프레임.
코어 플롯이 외설스런 양의 메모리를 사용하고 있으며 속도가 너무 느립니다.
내가 뭔가를 놓친 건가요? 아니면이게 바로 코어 플롯입니까? 이 작업 속도를 높이고 메모리 사용량을 줄이지 않으면 Core Plot을 프로덕션 환경에서 사용할 수 없습니다.
업데이트
계측기를 사용하여 앱을 프로파일 링했습니다. 모든 메모리 이득이 코어 플롯 (Core Plot) 객체 (또는 그로부터 파생 됨)에 있다는 점을 제외하고는 말할 것도 없습니다. 시간 프로파일 러는 플롯의 크기를 조정하거나 이동할 때 대부분 drawInContext: 메소드에서 시작된 다양한 코어 플롯 렌더링 방법 중 하나에서 시간을 소비하고 있음을 보여줍니다. 아이러니하게도이 방법의 첫 번째 줄은 self.useFastRendering = YES;입니다.
플롯이 거의 전체 화면으로 추가됩니다. 플롯 필드, 그래프 유형 등을 편집 할 수있는 몇 가지 다른 컨트롤이 있지만 그게 전부입니다.
솔직히 말해서, 나는 성능과 관련된 어떤 종류의 물건을 놓치기를 바랬지만, 그런 경우는 아닙니다. 코어 플롯은 정적 그래프에 대해서는 문제가 없지만 상호 작용 성과 성능면에서 뒤 떨어진다.
얼마 전까지 Shinobi Controls을 살펴본 후 iOS 데모를 확인했습니다. 이것은 정확하게 내 그래프에서 원하는 상호 작용의 종류 & 성과입니다. 하지만 비싼, 닫힌, 제 3 자 코드를 내 앱에 포함시키는 것에 대해서는 신경이 쓰이지 않습니다 ...
가능성 그래프를 직접 작성하는 데 시간을 할애 할 것입니다.
코어 플롯은 특히 iPad 3와 같은 오래된 하드웨어에서 성능에 대한 알려진 문제점이 있지만 꽤 심한 것으로 들립니다. 병목 현상이 어디 있는지 앱을 프로파일 링 했습니까? –
예, 앱을 프로파일 링했습니다 (위 참조). 문제는 거의 전적으로 Core Plot에 있습니다. –
나는 똑같은 이슈 Aaron을 가졌다. 간단한 파이 차트 .. 3 섹션 .. 장치 방향 알림과 메모리가 장치의 몇 회전 후에 앱을 충돌시키는 지붕을 통과하는 것을 지켜보고있다. Shinobi를보고 있었다. 차트가 너무 .. 자신 Shinobi에 대한 포크를해야 할 수도 있습니다 ..! – jheneghan