1. 初步了解
先看README文档，位于LTS/foundation/distributedschedule/samgr_lite/README_zh.md。
我们对其中的部分内容先做一下初步的理解。
系统服务框架[system ability (SA) framework]，是为了屏蔽不同的硬件架构、不同的平台资源、不同的运行形态等软硬件差异，而提供的统一的系统服务开发框架。
根据处理器的不同架构，如RISC-V架构(基于精简指令集RISC的开源架构)、ARM架构(如ARM的Cortex-M/Cortex-A等)、x86架构(主要用于PC市场，目前鸿蒙暂不支持，但指不定哪天就宣布支持了)等，目前分为两类硬件平台，以下简称M核(平台)、A核(平台)。
- M核：处理器架构为Cortex-M或同等处理能力的硬件平台，系统内存一般低于512KB，无文件系统或者仅提供一个可有限使用的轻量级文件系统，遵循CMSIS接口规范。
- A核：处理器架构为Cortex-A或同等处理能力的硬件平台，内存资源大于512KB，文件系统完善，可存储大量数据，遵循POSIX接口规范。
系统服务框架基于面向服务的架构(SOA，Service-Oriented Architecture)，提供了服务(service)开发、服务的子功能(feature)开发、对外接口(IUnknown)的开发、以及多服务共进程、进程间服务调用等开发能力。其中：
- M核：包含服务开发、服务的子功能开发、对外接口的开发以及多服务共进程的开发框架。
- A核：在M核能力基础之上，包含了进程间服务调用、进程间服务调用权限控制、进程间服务接口的开发等能力。
依赖关系上：
- M核：系统依赖bootstrap服务，在系统启动函数中调用HOS_SystemInit()函数。
- A核：系统依赖samgr库，在main函数中调用SAMGR_Bootstrap()函数。
我的简单理解：
- samgr是一个系统服务开发框架，开发者可以根据这里规定的规则，开发自定义的服务和功能(service+feature)、接口等等。
示例程序在Hi3861/applications/sample/wifi-iot/app/samgr/，打开BUILD.gn的编译规则即可参与编译。
示例程序可能会有编译错误，可以获取gitee上的最新代码对比着进行修改，或者参考《WiFi IoT 编译samgr模块》 进行修改。
编译出来的程序可能会出现kernel panic，我估计很大的原因是一次性注册和启动的service/feature/task太多了，导致系统资源耗尽引起的，所以最好还是只编译部分需要验证的示例程序，不要一次全部编译完。我后面附上的log，就是只编译了service_example.c和feature_example.c抓取的。
- samgr提供了对所有service、feature、接口的统一管理，包含了跨设备的service/feature的管理和调度，这是鸿蒙系统非常核心的特性之一。
2. 代码目录结构
先看一下LTS/foundation/distributedschedule/samgr_lite/ 的代码结构：
看上去相当复杂。
再看对应的Hi3861/foundation/distributedschedule/ 代码结构：
两相对比，其实大致上是一样的。
去 Hi3861/foundation/distributedschedule/service/samgr_lite/ 目录下看BUILD.gn文件的构建规则，把只在A核上编译的部分灰化，如上表，剩下的基本上就是M核要用到的了。
本文先只从Hi3861工程的角度来看samgr子系统，所以代码基本上只需要看：
- Hi3861/foundation/distributedschedule/service/samgr_lite/communication/broadcast/
- Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/source/
因为samgr“依赖bootstrap服务”，所以连带也要看 Hi3861/base/startup/services/bootstrap_lite/ 的代码。
至于：
- Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/adapter/
这是对调用者屏蔽了平台差异性的统一接口的声明和实现，暂不进一步深究。
- Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/registry/
这里定义了三个弱引用的API：
- SAMGR_RegisterServiceApi()
- SAMGR_FindServiceApi()
- SAMGR_RegisterFactory()
它们在/samgr_server/source/ samgr_server.c 中有实现，估计和跨设备的服务调用有关，但是M核不编译samgr_server，所以，M核的上述三个API其实没做什么工作，这里也暂不进一步深究。
这样清理一下相关代码和模块关系就会发现简单很多，入手也会相对容易一些，下面我们就开始“Read the f**king source code :)”。
3. 大概流程
Hi3861平台在启动到HOS_SystemInit()时，
- void HOS_SystemInit(void)
- {
- ......
- printf("[system_init] [7-4]: SYS_INIT(service)=====================\n");
- SYS_INIT(service);
- printf("[system_init] [7-5]: SYS_INIT(feature)=====================\n");
- SYS_INIT(feature);
- ......
- printf("[system_init] [7-7]: SAMGR_Bootstrap()=====================\n");
- SAMGR_Bootstrap();
- }
会分别通过上面三步来：向samgr注册系统服务(service)、注册系统服务提供的功能(feature)、通过samgr启动并开始管理系统服务和功能。
从抓回来的log看：
- [system_init] [7-4]: SYS_INIT(service)=====================
- [bootstrap_service] SYS_SERVICE_INIT(Init): Bootstrap
- [samgr_lite] SAMGR_GetInstance(mutex=NULL): NO SAMGR instance, Init() to create ONE
- [samgr_lite] Init. g_samgrImpl
- [samgr_lite] Init. mutex[956036]. sharedPool[0-8] reset to 0. status=0[BOOT_SYS]
- [samgr_lite] SAMGR_GetInstance(mutex=956036)
- [samgr_lite] RegisterService(Name:Bootstrap)->Sid[0]
- [broadcast_service] SYS_SERVICE_INIT(Init): Broadcast
- [samgr_lite] RegisterService(Name:Broadcast)->Sid[1]
- [hiview_service] SYS_SERVICE_INIT(Init): hiview
- [samgr_lite] RegisterService(Name:hiview)->Sid[2]
- [samgr_lite] RegisterFeatureApi(serviceName[hiview], feature[(null)])
- [hiview_service] Init.InitHiviewComponent.
- [system_init] [7-5]: SYS_INIT(feature)=====================
- [pub_sub_feature] Init. SYS_FEATURE_INIT(Init) g_broadcastFeature: Provider and subscriber
- [samgr_lite] RegisterFeature(serviceName:Broadcast, featureName:Provider and subscriber)->Fid[0]
- [pub_sub_implement] BCE_CreateInstance: set g_pubSubImplement.feature = &g_broadcastFeature
- [samgr_lite] RegisterFeatureApi(serviceName[Broadcast], feature[Provider and subscriber])
会注册三个系统服务和一个系统feature。
第一个注册的系统服务是Bootstrap，这个时候samgr还没有实例，所以需要先初始化samgr的全局实例g_samgrImpl，然后才能通过RegisterService((Service *)&bootstrap)来向g_samgrImpl注册bootstrap服务。这时候g_samgrImpl会通过SAMGR_CreateServiceImpl()来为bootstrap创建一个ServiceImpl 对象，将该对象加入g_samgrImpl.services向量中，并返回它在向量中的位置[0]，以此作为bootstrap 的ServiceID[0](文中或log中简写为Sid，同样FeatureID简写为Fid，QueueID简写为Qid)。
接下来注册的第二个服务broadcast和第三个服务hiview，就可以直接通过RegisterService((Service *)Xxx)记录进g_samgrImpl.services向量里了，Sid分别是[1]/[2]。
接下来再注册broadcast service的feature：PUB_SUB_FEATURE。feature的注册和运行需要依赖于对应的service，一个service可以有0个、1个或多个feature。通过RegisterFeature(service, feature)的调用，samgr也会先生成一个FeatureImpl对象，再将该对象加入到 g_samgrImpl.services向量中对应的service 的ServiceImpl 对象的向量features中去，以完成feature的注册。这一句看起来比较绕，简单来说，就是g_samgrImpl的services向量管理着所有登记在册的services的ServiceImpl ，而每个ServiceImpl又通过自己的features向量管理自己所有的features。【更具体的实现过程，后面会有详细的代码分析。】
在接下来的系统运行中，serviceName/serviceID(Sid) 和featureName/featureID(Fid) 都是非常重要的信息，samgr可以通过它们来找到对应的ServiceImpl/FeatureImpl对象，并提供相应的服务/功能。
- [system_init] [7-7]: SAMGR_Bootstrap()=====================
- [samgr_lite] SAMGR_Bootstrap. Begin: size=3
- InitializeAllServices: size=3
- Add service: Bootstrap to TaskPool: 0x0...
- TaskPool: 0xfa448...
- Qid: 956360...
- Add service: Broadcast to TaskPool: 0x0...
- TaskPool: 0xfaab8...
- Qid: 956404...
- Add service: hiview to TaskPool: 0x0...
- TaskPool: 0xfac78...
- Qid: 956448...
- [task_manager] SAMGR_StartTaskPool:
- CreateTask[Bootstrap(Tid: 0xe8780), size(8192), Prio(25)]-OK!
- [task_manager] SAMGR_StartTaskPool:
- CreateTask[Broadcast(Tid: 0xe871c), size(4096), Prio(32)]-OK!
- [task_manager] SAMGR_StartTaskPool:
- CreateTask[hiview(Tid: 0xe87e4), size(2048), Prio(24)]-OK!
- [samgr_lite] SAMGR_Bootstrap. End.
这里就是samgr开始为各个登记在g_samgrImpl.services向量里的service创建Queue和TaskPool这些运行环境了，在SAMGR_StartTaskPool() 这一步依次创建和启动service任务/线程，线程入口是TaskEntry()函数，位于Hi3861/foundation/distributedschedule/services/samgr_lite/samgr/source/task_manager.c 文件内。
各个服务的TaskEntry线程，监控着各自的消息队列Queue，从中检出消息，获取Exchange封装的数据，根据里面的相关标记调用相关的msg handler来进行对应的处理。
上面的流程仅仅是启动了用SYS_SERVICE_INIT()和SYS_FEATURE_INIT() 标记的service和feature，而通过SYSEX_SERVICE_INIT/APP_SERVICE_INIT/ SYSEX_FEATURE_INIT/APP_FEATURE_INIT 标记的service和feature(如在前面提到的示例程序samgr里定义的一部分service和feature)，则会在系统启动到 BOOT_APP 这一步时，通过发送消息BOOT_SYS_COMPLETED到Bootstrap的消息队列中，让Bootstrap调用MessageHandle()来处理该消息：通过调用INIT_APP_CALL(service)和INIT_APP_CALL(feature)来完成APP service和Feature的启动，从而提供用户定义的服务和功能。
上面是service/feature的注册和启动的大概过程，主要的工作都是samgr来实现的，这就是samgr_lite组件的基础代码部分所提供的功能。
log和简单的步骤描述，见附件log。
接下来我会对一些重要的结构体进行分解，对部分流程进行详细的分析。
