Я создал настраиваемое представление и вставил журнал для примерного сравнения производительности.
public class CustomInAppKeyboard extends LinearLayoutCompat {
private static final String TAG = "MyKeyboard";
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
super.onMeasure(widthMeasureSpec, heightMeasureSpec);
if (BuildConfig.DEBUG){
Log.e("CustomInAppKeyboard", "w:" + widthMeasureSpec + " :: " + MeasureSpec.toString(widthMeasureSpec));
Log.e("CustomInAppKeyboard", "h:" + heightMeasureSpec + " :: " + MeasureSpec.toString(heightMeasureSpec));
}
}
public CustomInAppKeyboard(Context context) {
this(context, null, 0);
}
public CustomInAppKeyboard(Context context, AttributeSet attrs) {
this(context, attrs, 0);
}
public CustomInAppKeyboard(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
init(context, attrs);
}
private void init(Context context, AttributeSet attrs) {
LayoutInflater.from(context).inflate(R.layout.keyboard_alphanumeric, this, true);
}
}
затем используя время начала и окончания журналов "MyKeyboard" ... я получаю следующие значения:
Это было основано на этих файлах макетов xml в следующем смысле: - https://gist.github.com/CrandellWS/fc7946ea653cf90828580b3c00d8da57
Итак, как я могу заставить ConstraintLayout отображаться так же быстро, как вложенный LinearLayout? Что я могу сделать по-другому или изменить, чтобы ConstraintLayout более точно соответствовал производительности LinearLayout?
"фактические" файлы раскладки клавиатуры, как известно, отличаются
Обратите внимание, что на моем физическом устройстве https://stackoverflow.com/a/52836747/1815624 невозможно использовать Systrace ... отсюда и элементарный метод тестирования производительности ...





Чтобы ответить на этот вопрос, нам придется сделать обходной путь.
Я предполагаю, что вы читали о том, как ConstraintLayout работает изнутри, поэтому позвольте мне просто придерживаться сути. Да, я согласен с тем, что ConstraintLayout медленнее, чем LinearLayout, но только тогда, когда количество дочерних просмотров меньше.
Когда вы начинаете создавать макеты большего размера, скажем, состоящие из 20-30 представлений, ConstraintLayout вам пригодится. Если вы затем будете использовать LinearLayout или любой другой макет, скажем RelativeLayout, тогда вы в конечном итоге будете использовать несколько дочерних ViewGroups, и ваш график макета может быть таким.
LinearLayout(orientation vertical)
-> SomeChildView (let's say a TextView)
-> LinearLayout (orientation horizontal)
-> ChilView 1 -> ChildView 2
-> ImageView
-> ButtonView
-> ViewGroup (FrameLayout)
-> ImageView1
-> idk, maybe TextView?
И список продолжается.
Теперь, с такой компоновкой, традиционный ViewGroups в конечном итоге будет вычислять большее количество просмотров, чем ConstraintLayout.
Итак, мы можем сделать вывод, что никакая ViewGroup не идеальна !! Мы просто должны использовать их в соответствии с нашими потребностями.
Бонус !!ConstraintLayout следует избегать внутри RecyclerView, потому что он вызывает onMeasure() несколько раз, чем любой другой макет.
Однажды я сделал исследовать на ConstraintLayout, прежде чем применить его в своем проекте.
Это действительно мило с вашей стороны, @CrandellWS, но это то, что я пытаюсь передать, вы не можете настроить ViewGroups. Это просто эффективная реализация ViewGroup, которая делает его «быстрее» по сравнению с другими. Я понимаю, что мой ответ не удовлетворил ваши потребности, я хотел бы получить уведомление, если есть возможность сделать это. :)
ценю вклад, поэтому я проголосовал за вас, но это дает какое-либо решение для повышения производительности, поэтому я не могу принять его в качестве ответа. Благодарность