Charts: تحسينات في الأداء

كان الاختناق الأصلي في الأداء في إصدار Android العديد من التخصيصات الإضافية (من المصفوفات) داخل كود العرض. لا ينبغي تخصيص الذاكرة داخل رمز التقديم. لذا فقد نقل PhilJay هذا الرمز إلى المخزن المؤقت الذي تم تخصيصه مسبقًا ، وقام بتفويض حسابات التقديم إلى فئات Buffer أثناء العرض.

اخترت عدم نقل حسابات العرض إلى فئات Buffer ، ولكن فقط قم بتخصيص الذاكرة المطلوبة مسبقًا بنفس الطريقة - ولكن اجعل حسابات العرض في نفس الحلقة مثل رمز العرض. بهذه الطريقة يكون من الأسهل بكثير إدارة الكود.

كما أنه من مكاسب الأداء أن حسابات التقديم لا يتم إجراؤها داخل وظائف إضافية ، ويتم تكرار البيانات مرة واحدة فقط داخل كود العرض بدلاً من مرتين.

راجع للشغل ، في Swift الأداء أفضل بكثير من Java على أي حال ، لذلك كنت سترى أن الأداء مكسب حتى بدون تخصيص هذه المصفوفات مسبقًا.

من أجل شرحها بيانياً ، هذا ما تم / تم القيام به في كود العرض:

• [بدء العرض]
• حلقة فوق مجموعات البيانات
• - تخصيص مجموعة لنقاط مجموعة البيانات هذه - الآن تم تخصيصها مسبقًا في كلا النظامين الأساسيين
• - حساب النقاط للعرض - _الانتقال إلى المخازن المؤقتة في إصدار 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.

تلخيصها:

• يمكنك أن تكون مرتاحًا للعمل مع آلاف نقاط البيانات!
• أحاول إقناع فيل بإعادة حسابات النقاط إلى حلقات العرض لجعلها أبسط للحفاظ عليها ؛-)

شكرا لتفسيراتك دانيال. لست متأكدًا تمامًا مما يجب أن آخذه من هذا ، مع ذلك.
ما فعلته هو إعداد المشروع الأساسي (انظر الكود أدناه) والأداء لا يمكن مقارنته بإصدار Android ، ولا حتى قريبًا من أن نكون صادقين تمامًا. ينتج عن استخدام ألف نقطة بيانات قطرات إطار ضخمة بمجرد الاقتراب من عرض أكبر قدر من نقاط البيانات (التصغير بالكامل) حتى على معظم أجهزة iOS الحالية مثل iPad Mini3 و iPhone6. كما قلت ، يمكن لـ MPAndroidcharts تقديم عدة آلاف على أجهزة أبطأ بكثير دون كسر العرق.

تجاوز 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;
}

حسنًا ، لم أختبر جميع الرسوم البيانية للأداء حتى الآن - لذلك أحتاج إلى القيام بذلك قريبًا.
من المحتمل أن يكون عنق الزجاجة تخصيصًا فاتني في مكان ما ... سأختبر وأعلمك! :-)

شكرا جزيلا دانيال. نتطلع إلى ما يمكنك الضغط عليه للخروج من هذا. سيكون من الرائع أن يكون لديك رفيق قابل للتطبيق لـ MPAndroidCharts على iOS.

حسنًا ، لقد لعبت قليلاً مع LineChartRenderer (وهو بطيء بشكل خاص مقارنةً بـ BarChartRenderer على سبيل المثال) وتقول Instruments أن drawPath الخاص بـ CGContext هو الجاني هنا.
لقد حاولت التخفيف من هذه المشكلة باستخدام UIBezierPath بدلاً من ذلك ، ولكن الأداء هو نفسه بمجرد استدعاء stroke () على المسار. قبل ذلك ، يكون أداء الرسم رائعًا ، ولكن المسار مليء فيما يتعلق بنقطة البداية والنهاية ، وليس ما نريده لمخطط خطي بسيط.
نأمل أن يكون لديك المزيد من الحظ في إيجاد حل لذلك.

أنا أختبر هذا الآن ، ونعم يبدو أن CGContextStrokePath الفعلي يعاني من ضعف الأداء.
أحد الضاربين الرئيسيين هو الخط المتقطع. عند تعطيله ، يتضاعف الأداء. لكنها لا تزال فقيرة بألف نقطة.
أقوم ببعض القراءة في مستندات Apple لمعرفة كيفية جعل CoreGraphics أسرع

