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

تستند هذه المقالة إلى تقرير ألكسندر سميرنوف في AppsConf 2017 وسيساعد على معرفة ما إذا كان من الممكن كتابة التعليمات البرمجية في Kotlin ، والتي لن تكون أقل شأناً من Java في السرعة.


حول المتحدث: ألكسندر سميرنوف CTO في PapaJobs ، يدير مدونة الفيديو Android in Faces ، وهو أيضًا أحد منظمي مجتمع Mosdroid.

لنبدأ بتوقعاتك.

هل تعتقد أن Kotlin في وقت التشغيل أبطأ من Java؟ أو أسرع؟ أو ربما لا يوجد فرق كبير؟ بعد كل شيء ، يعمل كلاهما على الرمز الثانوي الذي توفره لنا الآلة الافتراضية.

دعنا نحصل على حق. تقليديا ، عندما يطرح سؤال مقارنة الأداء ، يريد الجميع رؤية معايير وأرقام محددة. لسوء الحظ ، بالنسبة إلى Android ، لا يوجد JMH ( Java Microbenchmark Harness ) ، لذلك لا يمكننا فقط قياس مدى روعة ما يمكن القيام به في Java. إذن ما الذي يمكننا فعله لإجراء القياس ، كما هو موضح أدناه؟

fun measure() : Long { val startTime = System.nanoTime() work() return System.nanoTime() - startTime } adb shell dumpsys gfxinfo %package_name% 

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

على Android ، يمكنك وضع معايير ، على وجه الخصوص ، عرضت Google ذلك في مؤتمر I / O العام الماضي. قالوا إنهم قاموا بتحسين الجهاز الظاهري بشكل كبير ، في هذه الحالة ART ، وإذا كان على Android 4.1 تخصيص واحد لكائن استغرق حوالي 600-700 نانو ثانية ، ثم في الإصدار الثامن سيستغرق حوالي 60 نانو ثانية. على سبيل المثال كانوا قادرين على قياسه بهذه الدقة في جهاز افتراضي. لماذا لا نستطيع القيام بذلك أيضًا - ليس لدينا مثل هذه الأدوات.

إذا نظرنا إلى جميع الوثائق ، فإن الشيء الوحيد الذي يمكننا العثور عليه هو التوصية أعلاه ، وكيفية قياس واجهة المستخدم:

مقالب adb shell gfxinfo٪ package_name٪

في الواقع ، دعونا نفعل ذلك بهذه الطريقة ونرى في النهاية ما سيعطيه. لكن أولاً ، سنحدد ما سنقيسه وما يمكننا فعله أيضًا.

السؤال التالي. أين تعتقد أن الأداء مهم عند إنشاء تطبيق من الدرجة الأولى؟

1. بالتأكيد في كل مكان.
2. موضوع واجهة المستخدم.
3. عرض مخصص + رسوم متحركة.

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

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

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

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

لذا القاعدة الأولى هي التفكير في المستخدم.

وللقاعدة الثانية ، تحتاج إلى الانغماس في المتشددين.

نمط كوتلن

لتقييم أداء Kotlin بصدق ، سنقارنه بـ Java. لذلك ، اتضح أنه من المستحيل قياس بعض الأشياء الموجودة فقط في Kotlin ، على سبيل المثال:

• مجموعة Api.
• معلمات الطريقة الافتراضية.
• فئات البيانات.
• أنواع Reified.
• Coroutines.

واجهة برمجة تطبيقات المجموعة التي يوفرها لنا Kotlin رائعة جدًا وسريعة جدًا. في Java ، هذا ببساطة غير موجود ، هناك فقط تطبيقات مختلفة. على سبيل المثال ، ستكون مكتبة Liteweight Stream API أبطأ لأنها تفعل كل شيء مثل Kotlin ، ولكن مع تخصيص واحد أو اثنين من العمليات الإضافية ، حيث يتحول كل شيء إلى كائن إضافي.

