Создание собственной View под Android – может ли что-то пойти не так?24.02.2017 15:19

• вызывается пару раз onMeasure() для определения размеров;
• вызывается onLayout() для расположения элемента внутри контейнера;
• вызывается onDraw() для отрисовки.

• onMeasure() предназначен только для определения размеров. Не имеет абсолютно никакого смысла помещать в него что-либо ещё. Причина не только в том, что метод вызывается несколько раз, но и в том, что нельзя с уверенностью сказать, будет ли вызван он ещё раз до onLayout() или же текущий подсчитанный размер — финальный;
• onSizeChanged(), который по какой-то невероятной причине зачастую не упоминается в статьях по кастомным вьюшкам, вызывается до onLayout(), но внутри метода layout(), вызванным родителем. Суть такова, что layout() вызывает setFrame(), который вызывает onSizeChanged(), а уже потом (после выхода из setFrame()) вызывается onLayout(). Это означает, что внутри метода onSizeChanged() вы всё ещё не можете положиться на то, что все дочерние вью внутри вашего вью расположены как нужно. Более того, у них ещё не были вызваны их onSizeChanged(), не говоря уже об onLayout();
• Внутри onLayout() можно вызывать measureChildren() самостоятельно. Иначе говоря, если вью того пожелает, он может ещё несколько раз прогнать measurement pass;
• Последним методом в onLayout() лучше оставлять super.onLayout(). В противном случае вы можете создать ситуацию, при которой у дочерних вью будет дважды вызван onSizeChanged() с onLayout(). А уж если не повезет, то и вовсе можете зациклиться так, что каждые 16 мс (60 fps ведь) будет вызываться requestLayout() (спойлер: автор здесь себе в ногу выстрелил, но об этом позднее).

В моем случае внутри UsersView.onLayout() происходит изменение Y-координат вьюшек, из-за чего некоторые вьюшки становятся видны, а другие прячутся, и это приводит к… (внимание на правый низ):

…обрезанию нижней вьюшки. Подобное происходило только при отдалении. Пришлось потупить повозиться, но удалось разобраться, что, похоже, дочерняя вьюшка определила, что со своей текущей позицией Y она в родителе появится лишь на половину, а посему можно обрезать свой Bitmap drawingCache;. Тут на помощь и пришел тот самый дополнительный «measurement pass» в виде measureChildren() внутри onLayout(), заставивший вьюшку пересмотреть свои кэши после изменения её Y-координаты.

2.3. ScrollView не разрешает менять размер ребенка

Давайте по порядку. Как вообще можно изменить высоту элемента? Через LayoutParams.height конечно же, больше никак. Проблема решена? Нет. Высота осталась неизменной. Что же произошло? Изучив onMeasure() в дочернем вью, я пришел к выводу, что ScrollView просто игнорирует установленный height в параметрах, отсылая ему сначала onMeasure() с mode равным »UNSPECIFIED», а затем onMeasure() с »EXACTLY» и значением height«а, равным размеру ScrollView (если установлен fillViewport). А так как единственный способ изменить height вьюшки — изменить его LayoutParams — то ребенок и не меняется.

Решений я нашел два:

1. Коль ScrollView такой наглый умный и игнорирует LayoutParams, можно просто переписать метод onMeasure() у ребенка и перед тамошним super.onMeasure() добавить это:
   

   
   	if (MeasureSpec.getMode(heightMeasureSpec) == MeasureSpec.UNSPECIFIED
   		&& getLayoutParams().height > 0) {
   		heightMeasureSpec = MeasureSpec.makeMeasureSpec(
   			getLayoutParams().height, MeasureSpec.EXACTLY);
   	}

   
   Тем самым сделав работу ScrollView за него. Но естественно создавать каждый раз подкласс лишь для этого — не очень хорошая идея. Мало ли, какого именно класса должно быть дочернее вью: FrameLayout, LinearLayout, RelativeLayout и т.д. Делать для каждого возможного Layout«а свой подкласс — только мусорить. Поэтому вот вам решение №2.
2. Обернуть ребенка во FrameLayout и изменять размер ребенка этого FrameLayout«а.

Ах да, проблема с неизменяемым размером ребенка у ScrollView есть на багтрекере, но как это обычно и бывает с Android«ом, оно всё ещё в статусе New с 2014-го года.

2.4. Закругленные углы у background

Как ни странно, у класса ShapeDrawable нет методов для работы с закругленными углами, как можно было бы ожидать. Но к счастью, есть наследник RoundRectShape и PaintDrawable (зачем нужен этот класс — не спрашивайте, сам в шоке), у которых присутствуют недостающие методы. На этом проблему для практически всех приложений можно было бы считать решенной, но не для данной задачи.