نعم ، تعمل Core Graphics بالتأكيد على جعل المسارات بطيئة. يبدو أنه يحدث بسبب الدقة - الدقة على أجهزة Apple الأحدث عالية جدًا ، مما يعني المزيد من وحدات البكسل لعرضها.

أعتقد أن CG يتم عرضها على وحدة المعالجة المركزية بدلاً من وحدة معالجة الرسومات. ربما شخص ما يعرف طريقة لتغيير ذلك؟

من المؤكد أن CG يستخدم وحدة المعالجة المركزية (CPU) لتقديمها وبقدر ما أعرف لا توجد طريقة لتغيير ذلك.
عرض GPU يعني استخدام OpenGL ، للأسف. المشكله هو أن CG بطيئة مقارنة بكيفية عرض Android لهذه الأشياء على وحدة المعالجة المركزية.

إنها في الواقع وحدات المعالجة المركزية للأجهزة بطيئة. في معظم الحالات يكون بطيئا جدا
توفر وحدة المعالجة المركزية تجربة أفضل مع نظام التشغيل iOS مقارنة بوحدة المعالجة المركزية السريعة التي تعمل بنظام Android.

لكن Apple لم تفكر في الحالات التي لا يكون فيها نظام التشغيل الأمثل
يكفي لإبقائها سريعة.

أعتقد أنه عندما نستخدم الكثير من النقاط يمكننا فقط تجنب الرسوم المتحركة - لكن
ما زلت آمل أن أجد طريقة لتحسين أداء الخط
الرسوم البيانية القائمة.

يبدو على وجه التحديد أن نظام رسم المسار بطيء ومتى
اللعب مع ميتري والتسطيح ، وتعطيل الخطوط المتقطعة و
منع الحواف - يتحسن الأداء بكثير عند 500-700 نقطة على
iPhone 6 ، ولكن لا يزال Jerky مع 1000

قد تكون هناك فرصة باستخدام UIBezierPath. كما قلت ، يكون هذا الشيء سريعًا بما يكفي بمجرد أن لا تسمي "ضربة" ، والتي تخبر النظام بشكل أساسي أن المسار عبارة عن حد ويجب عدم ملؤه من نقطة البداية إلى نقطة النهاية. ليس لدي أي فكرة عما يحدث مع ذلك في الخلفية ، لكن هذا يوضح أن الرسم البياني نفسه ليس هو المشكلة في حد ذاته.

ومع ذلك ، نظرًا لأنني لم أتمكن من العثور على طريقة لاستخدام UIBezierPath بشكل صحيح للمخطط الخطي ، فقد يكون خيارًا قابلاً للتطبيق لخطوط الشبكة حيث يمكن للمرء أن يخدع المسار للرسم دون استدعاء الحد. على الرغم من أن هذا "خطأ" من وجهة نظر API ، إلا أنه يجب أن يؤدي إلى أداء أفضل.

يعد UIBezierPath مجرد غلاف UIKit حول CGPath و CGContextDrawPath و
إلخ.
يرجع الاختلاف في الأداء الذي لوحظ في بعض الحالات إلى ذلك
إعداد CG أولاً ، مع خصائص UIBezierPath الخاصة بـ
antialiasing ، ميتري حد إلخ.

في الواقع ، لا يوجد أي سبب على الإطلاق لاستخدامه عندما تعرف كيفية استخدامه
الرسومات الأساسية.

ونعم ، نحن بحاجة إلى تسمية "السكتة الدماغية" ، لأننا نريد أن نقطع هذا المسار ...
لا تملأه.
يكون الضرب في معظم الحالات أصعب على الجهاز من الملء الصلب
اللون ، لأنه يحتاج إلى الاهتمام بعرض الخطوط ، الصلات
بين الخطوط وشكل الصلات.

في الجمعة 17 أبريل 2015 الساعة 10:50 صباحًا ، كتب AlBirdie [email protected] :

قد تكون هناك فرصة باستخدام UIBezierPath. كما قلت ، هذا الشيء
يكون سريعًا بما فيه الكفاية بمجرد عدم استدعاء "السكتة الدماغية" ، وهي في الأساس
يخبر النظام أن المسار عبارة عن حد ولا يجب ملؤه من ملف
نقطة البداية إلى نقطة النهاية. ليس لدي أي فكرة عما يحدث مع ذلك في
الخلفية ، ولكن هذا يوضح أن الرسم البياني نفسه ليس هو
القضية في حد ذاتها.

