Charts: 성능 향상

Android 버전의 원래 성능 병목 현상은 렌더링 코드 내부에 많은 추가 할당 (배열)이었습니다. 렌더링 코드 내부에 메모리 를 할당하면 안됩니다 . 그래서 @PhilJay 는 해당 코드를 미리 할당 된 Buffer로 옮기고 렌더링하는 동안 렌더링 계산을 Buffer 클래스에 위임했습니다.

렌더링 계산을 Buffer 클래스로 이동하지 않기로 선택했지만 필요한 메모리를 동일한 방식으로 미리 할당하지만 렌더링 코드와 동일한 루프에서 렌더링 계산을 수행합니다. 이렇게하면 코드를 훨씬 쉽게 관리 할 수 ​​있습니다.

또한 렌더링 계산이 추가 함수 내에서 수행되지 않고 데이터가 렌더링 코드 내에서 두 번이 아니라 한 번만 반복된다는 것은 성능 향상입니다.

Btw, Swift에서 성능은 어쨌든 Java보다 훨씬 낫기 때문에 이러한 배열을 사전 할당하지 않고도 성능이 향상되는 것을 보았을 것입니다.

그래픽으로 설명하기 위해 렌더링 코드에서 수행되고있는 작업은 다음과 같습니다.

• [렌더링 시작]
• 데이터 세트에 대한 루프
• -이 DataSet의 포인트에 대한 배열 할당- 이제 두 플랫폼 모두에 사전 할당 됨
• -렌더링 포인트 계산-_Android 버전의 버퍼로 이동 _
• -그 포인트를 렌더링
• [렌더링 커밋]

또한 Java에서는 추상화 (함수, 클래스, 상속)가 대가를 치르게됩니다. Google 자체가 중요한 권장 사항을 작성한 것은 아닙니다.

Be careful with code abstractions

Often, developers use abstractions simply as a "good programming practice," 
because abstractions can improve code flexibility and maintenance. 
However, abstractions come at a significant cost: 
    generally they require a fair amount more code that needs to be executed, 
requiring more time and more RAM for that code to be mapped into memory. 
So if your abstractions aren't supplying a significant benefit, you should avoid them.

요약 :

• 수천 개의 데이터 포인트로 작업하는 데 익숙 할 수 있습니다!
• 나는 Phil을 설득하여 포인트 계산을 다시 렌더링 루프로 옮겨 유지 관리를 더 간단하게 유지하려고합니다 ;-)

설명 Daniel에 감사드립니다. 그래도 나는 이것에서 무엇을 가져 가야할지 잘 모르겠습니다.
내가 한 일은 가장 기본적인 프로젝트를 설정하는 것이며 (아래 코드 참조) 성능은 Android 버전과 비교할 수 없으며 완전히 정직하지도 않습니다. 수천 개의 데이터 포인트를 사용하면 iPad Mini3 및 iPhone6과 같은 최신 iOS 기기에서도 최대 데이터 포인트 수 (완전히 축소)를 표시하는 데 가까워지면 엄청난 프레임 드롭이 발생합니다. 내가 말했듯이 MPAndroidcharts는 땀을 흘리지 않고 훨씬 느린 장치에서 수천을 렌더링 할 수 있습니다.

override func viewDidLoad () {
super.viewDidLoad ()

    lineChart = LineChartView(frame: view.frame);
    view.addSubview(lineChart);
    lineChart.backgroundColor = UIColor.whiteColor()
    lineChart.descriptionText = "Just a test"
    lineChart.leftAxis.enabled = false
    lineChart.legend.enabled = false

    setData(20)
}

func setData(range:Float) {

    var count = 1000;
    var xVals = Array<String>();

    for(var i = 0; i<count; i++) {
        xVals.append(String(i) + "");
    }

    var yVals = Array<ChartDataEntry>();

    for (var i = 0; i<count; i++) {
        var mult = range + 1
        var val:Float = Float(random()) * mult + 3;
        yVals.append(ChartDataEntry(value: val, xIndex: i));
    }

    var lineSet:LineChartDataSet = LineChartDataSet(yVals: yVals, label: " ");
    lineSet.drawCirclesEnabled = false;
    lineSet.drawValuesEnabled = false;

    var lineData:LineChartData = LineChartData(xVals: xVals, dataSet: lineSet);
    lineChart.data = lineData;
}

