跨桌面端之组件化实践

发表于 2年以前 | 总阅读数：311 次

本文主要介绍了千牛PC跨端框架中，我们关于组件化部分的思考、方案选择、遇到的一些问题和解法。

此文为本系列文章第三篇，

第一篇：[跨全端SDK技术演进]

第二篇：[跨桌面端之Web容器演进]

本文：跨桌面端之组件化实践

背景介绍

windows千牛功能很丰富，mac千牛什么时候可以把能力对齐？

相信所有跨平台应用，都有遇到过这样的窘境。由于平台差异的复杂性，维护多端产品成本非常高，且常常存在多端体验不一致的问题。情况就是这样，而我们团队维护了pc千牛和pc旺旺2款跨端产品，在效能和体验的双重压力之下，搭建一个多端统一的pc应用跨平台开发框架势在必行。

本文主要介绍了千牛PC跨端框架中，我们关于组件化部分的思考、方案选择、遇到的一些问题和解法。

所谓框架，它既是一个“框子”，有一定的约束性，也是一个“架子”，有一定的支撑性。IT语境中的框架，特指为解决一个开放性问题而设计的具有一定约束性的支撑结构。在此结构上可以根据具体问题扩展、安插更多的组成部分，从而更迅速和方便地构建完整的解决问题的方案。

为什么要做组件化？

跨端框架为什么选择做组件化？

框架本身一般不能直接解决某个具体问题，但为解决问题的相关组件提供了一些衔接、组合的基础能力。

框架的科学性、易用性，直接决定了研发效率和产品质量。

组件化是用来解决框架功能扩展、复用的一种非常合适的技术方案。

而用组件化模式设计的一个应用框架，一般具备以下特性：

极好的扩展性
极好的复用性
灵活度高，可以很方便组装或下线功能
修改功能，影响范围很小
非常适合团队分工协作

这些优点，每一项都是我们梦寐以求的，所以说组件化对我们几乎是必然选择。

组件化是什么？

组件化是指解耦复杂系统时将多个功能模块拆分、重组的过程，有多种属性、状态反映其内部特性。

举个例子，你要造一个汽车，但是发现汽车实在太复杂了，很难实现，于是：

你把汽车拆分成了底盘，发动机，变速箱，轮子等模块，定义好了他们各自的职责。
然后你找来小伙伴帮忙，先约定好了组件标准，再让每个人实现其中一个独立模块。
你还需要一个控制系统，能够让这些模块互相配合，协同工作。
由于大家都按照一个标准来开发，这些模块很容易被组装到一起，进行管理和控制。
这样，你们实现了一个汽车。

这里的一个功能模块，就是一个组件，用来控制组件协作运行的系统，就是组件框架。

组件框架需要解决的几个问题：

如何发现组件
如何管理组件的生命周期
如何组件间调用
提供的公共基础能力

怎么选择组件化方案？

组件化的落地方案很多，我们怎么选择适合自己的技术方案？

业界的组件化方案很多，例如windows下的com组件，andriod下的ARouter组件，基于消息总线的ths组件，千牛自研的prg::com组件，还有一些基于rpc框架，更宽泛意义上组件化（微服务）。

在我看来，组件化方案没有最好的，只有相对合适的。根据业务场景，选择一个满足当前业务需要，又能适当照顾到未来发展需要，好用好维护的方案就可以。

这里提供一些组件化方案选型一些可参考的维度：

发现机制
通信机制
跨平台
跨编程语言
维护成本
研发效率
编译依赖
性能
稳定性

在跨端千牛的场景下，我们的诉求优先级是：

首先必须是支持跨平台的，
其次是良好的可维护性，长期来看，可维护性对产品质量、效能和研发体验都影响深远。
然后是良好的性能和稳定性，
最后是较好的研发效能和研发体验。

这里我们主要对比了ths组件和prg::com组件方案：