ومع ذلك ، نظرًا لأنني لم أتمكن من العثور على طريقة لاستخدام UIBezierPath بشكل صحيح من أجل
على الرسم البياني الخطي ، قد يكون توضيحات قابلة للتطبيق لخطوط الشبكة كواحد
يمكن أن يخدع مسار الرسم دون استدعاء ضربة. على الرغم من أن هذا هو
"خطأ" من وجهة نظر API ، يجب أن يؤدي إلى أداء أفضل.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -93937181
.

danielgindi هل فكرت في أنه إذا كانت الرسوم المتحركة تبطئ الأمور ،

حسنًا ، هذه فكرة رائعة! :)

على الرغم من وجود جانب سلبي:
سوف يشل نوع الرسوم المتحركة التي يمكنك القيام بها بها. كما نسمح
تحريك المحور ص بحيث "ينمو" المخطط ، والطريقة التي يملأ بها الخط
على المحور X يختلف أيضًا عما يحدث عندما يكون هناك جلطة فقط.

قائمة الأشياء التي يجب تجربتها هي:

1. بطريقة ما تقوم بتحسين CoreGraphics أو رفع جزء من العرض إلى
   GPU
   
   
   
   1. عرض مسبق لجميع إطارات الرسوم المتحركة - سيؤدي ذلك إلى تأخير بدء الرسوم المتحركة ، و
      
      تستهلك قدرًا كبيرًا من الذاكرة
   
   
   2. فكرة التقنيع الخاصة بك - والتي تحد من أنواع الرسوم المتحركة
   
   

إذا كانت هناك أفكار أخرى أحب أن أسمعها!

دانيال ، هل حاولت تفريغ العمل في وحدة معالجة الرسومات حتى الآن؟
أنا حقًا ، حقًا غير راضٍ عن الحل التجاري الذي نعمل عليه حاليًا (واجهة برمجة تطبيقات رهيبة ، مغلقة بشكل رهيب ، والكثير من الأخطاء التي تتسبب في تعطل التطبيق) ، وحقق نجاحًا كبيرًا مع MPAndroidCharts ، نود التبديل إلى مخططات iOS في النهاية إذا كان الأداء على قدم المساواة. كن مطمئنًا ، سيتم مكافأة عملك. ؛)

بتجربة بعض الأساليب المختلفة ، سأقدم لك تحديثًا في غضون أيام قليلة!

في يوم الإثنين 20 أبريل 2015 الساعة 12:38 ظهرًا ، كتب AlBirdie [email protected] :

دانيال ، هل حاولت تفريغ العمل في وحدة معالجة الرسومات حتى الآن؟
أنا حقًا غير راضٍ عن الحل التجاري الذي نحن عليه حاليًا
العمل مع (API الرهيب ، مغلق بشكل رهيب ، والكثير من الأخطاء التي تسبب
التطبيق الذي يتعطل) ، وحققنا نجاحًا كبيرًا مع MPAndroidCharts ، سنفعل
أحب التبديل إلى مخططات iOS في النهاية إذا كان الأداء على قدم المساواة. راحة
مطمئن ، سوف يكافأ عملك. ؛)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -94408574
.

AlBirdie أي نوع من اختناق الأداء التقيت؟ أمتلك حاليًا منتجًا يرسم المخططات تمامًا مثل مخططات ios ، فلدينا بالفعل مكتبة مخططات داخليًا. أنا قلق أيضًا بشأن الأداء ، حاليًا ، نقوم فقط بتحميل 100-1000 مجموعة بيانات ، يبدو جيدًا الآن.

أنا أفكر أيضًا في التغيير إلى مخططات ios إن أمكن في المستقبل ، لكن مكتبتنا بها إيماءات قد تتعارض مع مخططات ios.

مشكلة الأداء هي بطء معدل الإطارات في الرسوم المتحركة عند الحاجة إلى ذلك
ارسم 500-1000 خط في مخطط خطي.

فيما يتعلق بالإيماءات - نحن نستخدم مُعرفات UIGestureRecognizers القياسية - والتي تستخدمها أنت
يمكن تعطيله أو تعديله أو العمل معه. كل شيء موحد. :-)

في يوم الاثنين ، 20 أبريل ، 2015 الساعة 12:53 مساءً ، كتب Xuan [email protected] :

