Нельзя, т.к. некоторые директивы напрямую вносят эти проверки. Но можно написать срезы, которые не порождают эти проверки :) В основном, проверки вставляются туда, где нет возможность статически выявить типы и приходится эту функцию переносить в рантайм. Например, проверки аннотаций над аргументами/методом/классом чаще всего разрешаются в рантайме, если описывать их в срезе. Это можно обойти, если использовать механизмы маркировки и расширения дерева родителей класса.
NonNull-проверки действительно очень быстро работают и не замедляют основное выполнение. Я имел в виду более сложные вещи: директивы cflow/cflowbelow и динамическая директива if(expr), которая в рантайме выполняется на каждом джоинпоинте.
Но можно выстрелить в ногу еще более изощрённо. Например, написать срез, в область видимости которого попадает каждый метод каждого класса и уже внутри джоинпоинтов выполняются runtime-проверки на наличие аннотаций над методами. В таком сценарии время выполнения методов будет сильно провисать.
К слову, на последних версиях андроида уже нет JIT'a. Среда выполнения ART прекомпилирует код приложения при установке и, поэтому, никаких дополнительных оптимизаций уже не будет в процессе выполнения.
Насчёт приватного доступа вы правы, я что-то напутал :)
Тем не менее, это синтаксический сахар в своём чистом виде — по сути, обычные статические методы, которые первым аргументом принимают целевой класс. Без статического импорта нужного метода/поля эти экстенды работать не будут и в целевом классе не появятся :)
Экстенды методов и полей не вставляются в целевой класс, а значит это именно «синтаксический сахар». Но они связывают код конкретного класса (и дают доступ к приватным полям/методам) и самой программы — а это аспектный подход. :)
Эта часть описывает взаимодействия с кодом на уровне команд компилятору. Другими словами, AspectJ позволяет описывать правила вхождений/исключений каких-либо директив в java-исходниках и компилятор будет ругаться при сборке проекта, если эти правила были нарушены разработчиком :)
При этом, компилятор не просто смотрит на код, как на текст, а так же анализирует контекст класса/объекта, области видимости и вызова методов, обработку ошибок. И также позволяет настраивать порядок внедрения инъекций :)
Для тех, кому лень читать или не понятны какие-либо магические штуки, о которых я рассказываю — можно послушать и посмотреть мой доклад в Яндексе на Droid Party, где я подробно рассказываю материал этой статьи :)
На данный момент плагин поддержки AspectJ выжимает менее 10 секунд на полную компиляцию и внедрение инъекций в java-код довольно большого проекта. Мне кажется, проблем с этим быть не должно :)
Кстати, он не должен мёржить ресурсы из других флаворов. Только из тех, вариант сборки которых выбран.
Но если говорить о произвольной выборке в пределах выбранного варианта, то Вы забываете про lint проверки. Некоторые проблемы с ресурсами выяляются только на этапе сборки. Это и отсутствие переводов строк, и коллизии/баги с 9патч. Представьте себе обработку 10-20 языков, по 2-5 тысяч записей в каждом, в фоне во время основной работы с проектом. Могу ошибаться, но по-моему логичнее незначительно увеличить время сборки, но убедиться в корректности всех ресурсов.
Не обязательно. Можно сделать через flavor dimensions. Например, есть дименшен device: phone, tablet, wear; и есть дименшен environment: production, develop, marketing. На выходе получаем device.count * environment.count * buildType.count вариантов (18 вариантов сборки).
В предыдущем проекте пришёл к выводу, что получается очень удобно если просто вынести все метрики и аналитики в отдельный флавор. Таким образом, в дев-версию сборки, где не нужен крашлитикс и аналитика, соответствующие зависимости даже не попадут в classpath.
Для этого:
Могу в пример привести задачу включения в проекте метрик (Google Analytics, Fabric, etc.). Каждая аналитическая библиотека подключена и описана в отдельном Java-классе, а внедряется во множество точек приложения через аспектный класс :) Получается удобная структура и не надо искать по всему приложению или модулю эти срезы :) Подход такой же, как в случае написания провайдера, но исходное приложение полностью свободно от лишнего кода.
Но можно выстрелить в ногу еще более изощрённо. Например, написать срез, в область видимости которого попадает каждый метод каждого класса и уже внутри джоинпоинтов выполняются runtime-проверки на наличие аннотаций над методами. В таком сценарии время выполнения методов будет сильно провисать.
К слову, на последних версиях андроида уже нет JIT'a. Среда выполнения ART прекомпилирует код приложения при установке и, поэтому, никаких дополнительных оптимизаций уже не будет в процессе выполнения.
Тем не менее, это синтаксический сахар в своём чистом виде — по сути, обычные статические методы, которые первым аргументом принимают целевой класс. Без статического импорта нужного метода/поля эти экстенды работать не будут и в целевом классе не появятся :)
При этом, компилятор не просто смотрит на код, как на текст, а так же анализирует контекст класса/объекта, области видимости и вызова методов, обработку ошибок. И также позволяет настраивать порядок внедрения инъекций :)
Но если говорить о произвольной выборке в пределах выбранного варианта, то Вы забываете про lint проверки. Некоторые проблемы с ресурсами выяляются только на этапе сборки. Это и отсутствие переводов строк, и коллизии/баги с 9патч. Представьте себе обработку 10-20 языков, по 2-5 тысяч записей в каждом, в фоне во время основной работы с проектом. Могу ошибаться, но по-моему логичнее незначительно увеличить время сборки, но убедиться в корректности всех ресурсов.
В предыдущем проекте пришёл к выводу, что получается очень удобно если просто вынести все метрики и аналитики в отдельный флавор. Таким образом, в дев-версию сборки, где не нужен крашлитикс и аналитика, соответствующие зависимости даже не попадут в classpath.
Для этого:
За jitpack.io спасибо — обязательно гляну и займусь :)