Comments 36
Отличная статья! Эх если бы я мог за не проголосовать ;)
скачать изображение из интернета по 3G получается быстрее, чем прочитать её из внутреннего хранилища — о таких проблемах изначально очень сложно догадаться.
Почему так? Расскажите подробнее.
насколько я понял, вместо просто загрузки из сети идет просмотр всего кэша на наличие, потом загрузка из сети в кэш, потом загрузка из кэша. потому и дольше
Это понятно, но интересно что в этой цепочке тормозит:
— если поиск в кэше — можно построить индекс в локальной БД.
— после загрузки из сети можно сразу это изображение использовать, а в кэш сохранять в фоне.
— если поиск в кэше — можно построить индекс в локальной БД.
— после загрузки из сети можно сразу это изображение использовать, а в кэш сохранять в фоне.
Поиск в кеше проходит достаточно быстро, а с загрузкой было сделано так — сначала изображение загружалось в кеш, а потом из кеша показывалось, то есть происходил двойной доступ к хранилищу, но экономился траффик пользователя. Конечно есть вариант сначала загрузить все изображение в память, а потом уже декодировать его в рисуемый объект и сохранять его в хранилище, однако это повышает пиковое использование памяти, что критично в некоторых ситуациях. Так вот, эта двойная операция обращения к хранилищу оказалась на удивление медленной, поэтому сейчас такое кеширование оставлено только для изображений главной панорамы, а все остальные изображения грузятся напрямую и не кешируются. Кстати, очень нехватает возможности определить сколько места занято под кеш, из за этого приходится изобретать хитрый скавенджер :(
Приложение на самом деле получилось очень хорошим, спасибо :-)
UFO just landed and posted this here
>Стоит сказать, что мы немножко схитрили, используя не тот «голый» язык в той версии, которая
>доступна всем, а применяли некоторые свойства для упрощения асинхронной работы с данными,
>которые только появятся в следующей версии языка.
Вы про async await?
Можете расказать подробнее, как из можно использовать уже?
>доступна всем, а применяли некоторые свойства для упрощения асинхронной работы с данными,
>которые только появятся в следующей версии языка.
Вы про async await?
Можете расказать подробнее, как из можно использовать уже?
С помощью Async CTP. Скачать можно по ссылке msdn.microsoft.com/en-us/vstudio/gg316360
Крайне удобная вещь, я в своем приложении переписал под Async CTP 3, код получился раза в 2 короче и читабельнее.
Еще бы сделали HttpContent, как в WinRT, цены бы не было!
Еще бы сделали HttpContent, как в WinRT, цены бы не было!
Только сейчас заметил, что установленное у меня приложение Кинопоиск.Ru — неофициальное, а в Маркетплейсе есть еще одно — Кинопоиск :)
Официальное приложение гораздо лучше!
Ну и за статью — отдельное спасибо! ;)
Официальное приложение гораздо лучше!
Ну и за статью — отдельное спасибо! ;)
Приложение получилось довольно хорошим, но есть несколько замечаний.
Первое — производительность. Скроллинг панорамы заметно тормозит. Проверьте показатели FPS для compositor thread и fill rate. Навигация с какого-нибудь экрана обратно на главную страницу также занимает довольно много времени. Вероятно, какой-нибудь «тяжёлый» код выполняется в OnNavigatedTo/OnNavigatingFrom.
Второе — отступы в разделе «кино!» на стартовой панораме. Можно заметить, что у заголовка и контента разный margin слева. Стандартное значение — 24 пикселя
Ну и размер самих элементов меню на этой же странице можно было бы сделать чуть больше. Свободное место есть, да и попасть пальцем в нужный пункт было бы проще. Посмотрите например как это сделано в стандартном приложении marketplace.
Не пинайте за длинный комментарий. Надеюсь он поможет сделать приложение ещё лучше.
Первое — производительность. Скроллинг панорамы заметно тормозит. Проверьте показатели FPS для compositor thread и fill rate. Навигация с какого-нибудь экрана обратно на главную страницу также занимает довольно много времени. Вероятно, какой-нибудь «тяжёлый» код выполняется в OnNavigatedTo/OnNavigatingFrom.
Второе — отступы в разделе «кино!» на стартовой панораме. Можно заметить, что у заголовка и контента разный margin слева. Стандартное значение — 24 пикселя
Ну и размер самих элементов меню на этой же странице можно было бы сделать чуть больше. Свободное место есть, да и попасть пальцем в нужный пункт было бы проще. Посмотрите например как это сделано в стандартном приложении marketplace.
Не пинайте за длинный комментарий. Надеюсь он поможет сделать приложение ещё лучше.
Приложение, действительно, удачное (приятно, что Нокия не стала делать его своим эксклюзивом и на HTC оно тоже доступно).
Жаль, пополнение Marketplace программами такого уровня идёт сильно медленнее, чем хотелось бы.
К моменту, когда все приятные и привычные по iOS и Android программы наконец появятся, уже WP8 успеет выйти.
Спасибо за статью :)
Жаль, пополнение Marketplace программами такого уровня идёт сильно медленнее, чем хотелось бы.
К моменту, когда все приятные и привычные по iOS и Android программы наконец появятся, уже WP8 успеет выйти.
Спасибо за статью :)
Вот чего я понять не могу: есть приложение от facebook, которое работает так же плавно, как и сама система. Почему у подавляющего большинства других приложений, которые что-то грузят из сети, такие ужасные задержки и тормоза?
Кинопоиск тому пример. Было бы отлично, если бы это чудо-приложение не фризилось при загрузке данных из сети. А прокрутка панорамы — вообще отдельная песня.
Кинопоиск тому пример. Было бы отлично, если бы это чудо-приложение не фризилось при загрузке данных из сети. А прокрутка панорамы — вообще отдельная песня.
Отличное приложение, но над производительностью стоит поработать. Помните, что устройства первой волны имеют Adreno200 вместо Adreno205.
Видимо этот разработчик давно под iOS не писал, с xcode 4 и iOS 5 стало еще проще и приятнее. Да и под андроид интерфейсы рисовать можно.
Уважаемые хаброжители! Прежде всего хочу сказать спасибо за добрые отзывы и конструктивную критику — и того, и другого так мало стало в современных интернетах :-) Мы продолжаем улучшать Кинопоиск ориентируясь, в том числе, и на ваши пожелания и замечания. Большая часть проблем, связанных с производительностью, была решена в версии 1.3, отдано мы не остановимся на достигнутом.
Одной из причин, по которой возникают задержки, является большое количество графики, которую приложение загружает из интернета. Вся загвоздка в том, что финальное декодирование изображения производится в потоке пользовательского интерфейса (сама загрузка идет в фоне) — и вот тут-то начинаются притормаживания. К сожалению элегантного способа решения проблемы мы пока не нашли, а уж совсем откровенных «гнусных хаков» делать не хочется, так что продолжаем борьбу на этом фронте :-)
@andrew_kane: В обработчиках
Одной из причин, по которой возникают задержки, является большое количество графики, которую приложение загружает из интернета. Вся загвоздка в том, что финальное декодирование изображения производится в потоке пользовательского интерфейса (сама загрузка идет в фоне) — и вот тут-то начинаются притормаживания. К сожалению элегантного способа решения проблемы мы пока не нашли, а уж совсем откровенных «гнусных хаков» делать не хочется, так что продолжаем борьбу на этом фронте :-)
@andrew_kane: В обработчиках
Эмма прекрасна!
Уважаемый Anadale, спасибо за интервью, оно очень интересное. Но Ваше сравнение разработки под Android и WP7 не выдерживает никакой критики. Особенно часть про асинхронное программирование.
А я не сравнивал именно асинхронное программирование у WP7 и Android. Я говорил про общую дружелюбность платформы к разработчику. Да, Android очень гибок и позволяет очень много сделать. Мне ужасно нравится сама концепция общения между приложениями в Android — у WP7 этого пока нет. Да и сама платформа постарше (в смысле зрелости). Однако то, что в VisualStudio для WP7 делается за минуту, на Android нужно тщательно описывать. Про это я и говорил. А еще при разработке под Android ужасно нехватает свойств (C# properties), LINQ, связывания и ах да! async/await, но тут я, пожалуй, остановлюсь иначе начнется холивор :)
1) Java vs C# != Android vs WP7. Хотите C# под Andriod? Есть MonoDroid в конце концов.
2) Про удобство согласен, но это дело вкуса.
3) … применяли некоторые свойства для упрощения асинхронной работы с данными, которые только появятся в следующей версии языка C#… Этих вещей ни в iOS, ни в Android нет. Что Вы имеете ввиду? Если, Вы говорите про async/await (опять к Android не имеет отношения это чистый C#), то вводите неопытных читателей в заблуждение. Конкретной реализации async/await в java нет и, возможно, не будет, но асинхронные вычислительные операции возможны, и конечно работают очень неплохо.
Спасибо.
2) Про удобство согласен, но это дело вкуса.
3) … применяли некоторые свойства для упрощения асинхронной работы с данными, которые только появятся в следующей версии языка C#… Этих вещей ни в iOS, ни в Android нет. Что Вы имеете ввиду? Если, Вы говорите про async/await (опять к Android не имеет отношения это чистый C#), то вводите неопытных читателей в заблуждение. Конкретной реализации async/await в java нет и, возможно, не будет, но асинхронные вычислительные операции возможны, и конечно работают очень неплохо.
Спасибо.
1) Хочу C# под Android! Но MonoDroid, по рассказам очевидцев, пока недостаточно зрелый, что ли. Сам не пробовал, поэтому врать не буду. Хотя в большинстве случаев, кстати, Android == Java && iOS == ObjectiveC.
2) Да к этому удобству так привыкаешь быстро…
3) Еще раз, я не спорю, что асинхронные паттерны (begin/callback/end) есть сейчас в любой мобильной платформе. Я говорю именно про конкретную реализацию в том инструменте, который наиболее часто используется для разработки под конкретную платформу. Вот у VS/C# есть async/await который, согласитесь, уж всяко лучше тех конструкций, которые придется писать на Java || Objective C. Да, мыЧелябинские металлурги олдскульные хардкорщики, не обломимся и напишем таки 4 экрана коллбеков и при этом не запутаемся в них. Но этот гадский инструмент VS лишает нас этого удовольствия и заставляет писать коротко и понятно :)
2) Да к этому удобству так привыкаешь быстро…
3) Еще раз, я не спорю, что асинхронные паттерны (begin/callback/end) есть сейчас в любой мобильной платформе. Я говорю именно про конкретную реализацию в том инструменте, который наиболее часто используется для разработки под конкретную платформу. Вот у VS/C# есть async/await который, согласитесь, уж всяко лучше тех конструкций, которые придется писать на Java || Objective C. Да, мы
1) Ok. Закрыли.
2) Ok. Закрыли. LINQ наше всё)
3) Вот у VS/C# есть async/await который, согласитесь, уж всяко лучше тех конструкций, которые придется писать на Java. Конечно, всё зависит от решаемой задачи. Не факт, что эта конструкция будет лучше работать.
3.1) писать коротко и понятно. Не соглашусь, что коротко и понятно можно связывать. И вообще коротко не значит лучше. Как пример приведу слово lock из C#! Так что посмотрим на итоговую реализацию и подводные камни, которых скорее всего будет навалом.
По итогу 3) Ok. Закрыли.
Спасибо ещё раз.
2) Ok. Закрыли. LINQ наше всё)
3) Вот у VS/C# есть async/await который, согласитесь, уж всяко лучше тех конструкций, которые придется писать на Java. Конечно, всё зависит от решаемой задачи. Не факт, что эта конструкция будет лучше работать.
3.1) писать коротко и понятно. Не соглашусь, что коротко и понятно можно связывать. И вообще коротко не значит лучше. Как пример приведу слово lock из C#! Так что посмотрим на итоговую реализацию и подводные камни, которых скорее всего будет навалом.
По итогу 3) Ok. Закрыли.
Спасибо ещё раз.
позвольте вторгнуться в ваш холивар.
касательно андроида, тут присутствует большое кол-во классов для асинхронной работы. лично мне больше всего нравятся механизмы Loader, CursorLoader, IntentService. минимум кода и обработка многих возникающих в процессе работы ситуций и проблем из коробки.
я не разбираюсь в механизме async/await, но мне интересно было бы сравнение, если вы конечно сталкивались с тем, что я описал
касательно андроида, тут присутствует большое кол-во классов для асинхронной работы. лично мне больше всего нравятся механизмы Loader, CursorLoader, IntentService. минимум кода и обработка многих возникающих в процессе работы ситуций и проблем из коробки.
я не разбираюсь в механизме async/await, но мне интересно было бы сравнение, если вы конечно сталкивались с тем, что я описал
Тут разговор шел, в основном, о синтаксическом сахаре паттерны Asynchronous Callbacks, который предоставляет компилятор C#. Если коротко, то код, который на «чистом» C# выглядит как цепочка методов (начало обработки/завершение обработки) с использованием Async CTP превращается (для разработчика) в один метод. А «на самом деле» компилятор сам пишет те самые «начало обработки» и «завершение обработки». В простых ситуациях это само по себе приятно, а особенно это приятно, например, когда по результатам одной асинхронной операции нужно запустить еще несколько. Такой сценарий, кстати, часто встречается — например мы получаем от сервера информацию о фильме и стартуем загрузку кадров из фильма.
Вы использовали async/await в проекте? В VS11 разрабатывали?
Очень не хватает функционала выбора кинотеатра и показа идущих уже в нем сеансов, а не наоборот, как сделано сейчас(сначала фильм, а потом уже кинотеатры)
Будет обязательно, но, к сожалению, не могу пока сказать дату релиза. Прошу отнестись с пониманием — www.kinopoisk.ru — это большой, удивительно мощный проект, с большим количеством функционала. Хочется аккуратно переводить его в мобильный вид, чтобы с одной стороны представить все функции, а с другой — не сделать приложение чересчур громоздким и выбивающимся из экосистемы. Так что «семь раз отмерь — один раз запрограммируй».
Sign up to leave a comment.
Как создавался «Кинопоиск» для Windows Phone