AlBirdie https://github.com/AlBirdie أي نوع من الأداء
عنق الزجاجة التقيت؟ أمتلك حاليًا منتجًا يرسم المخططات فقط
مثل مخططات ios ، كان لدينا بالفعل مكتبة مخططات داخليًا. أنا قلق أيضا
حول الأداء ، حاليًا ، نقوم فقط بتحميل 100-1000 مجموعة بيانات ، يبدو جيدًا
الآن.

أفكر أيضًا في التغيير إلى مخططات ios إن أمكن في المستقبل ،
لكن مكتبتنا بها إيماءات قد تتعارض مع مخططات ios.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -94411060
.

danielgindi حسنًا ، أعتقد أننا نستخدم عرض القناع للتغلب على الرسوم المتحركة ... يحتوي
ما يدور في ذهني الآن هو أنه إذا كان لدينا متجه لوصف اتجاه X + Y الخاص بك ، فربما تكون هناك فرصة لاستخدام خدعة القناع ... تطلع إلى نتائجك!

@ liuxuan30 فقط الأداء العام البطيء على ما أعتقد. الرسوم المتحركة ليست مشكلة لأنني لا أعمل معها. أنا أعمل على المخططات المالية حيث تحتاج إلى مجموعات بيانات متعددة في مخطط واحد (أسهم متعددة + مجموعة من المؤشرات). لنطاق بيانات من 250 عنصرًا يضيف بسهولة ما يصل إلى عدة آلاف من النقاط التي يجب عرضها مرة واحدة أثناء التحريك والقرص. يعمل الحل التجاري الذي أعمل معه حاليًا بشكل جيد (باستخدام OpenGL ، يمكنك عرض آلاف النقاط دون زيادة التحميل على وحدة المعالجة المركزية) ، لكنني لست صديقًا للمكتبات المغلقة المصدر حيث يتعين عليك الانتظار شهورًا لإصلاح الأخطاء.
سأشعر براحة أكبر مع مخططات ios ، خاصة وأن واجهة برمجة تطبيقات MPAndroidCharts سهلة للغاية للعمل معها.

أرى البيانات المالية كارثة. يقوم الخادم لدينا بإرسال ما يصل إلى 1000 مجموعة بيانات إلى الجهاز المحمول ، لذلك قلل من الحمل الزائد لدينا. هل هناك أي فرصة لاستخدام OpenGL لمخططات iOS؟ تضمين التغريدة

سيكون دعم OpenGL بمثابة ارسالا ساحقا. من المحتمل أن يكون الرسم البياني الخطي المقدم من خلال GPU كافياً في الوقت الحالي.
لسوء الحظ ، ليس لدي أي فكرة على الإطلاق عن OpenGL ، وإلا فسيسعدني تقديم المساعدة.

هناك تحسن في CGContextStrokeLineSegments بدلاً من استخدام المسارات ، لذلك يجب أن تجرب هذا.
ما زلت أحاول الطرق الأخرى لتحسين الأشياء :-)

شكرًا دانيال ، سأُنشئ تطبيقًا تجريبيًا صغيرًا يضع النسختين مقابل بعضهما البعض لمعرفة ما هو. ما هي مكاسب الأداء التي حققتها باستخدام LineSegments الجديد؟

AlBirdie هل تشعر بالفرق مع مقاطع الخط؟

لقد أدركت للتو أيضًا: في نظام Android للحصول على أقصى أداء قمت بتعيينه على طبقة الأجهزة - وفي هذه الحالة لا تكون الخطوط المتقطعة متقطعة ، فهي كلها صلبة.

لذلك أول شيء إذا قمت بتعطيل الخطوط المتقطعة على نظام iOS ، فستحصل أيضًا على دفعة كبيرة!

لكنني أعتقد أنه يمكنني بالفعل رسمه باستخدام OpenGL ES على CIImage ، ولكن يجب أن أكون حذراً للغاية لأنه إذا تم تشغيل سطر GL واحد عندما يكون التطبيق غير نشط ، فسوف يتعطل.

هناك أيضًا فرصة لا يزال بإمكاني السماح بالشرطات عن طريق تقديم نسيج مسبقًا. سيستغرق الأمر بعض العمل وهو ليس أولويتي الرئيسية ، لكنني أبدأ مشروعًا جانبيًا لطبقة OpenGL يمكنها استبدال CGContext بسلاسة.

