Учитывая то, как вы задали несколько вопросов, вы, вероятно, понимаете, что конечным решением, которое вы используете, будет баланс между конкурирующими целями.
1: вам нужно лучше определить «производительность».Я предполагаю, что вы имеете в виду время передачи по сети, что означает низкую задержку сервера и низкое количество передаваемых байтов.Конечным результатом, вероятно, является собственный двоичный протокол проводов, который также был проанализирован на предмет сжимаемости и сжатия, применяемых там, где это необходимо (например, повторяющиеся строки или последовательности).Недостатком такого протокола является то, что, вероятно, будет сложнее кодировать как на сервере, так и на клиенте, так как вы не сможете использовать поддержку SDK для стандартизированных кодировок, и если тщательно продуманные двоичные протоколы не станут хрупкими для поддержки будущих измененийи расширения для вашего приложения.
Также вы должны подумать о том, как вы определяете транзакции вашего протокола, даже с эффективной кодировкой, если вашему протоколу требуется много циклов или один цикл, вы все равно будете медленными.
Наконец, в зависимости от размера данных, которые вы отправляете, накладные расходы на кодирование могут быть несущественными по сравнению с размером данных.
Я рекомендую придерживаться стандартного формата кодирования, которыйможет быть проанализирован с поддержкой библиотеки, которая сужает поле до двух основных грамматик: XML или JSON.
2: XML и JSON хорошо поддерживаются в серверных инфраструктурах.При использовании сервисов XML я рекомендую шаблон стиля REST, поскольку его обычно легко создать, и вам не нужно согласовывать свое приложение с чьим-либо стилем.
Я бы держался подальше от веб-сервисов на основе SOAP дажехотя их создание может быть хорошо поддержано (особенно на платформах Windows), потому что сложность выполнения полного SOAP-анализа на мобильном клиенте высока и там не очень хорошо поддерживается.Я не нахожу автоматически созданную сериализацию объектов компиляторами WSDL такой большой выгодой для экономии времени при кодировании, обычно довольно легко сериализовать в XML-стиле REST или часто даже проще для JSON.
3: iOS поддерживает встроенный синтаксический анализатор XML в стиле SAX, и существует множество доступных библиотек классов, которые поддерживают реализации DOM в памяти с различными функциями и уровнями скорости.Выберите наиболее подходящий для ваших нужд.Лично я предпочитаю TBXML, который является быстрым, довольно легким и простым в программировании, но поскольку он не проверяет схемы и является деревом в памяти, он не подходит в некоторых ситуациях. Вот пример производительности iOS XML-библиотеки.
Существует несколько библиотек JSON, доступных для iOS, если вы пользуетесь Google.Или посмотрите в этом ответе .
SOAP не очень хорошо поддерживается, и выбор библиотек ограничен.Вы всегда можете вручную проанализировать ответы SOAP, сгенерированные сервером, но это является хрупким для изменений на стороне сервера, которые являются допустимыми SOAP (например, различные префиксы пространства имен), которые могут нарушить жестко закодированный анализатор XML.
4: сложно дляотвечайте, не зная больше о деталях вашего проекта, но я бы предпочел JSON или простую кодировку на основе XML, потому что: оба обычно легко программировать на клиенте и сервере, оба могут быть выполнены с разумной эффективностью на проводе ивероятно, будет расширяемым для будущих итераций приложения.
JSON имеет некоторые преимущества, заключающиеся в том, что он немного проще для анализа, он может быть менее многословным, а также может быть проще повторное задание для других целей, таких как создание Ajax-сети.клиент поверх ваших сервисов.
5: XML против JSON против других кодировок?Я думаю, что это личное предпочтение.XML может быть более самоописуемым, чем JSON, но, вероятно, будет больше работы для анализа.JSON может снизить издержки в необработанных байтах и его легко анализировать.Опять же, накладные расходы на кодирование могут быть значительными или незначительными в зависимости от размера вашего контента.Также вы можете применить внешнее сжатие в любом случае.