ths组件：ths方案类似于一个rpc调用框架，所有调用以消息的形式在总线上传递，其运行时隔离&有中心节点切面，但其接口可维护性较差，无法在编译期发现问题。ths方案更适合跨团队场景，或开放场景。
prg::com组件：prg::com组件类似于微软的com组件，但它支持了跨平台，并对com接口调用方式进行了优化，调用方便。其接口的可维护性较佳，编译时就可以发现接口兼容性问题，性能也非常不错，十分适用于团队内部的组件化场景。

最终我们选用了自研的prg::com作为跨端框架组件化的技术方案，下面具体介绍一下这个方案。

跨端组件化实践

组件化方案，包含框架能力和组件约束两部分。

框架设计是否科学，组件约束下是否易开发、易使用、易维护，是组件化方案要考量的核心因素。

组件框架，提供了组件运行的基础能力，主要包括：

组件发现机制

组件生命管理

组件间通信

其他公共基础能力 2. 组件约束，定义了组件开发时需要遵循的标准，其主要目的包括了：

支持组件在prg框架上运行，例如组件都继承自prg::com对象，并需要完成I接口注册。

支持组件跨平台，例如ui组件需要遵守mvp分层，在替换ui渲染层时，能确保做到业务逻辑多端一致。

为了便于团队协作，例如文件结构、代码分层、命名规则等，使用相同范式去开发和使用组件。

……

组件约束是根据组件的类型、具体使用场景等因素，分别进行定义的，不同组件的标准并不完全相同。

例如ui组件和非ui组件的标准就有很大的不同。

后面介绍下prg框架，及我们在各种场景下定义的组件约束条件。

▐ prg框架

组件发现机制

prg框架利用模板技术，通过打包时扫描dll生成配置、加载dll时静态注册组件，实现了一套组件发现机制。

prg框架的组件发现机制，依赖于id注册，组件对外只暴露类id和I接口，实现了组件间完全去依赖。

先来看一下示意代码：

// 定义一个prg::com组件
class IxxxService；
DEFINE_IID(IxxxService, "{4E6A382D-1FDA-49C6-8521-E284DA7B71CC}")
DEFINE_CLSID(xxxService, "{D1A52645-7587-4885-ABFD-323BA62905F5}")

// 创建这个prg::com组件
scoped_refptr<IxxxService> spInterface;
prg::PrgCOMCreateInstance(c_uuidof(xxxService),  spInterface);

//////////////////////////////////////////////////////////////////////////
// implement（不对外暴露）
class CxxxService
  : public prg::CPrgCOMRootObject<prg::CCOMThreadSafeRefPolicy>
  , public IxxxService
{
public:
  DECLARE_PRGCOM_RUNTIME(CxxxService, c_uuidof(xxxService), "xxxService", "xxxService", prg::GetDependsCLSID())

    BEGIN_PRGCOM_MAP(CxxxService)
    PRGCOM_INTERFACE_ENTRY(IxxxService)
  END_PRGCOM_MAP()
}；

IMPLEMENT_PRGCOM_RUNTIME(CxxxService);

它的实现原理是：

打包时，扫描目录下所有dll，遍历调用 GetPrgCOMFactory接口，生成组件配置xml。
创建对象时，通过xml配置，找到并load对应的dll。
加载dll时，会创建prg::CPrgCOMObjectRuntime静态变量g_prgRuntime，并在构造时向PrgCOMFactory注册clsid到this的映射关系。
根据clsid，在PrgCOMFactory中找到对应的g_prgRuntime变量，调用CreateInstance静态方法，由于g_prgRuntime变量是带了T类型信息的，就可以创建出对应的T对象。

这里利用了c++模版技术和静态注册技术，巧妙地完成组件解耦，解决了依赖问题和跨模块调用问题。

组件生命管理

prg组件支持无感跨模块创建、使用、释放对象，真正做到了一次开发，到处使用，开箱即用。

prg组件使用scoped_refptr引用计数管理内存，使用者不需要自行管理内存。

prg框架支持跨dll/dylib创建、使用、释放对象，对使用者来说dll/dylib是完全无感的，指定要创建的对象类型，接口类型，实例名称，就可以直接开始使用这个接口了，非常丝滑。


class IxxxService : public prg::IPrgCOMRefCounted
{
public:
    base::event<void()> onDataChanged;
public:
    virtual bool GetData(const std::string& data) = 0;
}

