Чому з підказок щодо продуктивності Android було видалено "Уникайте енумів, де вам потрібні лише інти"?

175

З офіційної документації для розробників було видалено розділ "Уникайте переліків, де вам потрібні лише інти" . (Див. Чому Android не використовує більше перерахунків? Для старого вмісту розділу)

Чому? Чи відбулася зміна Android VM, яка зробила наконечник застарілим?

android  enums 
— Тьєррі-Димитрій Рой
джерело
2
Для довідки, ось декомпільований байт-код для прикладу Shrubbery: https://gist.github.com/847418
— Josh Lee
15
Станом на березень 2014 року наступна сторінка все ще містить поради щодо використання переписки: developer.android.com/training/articles/memory.html#Overhead
— Тахір Ахтар
2
Через рік, як сказав @TahirAkhtar, в офіційному навчанні Android все ще сказано: "Вам слід суворо уникати використання переписок на Android".
— LarsH
1
Цікаво відзначити, що рекомендується уникати перерахунків у цій статті 2015 року від провідного розробника Android: medium.com/google-developers/… Також: "Зауважте, що використовуйте анотацію @IntDef, яку підтримують Android Studio та Gradle 1.3+, забезпечить безпеку типу строку побудови коду (коли ввімкнуті помилки ворта), зберігаючи розмір та ефективність використання змінних int. "
— тоніло
4
Станом на квітень 2018 року наступна сторінка більше не містить порад щодо використання переписок. developer.android.com/topic/performance/memory#Overhead
— Робін Девіс

Відповіді:

157

оригінальна версія цього документа була лише купою забобонів. він був переписаний, щоб містити лише факти, підкріплені фактичними орієнтирами, і він оновлюється по мірі оновлення VM. ви можете знайти різні орієнтири - плюс деякі орієнтири, які ми використовуємо для оптимізації основних бібліотек - на веб-сайті http://code.google.com/p/dalvik/ .

— Еліот Х'юз
джерело
35
Це допоможе, якщо ви перерахуєте свої облікові дані у своєму профілі SO. Мені знадобилося трохи копати. Але тепер, коли я бачу, що ви, здається, працюєте в команді VM, я прийму вашу відповідь як офіційну відповідь. :)
— Thierry-Dimitri Roy
25
Додавання перелічувального курсу, звичайно, означає, що ваш додаток містить додатковий клас, тому це не безкоштовно , але ми повинні припустити, що розробник додає переліки лише там, де вони корисні. Єдине дуже погане використання, яке я бачив із перерахунками, було в якомусь коді гармонії, де вони дуже хотіли ints (для бітових масок тощо), і "enum" не був перерахунком у жодному розумному сенсі. Якщо ви дуже часто називаєте "ordinal ()", це, мабуть, поганий запах, що означає, що ви не хочете перераховувати. Але це не підказка для Android, і все одно це дійсно рідкісна помилка дизайну.
— Елліотт Х'юз
17
Чи цей документ застарів і @ Thierry-DimitriRoy? Зокрема, вам слід суворо уникати використання переписок на Android.
— Яків Табак
3
FWIW, Proguard перетворює перерахунки в int за замовчуванням.
— Nacho Coloma
11
Посилання, яке ви надали, мертве.
— Террі
26

Здогадка:

  • Процесори Gigahertz, такі як Hummingbird та Snapdragon, зараз поширені, а вимоги з малою кодовою пам’яттю з невеликим кодом, які спочатку обмежували Dalvik VM, вже не є істинними.
  • Кожен транспортний пристрій використовує JIT (новий для 2.2). Ініціалізатор класів enum запуститься швидше, ці значення можуть трактуватися як константи часу JIT, і JIT цілком може мати спеціальну підтримку для упорядкування класів enum.
  • Код, який дійсно чутливий до продуктивності, використовує NDK, який був ще новим та непопулярним, коли вийшов Android 1.5. NDK в версії 2.3 підтримує вбудовану діяльність, яка дозволяє проводити майже повністю некеровані ігри.

Таким чином, для порівняно щоденних вимог програми GUI, переваги переліків у часі на розвиток значно перевищують додаткові витрати на виконання.

— Джош Лі
джерело
23

Елліотт Х'юз пропонує більше подробиць про перезапис документації у своєму блозі: http://elliotth.blogspot.com/2010/09/java-benchmarks.html

У другій половині публікації пояснюється, що кожна претензія на документ про продуктивність тепер підкріплена критеріями. Попередні версії doc, очевидно, містили неперевірені твердження, як-от: "Уникайте переживань, оскільки вони занадто дорогі".

— jkooker
джерело
Просто хотів доповнити прийняту відповідь Елліотта цим посиланням.
— jkooker
12

У відповіді Елліота Х'юза в 2011 році сказано, що первісна причина уникнути занурення була з міркувань продуктивності ... як у "обробці продуктивності". Оскільки ця причина не була підтверджена фактом, її було вилучено з офіційної документації.

Це було додано пізніше, тому що енуми додають у пам'ять набагато більше даних, ніж використання цілого числа.

— Тьєррі-Димитрій Рой
джерело
2
Крім того, хлопці Google представили IntDefанотації, які дозволяють безпечно використовувати int-константи із помилками та попередженням Android Studio. blog.shamanland.com/2016/02/int-string-enum.html
— Олексій К.
9

TLDR: Далвіку було непогано з розподілом пам'яті і він Enumвикористовує більше пам'яті, ніж int. Android Lollipop замінив Dalvik на ART, який не зазнає однакових обмежень. Тому ця рекомендація вже не актуальна.

Довга відповідь:

Оце Так! 8 років, 5 відповідей і багато коментарів пізніше справжня причина все ще не вирішена.

У перед-льодяникові Android дні Далвік був процесом, що використовувався ВМ. Оскільки невеликий обсяг пам’яті був доступний для програм, які використовувались у той час, у Далвіка було багато обмежень щодо пам’яті. Для виділення пам’яті Далвіку довелося пройтися по купі і знайти місце. Купа також буде роздроблена з часом. Дальвік не міг дефрагментуватись, тому він би виділявся з часом і врешті-решт не вистачало місця.

Уникайте енумів там, де вам потрібні лише інти

походить з Далвік днів, тому що Enumце набагато більше, ніж intі розподіл пам'яті було дуже дорогим.

Сьогодні вперед, Дальвік змінив ART. ART вийшов у KitKat і за замовчуванням починає працювати з Lollipop.

АРТ створено з нуля не для оптимізації пам’яті, а для оптимізації продуктивності. Він також оптимізований для розподілу та колекцій. Причина в тому, що для великих об'єктів відведена пам'ять. Замість того, щоб розміщувати все в одній купі, а потім потрібно знаходити простір для великих об'єктів серед усіх крихітних, ART розміщує всі великі об'єкти та растрові карти в окрему купу. А потім дрібні предмети йдуть в окрему купу. Також він може дефрагментувати.

Після ART, якщо ви користуєтесь EnumAndroid, це не важливо, і саме тому зараз рекомендація відсутня.

Це йде від Chet Haase в Google. Рекомендую знайти його розмову в I / O в Google і переглянути все відео. Він містить багато корисної інформації та розуміння Android.

— Адель Ахмед
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.