Источником этой проблемы является сама Java, где вы не можете иметь вещи, похожие на #ifdef, и большинство компиляторов не позволяют полностью заменить класс или его часть.
У меня на самом деле есть базовый проект, из которого я строю 6 АПК уже, и еще быстрее.
Каждый APK использует свое собственное имя пакета, однако весь код находится под одним пакетом, но это не создает никаких проблем.
Существует, однако, много проблем: - Все ресурсы, все классы будут в целевых APK, независимо от того, используются они или нет. - Различное поведение означает разный код или разные ресурсы, каждый из которых должен обрабатываться по-разному.
Для ресурсов это «довольно просто», просто замените ресурсы в финальных проектах приложений. Однако неиспользованные ресурсы будут оставлены.
Для классов, где это становится очень сложным.
Чтобы создать немного другое поведение, которое вы можете использовать отражение и интерфейсы, каждый APK реализует собственную версию интерфейса, используя общее имя, например, myActivityPrj, который извлекается с помощью отражения.
Иногда также легче проверить имя пакета APK из кода, поэтому в объекте Application я установил несколько логических значений, которые фактически выполняются APK. Обязательно используйте их только из пользовательского интерфейса, чтобы избежать любого удара производительности.
Чтобы создать совсем другое поведение, например, деятельность не используется в APK, ну, может быть, использовать метод выше и флаг, который доступен или нет, но какая пустая трата пространства внутри APK!
Другим вариантом является разбивка центрального проекта на мелкие кусочки, если это вообще возможно!
Чтобы действительно сделать APK меньше, я нашел только один способ до сих пор: создать проект Java, который будет копировать центральный проект, а затем удалить и/или заменить файлы в этой копии, из удаленного источника дерева (а каталог с именем «замены-файлы», который содержит папку res и src).
Для ресурсов этот Java-проект фактически проанализирует все strings.xml и удалит неиспользуемые строки из жестко запрограммированного списка, не может доверять выходу lint, поскольку некоторые ресурсы используются в подпроектах, а lint не волнует.
До сих пор APK, который включает в себя все функции, составляет около 10 МБ, один вариант составляет около 4 МБ, тогда как он должен быть фактически менее 2 МБ. Другой вариант - около 8 МБ, тогда как он действительно должен быть 2 или 3 МБ. Вышеупомянутый метод чрезмерно усложняется и возможность удаления неиспользуемого кода и ресурсов становится все более сложной.
Я рассмотрел различные другие решения, но все они очень сложны с большим количеством ограничений, ограничений.
После 4 лет разработки на Android, мой единственный вывод заключается в том, что Java является самым бедным выбором для мобильного устройства: медленным, неэффективным, ресурсоемким и очень негибким. Глядя на NDK, он кажется очень неудобным и очень ограниченным.
Android Studio + Gradle кажется слишком сложным, и фактическим источником этой проблемы является сама Java. – 3c71
Я начал использовать Gradle и, как его гибкость. Что я считаю недостатком, так это то, что он немного медленнее даже на моем std-pc. Я не думаю, что сама проблема Java заключается в том, что вам нужно создать базовый класс и извлечь из него его ООП. Они специально отказались от #ifdef. Если у вас возникли проблемы с раздутыми пакетами из-за неиспользуемых компонентов при создании вариантов сборки, попробуйте использовать ProGuard, он оптимизирует неиспользуемые ресурсы и классы. – RookieGuy