아직 성능에 대한 모든 차트를 테스트하지 않았으므로 곧 수행해야합니다.
병목 현상 은 아마도 내가 어딘가에서 놓친 할당 일 것입니다. 테스트하고 알려 드리겠습니다! :-)

고마워요 다니엘. 이것에서 무엇을 짜낼 수 있는지 기대합니다. iOS에서 MPAndroidCharts에 대한 실행 가능한 동반자가 있으면 멋질 것입니다.

글쎄, 나는 LineChartRenderer (예를 들어 BarChartRenderer에 비해 특히 느림)를 약간 사용했으며 Instruments는 CGContext의 drawPath가 여기서 범인이라고 말합니다.
대신 UIBezierPath를 사용하여이 문제를 완화하려고 시도했지만 경로에서 stroke ()를 호출하자마자 성능이 동일합니다. 그 전에는 그리기 성능이 좋지만 단순한 선 차트에서 원하는 것이 아니라 시작점과 끝점에 대해 경로가 채워져 있습니다.
이것에 대한 해결책을 찾는 데 약간의 행운이 있기를 바랍니다.

지금 테스트 중이며 실제 CGContextStrokePath 성능이 저하되는 것 같습니다.
주요 타자 중 하나는 점선입니다. 비활성화하면 성능이 두 배가됩니다. 하지만 여전히 천 점으로 가난합니다.
CoreGraphics를 더 빠르게 만드는 방법을 찾기 위해 Apple 문서를 읽고 있습니다.

예, Core Graphics는 확실히 경로를 느리게 렌더링합니다. 해상도 때문에 발생하는 것 같습니다. 최신 Apple 장치의 해상도가 매우 높아 렌더링 할 픽셀이 더 많아집니다.

나는 CG가 GPU 대신 CPU에서 렌더링한다고 생각합니다. 누군가 그것을 바꿀 방법을 알고 있습니까?

CG는 렌더링을 위해 CPU를 가장 확실히 사용하고 있으며 내가 아는 한 변경할 방법이 없습니다.
GPU 렌더링은 불행히도 OpenGL을 사용하는 것을 의미합니다. CG는 Android가 CPU에서 이러한 항목을 렌더링하는 방법에 비해 느립니다.

실제로 느린 장치의 CPU입니다. 대부분의 경우 매우 느린
CPU는 Android의 빠른 CPU보다 iOS에서 훨씬 더 나은 경험을 제공합니다.

하지만 애플은 최적의 OS가 아닌 경우는 생각하지 않았습니다.
빠르게 유지하기에 충분합니다.

많은 포인트를 사용하면 애니메이션을 피할 수 있다고 생각합니다.
나는 여전히 라인의 성능을 향상시키는 방법을 찾고 있습니다.
기반 차트.

특히 경로 그리기 시스템이 느린 것 같습니다.
Miter 및 Flatness를 사용하고 점선을 비활성화하고
안티 앨리어싱-성능은 500-700 포인트에서 훨씬 좋아집니다.
iPhone 6이지만 여전히 1000을 가진 Jerky

UIBezierPath를 사용하는 기회가있을 수 있습니다. 내가 말했듯이, 그 것은 '스트로크'를 호출하지 않으면 충분히 빠르며, 이는 본질적으로 경로가 스트로크이며 시작점에서 끝점까지 채워서는 안된다는 것을 시스템에 알려줍니다. 나는 백그라운드에서 무슨 일이 일어나고 있는지 전혀 모르지만 그래프 그리기 자체가 문제가 아님을 보여줍니다.

그러나 꺾은 선형 차트에 UIBezierPath를 적절하게 사용하는 방법을 찾을 수 없었기 때문에 스트로크를 호출하지 않고 경로를 그리도록 속일 수 있기 때문에 그리드 선에 대한 실행 가능한 후보가 될 수 있습니다. API 관점에서 '틀렸지 만'더 나은 성능을 제공해야합니다.

UIBezierPath는 CGPath, CGContextDrawPath를 둘러싼 UIKit 래퍼입니다.
기타
어떤 경우에 관찰되는 성능 차이는
UIBezierPath의 속성을 사용하여 먼저 CG를 설정합니다.
앤티 앨리어싱, 마이 터 제한 등

