Что больше всего жрет батарейку?

[wtd]

Вертикальную и горизонтальную оптимизацию делают уже почти в конце разработки. А не в начале.

гнать быдлокодеров ссатыми тряпками, ибо некоторые быдлорешения проще бывает переписать заново чем доработать.
оптимизация по энергопотреблению может быть смехотворна по сравнению со всеми остальными "потребителями".
насколько сложный код планируется? ибо висеть в сети - это одно. передавать данные - несколько другое. А грызть числа - уже третье. Тут должен встать вопрос по эффективному коду на предмет вычислений.
Когда сдавал трехмерку (это геометрия такая графическая) то путём несложных оптимизаций из быдлокода делал конфекту - рендер картинки или >30 секунд, или 2-3... Так что вопрос алгоритмической обработки данных и оптимизиции кода всё же первичен.
Мой смарт сейчас по производительности почти что равен настольнику (ядер точно в два раза больше) с которого пишу сейчас... %-)

[voldyr]

По процам: зависит разрядность,число ядер,разгон.

[Кувалдыч ТС]

быдлокодеров ссатыми тряпками, ибо некоторые быдлорешения

Программисты не принимают решений. Они занимаются реализацией.
Быдлорешения принимаю я.

Еще раз говорю - кода еще нет. Соотвесвенно до фазы его оптимизации еще очень далеко.
Сейчас идет речь об архитектуре решения.

Потому что если быдлокодить, то и получится как ты говоришь - проще переписать. А это нафиг никому не нужно. Это все стоит огромных денег и времени. Поэтому работать надо правильно. Сначала проектирование. Потом разработка. Потом оптимизация и тестирование.

Мой смарт

У меня так же. И что?

Так что вопрос алгоритмической обработки данных и оптимизиции кода всё же первичен.

Вторичен. По моему ты просто не видешь разницы между понятиеями проектирование и оптимизация.

[mike]

так что платформа не так важна.

Важна и ещё как важна. Потреблением ликстричесва процом заведует далеко не приложение, имхо. Если есть возможность принудительно кирпич уводить в Powersave, то это надо делать в первую очередь.

При переносе вычислительных дел на сервера - разгружаем процессоры устройств, но интенсивно нагружаем связь.

Не верно. Клиент, на сколька я понял, должен получать данные. Готовые данные. Вся его задача, как клиента, должна сводиться к растеризации/представлению их перед глазыньками пользователя. Вот на этом этапе должны об экономии позаботиться програмеры.
С точки зрения сетвого стека - имеет смысл жать трафик, отдаваемый клиенту. Но только без фанатизма, что бы клиентская часть не тратила туеву часть ресурсов на его преобразование для приложения. Тут нужен метод научного тыка и сбор с неё статистики.

[wtd]

У меня так же. И что?

а то, что настольный ПК при этом сжирает электричества в десятки если не сотни раз больше.

Поэтому работать надо правильно. Сначала проектирование. Потом разработка. Потом оптимизация и тестирование.

Пока проектируешь одну ветку - вторая может получить очень энергичное развитие.
Но вот развитие сетей связи пока что идёт несравненно более медленными темпами.
Так что оптимизация трафика, мне кажется - тут пустое. Пусть на мобильных станциях считает. Насколько ресурсоёмкая то задача? может там арифметика начальной школы...

[Кувалдыч ТС]

Вот на этом этапе должны об экономии позаботиться програмеры.

Не. Об этом заботятся архитекторы. 99% эффективности кроется именно в архитектуре програмной системы. А программеры уже свой 1% отрабатывают, чтобы он из начального скетчка превратился в продукт кторый работает так, как расчитали архитекторы, а не тупит.

Клиент, на сколька я понял, должен получать данные. Готовые данные.

И получать и отправлять. И вот как раз типы и объемы данных, их потоки и определяет архитектура.

имеет смысл жать трафик

Это вопросы вертикального масштабирования. До них еще далеко очень. По вертикальному и горизонтальному масштабированию у нас и так уже польшой опыт, тут мы умеем все. Поэтому и вопросов не возникает.

А вот мобильные клиенты как основной потребитель - это да... тут специфика в слабости этих терминалов. Соотвесвенно и орхитектура тонкого киента сильно отличается для того же тонкого, только десктопного. У десктопного мощей больше во всех отношениях.

Пусть на мобильных станциях считает

Ду ж не считает... валится

Насколько ресурсоёмкая то задача? может там арифметика начальной школы...

Да, начальная школа, это точно

ГИС-система. Пользователь должен работать с векторной графикой - геометрий объектов. Гэлакси С4 валится при загрузке порядка 100 геометрий

[mike]

программеры уже свой 1% отрабатывают

Дык программер тоже человек. Вот напишет что-нибудь подобное SELECT * FROM и можно быть в крепком пападосе. Качество кода штука архиважная. Но об этом толковать пока ещё рано, как ты говоришь.

[Кувалдыч ТС]

Качество кода штука архиважная.

Поэтому у нас как и положено целый штат тестировщиков есть

[OVA]

На планшетах Android?
Поставь на тестовые планшеты Battery Doctor и поработают пусть тестеры. Battery Doctor всю статистику по энергопотреблению по приложениям сформирует.

[Кувалдыч ТС]

Мне не по приложениям надо, а по аппаратным модулям....

[OVA]

При переносе вычислительных дел на сервера - разгружаем процессоры устройств, но интенсивно нагружаем связь.

Че-то тут не так. С каких это пор перенос бизнес-логики на сервер стал нагружать связь?

[OVA]

В Свойствах-Об устройстве - Расход заряда
разве не показательно распределение потребление питания по железу?

[voldyr]

Мне не по приложениям надо, а по аппаратным модулям....

Модули связи и жирут,да и программно при подключении ВиФи отключается G

[Кувалдыч ТС]

С каких это пор перенос бизнес-логики на сервер стал нагружать связь?

C тех пор, как появились мобильные устройства.
Если бизнес-логика обрабатывается локально в клиенте - связь с сервером не нужна.
Если на сервере - то используется канал связи для взаимодействия с API сервера.

разве не показательно распределение потребление питания по железу?

там такого скриншота не нашел... только скинот с приложениями...

[voldyr]

Помнится ещё с обычных телефонов,забыл выключить Блюпуп,все хана батарейки :-)