Первое, что нужно сделать, это не предполагать, что загрузка пера является узким местом без прямых доказательств того, что это так. Загрузка пера высоко оптимизирована и очень эффективна. Более вероятно, что вашим узким местом является сетевой запрос, а не перья. Используйте инструменты, чтобы получить конкретные данные о том, где приложение тратит свое время, прежде чем что-либо делать.
Если предположить, что это перья, Ответ Andiih лучше всего подходит для профилирования, но для меня это звучит так, будто у вас действительно есть проблема с дизайном.
Похоже, вам нужно разбить большой перо на более мелкие.
Как правило, на перо можно смотреть по одному. Например, предположим, что у вас есть приложение с панелью вкладок с пятью вкладками. Тогда каждая вкладка имела табличное представление, которое открывало бы подробное представление. В обычной настройке у вас будет 11 отдельных перьев. Один кончик будет определять панель вкладок, один кончик для просмотра каждой вкладки, а затем один кончик для подробного просмотра. Когда приложение запускалось, загружались только перо для панели вкладок и первой видимой вкладки, поэтому для запуска вам нужно было загрузить только два из 11 перьев.
Чтобы оптимизировать, первое, что нужно сделать, это разбить его на наименьшие возможные отдельные кончики. Перо загружается только при необходимости. Вы должны разместить функциональность по всему пиру так, чтобы он не загружался, если его вид не отображается сразу.
Перья - это просто легкие файлы данных, поэтому не бойтесь создавать перья, которые на 99% идентичны. Например, я часто использую отдельные виды для каждого портретного и ландшафтного вида. С точки зрения пользователя, это один вид, но у меня есть три отдельных кончика. Я делаю это в тех случаях, когда проще использовать совершенно отдельный вид, чем поворачивать один сложный вид. Каждый кончик загружается, когда используется его ориентация. Если ориентация никогда не меняется, она никогда не загружается.
Если у вас сложный интерфейс, который значительно меняется в зависимости от сетевого запроса, во время выполнения будет быстрее иметь отдельные кончики для каждого варианта, чем объединять все функциональные возможности в один кончик.