실제로 사용 방법을 안다면 사용할 이유가 전혀 없습니다.
핵심 그래픽.

그리고 네, 우리는 그 경로를 쓰길 원하기 때문에 "stroke"라고 부를 필요가 있습니다 ...
그것을 채우지 마십시오.
대부분의 경우 쓰다듬어주는 것이 고체를 채우는 것보다 시스템에 더 어렵습니다
색상, 선의 너비를 처리해야하기 때문에 조인은
선과 조인의 모양 사이.

2015 년 4 월 17 일 금요일 오전 10시 50 분에 AlBirdie [email protected] 은 다음과 같이 썼습니다.

UIBezierPath를 사용하는 기회가있을 수 있습니다. 내가 말했듯이
'스트로크'라고 부르지 않으면 충분히 빠릅니다.
경로가 스트로크이므로 시스템에
끝점에 대한 시작점. 나는 그것에 무슨 일이 일어나고 있는지 전혀 모른다
그러나 이것은 그래프 그리기 자체가
그 자체로 문제.

그러나 UIBezierPath를 올바르게 사용하는 방법을 찾을 수 없었기 때문에
꺾은 선형 차트는 하나의 그리드 라인에 대한 실행 가능한 후보가 될 수 있습니다.
스트로크를 호출하지 않고 그리도록 경로를 속일 수 있습니다. 그래도
API 관점에서 '잘못된'경우 더 나은 성능을 제공해야합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -93937181
.

@danielgindi 애니메이션 속도가 느려지는 경우 애니메이션없이 모든 선을 그리고이를 덮는 마스크보기를 사용한 다음 마스크보기를 애니메이션하여 애니메이션을 모방하는 것은 어떻습니까?

좋은 생각입니다! :)

단점이 있지만 :
그것은 당신이 할 수있는 애니메이션의 종류를 불구로 만들 것입니다. 우리가 허용하는대로
차트가 "성장"하도록 Y 축 애니메이션 및 선이 채워지는 방식
X 축에서도 스트로크가있을 때와 다릅니다.

내 시도 목록은 다음과 같습니다.

1. 어떻게 든 CoreGraphics를 향상 시키거나 렌더링의 일부를
   GPU
   
   
   
   1. 모든 애니메이션 프레임을 미리 렌더링합니다. 애니메이션 시작이 지연되고
      
      상당한 양의 메모리를 소비
   
   
   2. 애니메이션의 종류를 제한하는 마스킹 아이디어
   
   

다른 아이디어가 있다면 듣고 싶습니다!

Daniel, 작업을 GPU로 오프로드 해 보셨나요?
저는 우리가 현재 작업하고있는 상용 솔루션 (끔찍한 API, 끔찍하게 닫힘, 앱 충돌을 유발하는 많은 버그)에 정말 정말 불만스럽고 MPAndroidCharts로 큰 성공을 거두었습니다. 성능이 동등하다면 결국 iOS 차트. 당신의 작업은 보상받을 것입니다. ;)

몇 가지 다른 기술을 시도해보고 며칠 후에 업데이트를 드리겠습니다!

2015 년 4 월 20 일 월요일 오후 12시 38 분에 AlBirdie [email protected] 은 다음과 같이 썼습니다.

Daniel, 작업을 GPU로 오프로드 해 보셨나요?
저는 현재 우리가 현재 사용하고있는 상용 솔루션에 정말 불만 스럽습니다.
(끔찍한 API, 끔찍하게 닫힘, 그리고
앱 충돌) MPAndroidCharts로 큰 성공을 거두었다면
성능이 동등하다면 결국 iOS 차트로 전환하는 것을 좋아합니다. 쉬다
당신의 작업은 보상받을 것입니다. ;)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -94408574
.

@AlBirdie 어떤 종류의 성능 병목 현상을 만났습니까? 저는 현재 ios-charts처럼 차트를 그리는 제품을 소유하고 있으며 내부적으로 이미 차트 라이브러리를 가지고 있습니다. 나는 또한 성능에 대해 우려하고 있습니다. 현재 우리는 단지 100-1000 개의 데이터 세트를로드합니다. 이제 괜찮아 보입니다.

