Это очень актуально и зависит от системы, которую вы пытаетесь внедрить.Моя рекомендация состоит в том, чтобы пойти по многим отдельным характеристикам.Причина в том, что вы будете упрощать приложение как на стороне сервера GATT (где хранятся все характеристики), так и на стороне клиента GATT.Например, если вы используете несколько характеристик, это означает, что вам необходимо добавить дополнительные сведения на свою клиентскую сторону GATT, чтобы разделить данные по этим характеристикам.Если сторона данных является переменной, то это будет еще сложнее.Если в будущем вам придется обновить эту объединенную характеристику новыми функциями, задача, вероятно, будет относительно более сложной как для клиентской, так и для серверной части по сравнению со многими характеристиками, поскольку вещи будут более категоризованными и разделенными.
Еще одна вещь, которую следует учитывать, это тестирование.Когда вы создаете свое приложение сервера GATT, вам нужно протестировать его с одной или несколькими различными реализациями клиента GATT (например, iOS-устройство, Linux-машина и т. Д.).Для этого будет намного проще, если удаленное устройство не получает объединенную характеристику и пытается разобраться в данных.
Наконец, обратите внимание, что, как вы сказали, транзакция в Bluetooth относительно быстраяи вы не будете получать огромную разницу при использовании нескольких характеристик против одной.Причина в том, что по умолчанию характерная длина равна 20, а длина пакета Bluetooth - 27 (если вы не используете функцию Bluetooth 4.2, известную как расширение длины данных , которую поддерживают не все телефоны).Поэтому, даже если вы используете характеристики длиной более 20, стек / основная полоса Bluetooth будет делить характеристику на куски и передавать их по радиоканалу, что не приведет к достижению улучшенной пропускной способности, на которую вы рассчитывали.
Надеюсь, это поможет.