Конечно, будет неправильным сказать, что каждое приложение обязано быть совместимо с большим количеством различных платформ. Тем не менее, кросс-платформенные программы есть и продолжают появляться. Уже одно это говорит о том, что рынок нуждается в подобном ПО. Давайте попробуем разобраться подробнее в некоторых особенностях, связанных с его проектированием (конечно же, не во всех - эта статья не претендует на исчерпывающую полноту), а также в принципиальном вопросе, имеет ли вообще смысл страдать над кросс-платформеностью вашей разработки.
Итак, каковы преимущества кросс-платформенных приложений перед теми, которые могут запускаться только на одной платформе? В принципе, они очевидны. Во-первых, программы, которые обладают таким полезным свойством, как кросс-платформенность, более устойчивы на рынке программного обеспечения, таком сложном и нестабильном в наши нелёгкие времена. В самых разных категориях сейчас набирают популярность приложения, которые умеют работать под основными "китами" мира операционных систем: Windows, Linux, FreeBSD и MacOS. Среди программ для конечных пользователей на вершинах хит-парадов софта стоят Mozilla Firefox, OpenOffice.org, Opera... Список велик, и каждый день он пополняется новыми участниками. В свете этих фактов разработчикам, которые смотрят в будущее и не видят его без своих, несомненно, очень нужных и качественных продуктов, стоит подумать о кросс-платформенности. Правда, как вы, может быть, заметили, большая часть этого списка - программы бесплатные или даже вовсе open-source. Собственно говоря, для программ, предназначенных для Desktop-систем, кросс-платформенность не так уж и прибыльна в денежном эквиваленте. Однако стоит заметить, что высказанное выше правило о стабильности более чем актуально для того, кто разрабатывает программное обеспечение для станций-серверов или корпоративных пользователей. Для серверов - потому что платформа POSIX (UNIX-подобные системы типа Solaris, MacOS, FreeBSD, Linux) сдаёт свои позиции под яростным натиском неугомонных "мелкомягких". А задачи у обеих платформ довольно похожи, несмотря на фундаментальные различия в архитектуре. Что касается корпоративной сферы, тут очень популярны два слова: Java и .NET. Как известно, это архитектуры, которые по своей природе опираются на понятие кросс-платформенности. Конечно, никто не запрещает создавать корпоративные приложения под одну платформу, но стоимость их, как правило, обоснованно ниже.
В общем-то, чтобы узнать, имеет ли смысл делать ту или иную разработку кросс-платформенной, проще всего посмотреть на конкурентов. У них есть кросс-платформенная версия программы - значит, вам тоже есть о чём задуматься. Если же конкурентов у вас нет (и вы при этом всё же умудряетесь как-то зарабатывать деньги), то нужно оценить предполагаемое количество пользователей вашей программы для каждой из платформ - это называется маркетинговыми исследованиями. Если среди платформ нет явного лидера по количеству пользователей, то имеет смысл делать программу кросс-платформенной.
Итак, решение принято. Если оно отрицательное (то есть, программа будет только для одной платформы), то дальше можно не читать. Иначе... О чём стоит подумать дальше?
Едва ли не самым важным моментом является выбор языка программирования и, соответственно, совместимых с ним технологий и стандартов. На текущий момент основных предложений в этом секторе три: старичок C++; ещё молодой, но уже взрослый язык Java и новомодный C#. Есть, конечно, и более экзотичные варианты: например, очень даже кросс-платформенные Ada, Python, Free Pascal или даже PHP. Они имеют множество недостатков. Например, Ада, несмотря на отличные языковые возможности и богатый выбор очень хорошо отлаженных библиотек, имеет более чем дорогие средства для разработки программ (компиляторы и IDE). Free Pascal довольно сыр и содержит много ошибок, однако потенциал у этой системы программирования есть. PHP - скриптовый язык, поэтому скорость разработанных с его помощью решений зачастую не позволяет использовать его повсеместно. Это касается и Python, который, конечно, в этом плане намного лучше PHP или Perl'a, зато имеет своеобразный синтаксис и поэтому не очень популярен у программистов.
Так что обратимся лучше к тройке лидеров. Каждый из них, естественно, имеет преимущества и недостатки, и сейчас мы немного о них поговорим. C++ позволяет создавать очень компактные и быстрые решения, однако требует наибольших затрат на разработку, поскольку решение для каждой платформы придётся писать отдельно. Наличие огромного числа библиотек и высокопроизводительных компиляторов (в том числе и бесплатных) - конечно, плюс, но вряд ли он перевешивает минусы. Java в этом плане проигрывает по скорости работы программ за счёт своей виртуальной машины, зато имеет огромную фору в том, что для обеспечения совместимости с разными платформами со стороны разработчика конечного продукта нужны минимальные телодвижения. Количество различных библиотек для этого языка уже плавно приблизилось к числу аналогичных для C++, так что в этом вопросе они практически на одном уровне. Плохо только то, что рынок испытывает дефицит в хороших Java-разработчиках, и это одна из многих причин того, что разработка программ на этом языке может стать более дорогостоящей, чем на C++. C#, в принципе, тоже похож на Java - для работы программ, написанных на этом языке, также нужна виртуальная машина. Однако поскольку язык разработан корпорацией Microsoft, то и виртуальная машина .NET Framework от этих разработчиков работает только под управлением Windows. К счастью, есть ещё и Mono, которая совместима с программами для .NET, и при этом умеет работать как под Win32, так и под POSIX-платформами. В целом, Mono имеет очень хорошую совместимость с .NET Framework, но некоторые возможности C# в ней поддерживаются не полностью. Это одно из "скользких мест" C#. Вторая загвоздка заключается в сравнительной новизне этого языка, которая является причиной малого количества готовых решений для этого языка и некоторого (хотя и не такого острого, как для Java) дефицита специалистов по этому языку. Зато синтаксис C# и его рантайм-библиотека проще, чем аналогичные в Java, и изучить его проще.
В принципе, как видите, явного лидера нет, поэтому при выборе языка нужно учитывать, что вам важнее - скорость разработки или скорость работы готового приложения. И если критичнее первое, нужно подумать, какой язык вы или ваши программисты знают лучше или освоят быстрее. Можно, конечно, сделать и многоязычный проект, но совмещать такие языки, как Java, C++ и C# - технически не самая простая задача. Хотя в некоторых программах она и решена, стоит принять во внимание, что такой подход увеличивает затраты на разработку.
Ещё один немаловажный фактор - количество поддерживаемых платформ. Это особенно актуально, если в предыдущем списке вы выбрали C++. Потому что для Java и C# это не особо критично, как я уже говорил, а вот на C++ весь платформно-зависимый код нужно будет писать отдельно для каждой ОС. Соответственно, чем меньше поддерживаемых ОС, тем меньше код. Для пользователей операционных систем вроде OS/2 или QNX стараться вряд ли имеет смысл, поскольку их мало. Аналогично, если ваш продукт имеет чисто серверную направленность, очевидно, вряд ли стоит его портировать под настольные системы семейства Windows.
Третий пункт в списке задач, решаемых на этапе проектирования кросс-платформенного приложения, это выбор различных стандартов, которые оно будет поддерживать. В принципе, это не так уж и отличается от принципа создания приложений, работающих только на одной платформе, но по существу весь вопрос заключается в кросс-платформенности самих стандартов и технологий. Например, если под Windows для распределённых приложений вы могли бы обойтись DCOM'ом, то кросс-платформенное приложение уже должно использовать CORBA, архитектуру значительно более дорогую и ресурсоёмкую. Аналогично и с другими технологиями, например, COM, на которой, кстати, DCOM и базируется. Под POSIX-системами эта технология работать не будет, поэтому стоит посмотреть в сторону XPCOM - кросс-платформенного аналога этой технологии, который используется в таких продуктах, как OpenOffice.org и Mozilla. Как правило, технологии, обеспечивающие кросс-платформенность, более дороги как при разработке, так и при эксплуатации. Это касается даже GUI-библиотек (речь о C++): если под Win32 за MFC можно было не платить, то кросс-платформенная библиотека Qt уже отнюдь не бесплатна... Кто не верит - посмотрите здесь: www.trolltech.com/products/qt/licenses/pricing. Хотя, конечно, можно найти и бесплатные решения, они, как правило, обладают гораздо менее впечатляющей функциональностью.
Довольно серьёзной ошибкой бывает перенос технологии, работающей под одной системой, на другую при помощи эмуляторов. Технологически такое решение, пусть и не самое красивое, имеет право на жизнь. Однако следует помнить, что пользователями кросс-платформенных приложений обычно являются люди, имеющие неплохие познания в информационных технологиях, а в их глазах такая излишняя простота не прибавляет приложению бонусов в рейтинге. Даже наоборот - это свидетельствует о недостаточном профессионализме разработчика, и, как понимаете, отрицательно сказывается на продажах. Поэтому в таком деле самый простой путь далеко не всегда самый выгодный финансово.
Очень важно при использовании готовых библиотек обращать внимание на текст лицензионного соглашения. Многие лицензии для библиотек с открытым исходным кодом не позволяют использовать их в коммерческом программном обеспечении. Другие, менее радикальные, требуют в этом случае плату за использование. А коммерческие библиотеки для кросс-платформенного программирования (как, кстати, и среды разработки) стоят достаточно дорого, и один пример я уже приводил - Qt. Кроме того, программисты, разрабатывающие приложения для разных платформ, должны разбираться в них, а, как известно, чем квалифицированнее рабочая сила, тем большую требует себе зарплату. Если же вы задумали в одиночку создавать приложение, умеющее работать на разных платформах, то вспомните о том, что время - это тоже деньги. Поэтому морально приготовьтесь к тому, что кросс-платформенность - довольно дорогое удовольствие.
Что ж, пожалуй, закончим пока на этом. Некоторые "подводные камни", возникающие при постановке задачи о создании кросс-платформенного приложения, мы с вами рассмотрели. Конечно, их неизмеримо больше, и существует множество специальных ресурсов и изданий, посвящённых этим вопросам. Надеюсь, мы ещё вернёмся к этой теме на страницах "Компьютерных Вестей".
Вадим СТАНКЕВИЧ
Комментарии
Страницы
Дмитрий, Вы сами говорили, что open-source и free software - разные вещи.
Вот вам ещё аналогия. Миллиарды мух не могут ошибаться. Давайте и мы все будем жрать говно.
> Не втягивайте людей в вашу "борьбу" с "буржуями".
Если вам сейчас наплевать на свободу, это ещё не значит, что она вам не понадобится потом, когда будет уже поздно.
> Дмитрий, Вы сами говорили, что open-source и free software - разные вещи.
Разные. При этом я считаю, что open-source -- лишняя сущность, которой давно пора под бритву Оккама. Потому и предлагаю в русский язык, где её использование ещё вовсе не устоялось, зря её не тянуть.
Я не против термина "свободные программы", но в связи с довольно своеобразным местом слова "свобода" в менталитете русских и белорусов я бы предпочёл менее яркие термины.
Этот призыв не разделяю. Кушать давайте шкварку да пить гарэлкi чарку.
>Если вам сейчас наплевать на свободу, это ещё не значит, что она вам не понадобится потом, когда будет уже поздно.
О! Это из области: "Вы еще не свободны? Тогда мы идем к вам!" Так понимаю, югославы и иракцы плевали на свободу, так что дядя Сэм взял да и заставил понять их, дурней, что свобода им нужна. Дмитрий, будуте из компов платные проги выкорчевывать на место их "свободные" ставить? А тот, кто захочет в вашем будущем заплатить за софт будет немедленно четвертован?
>open-source -- лишняя сущность
Этот термин ТОЧНО определяет сущность софта данного типа. Так что ваша настойчивость, Дмитрий, продиктована совсем другими целями, а не любовью к русскому языку.
Понимаете, тут как обычно. Общую теорию относительности понимает 10 человек в мире, частную - 1 000 000 000. Получается, с людьми все же проще все же общаться в терминах "частной" (возможно, пример не сильно удачный, но надеюсь - покатит)...
Страницы