또한 가능하면 ios-charts로 변경하는 것을 고려하고 있지만 라이브러리에는 ios-chart와 충돌 할 수있는 제스처가있었습니다.

성능 문제는 애니메이션의 느린 프레임 속도입니다.
꺾은 선형 차트에 500-1000 개의 선을 그립니다.

제스처와 관련하여-표준 UIGestureRecognizers를 사용하고 있습니다.
비활성화, 수정 또는 작업 할 수 있습니다. 모든 것이 표준화되었습니다. :-)

2015 년 4 월 20 일 월요일 오후 12시 53 분에 Xuan [email protected] 은 다음과 같이 썼습니다.

@AlBirdie https://github.com/AlBirdie 어떤 성능
만난 병목? 나는 현재 차트를 그리는 제품을 소유하고 있습니다.
ios-charts처럼 우리는 이미 내부적으로 차트 라이브러리를 가지고 있습니다. 나는 또한 걱정한다
성능에 대해서는 현재 100 ~ 1000 개의 데이터 세트 만로드합니다.
지금.

앞으로 가능하면 ios-charts로 변경하는 것도 고려 중입니다.
하지만 우리 도서관에는 ios-chart와 충돌 할 수있는 제스처가있었습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -94411060
.

@danielgindi 글쎄, 나는 우리가 애니메이션을 극복하기 위해 마스크보기를 사용한다고 생각한다. 우리의 라인 차트에는 그라디언트 레이어가 있습니다. 데모로 애니메이션은 X + Y 방향을 동시에 수행 할 수 있지만 우리는 X 방향 만 수행합니다. 마스크 트릭이 도움이 될 수 있는지 잘 모르겠습니다.
지금 제가 생각하는 것은 X + Y 방향을 설명하는 벡터가 있다면 마스크 트릭을 사용할 기회가있을 수 있다는 것입니다. 결과를 기대하십시오!

@ liuxuan30 은 일반적인 느린 성능입니다. 애니메이션은 작업하지 않기 때문에 문제가되지 않습니다. 저는 단일 차트에 여러 데이터 세트 (여러 주식 + 지표 범위)가 필요한 금융 차트를 작업하고 있습니다. 패닝 및 핀치 중에 한 번에 렌더링해야하는 최대 수천 개의 포인트를 쉽게 추가하는 250 개 항목의 데이터 범위. 내가 현재 작업하고있는 상용 솔루션은 꽤 잘 작동하지만 (OpenGL을 사용하면 CPU 과부하없이 수천 개의 포인트를 렌더링 할 수 있음) 버그 수정을 위해 몇 달을 기다려야하는 폐쇄 소스 라이브러리의 친구가 아닙니다.
특히 MPAndroidCharts의 API는 작업하기가 매우 쉽기 때문에 ios-charts가 훨씬 더 편합니다.

금융 데이터는 재앙입니다. 서버가 최대 1000 개의 데이터 세트를 모바일 장치로 전송하도록하여 과부하를 줄였습니다. ios-charts에 OpenGL을 사용할 수 있습니까? 뿡 빵뀨

OpenGL 지원은 에이스입니다. GPU 렌더링 된 선형 차트는 현재로서는 충분할 것입니다.
불행히도 저는 OpenGL에 대해 전혀 몰랐습니다. 그렇지 않으면 기꺼이 도와 드리겠습니다.

경로를 사용하는 것과 달리 CGContextStrokeLineSegments가 개선되었으므로 이것을 시도해야합니다.
여전히 다른 개선 방법을 시도하고 있습니다. :-)

감사합니다 Daniel, 두 버전을 서로 비교하여 무엇이 무엇인지 확인하는 작은 테스트 앱을 만들겠습니다. 새로운 LineSegments를 사용하여 어떤 성능 향상을 얻었습니까?

@AlBirdie 선분의 차이를 느끼십니까?

또한 방금 깨달았습니다. Android에서 최대 성능을 얻으려면 하드웨어 레이어로 설정했습니다.이 경우 점선이 점선이 아니라 모두 실선입니다.

따라서 iOS에서 점선을 비활성화하면 먼저 상당한 향상을 얻을 수 있습니다!