إذا أخذنا Stream API من Java 8 ، فستعمل بشكل أبطأ من Kotlin Collection API ، ولكن بشرط واحد - لا يوجد مثل هذا الشلل في Collection API ، إذا قمنا بتضمين موازٍ ، على كميات كبيرة من بيانات Stream API ، ستتجاوز Java واجهة برمجة تطبيقات مجموعة Kotlin. لذلك ، لا يمكننا مقارنة مثل هذه الأشياء ، لأننا نجري المقارنة بدقة من وجهة نظر Android.

الشيء الثاني ، الذي ، كما يبدو لي ، لا يمكن مقارنته ، هو معلمات Method الافتراضية - وهي ميزة رائعة جدًا ، بالمناسبة ، في Dart. عند استدعاء بعض الطرق ، قد يكون لها بعض المعلمات التي قد تأخذ بعض القيمة ، ولكن قد تكون فارغة. وبالتالي ، لا تقوم بعمل 10 طرق مختلفة ، ولكن قم بأسلوب واحد وتقول أن إحدى المعلمات يمكن أن تكون فارغة ، وفي المستقبل استخدامها بدون أي معلمة. على سبيل المثال سينظر ، قد حان المعلمة ، أو لم يأت. من الملائم جدًا أنه يمكنك كتابة رمز أقل كثيرًا ، ولكن الإزعاج هو أنه يجب عليك الدفع مقابله. هذا هو السكر النحوي: أنت ، كمطور ، تعتقد أن هذه طريقة واحدة لواجهة برمجة التطبيقات ، ولكن في الواقع ، تحت غطاء المحرك ، يتم إنشاء كل شكل من أشكال الطريقة مع المعلمات المفقودة في الرمز الثانوي. وتقوم كل طريقة من هذه الطرق أيضًا بالتحقق تدريجيًا من وصول هذه المعلمة. إذا جاء ، ثم حسنًا ، إذا لم يحدث ذلك ، فإننا نصنع قناعًا صغيرًا ، واعتمادًا على قناع البت هذا ، فإن الطريقة الأصلية التي كتبتها تسمى فعلاً. عمليات Bitwise ، كل ذلك إذا كان / آخر يكلف القليل من المال ، ولكن القليل جدًا ، ومن الطبيعي أن تدفع مقابل الراحة. يبدو لي أن هذا أمر طبيعي تمامًا.

العنصر التالي الذي لا يمكن مقارنته هو فئات البيانات .

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

يتيح لك Kotlin الابتعاد عن كل شيء. أولاً ، نظرًا لوجود عقارات في Kotlin ، لا تحتاج إلى كتابة الرسائل والمستوطنين. ليس لديها معلمات الفئة ، جميع الخصائص . على أي حال ، نعتقد ذلك. ثانيًا ، إذا كتبت أن هذه هي فئات البيانات ، فسيتم إنشاء مجموعة كاملة من كل شيء آخر. على سبيل المثال ، يساوي () ، toStrung () / hasCode () ، إلخ.

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

لا أستخدم فئات البيانات لسبب آخر. في السابق ، كانت هناك قيود على توسيع هذه الفئات وشيء آخر. الآن الجميع أفضل مع هذا ، لكن هذه العادة باقية.

ما هو رائع جدًا في Kotlin ، وماذا سيكون دائمًا أسرع من Java في؟ هذا هو نوع Reified ، والذي ، بالمناسبة ، موجود أيضًا في Dart.

أنت تعلم أنه عند استخدام الأدوية الجنيسة ، يتم محو نوع المحو في مرحلة التجميع وفي وقت التشغيل لم تعد تعرف ما هو كائن هذا العام المستخدم بالفعل.

مع أنواع Reified ، لا تحتاج إلى استخدام الانعكاس في العديد من الأماكن عندما تحتاج إليه في Java ، لأنه من خلال الأساليب المضمنة ، مع Reified ، تعرف عن النوع ، وبالتالي يتبين أنك لا تستخدم الانعكاس ويعمل الرمز الخاص بك بشكل أسرع. السحر.

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

الحقول

لذلك دعونا نمضي قدمًا ، ننتقل إلى ما يمكننا مقارنته بـ Java وما يمكننا التأثير عليه بشكل عام.

 class Test { var a = 5 var b = 6 val c = B() fun work () { val d = a + b val e = ca + cb } } class B (@JvmField var a: Int = 5,var b: Int = 6) 