بدلاً من الذهاب إلى OpenGL للرسم ، يمكنك أيضًا محاولة خفض الرسوم المتحركة إلى Core Animation. ربما يمكن أن تعمل فئة CAShapeLayer . توصي Apple باستخدام CAShapeLayer s متعددة عند عرض مسار معقد ، لذلك قد تحتاج إلى تقسيم مقطع الخط إلى مقاطع متعددة. يجب أن يؤدي استخدام Core Animation إلى نقل العمل إلى وحدة معالجة الرسومات.

لسنوات في وظيفتي اليومية ، استخدمنا منتجًا تجاريًا كما هو مذكور أعلاه بواسطة AlBirdie يستخدم OpenGL على نطاق واسع ، وبالتالي يتجاوز CoreGraphics في كل شيء باستثناء التعليقات التوضيحية. بالتأكيد يبدو أنهم قادرون على التعامل مع مجموعات البيانات الكبيرة جدًا مع عرض سلس إلى حد ما ويزعمون أنهم يستخدمون وحدة معالجة الرسومات لهذا الغرض. ومع ذلك ، فإن نهجهم يأتي مع صداع هائل ، ليس أقلها الأخطاء التي يبدو أنهم لا يمكن إزعاجهم لإصلاحها مثل مكالمات العرض غير المتزامن التي تتعطل في OpenGL حيث ذهب التطبيق إلى الخلفية ، وهياكل الطبقة الغبية والقيود المجنونة على التخصيص. ما أريده غير موجود اليوم ، لكن في مخططات iOS أرى أنه قد يكون الطريق للوصول إلى هناك. على أي حال ، بالنسبة لي ، فإن الموثوقية تتفوق على الأداء في كل مرة ، لكنها بأدنى هامش ، وكلاهما مهم للغاية.

ملاحظة في رأيي ، فإن الخطوط المتقطعة هي مخلفات من الأيام التي لم يكن فيها لدى أجهزة الكمبيوتر خيار العرض بالألوان أو حتى التدرج الرمادي - ليست هناك حاجة إليها ما لم يتم تحويلها إلى أبيض وأسود نقيين ونصنع شيئًا يشبه القديم كتاب مدرسي مطبوع بحروف ، بالتأكيد؟ ؛) لذلك فإن التحسين لهؤلاء أقل أهمية بكثير من التحسين لحالة 10 آلاف نقطة عامة.

تمامًا معك onlyforart فيما يتعلق بالخطوط المتقطعة.
بالنظر إلى وصفك حول مكتبة الرسوم البيانية التجارية الخاصة بك ، أتساءل عما إذا كنا نستخدم نفس المنتج. :) لقد تخلينا عنها أخيرًا بالمناسبة. ما استغرق مني الجزء الأفضل من ثلاثة أشهر لتنفيذه (حتى أن ذلك لم يكن طويلًا بما يكفي للالتفاف على الأخطاء والقيود الشديدة (مثل الخطوط المتقاطعة) ، استغرق أسبوعين فقط مع iOSCharts ("هياكل الطبقة الغبية" ؛)). مضيعة للوقت والمال.

AlBirdie نعم هذا هو. لا تذكر حتى الشعيرات المتصالبة. صُنع بمساعدة الكثير من Newcastle Brown Ale واستهدف بلا شك سوق الشركات (حيث تعد واجهة برمجة التطبيقات (API) عامل مبيعات إيجابيًا ، لأنها تحبس العملاء في دورة دعم / صيانة باهظة الثمن). هل تعلم تاريخ هؤلاء الرجال؟ في الواقع (في ماضيهم العميق) كانوا روادًا حقيقيين في صناعة البرمجيات. على أي حال ، حان الوقت للمضي قدمًا والتطلع إلى المستقبل الآن.
نحن في الغالب نرسم مخططات الشمعدان (هذه تطبيقات للقطاع المالي). ما أريده حقًا لنظامي التشغيل iOS و Android هو شيء سهل جدًا في الواقع مع HighCharts / HighStock في عالم HTML5 / Javascript:

