Защо SparseArray в Android JFC не е съвместим?

И така, трябва да използвам SparseArray вместо HashMap в името на ефективността:

Въпреки това SparseArray не е част от JCF и не прилага Collection нито List нито Map. HashMap, от друга страна, имплементира < a href="http://docs.oracle.com/javase/6/docs/api/java/util/Map.html" rel="nofollow">Map и предоставя values(), с които мога да работя, когато имам нужда от JCF-съвместимо поведение. Например, използването му в ArrayAdapter и различно персонализирано сортиране (за стойности ).

Въпросът ми е троен:

  1. Защо SparseArray не внедрява JCF интерфейси? Искам да кажа, каква е мотивацията да не внедрим тези интерфейси в светлината на факта, че повечето от методите вече са там?
  2. Има ли алтернативи на SparseArray, които прилагат JCF интерфейси или могат лесно да бъдат конвертирани и да запазят SparseArray производителност?
  3. Наистина ли HashMapи с няколкостотин елемента толкова по-бавно? Моите потребители наистина ли ще забележат?

Търся задълбочени отговори и предпочитам да имам препратки към авторитетни сайтове. Ако смятате, че знаете защо SparseArray не е внедрен с JCF интерфейси, покажете малко подкрепа, помогнете ми да разбера. Ако смятате, че трябва да използвам SparseArray, покажете ми как да го използвам с ArrayAdapter и персонализирано сортиране (Comparator-подобно на предпочитаните решения). Ако има по-добри алтернативи, връзки към API документ, библиотека или урок биха били полезни. Ако смятате, че трябва да се придържам към HashMaps , обяснете защо ползата от производителността на SparseArray е по-малка от нуждите на интерфейси.


android collections sparse-array
person mawcsco    schedule 19.04.2013    source източник
comment
Наистина ли HashMaps с няколкостотин елемента са много по-бавни? Моите потребители наистина ли ще забележат? -- когато създадохте своя бенчмарк и проведохте тестовете си, особено с помощта на инструменти като Traceview, какво научихте?   -  person CommonsWare    schedule 23.04.2013
comment
@CommonsWare Никога не съм създавал бенчмарк. Защо, за бога, бих го направил? Създавам приложение, а не тествам ефективността на колекциите. Пусках Traceview, но нямам референтна точка, за да кажа, това е лошо или това е добро. Всичко върви добре. Нямам с какво да го сравня, защото никога не съм го правил със SparseArray. Всъщност няма практичен начин да направите това. Всичко, което трябва да продължа, е предупрежденията на Lint, които ми казват, че трябва да използвам SparseArray. Да пренебрегна ли тези предупреждения? Инвестирам ли време за цялостно преработване на моя код?   -  person mawcsco    schedule 23.04.2013
comment
Защо, за бога, бих го направил? -- за да отговорите на въпросите: наистина ли HashMaps с няколкостотин елемента са много по-бавни? Моите потребители наистина ли ще забележат? Никой друг няма да може да отговори на това, тъй като нямаме представа как, къде и кога използвате HashMap. Всъщност няма практичен начин да направите това – тъй като вие сте единственият човек на планетата, който познава вашето приложение, ще трябва да приемем това за чиста монета. Да пренебрегна ли тези предупреждения? -- ако няма практически начин да използвате SparseArray, изглежда, че нямате избор.   -  person CommonsWare    schedule 23.04.2013
comment
@CommonsWare Изграждането на бенчмарк предполага, че имам някаква отправна точка за сравнение. Аз нямам това. Не използвам SparseArray, защото трябва да използвам тези данни с ArrayAdapter и имам нужда от персонализирано сортиране (в момента се прилага с Comparator и Collections.sort()). И така, първоначалният ми въпрос е защо SparseArray е внедрен по този начин. И тъй като е така, как да се справя с това предупреждение Lint.   -  person mawcsco    schedule 23.04.2013
comment
Тогава как бихте очаквали някой да може да отговори на въпрос №3? Ако вие не знаете от какво са толкова по-бавни, как можем ние?   -  person CommonsWare    schedule 23.04.2013
comment
Ако (колективно) не можете да отговорите на #3, тогава защо се препоръчва? Ясно е, че някой знае, че SparseArray е по-добре представяща се колекция. Ясно е, че някой има данни от многократно излагане на проблема, които могат да кажат с увереност, че трябва да използвам SparseArray. Очевидно те добавиха препоръката към правилата на Lint в ADK. Единствените данни, които открих, са твърде неясни, за да се определи дали това повишаване на производителността ще засегне малки колекции. Искам авторитетен отговор от някой, който има много опит в SparseArray, за да ми помогне да намеря повече/по-добри данни, преди да взема важно решение.   -  person mawcsco    schedule 23.04.2013
comment
Ако (колективно) не можете да отговорите на #3, тогава защо се препоръчва? -- предложено е от Lint като нещо, което може да обмислите. Lint не е AI двигател; някои от препоръките, които прави, ще бъдат неподходящи за вашата конкретна ситуация. Искам авторитетен отговор от някой, който има много опит със SparseArray, за да ми помогне да намеря повече/по-добри данни, преди да взема голямо решение - разбрахте го в коментара от fadden (инженер на Android).   -  person CommonsWare    schedule 23.04.2013
comment
Ако имате HashMap<Integer, Object>, помислете за SparseArray. Ако ще бъде болезнено да го използвате, използвайте Traceview, за да определите колко време заемате с настоящото си базирано на HashMap решение. Ако отговорът не е много, тогава по дефиниция SparseArray ще помогне по-малко, отколкото не много, и не си струва да се притеснявате. По отношение на предупреждението Lint, ако решите да се придържате към HashMap, трябва да има анотация @SuppressLint, която ще блокира предупреждението. Ако използвате Eclipse, тази анотация трябва да бъде в списъка за бързи корекции (ако не, това е ADT грешка).   -  person CommonsWare    schedule 23.04.2013
comment
От гледна точка на производителността също така е полезно да помислите за допълнителните разпределения, които вероятно се изискват от ints в кутия. Тук има наистина добра презентация от няколко момчета от IBM: cs.virginia.edu/kim/publicity/pldi09tutorials/   -  person fadden    schedule 23.04.2013

