Я занимаюсь проектированием и разработкой программного обеспечения для Windows Mobile и Windows CE на C, C ++ и C # уже несколько лет. Более того, я делал это для Honeywell (ранее Hand Held Products, приобретенной Honeywell в 2007 году), где я работал практически над всеми аспектами устройств, от драйверов и сервисов до графических интерфейсов и утилит Line of Business.
Прежде всего, я не буду говорить вам, что один язык лучше, чем другой ... Я, вероятно, трачу 50/50 времени с каждым, и каждая платформа определенно имеет свою место в мобильной разработке.
Однако я дам вам предположение, что вы, вероятно, держитесь подальше от любого устройства, на котором установлена ОС столь же старой, как WinCE 4.2, особенно если вы даже рассматриваете возможность разработки .NET. Это объясняется тем, что в 4.2 встроен только максимум .NET CF 1.0 в ПЗУ (часть образа ПЗУ ОС), а это означает, что для установки по крайней мере .NET CF 2.0 вам потребуется ~ 5 МБ CAB-файл. может развиваться с CF 1.0, но, на самом деле, это не стоит того, чтобы использовать такой старый фреймворк. Большинство устройств WinCE 5.0 в настоящее время поставляются с CF (Compact Framework) 2.0, установленным в ПЗУ, поэтому я по крайней мере поищу это.
С той же тщетностью вы можете даже подумать об использовании устройства с Windows Mobile 6.0 или 6.1, поскольку они просты в программировании и всегда будут иметь предварительно установленный CF 2.0. Если вам интересно, почему я не упомянул CF 3.0 или CF 3.5, это просто потому, что первой мобильной платформой, которая будет выпущена с этими версиями, будет Windows Mobile 6.5, которая еще не выпущена. Хотя вы всегда можете установить фреймворк, если хотите (~ 8 МБ CAB).
Конечно, WinCE определенно дает вам больше «Windows» внешнего вида своего графического интерфейса по сравнению с кузеном Windows Mobile, так что все это зависит от ваших предпочтений программирования и того, что ваши конечные пользователи хотят и нуждают.
Что касается комментариев kgiannakakis о том, что SDK являются всего лишь слоем вещей, то это просто неправда. Если у вас есть надлежащий SDK, у вас должен быть тот же доступ к любым устройствам или драйверам, что и в C ++, но с простотой C #. Например, Honeywell предоставляет обширный SDK для всех наших устройств в C ++, VB и C #, и часть SDK в C # на самом деле имеет больше функциональных возможностей, чем часть C ++. Вам никогда не придется выполнять P / Invoke с нашим кодом из C #.
Если вы хотите взглянуть на SDK, о котором я говорю, он свободно доступен для загрузки здесь и имеет несколько замечательных примеров.
ИМХО, я бы на самом деле считал предоставленный SDK более важным, чем аппаратное обеспечение во многих случаях, поскольку в большинстве случаев аппаратное обеспечение для устройств в значительной степени совпадает. Все они имеют процессоры ARM, WiFi, Bluetooth, лазерные или графические сканеры и т. Д.
Тем не менее, я посмотрел ссылку на Intermec, которую вы разместили, и не похоже, что на самом деле устройство имеет встроенный сканер ... Вы используете внешний сканер, подключенный к устройству?
Взгляните на предложение Honeywell, если вы хотите здесь . У нас есть устройства с, вероятно, лучшим в своем роде сканером штрих-кодов, встроенным во все наши устройства. И у нас есть надежный SDK (я должен знать, я написал много). А SDK обеспечивает .NET чрезвычайно доступ ко всем аппаратным средствам на устройстве. Хорошо ... Я остановлю свой шаг продаж.
Что касается одного языка поверх другого ... все зависит от того, что именно вы хотите делать.
Драйверы и службы не могут быть написаны ни на чем, кроме Native (Win32) C или C ++. Так что .NET для чего-то подобного.
C и C ++ могут быть вашими друзьями на мобильных устройствах с точки зрения упрощения работы, так как вам не нужна вся платформа .NET для запуска add. Помните, что у вас есть максимум 32 МБ памяти для любого процесса (не включая библиотеки DLL. Это еще одна лекция), поэтому, если ваше приложение будет обрабатывать тонну данных, C ++ может быть подходящим вариантом. ,
Один из основных недостатков, которые я обнаружил в C и C ++ в мобильных системах, заключается в том, что создание графического интерфейса пользователя на путь сложнее, чем в .NET На самом деле, большинство приложений C ++, которые я писать полностью без головы и вообще без графического интерфейса ... .NET CF не не имеет WPF (пока) и застрял с WinForms, но его действительно легко подобрать. Довольно много перетащить в дизайнера. И помните, как я уже упоминал ранее, WinCE имеет совершенно другую парадигму графического интерфейса, чем Windows Mobile. Тем не менее, иногда способ Windows Mobile довольно приятен, поскольку он заставляет вас поддерживать простой и понятный графический интерфейс.
Потребление памяти может быть выше при использовании .NET, но не всегда. Во-первых, наличие устройства с версией CF, которую вы собираетесь использовать, сохраненной в ПЗУ, будет означать, что у вас больше не будет памяти в приложении .NET по сравнению с аналогичным приложением C ++. В некоторых случаях .NET будет даже использовать меньше памяти. Например, приложение .NET против приложения C ++, которое использует MFC, часто может использовать меньше памяти, потому что приложение C ++ должно загрузить инфраструктуру MFC (так как оно еще не загружено ОС ...).
Кроме того, поскольку C # управляется, вы часто будете использовать меньше памяти, поскольку сборщик мусора освобождает память, которую вы, возможно, забыли сделать в приложении C ++.
Скорость выполнения на более современных устройствах, как правило, не отличается между ними. Конечно, у вас всегда будут небольшие части каждого языка, где один будет быстрее другого, но на данный момент .NET достаточно зрел, чтобы скорость не была проблемой. Я запрограммировал чрезвычайно быстрые приложения с высокоинтерактивными анимированными графическими интерфейсами, которые прекрасно работали на устройстве с 128 МБ ОЗУ и процессором ARM 420 МГц. Я даже написал одно приложение, которое мне пришлось замедлить , потому что оно вызывало нативную DLL через P / Invoke, а часть .NET по сути становилась "нетерпеливой".
Я никогда не видел проблем с временем автономной работы на одном языке по сравнению с другим. Но я никогда специально не проверял это.
Я действительно думаю, что, в конце концов, это все равно сводится к SDK, который идет в комплекте с вашим устройством. Если у него плохая поддержка .NET, вы обнаружите, что делаете много дополнительной работы, заставляя все работать, и в этом случае я бы выбрал C ++. Но если у него будет отличная поддержка .NET (например, та, над которой я работаю), вы обнаружите, что у вас намного меньше работы и, вероятно, работа будет выполнена значительно быстрее.
Кроме того, помните, что необходимо учитывать не только SDK производителя оборудования. Хотя вам нужен этот конкретный SDK, поскольку каждое устройство отличается (т. Е. SDK, с которым я связывался ранее , не будет работать на этом устройстве Intermec), все не связанные с аппаратным обеспечением операционные системы в значительной степени стандартны для всех плат, вот где приходит Windows Mobile или Windows CE SDK от Microsoft. Их поддержка C ++ довольно хороша, но в настоящее время они действительно продвигают все .NET, поэтому, поскольку обновления производятся для ОС, меньше обновлений для C ++ SDK и гораздо больше функциональности теперь зависят от использования .NET Не то чтобы вы не могли сделать это в C ++, просто они не сделали для вас большую работу, которая они сделали в .NET SDK.
Хорошо ... это было долго, но я пытался свести воедино все тонкости моего многолетнего опыта. Надеюсь, это имело смысл.