1. أعداد هائلة من نقاط البيانات (10 آلاف أو أكثر)
2. الدمج التلقائي لبيانات OHLC في أشرطة متدرجة معقولة (على سبيل المثال ، إظهار أشرطة 1 ساعة عندما يكون عامل الزوم مناسبًا ، أو 1 متر أو 1 ثانية عند التصغير)
3. التحريك والتمرير السلس
4. قرصة للتكبير
5. تراكب العديد من سلاسل البيانات والتعليقات التوضيحية والشعيرات المتقاطعة ، بعضها برمجيًا والبعض الآخر عن طريق تفاعل المستخدم ، على سبيل المثال لتعيين سعر محدد ، يتم عرضها جميعها بسلاسة
6. (ها هي أداة التسديد - HighStock لا تساعد في هذا! على الرغم من أنه يبدو واضحًا جدًا بالنسبة لي) الجلب التدريجي للبيانات (مع lookahead) ، على سبيل المثال ، جلب بيانات منخفضة الدقة لمجموعة البيانات بأكملها ، كما هو الحال مع تطبيقات الخرائط ، جلب hi-rez البيانات (على سبيل المثال بيانات "التجزئة" بالمللي ثانية) فقط للمنطقة المعروضة على الرسم البياني
   نحن لا نستخدم مخططات iOS حتى الآن على الرغم من وجودها في قائمة "المهام" الخاصة بي وتقترب أكثر من القمة ، لذلك لم أنظر داخل الشفرة كثيرًا حتى الآن ، ولكن بمجرد أن أقوم بذلك - ربما الشهر المقبل - سوف أنظر في كل ذلك.
   بالعودة إلى العرض ، فإن ميل OpenGL للانهيار إذا كانت الظروف أقل من الكمال هو أمر مثير للقلق. يمكن أن تساعد GLKit في رسم GPU ؛ لقد تساءلت أيضًا منذ فترة عما إذا كان SpriteKit يمكن أن يساعد (عرض الرسم البياني ليس على بعد مليون ميل من صنع الألعاب) ، ولكن في الوقت الحالي يبدو GLKit مرشحًا أفضل.

LOLonlyforart ، لقد
أنا في نفس المركب فيما يتعلق بمتطلباتك (العمل على المنتجات المالية أيضًا) ، ولكن نعم ، دعنا نعود إلى الرسم الفعلي لهذه المخططات. نتطلع إلى النتائج الخاصة بك في المستقبل.

onlyforart ، @ AlBirdie شكرًا على

من الرائع حقًا أن نرى أشخاصًا يتخلون عن منتج المؤسسة التجارية لمكتبتنا ، على الرغم من أنني أشعر بالسوء تجاههم ... أنا في صراع!

كنت مترددًا في السماح لبرنامج OpenGL بالحصول على جزء من هذا لأنني كنت أعرف أن هناك أعطال محتملة إذا لم تتم إدارتها بشكل مثالي ، وهذا غير ممكن حقًا في تطبيق UIKit. إذا كنت تستخدم OpenGL لإنشاء لعبة ، فالأمر كله عبارة عن لوحة OpenGL ولا داعي للقلق بشأن مكالمة UIKit التي تحاول التسبب في عرض OpenGL أثناء وجودك في الخلفية.

onlyforart وجهة نظرك حول الخطوط المتقطعة صحيحة ، لكن للأسف لدي خبرة مع العملاء الذين يطالبون بخطوط متقطعة. كانت هناك حالة على Android حيث يتعين على المطور تحسين الأداء لتغيير الطبقة إلى طبقة أجهزة ، وأخبر العميل أن الخطوط المتقطعة ستصبح خطوطًا صلبة ، هذه هي التكلفة. وهناك بالطبع خيار لنقل كل التعليمات البرمجية للرسم إلى OpenGL ، ولكن رسم سطر واحد يعد صداعًا ، ولكن يمكنك إنشاء نسيج لخط متقطع والعمل معه. لم يرغبوا في دفع ثمنها ، لذا لم تكن الخطوط المتقطعة حرجة بالتأكيد ، لكنهم أحدثوا الكثير من الضجة حولها.

ملاحظة لنفسي: حاول استخدام GLKit للعرض. انظر ماذا سيحدث.

وإذا أخذت قائمتك:

