Обзор приложений для тонкой настройки android-устройств: 3C Toolbox (страница 6)
Вкладка «Приложения» сама говорит за себя. Можно очистить кэш всех приложений, а также обновить их данные. Если выбрать отдельную программу, то функционал значительно расширяется. Например, можно посмотреть разрешения, сделать бэкап отдельного приложения, принудительно назначить ориентацию, защитить от случайного удаления, заморозить, очистить данные и просто удалить. При этом абсолютно любое приложение можно переместить на SD-карту, а сама разрешения можно как заблокировать по отдельности, так и разрешить.
Что немаловажно – прописываются все разрешения, то есть те, что в Google Play не озвучены, или их смысл раскрыт не полностью. Честь и хвала разработчикам за это!
реклама
При этом для каждого приложения можно посмотреть его активность, то есть узнать, куда программа обращается, каких провайдеров использует, на что влияет и от чего зависит. При этом можно увидеть задействованный сервис и убить его, то есть приложение находится под вашим контролем. Главное – это знать, что делаешь, а не пользоваться методом научного тыка.
В случае с Clean Master – все плохо, ведь программа пустила свои корни везде, где можно и где нельзя. Отсюда и жалобы на то, что CM стал больше грузить систему, чем оптимизировать.
Завершающая вкладка – «бэкапы». Здесь собственно находятся все резервные копии. Также организована сортировка, где мы можем посмотреть только системные «бэкапы», «бэкапы» отдельные приложений и т.д.
реклама
Менеджер АКБ и твики CPU мы рассмотрели выше, когда описывали быстрое управление процессором и аккумулятором, поэтому воду лить не будем, а обратимся сразу к менеджеру сетей.
Итак, для нас доступна общая сводка, то есть скорость приема/передачи данных, уровень сигнала и максимальная скорость 2G|3G или Wi-Fi, а также график работы сети в реальном времени.
Следующая вкладка открывает детали подключения. Здесь смотрим IP, TCPv6 и прочее. Далее устанавливаем приоритет Wi-Fi или вовсе блокируем это подключение.
Предусмотрен собственный брандмауэр, который блокирует той или иной программе или процессу коннект с Интернет. При этом легко блокируется брандмауэр того же антивируса или системного медиа-сервера. При желании можно рубануть сеть основательно и никто без вашего ведома ничего не сделает, что радует.
Предусмотрено и изменение DNS, то есть можно вручную отдельно прописать DNS для Wi-Fi и 3G|2G-подключения. Для чего нужно это иногда делать думаем объяснять не надо.
Также есть возможность настроить алгоритм TCP IPv4, которые регулирует перегрузки с отдачей и загрузкой, то есть влияет на пропускную способность по разному. Доступно два алгоритма: reno и cubic.
Если кратко, это алгоритмы, которые пытаются сделать все возможное, чтобы обеспечить наиболее быструю скорость передачи данных между двумя узлами, передающими данные через TCP. Они управляют размером TCP-окна и могут ориентироваться на RTT (Round Trip Time — время от отправки запроса до получения ответа), потерю пакетов, время ожидания отправки пакета из очереди и т.д. Каждый алгоритм по разному ведет себя в той или иной ситуации и нет какого-то универсального.
реклама
Долгое время, в ходу были алгоритмы Reno, разработанный в 1990 году, и BIC. Первый применялся во всех ОС Windows до XP, а второй — в Linux до 2.6.18. Затем в Windows Vista появился новый алгоритм Compound TCP, а в Linux сменили BIC на Cubic. К сожалению cubic совершенно не подходит, например, для 3G-соединений. В то же время, он лидирует в скорости передачи данных за единицу времени.
В общем, выбираем алгоритм и тестим на том же торренте. В нашем случае для Wi-Fi cubic показал себя стабильней.
Здесь, прежде всего, настраиваем энтропию, то есть ускоряем отзывчивость устройства и ускоряем запуск программ. При этом, чтобы не мучаться с ползунком, предусмотрены четыре предустановки порога чтения/записи энтропии: маленький, средний, большой и очень большой. Сама программа использует пассивный метод для настройки ядра.
На тестовом «бюджетнике» уровень доступной энтропии не превышал 4% при размере пула в 4096 единиц. Естественно, что методом проб и ошибок этот показатель может быть значительно увеличен.
реклама
Оптимизация системы также реализовано очень серьезно. При этом можно оптимизировать все одним нажатием. Например для прошивки можно оптимизировать лаунчер, энергосбережение, отзывчивость. Для ядра – только энергосбережение, отзывчивость и т.д.
Если что-то пошло не так, но вы не уверены, что именно, можно сбросить все настройки по умолчанию. Здесь же можно создать CWM/TWRP-пакет для сброса всех твиков. Для тех, кому и этого мало, предусмотрена возможность воспользоваться одексом/деодексом ROM.
реклама
В следующей вкладке редактируем «.build.prop». Благоразумно в нижнем сайдбаре для этого предусмотрен «бэкап», который стоит сделать перед тем, как ковыряться в «давликах» и «провайдерах». Также здесь можно добавить свои ключи и выбрать предустановки, например, отключить уведомления отладки USB, анимацию при загрузке или вовсе изменить название устройства.
Сразу оговоримся, что баловаться с «.build.prop» не стоит, и не забывайте про «бэкап».
реклама
Для тех, кто не знает, для чего нужно копаться в «sysctl», приведем понятную цитату из Wiki. «sysctl — в BSD и Linux — команда, предназначенная для управления параметрами ядра на лету. Позволяет читать и изменять параметры ядра. Например — такие параметры как размер сегмента разделяемой памяти, ограничение на число запущенных процессов, а также включать функции наподобие маршрутизации».
Здесь мы ничего трогать не стали, поскольку этому разделу настроек можно посвятить отдельную статью, что мы и сделаем, если вы этого захотите.
Источник
Работа с сетью в Android: трафик, безопасность и батарейка
На сегодняшний день в Google Play насчитывается более 800 тысяч приложений. Многие из них реализованы на основе клиент-серверного общения. При разработке таких приложений нужно учесть три основных момента, о которых пойдет речь в этой статье.
О чем нужно помнить при реализации сетевой части приложения
Первое – это трафик. Не всегда есть возможность работать по бесплатному Wi-Fi-соединению, а мобильный интернет всё еще дорогой, и об этом нужно помнить, потому что трафик – это деньги пользователя.
Второе – это лимит батарейки. Мобильные устройства необходимы пользователю для каких-то повседневных дел, совещаний, прогулок, бизнеса, и когда батарейка садится в самый неподходящий момент, пользователь негодует.
Третье – это безопасность. Так как все-таки речь идет о мобильных клиентах, и данные гуляют по сети от клиента к серверу и обратно, то их необходимо защищать.
Подходы по реализации сетевого взаимодействия
Для начала вспомним, какие способы реализации клиент-серверного общения существуют и популярны на сегодняшний день.
Первый подход — на основе сокетов (здесь я имею в виду работу непосредственно с Socket API). Он часто используется в приложениях, где важна скорость доставки сообщения, важен порядок доставки сообщений и необходимо держать стабильное соединение с сервером. Такой способ зачастую реализуется в мессенджерах и играх.
Второй подход — это частые опросы (polling): клиент посылает запрос на сервер и говорит ему: «Дай мне свежие данные»; сервер отвечает на запрос клиента и отдает все, что у него накопилось к этому моменту.
Минус такого подхода в том, что клиент не знает, появились ли свежие данные на сервере. По сети лишний раз гоняется трафик, в первую очередь из-за частых установок соединений с сервером.
Третий подход — длинные опросы (long polling) — заключается в том, что клиент посылает «ожидающий» запрос на сервер. Сервер смотрит, есть ли свежие данные для клиента, если их нет, то он держит соединение с клиентом до тех пор, пока эти данные не появятся. Как только данные появились, он «пушит» их обратно клиенту. Клиент, получив данные от сервера, тут же посылает следующий «ожидающий» запрос и т.д.
Реализация этого подхода достаточно сложна на мобильном клиенте в первую очередь из-за нестабильности мобильного соединения. Зато при этом подходе трафика расходуется меньше, чем при обычном polling’e, т.к. сокращается количество установок соединений с сервером.
Механизм long polling, или пуш-уведомлений (push notifications), реализован в самой платформе Android. И, наверное, для большинства задач будет лучше использовать его, а не реализовывать самим. Ваше приложение подписывается у сервиса Google Cloud Messaging (GCM) на получение пуш-уведомлений.
Тем самым разрывается связь непосредственно между сервером и клиентом за счет того, что сервер работает с сервисом GCM и отправляет свежие данные всегда на этот сервис, а он уже в свою очередь реализует всю логику доставки этих данных до вашего приложения. Плюсы этого подхода в том, что устраняется необходимость частых установок соединения с сервером за счет того, что вы точно знаете, что данные появились, и об этом вас оповещает сервис GCM.
Из этих четырех подходов наиболее популярными при разработке бизнес-приложений являются пуш-уведомления и частые опросы. При реализации этих подходов нам так или иначе придется устанавливать соединение с сервером и передавать данные. Далее речь пойдет об инструментах, которые есть в наличии у разработчика для работы по HTTP/HTTPS-протоколам.
HttpUrlConnection и HttpClient
В арсенале Android-разработчика есть два класса для работы по этим протоколам. Первый – это java.net.HttpURLConnection, второй – org.apache.http.client.HttpClient. Обе эти библиотеки включены в Android SDK. Далее будут подробно рассмотрены основные моменты, которые будут влиять на трафик, батарею и безопасность при работе с каждой из этих библиотек.
С HttpURLConnection все просто. Один класс и все. Это объясняется тем, что родительский класс URLConnection был спроектирован для работы не только по HTTP-протоколу, а еще по таким, как file, mailto, ftp и т.п.
HttpClient спроектирован более объектно-ориентированно. В нем есть четкое разделение абстракций. В самом простом случае мы будем работать с пятью разными интерфейсами: HttpRequest, HttpResponse, HttpEntity и HttpContext. Поэтому апачевский клиент намного тяжеловеснее HttpUrlConnection.
Как правило, на все приложение существует всего один экземпляр класса HttpClient. Это обусловлено его тяжеловесностью. Использование отдельного экземпляра на каждый запрос будет расточительным. Мы можем, к примеру, хранить экземпляр HTTP-клиента в наследнике класса Application.
В случае HttpUrlConnection следует создавать на каждый запрос новый экземпляр клиента.
Из чего складывается трафик?
Во время работы нашего приложения картинка будет примерно такая.
Количество и частота запросов будет зависеть от функционала и насыщенности UI – интерфейса приложения. Каждый такой запрос устанавливает TCP-соединение с сервером. В данном случае трафик, который будет потрачен, будет равняться сумме установок соединений и сумме переданных данных. Понизить расход трафика в данном случае можно за счет использования долгоживущего соединения (keep alive).
Основная идея keep alive-соединения заключается в использовании одного и то же TCP-соединения для отправки и приема HTTP-запросов. Главные преимущества — снижение трафика и времени выполнения запроса. Мной был проделан простенький тест, который заключался в том, что выполнялось последовательно 10 запросов на один и тот же хост. Данные представлены в таблице ниже. При выключенном keep alive видно, что среднее время выполнения запроса составляло примерно две секунды. В случае с включенным keep alive это время снизилось до 1,7 секунды, что на 16% быстрее. Это обуславливается в первую очередь тем, что устраняется необходимость частой установки соединения с сервером. При использовании защищенного HTTPS-соединения разница была бы заметнее, т.к. процедура SSL Handshake гораздо тяжелее процедуры TCP Handshake.
Важным параметром keep alive-cоединения является keep alive duration. Он означает временной интервал. Если приходит несколько HTTP-запросов в пределах этого интервала, то будет переиспользоваться уже установленное TCP-соединение.
Из рисунка видно, что время между четвертым и третьим запросом превысило keep alive duration, поэтому создается новое TCP-соединение с сервером.
Давайте посмотрим, как можно настроить вышеописанный параметр. В случае HttpClient все хорошо, в нашем распоряжении есть интерфейс ConnectionKeepAliveStrategy. Переопределив метод getKeepAliveDuration, мы можем вернуть нужное значение параметра keep alive duration.
Работая с HttpUrlConnection, нужно помнить о баге в платформе Android 2.2 и отключать keep alive на платформах = 4.0.3 (API Level 15) должна стоять точка в начале домена
Защищенное соединение (HTTPS)
В завершение данной статьи я рассмотрю, как включить HTTPS в Android. Насколько мне известно, на других мобильных платформах достаточно включить HTTPS-схему, механизм транспорта SSL — и все должно работать. В Android есть некоторые проблемы, которые следует учитывать и решать. Для начала вспомним, как устанавливается защищенное соединение. На проблемное место указывает красная стрелка – это проверка подлинности сертификата.
Источник