Специфика задачи такова, что максимальный zoom in может быть каким угодно, а значит вьюшка с её background«ом сильно растянутся, что приводет к…
Logcat: W/OpenGLRenderer: Path too large to be rendered into a texture
Выглядит это так, что после превышения некоторого размера, background просто перестает отображаться. Как можно понять из предупреждения, некий Path слишком большой, чтобы можно было его отрисовать в текстуру. Чуток покопавшись в исходниках, я пришел к выводу, что виной всему этот товарищ:

canvas.drawPath(mPath, paint);

mPath.addRoundRect(mInnerRect, mInnerRadii, Path.Direction.CCW);

canvas.clipPath(roundedPath);

2.5. Позиционирование View внутри FrameLayout

Первое, что приходило на ум (да и то, что я считал единственным возможным способом перемещения вьюшки внутри FrameLayout) — использовать MarginLayoutParams и изменять параметр topMargin. Об этом же свидетельствуют большинство ответов на stackoverflow (раз, два, три).

Недостатком данного подхода является то, что изменение LayoutParams вызывает requestLayout(), а это крайне дорогая операция, особенно если она вызывается у всех GroupView внутри UsersView, даже с учетом того, что непосредственно сам layout pass откладывается до лучших времен (следующего 16 мс-фрейма).

Но к счастью, есть другой способ — View.setY() (ответ на stackoverflow). Идеально для анимаций и для дочерних элементов внутри неизменяющихся Layout«ов. Он не вызывает requestLayout(), а использует только поля самой вьюшки и влияет лишь на фазу (pass) layout«а. А так как просчет новых позиций вьюшек происходит прямо в onLayout() до вызова super.onLayout(), requestLayout() и вовсе не нужен.

2.6. Видишь отступы шрифта? Нет? А они тебя видят! © includeFontPadding

В общем, не буду томить, решение оказалось очень простым, но вот найти сходу его не получалось просто потому, что я не понимал, что вообще. Вот, кстати, ссылка на решение. Суть в том, что, оказывается, у шрифтов самих по себе есть padding«и, которые и являлись причиной нецентрируемости. Добавив TextView параметр includeFontPadding=false, проблема исчезла целиком и полностью.

2.7. У ViewPropertyAnimator нет метода reverse()

Однако, подобное работает хорошо только при быстрой анимации fade«а. Однако если fade будет медленным, то при резком zoom in после zoom out, альфа канал вьюшки будет не 1 или 0, а, например, 0.5. Из-за чего, анимация будет проигрывается от 0.5 до 0 за те же fadeDuration. Выглядеть это будет так, словно анимация замедлилась в 2 раза. Добавлять до вызова view.animate() нечто вроде view.setAlpha(0 or 1) не является хорошим решением. Вьюшка начнет мерцать при быстром зуме.

В идеале, здесь должен был бы быть какой-нибудь метод вида setReverseDuration() (без параметров), который бы понял, что, «ага, я проигрывал анимацию fade«а 500 мс, поэтому столько же и будет играть reverse-анимация». Но такого нет, увы. Единственный выход, что мне удалось найти, делать подобное ручками. В моем случае анимация была довольно простая, так что мне хватило этого для скрытия:

final float realDuration = iconView.getAlpha() * animationDuration;

final float realDuration = (1 - iconView.getAlpha()) * animationDuration;

2.8. ScaleGestureDetector (он же «пинч», он же «зум»)

2.8.1. Небольшие замечания

@Override
public boolean onTouchEvent(MotionEvent ev) {
   scaleDetector.onTouchEvent(ev); 
   super.onTouchEvent(ev); 
   return true;
}

Я был готов долго и нудно рыскать в поисках сложного решения разграничения ответственности между super.onTouchEvent() и scaleDetector.onTouchEvent()… и я и правда искал… Но как оказалось, решение было ужасно простое:

@Override
public boolean onTouchEvent(MotionEvent ev) {
   scaleDetector.onTouchEvent(ev);
   if (ev.getPointerCount() == 1) {
      super.onTouchEvent(ev);
   }
   return true;
}

Во-вторых, если вы страдаете микро оптимизационной болезнью, то вам придётся следить за размером ваших дочерних вью с особой осторожностью. Как вы уже знаете, при пинче я увеличиваю высоту для child внутри child у ScrollView. Этим child«ом является LinearLayout, дочерним элементам которого прописан layout_weight=1. Иначе говоря, все они одной высоты… хотя нет.

