Или секрет?

Есть

Ссылкой не поделишься? :) Ну или как называется

любопытно жи

чуть позже, я счас занят

через часок мож

Как раз вопрос о UWP. Есть годные ресурсы касательно оптимизации, помимо официальных источников?

гугл

тут зависит, что именно оптимизировать гуглил на прошлой неделе очень долго и упорото про ускорение закрузки страницы xaml, так ничего и не выгуглил

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

в особо запущенных случаях (либо когда лень) тупо пишешь task.delay(150) и пока он ждёт, играешь анимацию уползающего меню )

ну и решает количество элементов в visual tree. <Grid><StackPanel /></Grid> хуже чем просто <StackPanel/>, например

Это понятное дело. Task.Delay? Зачем? Мне конкретно интересно о том, какой элемент управления как отображается, и какой расход ресурсов за собой влечет?

Ну тут уж надо официальные доки смотреть.

Вопрос) какой язык легче php или c# и какой в наше время лучше учить ?)

лучше спроси на чём интереснее работать

Сколько они в каждый контрол всякой хрени полезной понапихали.

Я понял. Ждемс литературу

Ну вот Pivot например. https://msdn.microsoft.com/ru-ru/library/windows/apps/mt299144.aspx Создаётся куча объектов при прогрузке элемента управления, анимаций, вижуал стейтов. И соотв-но работает оно так же НЕРАСТОРОПНО

Тут надо на исходный код каждого контрола смотреть.

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

Это понятное дело. Task.Delay? Зачем? Мне конкретно интересно о том, какой элемент управления как отображается, и какой расход ресурсов за собой влечет?

Ну и отвечая на первый вопрос. Task.Delay используется для SplitView. При навигации на тяжелую страницу сплит меню исчезает без анимации, потому что время, которое могло бы быть затрачено на анимацию, цп тратит на подгрузку страницы. А я делаю хитрее: жду 150мс и играю анимацию в асинхронном потоке, в результате лаг почти ваще не ощущается.

Сомневаюсь, что это лучшее решение)

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

Ууу. Тут вообще гавно у M$. Память тупо утекает. Сценарий такой: есть у тебя приложение с довольно тяжёлыми страницами, которые на экране визуализируют какой-то датасет. И есть меню, в меню 5 таких страниц. Если раз 50-70 тыкнуть на пункты меню (грузануть эти страницы), приложение отожрёт 150 мегов памяти (в теории всю доступную) и рухнет.

Как решить проблему я не нашёл. Решаю как обычно, врубаю обязательный кэш страниц: <Page NavigationCacheMode="Required" /> Здесь оно запрещает создавать новые страницы. Тогда память течь перестаёт.

Привет fait, есть два стула... На одном винформы отточены, на другом XAMLы раскурочены. На какой сам сядешь, на какой братишку-джуниора посадишь?

Кстати, эта утечка воспроизводится даже в дефолтных приложениях, таких, как "Погода" или "Новости".

Можешь поиграться с тыками по меню и посмотреть на течь в диспетчере задач )

Это я уже понял из своего опыта) протестил dotMemory пару приложений из магазина

И как оно? Мусорщик тупо не трёт старые страницы?

Ресурсы нативные

Сборщик мусора не. Net'а собирает ресурсы

Тут бока у WinRT

Так вот оно что

Угу. Тут только доки читать

Я думал может кто-то уже собрал адекватную инфу в статье

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

забавно

мб это кто-то-там что-то набыдлокодил

снимает тип и болтается там куча говна, которую никто не убирает

Это прискорбно. Может будущие апдейты десятки поправят этот бред

Однако сборщик в WinRT таки собирает неиспользуемые компоненты, просто слишком поздно

Еще дело может быть во Frame, который при навигации хранит ссылки назад и вперед

а кстати. может влиять, под какой версией UWP собирать приложение?

я прост всё время собираю под 10240, чтобы максимизировать совместимость. не пробовал компилировать под 14***, например?