كما قلت ، ليس لدينا معلمات للفئة ، لدينا خصائص.

لدينا var ، ولدينا val ، ولدينا فئة خارجية ، واحدة من خصائصها هيJvmField ، وسننظر في ما يحدث بالفعل مع وظيفة العمل (): نجمع قيمة الحقل a والحقل b لفئتنا الخاصة و قيم الحقل أ والحقل ب للفئة الخارجية ، والتي تتم كتابتها في الحقل الثابت.

السؤال هو ما الذي سيتم استدعاؤه في الواقع d = a + b. نعلم جميعًا أن هذه الخاصية مرة واحدة ، سيتم استدعاء getter لهذه الفئة لهذه المعلمة.

  L0 LINENUMBER 10 L0 ALOAD 0 GETFIELD kotlin/Test.a : I ALOAD 0 GETFIELD kotlin/Test.b : I IADD ISTORE 1 

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

ماذا يحدث إذا رأينا ما هو الرمز الثانوي الذي تم إنشاؤه لخط آخر: val e = ca + cb؟

  L1 LINENUMBER 11 L1 ALOAD 0 GETFIELD kotlin/Test.c : Lkotlin/B; GETFIELD kotlin/Ba : I ALOAD 0 GETFIELD kotlin/Test.c : Lkotlin/B; INVOKEVIRTUAL kotlin/B.getB ()I IADD ISTORE 2 

في السابق ، إذا كنت تقوم بالوصول إلى ملكية خاصة ، فكان لديك دائمًا مكالمة InvokeVirtual. إذا كانت هذه ملكية خاصة ، فإن الوصول إليها كان من خلال GetField. GetField أسرع بكثير من InvokeVirtual ، وتزعم المواصفات الواردة من Android أن الوصول إلى حقل مباشر أسرع 3-7 مرات. لذلك ، يُنصح دائمًا بالرجوع إلى الحقل ، وليس من خلال الرسائل أو المستوطنين. الآن ، خاصة في الجهاز الظاهري ART الثامن ، سيكون هناك بالفعل أرقام مختلفة ، ولكن إذا كنت لا تزال تدعم 4.1 ، فسيكون هذا صحيحًا.

لذلك ، اتضح أنه لا يزال من المفيد بالنسبة لنا الحصول على GetField ، وليس InvokeVirtual.

الآن ، يمكنك تحقيق GetField إذا كنت تقوم بالوصول إلى خاصية من فئتك الخاصة ، أو إذا كانت هذه ملكية عامة ، يجب عليك تعيينJvmField. بعد ذلك ، سيكون نفس الشيء بالضبط في الرمز البايت هو استدعاء GetField ، وهو أسرع 3-7 مرات.

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

إذا قمنا بجمع كل التحسينات ، فبإجمالها يمكن أن تعطي شيئًا.

ثابت!؟

ماذا عن الاستاتيكا؟ نعلم جميعًا أن ثابت Kotlin هو كائن مصاحب. في السابق ، ربما أضفت نوعًا من العلامات ، على سبيل المثال ، ثابت عام ، ثابت نهائي ، وما إلى ذلك ، إذا قمت بتحويل هذا إلى كود Kotlin ، فستحصل على كائن مصاحب ، والذي سيكتب شيئًا مثل ما يلي:

  companion object { var k = 5 fun work2() : Int = 42 } 

هل تعتقد أن هذا الإدخال مطابق للإعلان النهائي القياسي الثابت في Java؟ هل هو ثابت على الإطلاق أم لا؟

نعم ، في الواقع ، يعلن Kotlin أنه هنا في Kotlin - ثابت ، يقول هذا الكائن أنه ثابت. في الواقع ، هذا ليس ثابتًا.