Это совершенно никогда не заметно, но его дочерние вью не всегда могут быть одной высоты, ведь пиксели — атомарные единицы. То есть, если LinearLayout имеет высоту 1001 и у него 2 дочерних элемента, то один из них будет размером 501, а другой 500. Заметить это на глаз практически нереально, но вот косвенные последствия могут быть.

Когда я говорил про ViewPropertyAnimator и reverse(), я показал анимацию сокрытия иконки ранга. Сама проверка простая — суммируем высоту 2-ух TextView и ImageView в onLayout(), и если они не влазят внутрь текущей вьюшки разом, то прячем fade«ом ImageView. Стоит отметить также, что эта суммарная высота (так сказать «порог высоты») не меняется. Как итог, если порог равен 500 пикселей, то в описанном случае, у одного вью размером 500 иконка спрячется, а у второго, размером 501, нет.

Ситуация редкая и не слишком критичная (было не так уж просто (но и не сложно) двигать мышкой так медленно, чтобы обнаружить не скрытые и скрытые иконки одновременно). Но всё же если вам не нравится такое поведение, исправить это можно только одним способом — не использовать getHeight() для сверки с порогом. В onSizeChanged() внутри LinearLayout«а находите наименьший размер у всех дочерних элементов и оповещаете всех о том, чтобы они сравнивали порог именно с этим числом. Я назвал это shared height и выглядит у меня это так:

private void updateChildsSharedHeight() {
   int minChildHeight = Integer.MAX_VALUE;
   for (int i = 0; i < binding.lRankings.getChildCount(); ++i) {
      minChildHeight = Math.min(minChildHeight, binding.lRankings.getChildAt(i).getMeasuredHeight());
   }

   for (int i = 0; i < binding.lRankings.getChildCount(); ++i) {
      RankingView child = (RankingView) binding.lRankings.getChildAt(i);
      child.setSharedHeight(minChildHeight);
   }
}

int requiredHeight = binding.tvScore.getHeight() + binding.tvTitle.getHeight() + binding.ivIcon.getHeight();
boolean shouldHideIcon = requiredHeight > sharedHeight;

2.8.2. Проблемы

2.8.2.1. Минимальный пинч

mMinSpan = res.getDimensionPixelSize(com.android.internal.R.dimen.config_minScalingSpan);

2.8.2.2. Слоп

Ладно-ладно, шутки в сторону. «Слоп» это такое состояние, когда считается, что юзер случайно задел экран и на самом деле не хотел ничего двигать/скроллить/зумить/ещё чего. Эдакая «защита от случайного движения». Гифка объяснит:

… на гифке видно, что до начала пинча допускаются минимальные движения, которые не будут считаться пинчем. В принципе, хорошая вещь, плюсую.

Но… слоп то тоже не изменяем! ScaleGestureDetector описывает его так:

mSpanSlop = ViewConfiguration.get(context).getScaledTouchSlop() * 2;

mTouchSlop = res.getDimensionPixelSize(
        com.android.internal.R.dimen.config_viewConfigurationTouchSlop);

2.8.2.3. Скачки detector.getScaleFactor() при первом пинче

Я долго пытался понять, в чем же проблема. Проверял на реальном устройстве (мало ли, вдруг проблема эмулятора), двигал мышкой так, будто за лишний миллиметр движения где-то умирает котик (мало ли, вдруг я дерганный и отсюда коэф. > 1 в логах) –, но нет. Ответ найден не был, но мне повезло. Так сказать «от балды», решил попробовал отправить в ScaleGestureDetector эвент MotionEvent.ACTION_CANCEL сразу после инициализации:

scaleDetector = new ScaleGestureDetector(getContext(), new ScaleListener());
long time = SystemClock.uptimeMillis();
MotionEvent motionEvent = MotionEvent.obtain(time - 100, time, MotionEvent.ACTION_CANCEL,
      0.0f, 0.0f, 0);
scaleDetector.onTouchEvent(motionEvent);
motionEvent.recycle();

2.9. ScrollView.setScroll() срабатывает только после super.onLayout()?

1. Просчитываем newHeight
2. Просчитываем newScrollPos
3. Устанавливаем newHeight через setLayoutParams ()
4. Устанавливаем newScrollPos через setScroll ()

nextScrollPos = newScrollY;

private void updateScrollPosition() { 
   if (nextScrollPos != null) {
      setScrollY(nextScrollPos.intValue());
      nextScrollPos = null;
   }
}

p.s. Однако если не использовать хак с «меняем height для child внутри child внутри ScrollView», то такой проблемы не будет. Но тогда возвращаемся к проблеме десятка подклассов.