Отговори (2)


arrow_upward
3
arrow_downward

Първата версия на SparseArray.java е написана през май 2006 г. В някои отношения тя предшества различните интерфейси за събиране, за които говорите (в Android, не в Java). Моето усещане е, че не поддържа различните JCF интерфейси, защото те не са съществували по времето, когато е написан кодът, и никой не е намерил причина да ги добави оттогава. (Дори не използваше генерични лекарства до началото на 2007 г.)

Ако смятате, че подобреният SparseArray е полезен, висококачествените корекции винаги са добре дошли.

person fadden    schedule 23.04.2013

arrow_upward
1
arrow_downward

Може би защото е Map ‹ Object, Object > но SparseArray има примитивни ключове.

Алтернативата е картата, както беше преди

За 3 по принцип да, но трябва да се измери и да се види дали е така в неговия случай

person Alexander Kulyakhtin    schedule 19.04.2013
comment
Автоматичното разопаковане на Map‹Integer, Object› влошава ли производителността? Какво ще кажете за интерфейса List? - person mawcsco; 19.04.2013
comment
В Java Puzzlers amazon.com/Java-Puzzlers-Traps-Pitfalls -Corner/dp/032133678X, ако не греша, е обяснено, че боксирането-разопаковане удря много производителността. Може да греша много, но по-добре проверете - person Alexander Kulyakhtin; 19.04.2013
comment
Можете ли да уточните отговора си повече? #1 Бих искал да знам повече от може би (и аз мога да гадая за може би). Търся солидни причини защо JCF не е внедрен. #2 Търся алтернативи освен решението, което вече имам. #3 Не мога да премина към SparseArray, без да пренапиша напълно голяма част от моя код, така че нямам практически начин да го измеря. Всичко, което намерих по темата, е една статия, към която съм дал връзка. Имам нужда от повече информация, а не от предположения. - person mawcsco; 22.04.2013
comment
Няма може би. Това е описано в документите: предназначено е да бъде по-ефективно от използването на HashMap за картографиране на цели числа към обекти. Избягването на постоянното боксиране и разопаковане на Integer е причината за неговото съществуване. FWIW, другата забавна част за SparseArray е, че той прилага Cloneable, но неговият clone() не връща Object, което го прави ковариантен метод, а не претоварване. - person fadden; 23.04.2013
comment
@fadden Избягването на постоянното боксиране и разопаковане на Integer е причината за неговото съществуване. Това не ми е съвсем ясно. Въпреки това, ако приемем, че е вярно, това само обяснява защо не прилага Map‹K, V›. Какво ще кажете за Collection‹E› (или всеки валиден подинтерфейс), където E е типът стойност? - person mawcsco; 23.04.2013
comment
@mawcsco: Collection<E> изисква add() метод, приемащ една стойност. SparseArray изисква ключове. - person CommonsWare; 23.04.2013
comment
@CommonsWare ръководството за JCF позволява някои методи да не се прилагат. От документа за API на колекцията: ...методите, които модифицират колекцията, върху която работят, са посочени да хвърлят UnsupportedOperationException, ако тази колекция не поддържа операцията. - person mawcsco; 23.04.2013
comment
@mawcsco: Първата версия на SparseArray.java беше написана през май 2006 г. В някои отношения тя предшества различните интерфейси за събиране, за които говорите (в рамките на Android, не на Java). Моето усещане е, че не поддържа различните JCF интерфейси, защото те не са съществували по времето, когато е написан кодът, и никой не е намерил причина да ги добави оттогава. (Дори не използваше генерични лекарства до началото на 2007 г.) Ако смятате, че е полезно, висококачествените корекции винаги са добре дошли. - person fadden; 23.04.2013
comment
@fadden Това е изключителна информация. Бихте ли го поставили в отговор вместо коментар. Ще отбележа това като отговор. - person mawcsco; 23.04.2013