История изменений

Частично это обусловено тем, что у Android достаточно специфический API, плюс иногда частично ломаемый между некоторыми версиями, так что автор сколько-нибудь сложного приложения обмазывается прослойками совместимости и фреймворками лишь бы не реализовывать фичи руками. Прослойки же очень универсальные и содержат в себе не только то что нужно конкретному приложению, поэтому жрут ОЗУ и ЦПУ.

Крч как графические тулкиты для Linux. На Windows можно написать приложение использующее только системные библиотеки и которое будет иметь развитый UI и мало весить и работать от Windows 95 до Windows 11. Для Linux сколько-нибудь сложное приложение нуждается в тяжёлых Qt/Gtk, либо их самописным аналоге (который могут позволить себе написать не только лишь все). Потому что на голом xlib/wayland сложный интерфейс не сделаешь. Только вот на Linux есть пакетный менеджер, а на Android все приложения должны все свои библиотеки носить с собой.

Также есть вопрос кроссплатформенности. Ибо у Android и iOS +- сравнимые доли рынка, так что по-хорошему надо разрабатывать под обе платформы. Но при этом платформы отличаются сильнее, чем Windows от Linux. И тут опять же на помощь приходят всякие фреймворки. Нет денег разработать два полностью разных приложения? Возьми Flutter/React Native. Разумеется, такая толстая прослойка не будет бесплатной.

Короче, если бы на рынке мобильных ОС был один доминатор и если бы у него было вменяемое стабильное API, то, возможно, приложения бы жрали меньше.

Но это только часть проблемы, да. Техническая. Есть ещё эффективные менеджеры «мы должны создать свою экосистему», тут проблема уже не в технологиях, а в головах. Но, к счастью, этим грешат в основном крупные игроки. И на конкретном телефоне «экосистемные» приложения можно пересчитать по пальцам. И да, лучше бы их распиливали на несколько приложений, умеющих общаться друг с другом. Но нет.

Частично это обусловено тем, что у Android достаточно специфический API, плюс иногда частично ломаемый между некоторыми версиями, так что автор сколько-нибудь сложного приложения обмазывается прослойками совместимости и фреймворками лишь бы не реализовывать фичи руками. Прослойки же очень универсальные и содержат в себе не только то что нужно конкретному приложению, поэтому жрут ОЗУ и ЦПУ.

Крч как графические тулкиты для Linux. На Windows можно написать приложение использующее только системные библиотеки и которое будет иметь развитый UI и мало весить и работать от Windows 95 до Windows 11. Для Linux сколько-нибудь сложное приложение нуждается в тяжёлых Qt/Gtk, либо их самописным аналоге (который могут позволить себе написать не только лишь все). Потому что на голом xlib/wayland сложный интерфейс не сделаешь. Только вот на Linux есть пакетный менеджер, а на Android все приложения должны все свои библиотеки носить с собой.

Также есть вопрос кроссплатформенности. Ибо у Android и iOS +- сравнимые доли рынка, так что по-хорошему надо разрабатывать под обе платформы. Но при этом платформы отличаются сильнее, чем Windows от Linux. И тут опять же на помощь приходят всякие фреймворки. Нет денег разработать два полностью разных приложения? Возьми Flutter/React Native. Разумеется, такая толстая прослойка не будет бесплатной.

Короче, если бы на рынке мобильных ОС был один доминатор и если бы у него было вменяемое стабильное API, то, возможно, приложения бы жрали меньше.

Но это только часть проблемы, да. Техническая. Есть ещё эффективные менеджеры «мы должны создать свою экосистему», тут проблема уже не в технологиях, а в головах. Но, к счастью, этим грешат в основном крупные игроки. И на конкретном телефоне «экосистемные» приложения можно пересчитать по пальцам. И да, лучше бы их распиливали на несколько приложений, умеющих общаться друг с другом.

Частично это обусловено тем, что у Android достаточно специфический API, плюс иногда частично ломаемый между некоторыми версиями, так что автор сколько-нибудь сложного приложения обмазывается прослойками совместимости и фреймворками лишь бы не реализовывать фичи руками. Прослойки же очень универсальные и содержат в себе не только то что нужно конкретному приложению, поэтому жрут ОЗУ и ЦПУ.

Крч как графические тулкиты для Linux. На Windows можно написать приложение использующее только системные библиотеки и которое будет иметь развитый UI и мало весить и работать от Windows 95 до Windows 11. Для Linux сколько-нибудь сложное приложение нуждается в тяжёлых Qt/Gtk, либо их самописным аналоге (который могут позволить себе написать не только лишь все). Потому что на голом xlib/wayland сложный интерфейс не сделаешь. Только вот на Linux есть пакетный менеджер, а на Android все приложения должны все свои библиотеки носить с собой.

Также есть вопрос кроссплатформенности. Ибо у Android и iOS +- сравнимые доли рынка, так что по-хорошему надо разрабатывать под обе платформы. Но при этом платформы отличаются сильнее, чем Windows от Linux. И тут опять же на помощь приходят всякие фреймворки. Нет денег разработать два полностью разных приложения? Возьми Flutter/React Native. Разумеется, такая толстая прослойка не будет бесплатной.

Короче, если бы на рынке мобильных ОС был один доминатор и если бы у него было вменяемое стабильное API, то, возможно, приложения бы жрали меньше.

Но это только часть проблемы, да. Техническая. Есть ещё эффективные менеджеры «мы должны создать свою экосистему», тут проблема уже не в технологиях, а в головах. Но, к счастью, этим грешат в основном крупные игроки. И на конкретном телефоне экосистемные приложения можно пересчитать по пальцам.

Частично это обусловено тем, что у Android достаточно специфический API, плюс иногда частично ломаемый между некоторыми версиями, так что автор сколько-нибудь сложного приложения обмазывается прослойками совместимости и фреймворками лишь бы не реализовывать фичи руками. Прослойки же очень универсальные и содержат в себе не только то что нужно конкретному приложению, поэтому жрут ОЗУ и ЦПУ.

Крч как графические тулкиты для Linux. На Windows можно написать приложение использующее только системные библиотеки и которое будет иметь развитый UI и мало весить и работать от Windows 95 до Windows 11. Для Linux сколько-нибудь сложное приложение нуждается в тяжёлых Qt/Gtk, либо их самописным аналоге (который могут позволить себе написать не только лишь все). Потому что на голом xlib/wayland сложный интерфейс не сделаешь. Только вот на Linux есть пакетный менеджер, а на Android все приложения должны все свои библиотеки носить с собой.

Также есть вопрос кроссплатформенности. Ибо у Android и iOS +- сравнимые доли рынка, так что по-хорошему надо разрабатывать под обе платформы. Но при этом платформы отличаются сильнее, чем Windows от Linux. И тут опять же на помощь приходят всякие фреймворки. Нет денег разработать два полностью разных приложения? Возьми Flutter/React Native. Разумеется, такая толстая прослойка не будет бесплатной.

Короче, если бы на рынке мобильных ОС был один доминатор и если бы у него было вменяемое стабильное API, то, возможно, приложения бы жрали меньше.

Но это только часть проблемы, да. Техническая. Есть ещё эффективные менеджеры «мы должны создать свою экосистему», тут проблема уже не в технологиях, а в головах. Но, к счастью, этим грешат в основном крупные игроки.