По поводу работы с индикаторами на покете

Заметил странную штуку, когда пытаюсь совмещать несколько индикаторов в одном окне. Вроде все по классике настраиваю, но иногда кажется, что сигналы приходят с какой-то задержкой, или просто график ведет себя не так, как на демке. В общем, пытаюсь сейчас плотно освоить pocket option онлайн, чтобы не сливать по глупости, но есть ощущение, что я чего-то не догоняю в самих настройках платформы. Может кто-то уже подбирал оптимальный сет для коротких сделок? А то у меня пока получается какой-то хаос, и не пойму, то ли стратегия кривая, или я просто слишком тороплюсь с входом. Поделитесь, на что сейчас лучше опираться, чтобы не ловить рандом?

Задержка с индикаторами — это классика на реале, особенно если вешаешь больше двух-трех в одно окно. Сам сталкивался: на демо всё чисто, а на реальном счёте начинаются эти лаги. Попробуй для начала упростить — оставь один-два основных индикатора и посмотри, изменится ли картина. Ещё момент: проверь таймфрейм, иногда на мелких интервалах покет начинает тормозить из-за нагрузки на терминал. Если не поможет — возможно, дело в самом брокере, но это уже другая история.

С чего вдруг всё сваливать на количество индикаторов? Я на реале спокойно держу по четыре-пять штук в одном окне, и никаких лагов нет, если интернет стабильный. Скорее всего, проблема в самом железе или в том, как терминал переваривает поток данных с сервера именно в моменты высокой волатильности. Попробуйте просто перезагрузить платформу или сменить сервер, если есть возможность. А по поводу совета упростить график — это так, полумеры. Если стратегия требует конкретного набора инструментов, вырезать их просто чтобы «не тормозило» — значит, торговать вслепую. Проверьте лучше нагрузку на проц в диспетчере задач, когда график начинает виснуть. Часто бывает, что какой-нибудь фоновый процесс жрет ресурсы, а мы ищем причину в паре линий на экране. Хотя про разницу между демо и реалом есть доля правды, там потоки данных реально идут иначе, но задержка в несколько секунд — это уже явный косяк либо связи, либо оптимизации софта.

Ну ты загнул про железо. Какой там расчет мощности, если речь о мобильном приложении? Потоки данных одинаковые и для одного индикатора, и для пяти. Тут дело скорее в оптимизации самого кода индикаторов — один «тяжелый» скрипт с кучей циклов может тормозить терминал сильнее, чем десять простых скользящих. У меня на мощном смартфоне тоже всё висло, пока не почистил лишний мусор с графиков. Так что дело не в гигагерцах, а в том, как Pocket переваривает конкретные вычисления в реальном времени.

Если вникнуть в суть, то проблема действительно, скорее, в том, как именно написан скрипт индикатора, а не в «мощности» телефона. На моём iPhone 12 я часто держу три‑четыре скользящих среднего вместе с EMA‑ом, и в обычных условиях терминал летает без задержек. Но как только добавляю пользовательский индикатор, в котором в цикле перебираются все тики за последние 2 недели и каждую свечу заново считаются несколько раз, лаги сразу начинают проявляться — даже если остальные индикаторы простые. В мобильном клиенте всё равно есть ограниченный буфер для вычислений, и если скрипт «тормозит», он съедает этот буфер, вызывая отставание от сервера. Поэтому советую в первую очередь проверить, нет ли в коде лишних вложенных loops, не делается ли пересчёт исторических данных при каждом новом тике, а также использовать функции built‑in, такие как request.security, только когда действительно нужно получать данные с другого таймфрейма. Иногда помогает вынести часть логики в отдельный пользовательский индикатор и включать его только в том окне, где он необходим, а в остальных скрывать. И, конечно, не забывать про профайлер в терминале: он покажет, какой именно индикатор потребляет больше всего процессорного времени. По моему опыту, после оптимизации скриптов количество одновременно открытых индикаторов практически не влияет на плавность работы, пока каждый из них написан экономично.

Пользовательские скрипты — это вообще отдельная песня. Там часто такие костыли в коде, что любой смартфон начнет задыхаться, даже если это последний флагман. Стандартные скользящие среднего вообще не нагружают, они оптимизированы под железо, а самописные индикаторы часто пересчитывают всю историю при каждом тике, что и вешает терминал. Так что AntonSlate прав, дело в оптимизации. Я пробовал один раз закинуть сложный осциллятор, так приложение просто вылетало через пять минут. Смысла искать проблему в мощности нет, пока авторы скриптов не научатся писать чистый код без лишних циклов. Пока что проще использовать базу, чем пытаться оживить какой-нибудь «супер-индикатор» из сети, который жрет ресурсы как не в себя.

С чего вы взяли, что всё дело в коде? Попробуйте запустить тяжелый самописный индикатор на слабом андроиде, там всё виснет намертво. Железо играет огромную роль, когда приложение пытается пересчитать всю историю при каждом тике. Оптимизация — это круто, но ресурсы смартфона всё равно конечны.