// 创建prg::com组件新实例
scoped_refptr<IxxxService> spInterface;
prg::PrgCOMCreateInstance(c_uuidof(xxxService),  spInterface);

// 获取prg::com组件（没有则create，prg框架内部会保存一份引用）
scoped_refptr<IxxxService> spInterface;
prg::PrgCOMGetInstance(c_uuidof(xxxService),  instanceName, spInterface);

// 判断prg::com组件实例是否存在
prg::PrgCOMHasInstance(c_uuidof(xxxService),  instanceName, bhave);

// 删除prg::com组件实例
prg::PrgCOMDropInstance(c_uuidof(xxxService),  instanceName);

我们一般会将组件获取封装成像下面这样的接口，对于使用者来说，调接口就像调用自己的代码一样方便。

/// 组件头文件
inline scoped_refptr<IxxxService> GetIxxxService()
{
    scoped_refptr<IxxxService> spInterface;
    prg::PrgCOMGetInstance(c_uuidof(UIAppGuideWidget), "", spInterface);
    return spInterface;
}

/////////////////////////////////////////////////////////////////////////
// 其他组件直接调用接口
std::string data;
GetIxxxService()->GetData(data);

组件间通信

prg组件的接口调用和事件订阅。

接口调用

prg组件接口调用与com组件类似，区别在于prg::com做了更好用的封装，可以直接get到I接口对象进行使用。（当然还是支持使用QueryInterface，可以通过QueryInterface获得不同类型的I接口）

class IxxxService : public prg::IPrgCOMRefCounted
{
public:
    base::event<void()> onDataChanged;
public:
    virtual bool GetData(const std::string& data) = 0;
}

// 获取组件
scoped_refptr<IxxxService> spInterface;
prg::PrgCOMGetInstance(c_uuidof(xxxService),  instanceName, spInterface);
// 调用组件方法
spInterface->GetData(callback);

事件订阅

事件订阅派发，依赖base::event实现，是典型的观察者模式。当事件触发时，按照注册顺序挨个调用观察者的base::callback，可以非常容易的完成复杂流程串联。这里的event是实例级别的，配合prg的账号隔离能力，可以很好的解决多账号业务的事件派发问题。但目前base::event暂不支持按优先级注册派发。


class IxxxService : public prg::IPrgCOMRefCounted
{
public:
    base::event<void()> onDataChanged;
public:
    virtual bool GetData(const std::string& data) = 0;
}
// 获取组件
scoped_refptr<IxxxService> spInterface;
prg::PrgCOMGetInstance(c_uuidof(xxxService),  instanceName, spInterface);

// 订阅组件事件
CBaseEventHelper::RegisterEvent(spInterface->onDataChanged, callback);

// 取消订阅组件事件
CBaseEventHelper::UnRegisterEvent(spInterface->onDataChanged);

▐ prg框架的组件约束

prg::com组件要遵循什么约束条件？

不同类型的组件，标准是不一样的，要说组件标准，首先要对组件进行分类。

以阿里旺旺应用为例，跨端旺旺包含的组件，大致可以分成以下几类：

框架层：

ali系pc应用基础组件
平台相关基础组件

框架和基础组件，是阿里系pc应用基座，这些组件由prg框架内置，从而实现快速搭建pc跨端应用的能力。

应用层：

旺旺业务-非UI组
旺旺业务-UI组件

应用层组件，主要用来实现业务功能，这部分组件经常要进行扩展和修改，是我们要重点关注的。

应用层组件，根据其技术实现，又可以分成ui相关和ui无关两种，ui组件会相对更加复杂。

（ps：UI组件上采用pv分层，p层负责控制界面逻辑，使用纯c++实现，view层只负责绘制和操作输入，这样在最大程度复用代码，提高效率的同时，保证业务双端一致。我们的ui组件都遵从这个标准。我们选用了Qt作为跨端UI框架，我们发现，Qt并不能做到UI功能完全跨端，考虑到后续替换UI框架或适配新平台的可能性，我们把Qt的使用范围收敛在UI渲染部分，即view层。）