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

Заметил странную штуку, когда пытаюсь совмещать несколько индикаторов в одном окне. Вроде все по классике настраиваю, но иногда кажется, что сигналы приходят с какой-то задержкой, или просто график ведет себя не так, как на демке. В общем, пытаюсь сейчас плотно освоить 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 прав, многие пишут индикаторы «на коленке», не думая об оптимизации, но когда железо такое древнее, даже один кривой цикл в коде превращает смартфон в кирпич. Попробуйте просто снести всё лишнее из памяти или сменить устройство, а то мучения с перерисовкой каждого тика закончатся только покупкой нового телефона.