하지만 실제로 CIImage에서 OpenGL ES를 사용하여 그릴 수 있다고 생각하지만 앱이 비활성 상태 일 때 하나의 GL 라인이 실행되면 충돌이 발생하므로 매우주의해야합니다.

또한 텍스처를 미리 렌더링하여 대시를 허용 할 수도 있습니다. 약간의 작업이 필요할 것이고 나의 주요 우선 순위는 아니지만 CGContext를 원활하게 대체 할 수있는 OpenGL 레이어의 사이드 프로젝트를 시작하고 있습니다.

그리기를 위해 OpenGL로 이동하는 대신 Core Animation으로 낮추어 볼 수도 있습니다. CAShapeLayer 클래스가 작동 할 수 있습니다. Apple은 복잡한 경로를 렌더링 할 때 여러 개의 CAShapeLayer 를 사용할 것을 권장하므로 선 세그먼트를 여러 세그먼트로 분할해야 할 수 있습니다. Core Animation을 사용하면 작업이 GPU로 이동됩니다.

나의 일상 업무에서 우리는 위에서 언급했듯이 @AlBirdie 가 OpenGL을 광범위하게 사용하여 주석을 제외한 모든 것에 대해 CoreGraphics를 우회하는 상용 제품을 사용해 왔습니다. 확실히 그들은 상당히 부드러운 렌더링으로 꽤 큰 데이터 세트에 대처할 수있는 것으로 보이며이를 위해 GPU를 사용한다고 주장합니다. 그러나 그들의 접근 방식에는 엄청난 골칫거리가 있습니다. 특히 앱이 백그라운드로 들어감에 따라 OpenGL에서 충돌하는 비동기 렌더링 호출, 멍청한 클래스 구조 및 사용자 지정 가능성에 대한 미친 제한과 같이 고칠 수없는 버그가 있습니다. 내가 원하는 것은 오늘날 존재하지 않지만 iOS- 차트에서는 그것이 거기에 도달하는 방법 일 수 있다는 것을 알았습니다. 어쨌든, 나에게 신뢰성은 매번 성능보다 우세하지만 가장 작은 차이로 둘 다 엄청나게 중요합니다.

내 생각에 점선은 컴퓨터가 컬러 또는 그레이 스케일로 렌더링 할 수있는 옵션이 없었던 시절의 숙취입니다. 순수한 흑백으로 렌더링하고 낡은 것처럼 보이게 만드는 경우가 아니면 필요하지 않습니다. 활자 인쇄 교과서, 확실히? ;) 따라서 일반적인 10K 포인트 사례를 최적화하는 것보다 최적화하는 것이 훨씬 덜 중요합니다.

파선과 관련하여 @onlyforart 와 절대적으로.
상업용 차트 라이브러리에 대한 설명을 감안할 때 동일한 제품을 사용하고 있는지 궁금합니다. :) 우리는 결국 그것을 버렸습니다. 구현하는 데 3 개월의 더 좋은 부분이 걸렸습니다 (심각한 버그와 제한 (예 : 십자선)을 피할 수있을만큼 길지 않았음에도 불구하고 iOSCharts ( '멍청한 클래스 구조');)). 시간과 돈의 총 낭비.

@AlBirdie 네 그게 하나입니다. 십자선도 언급하지 마십시오. 너무 많은 Newcastle Brown Ale의 도움으로 만들어졌고 의심 할 여지없이 기업 시장을 겨냥했습니다 (엄청난 API는 고객을 값 비싼 지원 / 유지 관리주기에 묶어두기 때문에 실제로 긍정적 인 판매 요소입니다). 그 사람들의 역사를 알고 계셨습니까? 실제로 (깊은 과거에) 그들은 소프트웨어 산업의 진정한 개척자였습니다. 어쨌든 이제 앞으로 나아가 미래를 바라 볼 때입니다.
주로 캔들 스틱 차트 (금융 부문 앱)를 그립니다. 내가 iOS와 Android에서 정말 원하는 것은 HTML5 / Javascript 세계에서 HighCharts / HighStock으로 실제로 매우 쉬운 것입니다.

