不，
我正在使用的代码：
client.blockingConnect();
try {
Wearable.MessageApi.sendMessage(client,
nodeId, path, message.getBytes("UTF-16"));
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
client.disconnect();
变量path和message是包含其命名名称的字符串，client和nodeId是用以下代码设置的(最新的Android Wear版本需要修改，以适应多个设备，但不是我正在处理的当前问题)：
client = new GoogleApiClient.Builder(context)
.addApi(Wearable.API)
.build();
while (nodeId.length() < 1) {
client.blockingConnect();
Wearable.NodeApi.getConnectedNodes(client).setResultCallback(new ResultCallback<NodeApi.GetConnectedNodesResult>() {
@Override
public void onResult(NodeApi.GetConnectedNodesResult nodes) {
for (Node node : nodes.getNodes()) {
nodeId = node.getId();
//nodeName = node.getDisplayName();
haveId = true;
status = ConnectionStatus.connected;
}
}
});
client.disconnect();
我遇到的问题是，有时它有效，有时很快，有时在长时间延迟后，有时根本无效。潮汐、月相、湿度、蝴蝶在世界的另一端拍打，不确定会发生什么变化。Android wear报告该设备始终处于连接状态。有时消息的值相同，但仍然需要单独处理，因为当它们发生时，手表或手机的响应很重要。
有没有办法提高可靠性？
我试过：
sendMessage(String.valueOf(System.currentTimeMillis()), "wake up!");
但这种情况有时也不会发生。
MessageApi本质上是不可靠的。把它想象成UDP。如果你想快速传递信息，并且不介意它会失败，你可以使用它，因为你可以重复它(例如，用户在你的音乐应用程序中切换曲目-要么它有效，要么他必须再次按下按钮)。
如果您需要可靠性，请使用DataApi。它速度较慢，但可以保证最终的一致性。
如果您既想要速度又想要有保证的交付，请使用这两种方法——同时发送消息和设置具有相同令牌的数据项。如果收到消息，请保留令牌，稍后忽略数据项。否则，数据项将最终触发该操作。
EDIT文档指出，只有当节点已连接时，消息才会传递到节点：
消息将传递到连接的网络节点。消息是如果已排队等待传递到指定的节点。只有当指定的节点已连接。DataApi应用于发送到以下节点的消息当前未连接(将在连接时传递)。