إذا نظرنا إلى الرمز الذي تم إنشاؤه ، فسوف نرى ما يلي:

  L2 LINENUMBER 21 L2 GETSTATIC kotlin/Test.Companion : Lkotlin/Test$Companion; INVOKEVIRTUAL kotlin/Test$Companion.getK ()I GETSTATIC kotlin/Test.Companion : Lkotlin/Test$Companion; INVOKEVIRTUAL kotlin/Test$Companion.work2 ()I IADD ISTORE 3 

يتم إنشاء Test.Companion ؛ كائن مفرد يتم إنشاء المثيل من أجله ، تتم كتابة هذا المثيل في الحقل الخاص به. بعد ذلك ، يتم الوصول إلى أحد العناصر المصاحبة من خلال هذا الكائن. يأخذ getstatic ، أي ، نسخة ثابتة من هذه الفئة ، ويستدعي وظيفة getK invokevirtual عليها ، والشيء نفسه تمامًا لوظيفة work2. لذلك نحصل على أنها ليست ثابتة.

هذا مهم ، لأنه في JVMs الأقدم ، كان الاستقلالي أسرع بنسبة 30 ٪ من Invokevirtual. الآن ، بالطبع ، في HotSpot ، أصبحت المحاكاة الافتراضية المحسنة رائعة حقًا ، وهي غير مرئية تقريبًا. ومع ذلك ، عليك أن تضع ذلك في الاعتبار ، خاصة وأن هناك تخصيصًا إضافيًا واحدًا ، والموقع الإضافي على 4ST1 هو 700 نانو ثانية ، كثيرًا.