1. 엄청난 수의 데이터 포인트 (10K 이상)
2. OHLC 데이터를 적절한 스케일 막대로 자동 통합 (예 : 줌 계수가 적절한 경우 1 시간 막대 표시, 축소 할 경우 1m 또는 1 초 막대 표시)
3. 부드러운 패닝 및 스크롤
4. 확대 / 축소하려면 핀치
5. 여러 데이터 시리즈와 주석 및 십자선 오버레이, 일부는 프로그래밍 방식으로, 일부는 사용자 상호 작용 (예 : 제한 가격 설정)에 의해 모두 원활하게 렌더링 됨
6. (여기에 키커가 있습니다-HighStock은 이것에 도움이되지 않습니다! 나에게는 꽤 분명해 보이지만) 데이터의 증분 가져 오기 (예측 포함) 예를 들어 전체 데이터 세트에 대한 저해상도 데이터 가져 오기 및지도 앱과 마찬가지로 hi-rez 가져 오기 차트의 표시된 영역에 대한 데이터 (예 : 밀리 초 "틱"데이터)
   우리는 아직 iOS-Charts를 사용하지 않고 있지만 "해야 할 일"목록에 있고 상위에 가까워 졌기 때문에 아직 코드 내부를별로 살펴 보지 않았지만 곧바로-아마도 다음 달에- 나는 모든 것을 조사 할 것이다.
   렌더링으로 돌아가서 상황이 완벽하지 않을 때 OpenGL이 충돌하는 경향은 걱정거리입니다. GLKit은 GPU 그리기에 도움이 될 수 있습니다. 나는 또한 SpriteKit이 도움이 될 수 있는지 (차트 렌더링이 게임을 만드는 데 수백만 마일이 아님) 궁금해했지만 지금은 GLKit이 더 나은 후보로 보입니다.

LOL @onlyforart , 뉴캐슬 브라운 에일에 저를
귀하의 요구 사항 (금융 상품에 대해서도 작업)과 관련하여 동일한 배를 타고 있지만 예,이 차트의 실제 그림으로 돌아가 보겠습니다. 향후 발견을 기대합니다.

@onlyforart , @AlBirdie 귀하의 통찰력에 감사드립니다 :-)

사람들이 우리 도서관을 위해 상업용 엔터프라이즈 제품을 버리는 것을 보는 것은 정말 좋은 일입니다.

완벽하게 관리되지 않으면 충돌이 발생할 수 있다는 것을 알았 기 때문에 OpenGL이이 문제를 해결하는 것을 주저했습니다. UIKit 앱에서는 불가능했습니다. OpenGL을 사용하여 게임을 만드는 경우 모든 것이 OpenGL 캔버스이며 백그라운드에서 OpenGL 렌더링을 유발하려는 UIKit 호출에 대해 걱정할 필요가 없습니다.

@onlyforart 점선에 대한 귀하의 요점은 정확하지만 불행히도 점선을 요구하는 고객과 경험이 있습니다. Android에서 성능을 높이기 위해 개발자가 계층을 하드웨어 계층으로 변경해야하는 경우가 있었고, 클라이언트에게 점선이 실선이 될 것이라고 말했고, 그것이 비용입니다. 물론 모든 그리기 코드를 OpenGL로 옮기는 옵션이 있지만 한 줄을 그리는 것은 골치 아픈 일이지만 점선에 대한 텍스처를 만들어 작업 할 수 있습니다. 그들은 비용을 지불하고 싶지 않았기 때문에 점선은 확실히 그다지 중요하지 않았지만 그것에 대해 많은 소음을 냈습니다.

나 자신을위한 메모 : 렌더링을 위해 GLKit을 사용해보십시오. 무슨 일이 일어나는지보십시오.

그리고 내가 당신의 목록을 취한다면 :