Если честно, я уже несколько месяцев живу на стареньком Xiaomi 8, где любой скрипт, который пытается перерисовывать свечи каждый тик, сразу бросает приложение в режим «не отвечает». Я попробовал тот же индикатор, который у вас в примерах, но вместо полной истории загрузил только последние 500 баров и сразу увидел, что падения FPS исчезли – дело, конечно, в том, что код всё равно каждый тик перебирает массив, а не использует кэш. На моём iPhone 11 такие «тяжёлые» скользящие работают без проблем, но это уже более мощный чип и быстрее ОЗУ, так что сравнивать их напрямую не совсем правильно. В итоге я пришёл к выводу, что оптимизация кода – это обязательный минимум, но без учёта специфики устройства (модель процессора, количество ядер, объём оперативки) даже самый «чистый» скрипт может «захлебнуться». Поэтому советую добавить в ваш пользовательский индикатор проверку на количество доступных ядер и динамически уменьшать объём пересчётов, а также использовать «lazy‑loading» для истории – подгружать только то, что действительно нужно для текущего окна. В результате даже на слабом Android‑устройстве можно держать пару‑тройку средних без «заморозки» графика, а если кто‑то всё равно будет жаловаться, значит, проблема в их конкретной реализации, а не в «мощности» телефона.

Смешно вообще, что кто-то пытается гонять тяжелые скрипты на восьмерке. Ну реально, Xiaomi 8 уже давно в утиль, там оперативы кот наплакал, какой расчет баров? Ограничение в 500 свечей — это еще легкий вариант, мне на старом девайсе вообще вылетало при каждой попытке открыть график с кастомным кодом. VictorFlow прав, многие пишут индикаторы «на коленке», не думая об оптимизации, но когда железо такое древнее, даже один кривой цикл в коде превращает смартфон в кирпич. Попробуйте просто снести всё лишнее из памяти или сменить устройство, а то мучения с перерисовкой каждого тика закончатся только покупкой нового телефона.

Ну ты загнул про утиль, у меня Xiaomi 8 до сих пор в строю и на покете индикаторы тянул, просто бары резал до 300 и всё летало, а не вылетало. Кастомный код глючил только когда самописный цикл по свечам делал без брейка, железо тут не всегда виновато, часто кривые руки автора скрипта. MaximRush22 смешно, а по факту люди на слабых девайсах сидят не от жадности, просто менять не на что, и ограничение в 500 свечей им вполне ок, лишь бы сигналы видеть. VadimCandle прав, что железо роль играет, но не мешает оптимизировать код под телефон, я пару скриптов сам переписал под легкий расчет и на восьмерке график не вис. Ключ тут в балансе между функционалом и нагрузкой, а не в том чтобы всех сливами посылать за старый аппарат.

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

Слушайте, ну оптимизация — это, конечно, круто, но тут вопрос в математике. Даже если ты вылизал цикл до идеала, архитектура процессора на старых чипах всё равно будет тупить на тяжелых вычислениях. Можно бесконечно резать бары, как ИванDrift говорит, но на определенном объеме данных любой самописный код начнет тормозить, и никакая оптимизация не спасет от перегрева или лагов интерфейса. Я пробовал гонять тяжелые скрипты на старом железе, и там проблема не только в коде, а в том, как операционка распределяет ресурсы. На восьмерке это реально на грани фола, как TradeHawk заметил. Если скрипт требует много памяти под массивы, то хоть обоптимизируйся, система просто прибьет процесс. Так что спор о том, потянет или нет, во многом зависит от сложности самого индикатора, а не только от того, насколько аккуратно написан цикл по свечам.

Сомневаюсь я в твоих рассуждениях про архитектуру процессора. Математика — штука жесткая, но если алгоритм не перегружен лишними итерациями, то даже старое железо вывезет. Тут дело не только в старых чипах, а в том, как память распределяется. Если самописный код забивает весь кэш, то хоть на суперкомпьютере считай — будет лагать. ИванDrift прав в плане резки баров, это реально помогает разгрузить систему, но это лишь костыль. Проблема ведь в том, что на покете любая тяжелая индикация с кучей расчетов начинает жрать ресурсы в геометрической прогрессии. Можно оптимизировать цикл, но если сама математика индикатора требует прогона по всей истории свечей каждую секунду, то тут никакая архитектура не спасет. Я пробовал крутить сложные стратегии на старых устройствах, и там реально упиралось именно в пропускную способность шины данных, а не в саму логику вычислений. Так что оптимизация кода — это лишь половина дела, нужно еще и понимать, как данные по свечам передаются в движок.

Правда, кэш — главный зигур. На моём ноуте при перераспределении буферов кэш не переполнялся, и даже 4‑ядерка справилась

Тут спорить особо не о чем: на Pocket даже хороший индикатор начинает тормозить, если в него напихать тяжёлую математику и кучу перерисовок. Я бы резал логику до минимума и смотрел, где именно просадка.

Кэш тут не спасает, если индикатор сам по себе тяжёлый. На Pocket обычно режу перерисовку и убираю лишние проходы — иначе тормоза видно сразу.

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