Вряд-ли, тут же проблемы во времени выполнения. Так как сборщик WinRT срабатывает даже при дальнейшем бездействии приложения

Уууу, кокие вы суровые UWP оптимизаторы, мне до вас далеко. Я так, ради баловства написал клиент для лепрорадио. В сторе легко ищется по "leproradio"

Есть для 8.1 со старым интерфейсом и глючное, и новое UWP, чуть менее глючное

супер вообще :) красота

Есть для 8.1 со старым интерфейсом и глючное, и новое UWP, чуть менее глючное

а чтоб пушить в стор, нужно лицензию покупать?

В принципе ничего сложного, гамбургер (чтоб все как у людей, фигле). Прослушка с бекграундворкером и жсон плейлист

а чтоб пушить в стор, нужно лицензию покупать?

разовый платёж

студентам дают бесплатно

Я платил за лицензию разработчика в 14 году, сейчас для стор получается актуален?

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

Я платил за лицензию разработчика в 14 году, сейчас для стор получается актуален?

да

ее сделали пожизненно валидной

круто!

пойду 5 звёзд тебе влеплю

топ

у меня вот такое https://www.microsoft.com/en-us/store/p/myfeed/9nblggh4nw02 и такое https://www.microsoft.com/en-us/store/p/mymatrix/9nblggh530bd

Пойдет, а у меня сейчас клиент для внутриофисной социалки, и тут без мыслей об оптимизации никуда...

Сча усядусь в транвай - подробее расскажу

недавно решил таки запелить нормальный клиент для ВК фор виндовс 10. после запила списка друзей с semanticzoom таки тоже про оптимизацию думать начал :)

Как уже говорил, приложение пилил ради фана и освоения новых технологий. Шаринг кода по разным версиям, универсальность и квазиуниверсальность для 8.1. Вообще туда еще нужно кучу всего добавлять. Например парсинг метаданных из аудиопотока. В плане добавить расписание программ, пуш-сообщения, но чето там посоны на сервере никак не прикрутят плагин для МС-пушей.

над свою тачку брать

ERROR: S client not available

Вопрос на засыпку: что такое делегат?

ну это кароч типа определение функции

в которую можно напихать кучу других функций

сигнатура?

типа того но я тут чуток плаваю тоже

А потом индус героически проебал наработки элопа и мобайл-маркет и я забил

Делегат это не сигнатура

Делегат это не сигнатура

но тесно связаны

уникальность делегата определяется сигнатурой же, не?

уникальность делегата определяется сигнатурой же, не?

верно

Кто имеет способности и желание допиливать приложение, а так же отточить свои навыки в UWP и потоковом аудиовещании - можете поучаствовать

Да, но это все равно, чо сказать, что указатель на функцию в c++ - это сигнатура

Ты прав

А каким образом например мы присасываемся к делегату?

ну типа принцип работы эвент хэндлеров

В смысле присасываемся?

+= -=

class Program { delegate void GetMessage(); // 1. Объявляем делегат static void Main(string[] args) { GetMessage del; // 2. Создаем переменную делегата if (DateTime.Now.Hour < 12) { del = GoodMorning; // 3. Присваиваем этой переменной адрес метода } else { del = GoodEvening; } del.Invoke(); // 4. Вызываем метод Console.ReadLine(); } private static void GoodMorning() { Console.WriteLine("Good Morning"); } private static void GoodEvening() { Console.WriteLine("Good Evening"); } }

А что тебя интересует? Как там внутри? Хз, какой-нибудь список методов

+= и -= это всего лишь удобный синтаксис

там все круче, чем список методов

там цепочка делегатов

см MulticastDelegate

Не путайте события с дилигатами

Оно очень схоже, но не то

События - это условно безопасный синтаксис для обертки делегата

Это не очень важно

Лол

а делегат — эт просто типизация функции, выходит?

Я про цепочку итд

Это важно ровно так же, как и знать как CLR устроена

а делегат — эт просто типизация функции, выходит?

метода