1. _ "엄청난 수의 데이터 포인트 (10K 이상)"_-현재 작업 중입니다. :) Android에 대해 말할 수는 없습니다. GL로 이동하면 더 큰 PITA가 될 것이기 때문입니다. GPU에서 모든 그림을 그리는 하드웨어 계층을 활용합니다.
2. _ "OHLC 데이터를 합리적인 축척 막대로 자동 통합"_-근사 필터를 곧 사용하게 될 것이므로이 기능이 처리 될 것이라고 생각합니다. 읽을 수없는 1m 막대가 많은 대신 대략 1 시간 막대 등이 있습니다.
3. _ "부드러운 이동 및 스크롤" _-완료 :-)
4. _ "핀치하여 확대 / 축소" _-완료 :-)
5. _ "여러 데이터 시리즈와 주석 및 십자선 오버레이"_-올바르게 이해했는지 모르겠지만 현재 여러 차트 유형을 오버레이 할 수있는 결합 차트가 있으며 모든 차트 유형은 여러 데이터 세트를 허용 할 수 있습니다. 또한 항상 ViewPortHandler에 연결하고 좌표를 가져 와서 문자 위에 원하는 것을 오버레이 할 수 있습니다.
6. 데이터의 증분 가져 오기-정적 데이터 세트를 설정하기위한 이전 API를 보유하면서 데이터 소스를 추상화 할 계획입니다 (이와 함께 작동하는 내장 데이터 소스가 될 것입니다). 이것은 또한 귀하의 요구 사항에 맞을 것 같지만 아직 언제 도착할 지 모릅니다.

@danielgindi , 그들에게 기분 나쁘지 마십시오. 당신이 개발하고있는 제품이 기본적으로 썩은 토마토이지만 여전히 그것에 대해 심각한 반죽을 청구한다면 사람들은 결국 다른 제품으로 옮길 것입니다. 그게 잘못이 아닙니다. 저는 몇 년 동안 재무 차트를 개발해 왔으며 현재 iOS 용 거의 모든 솔루션을 사용해 왔으며 실제로 과거에 ActionScript3에서 자체 차트 엔진을 작성했기 때문에 다음과 같이 말할 수 있습니다. iOSCharts 및 MPAndroidCharts는 실제로 자신의 앱에서 차트 작성이 필요한 개발자에게 현재 권장 할 수있는 유일한 제품입니다. 다른 모든 것은 그것을 자르지 않습니다.

두 번째 요구 사항과 관련하여, 여러분이 이것을 구현하려면 선택 사항이어야합니다. 우리는 차트 작성 제품 중 하나에서 이러한 종류의 통합을 얻었으며 고객은 대신 고정 된 빈도로 꾸준히 이동하고 있습니다. 확대 / 축소하는 동안 빈도를 변경하는 것은 일반 금융 차트 사용자에게 혼란 스러울뿐만 아니라 고정 주파수를 원했기 때문에 고급 사용자가 짜증을 냈습니다.

우리는 이것을 사용자에게 강요하는 것을 상상하지 못했습니다! 코드에 이미 필터가 포함되어 있음을 알 수 있으며 MPAndroidCharts에서 필터를 설정하는 속성 (모든 사용자 지정 필터 또는 기본 제공 필터)에 의해 필터가 활성화되었지만 나중에 구조적 변경으로 인해 제거 된 것을 볼 수 있습니다.

우리가 그것을 구현할 때 기능은 동일하게 유지 될 것입니다-그것은 단지 또 다른 멋진 기능 일 것입니다 :-)

@AlBirdie Re "두 번째 요구 사항과 관련하여, 여러분이 이것을 구현하려면 선택 사항이어야합니다. 우리는 차트 제품 중 하나에서 이러한 종류의 통합을 얻었으며 고객은 대신 고정 된 빈도로 꾸준히 이동하고 있습니다. 확대 중 빈도는 일반 금융 차트 사용자에게 혼란 스러울뿐만 아니라 고급 사용자는 고정 된 주파수를 원했기 때문에 짜증을 냈습니다. " 완전히 동의합니다-이것은 정보 제공 / 비 거래 사용자를위한 차트입니다. 거래 사용자는 다른 요구 사항이 있습니다.

@danielgindi Re "데이터 소스 요약"은 시간이 있다면 기여할 수있는 일입니다. 약속은 없지만 백 로그에 추가하겠습니다.

아무도 그리기 코드를 스레드를 분리하여 (CALayer.drawsAsynchronously) 놀았습니까? 이는 차트 추가, 각 데이터 세트, 그리드 및 축을 개별적으로 그릴 수있는 경우에 도움이 될 수 있습니다. CoreGraphics에 대한 매우 겸손한 경험을 감안할 때 (읽기; 아무것도 ;-)), 나는 이것으로 어떤 실험도하지 않았으며 GLKit을 찾고 차트 성능을 향상시킬 수있는 방법을 찾았습니다.