1. _ "عدد ضخم من نقاط البيانات (10 آلاف أو أكثر)" _ - نحن نعمل على ذلك :) لا أستطيع أن أقول عن Android ، حيث أن نقله إلى GL سيكون بمثابة PITA أكبر ، ولكنه يتمتع بالفعل بأداء جيد جدًا من خلال الاستفادة من طبقة الأجهزة ، والتي تقوم بالرسم كله على وحدة معالجة الرسومات.
2. _ "الدمج التلقائي لبيانات OHLC في أشرطة متدرجة معقولة" _ - سنقوم بوضع مرشحات التقريب قيد الاستخدام قريبًا جدًا ، لذلك أعتقد أن هذا سيهتم بذلك. بدلاً من وجود العديد من الأشرطة التي يبلغ طولها مليون شريط والتي لا يمكنك قراءتها ، سيكون لديك شريط تقريبي يبلغ ساعة واحدة وما إلى ذلك.
3. _ "التحريك والتمرير السلس" _ - تم :-)
4. _ "قرصة للتكبير" _ - تم :-)
5. _ "تراكب العديد من سلاسل البيانات والتعليقات التوضيحية والشعيرات المتقاطعة" _ - لا أعرف ما إذا كنت أفهم بشكل صحيح ، ولكن يوجد حاليًا مخطط مجمع يمكنه تراكب أنواع مخططات متعددة ، ويمكن لكل نوع مخطط قبول مجموعات بيانات متعددة. بالإضافة إلى ذلك ، يمكنك دائمًا الاتصال بـ ViewPortHandler وأخذ الإحداثيات بحيث يمكنك تراكب كل ما تريد فوق الحرف
6. الجلب التدريجي للبيانات - نحن نخطط لاستخراج مصدر البيانات ، بينما لا يزال لدينا واجهات برمجة التطبيقات القديمة لتعيين مجموعات البيانات الثابتة (سيكون مجرد مصدر بيانات مدمج يعمل مع هؤلاء). أعتقد أن هذا سيتناسب أيضًا مع متطلباتك ، لكننا لا نعرف متى سنصل إليه بعد

danielgindi ، لا تشعر بالسوء تجاههم. إذا كان المنتج الذي تقوم بتطويره عبارة عن طماطم فاسدة ومع ذلك لا تزال تتقاضى بعض العجين الشديد مقابل ذلك ، فسينتقل الأشخاص في النهاية إلى منتج مختلف. ثيريس حرج في ذلك. لقد عملت على تطوير الرسوم البيانية المالية لعدة سنوات حتى الآن ، واستخدمت إلى حد كبير جميع حلول iOS الموجودة حاليًا ، وقد كتبت في الواقع محرك الرسوم البيانية الخاص بي في ActionScript3 مرة أخرى في الأيام ، لذلك أشعر بثقة كبيرة في قول ذلك iOSCharts و MPAndroidCharts هي في الواقع المنتجات الوحيدة التي يمكنني أن أوصي بها حاليًا لأي مطور يحتاج إلى رسم بياني في تطبيقه. كل شيء آخر هناك فقط لا يقطعه.

فيما يتعلق بالمتطلب الثاني ، إذا كنتم ستنفذون هذا ، فيجب أن يكون اختياريًا. لقد حصلنا على هذا النوع من الدمج في أحد منتجاتنا الرسومية والعملاء ينتقلون بثبات إلى تردد ثابت بدلاً من ذلك. تبين أن تغيير الترددات أثناء التكبير لا يسبب فقط إرباكًا لمستخدم المخططات المالية المتوسطة ، بل انزعج المستخدمون المتمرسون لأنهم أرادوا ترددات ثابتة.

لم نتخيل أبدًا فرض هذا على المستخدمين! يمكنك أن ترى أن الكود يشتمل بالفعل على عوامل التصفية ، وفي MPAndroidCharts يمكنك رؤية عوامل التصفية التي تم تمكينها تاريخيًا بواسطة خاصية تحدد عامل التصفية (أي مرشح مخصص أو عوامل التصفية المضمنة) ، ولكن تمت إزالتها لاحقًا بسبب التغييرات الهيكلية.

عندما ننفذها ، ستبقى الوظيفة كما هي - ستكون مجرد ميزة رائعة أخرى :-)

AlBirdie Re "فيما يتعلق بالمتطلب الثاني ، إذا كنتم

danielgindi Re "استخراج مصدر البيانات" ربما يكون هذا شيئًا يمكننا المساهمة فيه ، إذا كان لدينا الوقت. لا توجد وعود ، لكنني سأضيفها إلى الأعمال المتأخرة لدينا.

