недетское вскрытие .NET

N|M{INT3 TEAM}{NIM@INT3.RU}

Спецвыпуск: Хакер, номер #066, стр. 066-044-1

ЖЕСТОКИЙ ВЗЛОМ КОМПОНЕНТОВ НА ПРАКТИКЕ

ЭТА СТАТЬЯ ПОВЕСТВУЕТ О ПРИНЦИПИАЛЬНЫХ ОСОБЕННОСТЯХ ВЗЛОМА .NET-КОМПОНЕНТОВ. КАК ИЗВЕСТНО, КОМПОНЕНТ — ЭТО ПРОГРАММНЫЙ ПРОДУКТ ДЛЯ РАЗРАБОТЧИКА. СМЫСЛ КОММЕРЧЕСКИХ КОМПОНЕНТОВ ЗАКЛЮЧАЕТСЯ В ТОМ, ЧТОБЫ ЭКОНОМИТЬ ВРЕМЯ

Возьмем такой пример. Команда разработчиков пишет корпоративный заказ (некая компания заказала им разработку программы). По плану команде также предстоит разработка некого компонента, но у программистов и без того дел по уши. Как обычно, они не успевают в срок :). В результате шеф чешет репу и думает, стоит ли нанимать еще одного человека для написания необходимого компонента и платить ему $1000 в месяц, если за эти же деньги можно купить готовый компонент. Чаще всего выбирают последнее. Весь этот процесс я наблюдал не раз. Если бы не коммерческое обстоятельство, вряд ли мне пришлось бы писать эту статью.

Самые распространенные компоненты представляют собой элементы графического интерфейса: button, progress bar, editbox, listbox, combobox, grid и т.д. Такие компоненты иногда называют контролами. Grid-контрол, пожалуй, в реализации оказывается одним из самых сложных. Почти всегда он является центровым, и часто случается такое, что хитрыми маркетинговыми телодвижениями вместе с ним кто-то пытается продать другие, чаще всего просто ненужные контролы. Сегодня мы будем рассматривать реверсинг компонентов именно на примере Grid-контрола.

Как ты уже догадался, Grid-контрол — это таблица. Grid’ы весьма разнообразны по функционалу — от умеющих работать напрямую с источниками данных DataSource до позволяющих создавать Nested Tables (вложенные таблицы).

Я считаю, что [главные характеристики Grid-контрола] — это, во-первых, скорость рендера, во-вторых, экономия памяти, скорость добавления новых элементов, надежность и удобство использования. Всей этой прелести можно достичь с помощью так называемой технологии Virtual Render Control, при которой происходит прорисовка не всего контрола, а только части, помещенной в View Region (область, которую может видеть пользователь). Конечно, то, что видит пользователь, и то, что рисует Grid, — два разных понятия. К примеру, в твоем Grid’е есть 1000 элементов, но в данный момент ты можешь видеть только 20. Grid все равно прорисовывает 1000, из них 980 рисует в невидимой части. Но он рисует их и тратит время! Вот почему Grid должен заранее знать, сколько элементов пользователь видит, и рисовать только то, что доступно взгляду (в нашем случае должно рисоваться только 20 элементов). Данная технология позволяет прорисовывать контрол с одинаковой скоростью, в то же время количество элементов никогда не повлияет на скорость скролла.

Здесь можно уделить особое внимание именно прокрутке. Некоторые из native Grid-контролов, встречавшихся мне, реализуют Virtual Render Control — делают скроллинг построчно, то есть благодаря им при прокрутке текст двигается дискретно, как бы перемещаясь из одной невидимой строки в другую. Этот способ реализации технологии Virtual Render Control легче, чем попиксельный скроллинг. Более того, наличие попиксельного скроллинга свидетельствует о высоком профессионализме изготовителей-программистов, так как такая реализация требует высокой производительности и самого контрола в целом, и модели доступа к элементу контрола.