☞ 返回总目录
1.服务发现的两种方式
-
StartFindService 方法
-
这是一个在后台启动的连续 “FindService” 活动，当服务实例的可用性发生变化时，会通过回调通知调用者。
-
它返回一个FindServiceHandle，可通过调用StopFindService来停止正在进行的监视服务实例可用性的后台活动。
-
其第一个参数是一个用户提供的处理函数（具有特定签名
std::function<void(ServiceHandleContainer<T>, FindServiceHandle)>），每当匹配的服务实例可用性改变时，就会调用该处理程序，并提供更新后的服务实例句柄列表。
-
-
FindService 方法
-
这是一次性调用，使用实例标识符的不同有两种重载方式（使用 ara::com::InstanceIdentifier 或 ara::core::InstanceSpecifier）。
-
它为匹配的服务实例返回一个句柄容器，如果当前没有匹配的服务实例，容器可能为空。
-
2.Auto Update Proxy instance 相关问题
-
服务启停后的重用问题
-
当服务实例停止运行后又重新运行时，ara::com的设计要求从绑定实现中解决服务消费者端代理实例的重用问题。
-
例如在服务消费者应用程序从 FindService 返回的句柄实例化服务代理实例后，在服务实例关闭再出现的过程中，服务代理实例的通信管理会被通知并静默更新（如在 T3 阶段传输层部分颜色从蓝色更改为玫瑰色），使得服务方法调用在服务实例再次可用时能够成功（T4 阶段）。
-
-
对开发者的好处
-
这种设计使客户端应用程序的实现者无需通过 GetSubscriptionState () 对事件进行轮询（仅在服务实例已关闭时才需调用）、无需重新调用 FindService 获取新句柄、无需重新注册FindServiceHandler（回调）以及重新创建代理实例和重新进行事件订阅调用等操作。
-
-
代码示例说明
-
在给定的代码片段中，
radarServiceAvailabilityHandler函数展示了在服务实例可用性变化的处理函数中，与现有 Proxy 实例进行交互的情况。当服务实例再次启动时，对代理实例的调用（如myRadarProxy->Calibrate("test")）不应导致服务实例不可达的异常，因为代理实例应该已经自动更新。
-
3.StartFindService方法的大致实现步骤：
3.1. 启动服务查找后台活动
-
初始化操作：当调用 StartFindService() 方法时，首先在后台开启一个持续的服务查找进程，这个进程负责不断监测符合条件的服务实例的可用性。
-
参数接收：接收用户提供的处理函数（具有
std::function<void(ServiceHandleContainer<T>, FindServiceHandle)>签名）作为第一个特定参数，同时进行其他必要参数的初始化。
3.1.1 监测服务实例可用性
-
绑定检测机制：通过特定的绑定检测机制来跟踪服务实例的状态变化。这些绑定是由服务接口部署形式的服务实例清单中的相应服务接口配置的技术绑定。
-
状态变化检测：持续检测那些与StartFindService() 的调用相匹配的服务实例的可用性是否发生改变。
3.1.2 回调处理
-
触发条件：每当绑定检测到服务实例的可用性发生改变时，触发回调操作。
-
回调执行：调用用户提供的处理函数，将包含当前可用的服务实例的句柄的更新列表（以 ServiceHandleContainer 容器形式）以及 FindServiceHandle 参数传递给该处理函数。
-
初始调用：在 StartFindService() 被调用后，即使在初始阶段没有服务实例可用性的变化，也会使用当前可用的服务实例（可能是空的句柄列表）来触发用户提供的处理函数，类似于一次性的 FindService() 方法的行为。
3.1.3 停止服务查找
-
停止机制：用户可以通过调用 StopFindService() 方法（使用 StartFindService() 返回的 FindServiceHandle）来停止正在进行的监视服务实例可用性的后台活动。
-
序列化处理：在整个过程中，由于处理者不必是可重入的，所以绑定实现者必须负责序列化对用户提供的处理函数的调用，确保操作的有序性和正确性。