هل لعب أي شخص حول تقسيم رمز الرسم لفصل الخيوط (CALayer.drawsAsynchronically)؟ قد يساعد ذلك في حالة السماح برسم إضافات الرسم البياني ، وكل مجموعة بيانات ، والشبكة والمحاور بشكل منفصل. نظرًا لتجربتي المتواضعة للغاية مع CoreGraphics (اقرأ ؛ لا شيء على الإطلاق ؛-)) ، لم أقم بأي تجارب مع هذا ، لقد وجدته للتو عندما كنت أبحث عن GLKit وكيف يمكنه تحسين أداء المخطط.

كنت بحاجة إلى إظهار مخطط شمعة يحتوي على 10 آلاف نقطة بيانات ، لذا أجريت بعض قياسات الوقت على CandleStickChartRenderer.drawDataSet ().

اتضح أن معظم الوقت يقضي على استدعاء dataSet.entryIndex (الأسطر 76 ، 77).

قد أكون مخطئًا ، لكن يبدو أن استدعاء dataSet.entryIndex () زائد عن الحاجة لأن قيم _minX _maxX تساوي دائمًا minx ، maxx المُعاد من dataSet.entryIndex ()

لقد تمكنت من إنشاء مخطط شمعة مع 10 آلاف نقطة بيانات يتم تحريكها / تكبيرها بسلاسة. عن طريق تغيير
CandleStickChartRenderer.swift ، السطر 76،77 من:

var minx = max (dataSet.entryIndex (entryFrom، isEqual: true)، 0)؛
var maxx = min (dataSet.entryIndex (entry: entryTo، isEqual: true) + 1، sources.count) ؛

ل

var minx = max (_minX، 0) ؛
var maxx = _maxX + 1 ؛

لقد أجريت نفس التغيير على LineChartRenderer وتمكنت من عرض مخطط شمعة / مخطط خطي مدمج مع سلسلتي بيانات (10 آلاف نقطة بيانات لكل منهما)

واو ، هذه زيادة هائلة في الأداء dorsoft !

لقد اختبرت هذا للتو ولم أصدق عيني. حتى على iPad 2 مع 4 CombinedCharts التي تعرض ما يصل إلى ثلاث مجموعات بيانات لكل منها 250 نقطة بيانات وحسابات min / max التلقائية للمحور y ، يمكننا الآن تحريك وتصغير جميع المخططات في وقت واحد بطريقة سلسة إلى حد ما. إنه ليس 60 إطارًا في الثانية ، ولكنه قريب. إنه أمر مثير للإعجاب لمثل هذا الجهاز القديم وطريقة (!) أسرع من حل OpenGL التجاري الذي تحدثنا عنه سابقًا.

أعتقد أنه يجب أن أجرب هذا :) وأحتاج إلى المناقشة مع فيل أيضًا
افهم ما إذا كانت هناك أي آثار ...

لقد قرأت هذا للتو ، يبدو مثيرًا للاهتمام ولكنه سيحتاج إلى بعض الاختبارات المكثفة لمعرفة ما إذا كان مناسبًا بالفعل لجميع السيناريوهات :-)

لقد قمت بإنشاء علاقات عامة مع تحسين أداء مخطط الشموع.
تم اختبار التحسين بشكل شامل باستخدام قيم الحد الأدنى / الأقصى و لا شيء للمقياس التلقائي.

لقد وجدت عنق الزجاجة المحتمل. في مخطط الوقت الفعلي ، بإضافة العديد من الإدخالات في الثانية إلى المخطط ، لاحظت أنه يتم استدعاء calcMinMax تلقائيًا لمجموعة البيانات بعد كل values.append(e) فقط

تحدد وظيفة calcMinMax القيم الدنيا والقصوى باستخدام. forEach الذي يتسبب في أن تزيد CPU بنسبة 60٪ عن تكرار القيم ، علاوة على ذلك في السلسلة الرئيسية.

أنا أجري بعض التجارب لتعطيل حساب min / max أو باستخدام original for loop بدلاً من array .forEach

danielgindi الرجاء إلقاء نظرة ، هل حقا calcMinMax على جميع القيم المطلوبة؟ أحسب قيم الحد الأدنى / القصوى Y يدويًا في الكود الخاص بي وفقط على القيم المرئية ، لذلك ربما يمكنك الكشف عن بعض

```
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

أقوم بتحميل أكثر من 13000 سجل في المخططات الخطية لنظام iOS. لكن الرسوم البيانية تجمد واجهة المستخدم أثناء التحميل. أيضًا ، بعد التحميل إذا اختار المستخدم أي نقطة ، فسيستغرق الأمر أيضًا وقتًا طويلاً لإبراز التحديد.