دعنا نلقي نظرة على كود Java الذي يظهر إذا قمت بنشر الرمز البايت العكسي:

 private static int k = 5; public static final Test.Companion Companion = new Test.Companion((DefaultConstructorMarker)null); public static final class Companion { public final int getK() { return Test.k;} public final void setK(int var1) { Test.k = var1; } public final int work2() { return 42; } private Companion() { } // $FF: synthetic method public Companion(DefaultConstructorMarker $constructor_marker) { this(); } } 

يتم إنشاء حقل ثابت ، وتنفيذ نهائي ثابت للكائن المرافق ، يتم إنشاء الحروف والمستوطنين ، وكما ترى ، بالإشارة إلى الحقل الثابت بالداخل ، تظهر طريقة ثابتة إضافية. كل شيء حزين بما فيه الكفاية.

ماذا يمكننا أن نفعل ، مع التأكد من أنها ليست ثابتة؟ يمكننا محاولة إضافةJvmField و @ JvmStatic ونرى ما سيحدث.

 val i = k + work2() companion object { @JvmField var k = 5 JvmStatic fun work2() : Int = 42 } 

سأقول على الفور أنك لن تهرب منJvmStatic ، سيكون نفس الكائن ، نظرًا لأن هذا كائن مصاحب ، سيكون هناك تخصيص إضافي لهذا الكائن وسيكون هناك مكالمة إضافية.

 private static int k = 5; public static final Test.Companion Companion = new Test.Companion((DefaultConstructorMarker)null); public static final class Companion { @JvmStatic public final int work2() { return 42; } private Companion() {} // $FF: synthetic method public Companion(DefaultConstructorMarker $constructor_marker) { this(); } } 

لكن المكالمة ستتغير فقط لـ k ، لأنها ستكونJvmField ، سيتم اعتبارها مباشرة على أنها getstatic ، لن يتم إنشاء الحروف والمستوطنين. ولكن بالنسبة للوظيفة work2 لن يتغير شيء.

  L2 LINENUMBER 21 L2 GETSTATIC kotlin/Test.k : I GETSTATIC kotlin/Test.Companion : Lkotlin/Test$Companion; INVOKEVIRTUAL kotlin/Test$Companion.work2 ()I IADD ISTORE 3 

يتم اقتراح الخيار الثاني حول كيفية إنشاء ثابت في وثائق Kotlin ، لذلك يقال أنه يمكننا فقط إنشاء كائن ، وسيكون هذا رمز ثابت.

 object A { fun test() = 53 } 

في الواقع ، الأمر ليس كذلك.

 L3 LINENUMBER 23 L3 GETSTATIC kotlin/A.INSTANCE : Lkotlin/A; INVOKEVIRTUAL kotlin/A.test ()I POP 

اتضح أننا نجري مكالمة مثيل getstatic من singletone ، والتي يتم إنشاؤها ، وندعو نفس الأساليب الافتراضية بالضبط.

الطريقة الوحيدة التي يمكننا من خلالها تحقيق Invokestatic هي وظائف عالية الترتيب. عندما نكتب فقط بعض الوظائف خارج الفصل ، على سبيل المثال ، سيتم استدعاء اختبار test2 الممتع على أنه ثابت.

  fun test2() = 99 L4 LINENUMBER 24 L4 INVOKESTATIC kotlin/TestKt.test2 ()I POP 

علاوة على ذلك ، فإن الشيء الأكثر إثارة للاهتمام هو أنه سيتم إنشاء فئة ، كائن ، في هذه الحالة testKt ، فإنه سيولد كائنًا لنفسه ، وسوف يولد وظيفة يضعها في هذا الكائن ، والآن سيتم تسميته باسم Invokestatic.

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

بطلان

 fun test(first: String, second: String?) : String { second ?: return first return "$first $second" } 

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

كيف يتكشف كل هذا في كود جافا؟ في الواقع سيكون هناك شيك.

 @NotNull public final String test(@NotNull String first,@Nullable String second) { Intrinsics.checkParameterIsNotNull(first, "first"); return second != null ? (first + " " + second) : first; } 

سنحصل على الجوهرة في البداية. دعنا نقول أن أقول هذا

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

Intrinsics هي فئة داخلية في Kotlin تحتوي على مجموعة معينة من المعلمات والشيكات. وفي كل مرة تجعل معلمة الأسلوب غير قابلة للإلغاء ، فإنها تتحقق من ذلك على أي حال. لماذا؟ بعد ذلك ، نعمل في Interop Java ، وقد يحدث أنك تتوقع أنه لن يكون لاغياً هنا ، ولكن مع Java سيأتي من مكان ما.

إذا قمت بالتحقق من ذلك ، فسوف يذهب أبعد من ذلك على طول الكود ، ثم بعد 10-20 مكالمات الأسلوب ، ستفعل شيئًا مع معلمة ، على الرغم من أنها قد لا تكون قابلة للإلغاء ، ولكن لسبب ما تبين أنها. كل شيء سيسقط عليك ، ولن تكون قادرًا على فهم ما حدث بالفعل. لتجنب هذا الموقف ، في كل مرة تجتاز فيها المعلمة الفارغة ، سيظل عليك التحقق منها. وإذا كانت لاغية ، فسيكون هناك استثناء.

هذا الفحص يستحق شيئًا أيضًا ، وإذا كان هناك الكثير منهم ، فلن يكون جيدًا جدًا.

ولكن في الواقع ، إذا تحدثنا عن HotSpot ، فستستغرق 10 مكالمات من هذه الجوهر حوالي أربعة نانو ثانية. هذا صغير جدًا جدًا ، ولا داعي للقلق بشأن هذا ، ولكن هذا عامل مثير للاهتمام.

البدائل

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

  var a = 5 var b = 6 var bOption : Int? = 6 

هناك ثلاثة أرقام ، لن يتم استنتاج النوعين الأولين غير الفارغين ، ونقسم الرقم الثالث إلى أنه يمكن أن يكون لاغياً.

  private int a = 5; private int b = 6; @Nullable private Integer bOption = Integer.valueOf(6); 

إذا نظرت إلى الرمز الثانوي ورأيت رمز Java الذي تم إنشاؤه ، فلن يكون الرقمان الأولان خاليين ، وبالتالي يمكن أن يكونا بدائيين. لكن البدائي لا يمكن أن يحتوي على Null ، فقط كائن يمكن أن يفعل ذلك ، لذلك سيتم إنشاء كائن للرقم الثالث.

AUTOBOXING

عندما تعمل مع بدائيين وتجري عملية بدائية وغير بدائية ، ستحتاج إما إلى ترجمة أحدهم إلى بدائي أو إلى كائن.

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

  val a: String? = null var b = a?.isBlank() == true 

ترى أين ستكون الملاكمة / أونبوكسينغ هنا؟ كما أنني لم أر حتى نظرت إلى الرمز الفرعي.

 if (a != null && a.isBlank()) true else false 

في الواقع ، توقعت أنه سيكون هناك شيء مثل هذه المقارنة: إذا لم تكن السلسلة فارغة وإذا كانت فارغة ، فقم بتعيينها على true ، وإلا تم تعيينها على false. يبدو أن كل شيء بسيط ، ولكن في الواقع يتم إنشاء التعليمات البرمجية التالية:

 String a = (String)null; boolean b = Intrinsics.areEqual(a != null ? Boolean.valueOf(StringsKt.isBlank((CharSequence)a)) : null, Boolean.valueOf(true)); 

دعونا ننظر في الداخل. يتم أخذ المتغير a ، ويتم طرحه في CharSequence ، بعد طرحه ، والذي تم إنفاقه أيضًا لبعض الوقت ، ويسمى الاختيار الآخر - StringsKt.isBlank - هذه هي الطريقة التي تتم بها كتابة وظيفة التمديد لـ CharSequence ، لذلك يتم إرسالها وإرسالها. نظرًا لأن التعبير الأول يمكن أن يكون لاغياً ، فإنه يأخذه ويقوم بالملاكمة ، ويلفها كلها في Boolean.valueOf. لذلك ، يصبح البدائي الحقيقي أيضًا كائنًا ، وفقط بعد ذلك يتم التحقق بالفعل ويتم استدعاء Intrinsics.areEqual.

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

حلقات

الشيء التالي المثير للاهتمام.

يمكنك استخدام المعتاد لـ ، وهو في Java ، ولكن يمكنك أيضًا استخدام واجهة برمجة التطبيقات المناسبة الجديدة - كتابة تعداد العناصر في القائمة على الفور. , work, it - .

 list.forEach { work(it * 2) } 

. , . , Google, , ArrayList for 3 , . .

, ArrayList, — foreach.

 inline fun <reified T> List<T>.foreach(crossinline action: (T) -> Unit): Unit { val size = size var i = 0 while (i < size) { action(get(i)) i++ } } list.foreach { } 

API, - . , Kotlin: extension , «», reified, .. , , , crossinline. , , . 3 , Android Google.

RANGES

Ranges.

 inline fun <reified T> List<T>.foreach(crossinline action: (T) -> Unit): Unit { val size = size for(i in 0..size) { work(i * 2) } } 

: Unit -. −1, until , , . , , ranges. على سبيل المثال , . step. .

INTRINSICS

- Intrinsics, :

 class Test { fun concat(first: String, second: String) = "$first $second" } 

Intrinsics — second, first.

 public final class Test { @NotNull public final String concat(@NotNull String first, @NotNull String second) { Intrinsics.checkParameterIsNotNull(first, "first"); Intrinsics.checkParameterIsNotNull(second, "second"); return first + " " + second; } } 

, gradle. , - 4 , . Kotlin UI, , nullable, Kotlin :

kotlinc -Xno-call-assertions -Xno-param-assertions Test.kt

Intrinsics, , .

, , . — Xno-param-assertions — Intrinsics, .

, , , , , . , , , .

REDEX

, , , Proguard. , 99% , , . Android 8.0 , . , .

, Proguard, Facebook, Redex . -, , . , Jvm Fields , .

, Redex . , , , Proguard, , . Redex 7% APK. , .

BENCHMARKS

. , , . , . , dumpsys gfxinfo , . github github.com/smred .

, Huawei.


. — , . , , 0,04 . , , — , .


Kotlin, . , , . - , Kotlin , Java. , , , , . .


, , , , Kotlin Java. , - , , , , , .


, : - Kotlin , .. . , . - - — 2 , Galaxy S6, .


Google Pixel. , 0,1 .

, , ,

• UI custom view.
• onmeasure-onlayout-ondraw. autoboxing, not null ..
• Kotlin, Java , .
• — .

, , . , , , , Kotlin, . , Kotlin .

, .

brand new AppsConf , Android . , . , 8 9 .