10k 데이터 포인트가있는 캔들 스틱 차트를 표시해야했기 때문에 CandleStickChartRenderer.drawDataSet ()에서 시간 측정을 실행했습니다.

대부분의 시간은 dataSet.entryIndex를 호출하는 데 소요됩니다 (76,77 행).

실수 할 수도 있지만 dataSet.entryIndex () 호출은 _minX, _maxX 값이 항상 minx와 같고, maxx는 dataSet.entryIndex ()에서 반환되므로 중복되는 것처럼 보입니다.

10k 데이터 포인트가있는 캔들 스틱 차트를 부드럽게 팬 / 줌으로 만들 수있었습니다. 변경하여
CandleStickChartRenderer.swift, 76,77 행 :

var minx = max (dataSet.entryIndex (entry : entryFrom, isEqual : true), 0);
var maxx = min (dataSet.entryIndex (entry : entryTo, isEqual : true) + 1, entries.count);

...에

var minx = max (_minX, 0);
var maxx = _maxX + 1;

LineChartRenderer를 동일하게 변경하고 2 개의 데이터 시리즈 (각각 10,000 개의 데이터 포인트)가있는 결합 된 캔들 스틱 / 라인 차트를 표시 할 수 있습니다.

와우, @dorsoft 의 엄청난 성능 향상

나는 이것을 방금 테스트했고 내 눈을 믿을 수 없었습니다. 4 개의 CombinedCharts가있는 iPad 2에서도 각각 250 개의 데이터 포인트와 y 축의 자동 최소 / 최대 계산을 포함하는 최대 3 개의 데이터 세트를 표시하여 모든 차트를 동시에 매우 부드러운 방식으로 이동 및 확대 / 축소 할 수 있습니다. 60fps가 아니라 가깝습니다. 이러한 오래된 장치에 대해 인상적이며 앞서 언급 한 상용 OpenGL 솔루션보다 빠른 WAY (!)입니다.

나는 이것을 시도해야한다고 생각한다 :) 그리고 또한 Phil과 의논해야한다
의미가 있는지 이해 ...

나는 방금 이것을 읽었고, 매우 흥미로워 보이지만 실제로 모든 시나리오에 적합한 지 확인하기 위해 집중적 인 테스트가 필요할 것입니다 :-)

캔들 차트 성능 향상으로 PR을 만들었습니다.
향상은 자동 스케일 최소 / 최대 및 nil 값을 사용하여 철저하게 테스트되었습니다.

가능한 병목 현상을 발견했습니다. 실시간 차트에서 차트에 초당 많은 항목을 추가하면 데이터 집합의 calcMinMax가 EACH values.append(e) 직후에 자동으로 호출된다는 것을 알았습니다.

calcMinMax 함수는 .forEach를 사용하여 CPU가 60 % 이상의 값을 루핑하는 데 소요되는 최소 및 최대 값을 결정합니다.

최소 / 최대 계산을 비활성화하거나 array .forEach 대신 기본 for 루프를 사용하는 실험을 수행하고 있습니다.

@danielgindi 좀 봐주세요, 정말 필요한 모든 값에 calcMinMax입니까? 나는 내 코드와 보이는 값 에서만 수동으로 최소 / 최대 Y 값을 계산하므로 최소 / 최대 자동 계산을 활성화 / 비활성화하고 성능을 향상시키고 forEach 함수를 제거하고 함수 호출을 피하기 위해 일부 부울을 노출 할 수 있습니다.

```
open override func calcMinMax()
{
    guard !values.isEmpty else { return }

    _yMax = -Double.greatestFiniteMagnitude
    _yMin = Double.greatestFiniteMagnitude
    _xMax = -Double.greatestFiniteMagnitude
    _xMin = Double.greatestFiniteMagnitude

    values.forEach { calcMinMax(entry: $0) }
}

```

@samueleperricone 별도의 티켓으로 만들어 주시면 우선 순위를 정하겠습니다.

@jjatie 감사합니다, 그냥 열어 # 3166

iOS 용 라인 차트에 13000 개 이상의 레코드를로드하고 있습니다. 그러나 차트는로드하는 동안 UI를 고정합니다. 또한로드 후 사용자가 임의의 지점을 선택하면 선택 항목을 강조 표시하는 데 너무 많은 시간이 걸립니다.