2009-11-12 4 views
7

Я пишу приложение для Android, которое будет хранить данные и связываться с сервером с использованием буферов протокола. Тем не менее, stock implementation буферов протокола, скомпилированных с флагом LITE (как в библиотеке JAR, так и в сгенерированных файлах .java), имеет накладные расходы ~ 30 КБ, где сама программа составляет всего ~ 30 КБ. Другими словами, буферы протокола удваивали размер программы.Android и протокольные буферы

Поиск в Интернете, я нашел reference до Android specific implementation. К сожалению, для него, похоже, нет документации, и код, сгенерированный из стандартного файла .proto, несовместим с ним. Кто-нибудь использовал его? Как создать код из файла .proto для этой реализации? Есть ли другие легкие альтернативы?

ответ

1

Просто возродить эту архаическую нить для любой видя его, ответ заключается в использовании Wire библиотеки Square чрезвычайно (https://github.com/square/wire)

Как они упоминают себя:

провода сообщения объявляют публичные конечные поля вместо обычных методов getter. Это сокращает как генерируемый код, так и выполненный код. Меньше кода особенно полезно для Android-программ.

Они также внутренне строятся с использованием Lite runtime, я считаю.

И конечно Proguard, новых Android 2.0 Минимизировать инструментов, [другие общие ответы], и т.д. и т.п.

6

Я знаю, что это не прямой ответ на ваш вопрос, но дополнительный 30кб не звучит так плохо для меня. Даже на EDGE, для загрузки потребуется только 1 - 2 секунды. И память жестко привязана к андроиду, но не THAT tight - 30 kb составляет всего около 1/10 от одного процента доступного пространства памяти приложения.

+0

Ну, я думаю, проблема в том, что практически удваивает размер приложения. Просто то, что было немного непривлекательным. – kwogger

2

Есть ли другие облегченные альтернативы?

Я принимаю это как «использовать протокольные буферы», а не «для использования буферов протокола с приложением для Android». Приносим извинения, если вы уже зарегистрированы в буферах протокола.

This сайт посвящен «сравнению производительности сериализации и других аспектов библиотек сериализации на JVM». Здесь вы найдете множество альтернатив.

Хотя нет никакого упоминания о занимаемой памяти различных реализаций в данный момент я уверен, что это показатель, который люди на вики было бы интересно.

+0

Спасибо, а не то, что я искал, но, тем не менее, полезную информацию. – kwogger