3. Задача кластеризации юзеров

3.1. Что делать с граничными юзерами?

Забегая вперед отмечу, что это добавило очень много мороки алгоритму группировку и логике работы приложения в целом.

3.2. Какое кол-во очков показывать у группы?

Усложним задачу. А этих как объединить?

Здесь есть 2 способа решения:

1. Так же, как с юзерами 40% и 50%. То есть, ставим группу на позицию 2.5%.
2. Ставим группу в позицию , а очки уже вычисляем из позиции вьюшки в пикселях.

Предпочитая UX, я решил делать именно способом №2, однако у подхода обнаружился существенный недостаток: очки группы вычисляются совершенно криво. Дело в том, что юзер с 0% на самом деле расположен не в позиции 0 (ведь в таком случае он бы заезжал на территорию чужого ранга), поэтому можно сказать что у всех вьюшек в ранге не может быть очков меньше, чем некоторый minScore, который ещё и меняется при зуме, ведь вычисляется по формуле (упрощенная версия):

Учитывая все эти недостатки способа №2, было принято решение использовать способ №1, хоть и групповая вьюшка будет появляться не точно по центру между юзер-вьюшками.

3.3. Алгоритм

Я мог бы написать финальную реализацию и закончить на этом, но всё же предпочел описать несколько своих реализаций. Если вам интересна описанная ниже проблема кластеризации, подумайте, как бы вы её решили (какой алгоритм бы придумали/использовали), а уже затем читайте абзац за абзацем, меняя своё решение, если оно, также как было моё, подвержено артефактам.

3.3.1. Задача

1. Граничные вью должны оставаться внутри ранга.
2. Юзеры должны объединяться в строго заданном порядке — не допускается, что при zoom in с последующим zoom out и повторным zoom in юзеры будут объединяться в группы как-то иначе.
3. Юзеры устанавливаются единожды и больше не добавляются/удаляются (правило добавлено из соображений по пункту №2).

3.3.2. Пару слов об алгоритмах

По поводу обозначений. Я буду отмечать номер юзера одной цифрой:»7», —, а группы — двумя:»78». Цифры в номере группы обозначают номера юзеров в неё входящих, то есть группа 78 состоит из юзеров 7 и 8.

К каждому алгоритму будет приведено как словесное описание, так и псевдокод.

3.3.3. Алгоритм №1

Шаги:
1. Проверить, пересекаются ли юзеры с индексом i и i+1.
2.1. Если пересекаются – объединить и сделать ячейкой №1.
2.2. Если не пересекаются, инкрементировать индекс.
3. Повторять с шага 1 пока не достигнут последний индекс.

for (int i = 0; i < groups.size() - 1; ) {
	if (isInersected(groups[i], groups[i+1])) {
		groups[i].addUsersToGroup(groups[i+1]);
		groups.remove(i+1);
	} else {
		++i;
	}
}

Но у этого алгоритма есть проблема с UX:

Он объединяет всех юзеров воедино, если те достаточно близки изначально, что приводит к нерациональному использованию пространства, а значит — алгоритм не подходит по UX.

3.3.4. Алгоритм №2

Шаги:
0. i = 0.
1. Проверить, пересекаются юзеры с индексом i и i+1.
2.1. Если пересекаются – объединить, и записать в первую ячейку. Индекс инкрементируется на 1.
2.2. Если не пересекаются, индекс инкрементируется на 2.
3. Если не достигнут последний индекс, повторить шаг 1.
4. Если i == 1 и не нашлось пересекающихся групп, то закончить алгоритм.
5. Повторить с шага 0, инвертировав i (с 0 на 1 или с 1 на 0 – смена на нечетный или четный проходы).

bool didIntersected, isEvenPass = false;
do {
	didIntersected = false;
	isEvenPass = !isEvenPass;
	int i = isEvenPass ? 0 : 1;
	
	while (i < (groups.size() - 1)) {
		if (isInersected(groups[i], groups[i+1)) {
			didIntersected = true;
			groups[i].addUsersToGroup(groups[i+1]);
			groups.remove(i+1);
			i += 1;
		} else {
			i += 2;
		}
	}
} while(isEvenPass || didIntersected);

Алгоритм решает предыдущую проблему, но появляется новая, связанная с неправильным разъединением после объединения (из-за иной скорости зума). Такую проблему я называю «проблема 21–12» (название поясню позже):

Объясню, что здесь произошло. При запуске алгоритма, было выявлено, что 1 и 2 юзеры пересекаются и образуют группу. С их группой пересекается 3ий юзер,

© Habrahabr.ru