共计 5643 个字符，预计需要花费 15 分钟才能阅读完成。
简介：细想，团队进行跨平台开发已有三年无余，也是团体外面 C ++ 方向里比拟早波及该畛域的部门之一，随同业界跨平台技术倒退与演进，咱们也积淀了一整套基于 C ++ 的跨平台技术体系，本文将以音讯 SDK 为例，详述这一技术演进历程，心愿能给想做跨平台的，尤其是刚步入跨平台开发的同学和团队，一些借鉴和启发，帮忙大家少走一些弯路。此文为本系列文章第一篇，第二篇：跨桌面端之 Web 容器演进 第三篇：跨桌面端之组件化实际对于为什么要抉择跨平台的实现形式 Write Once，Run AnyWhere. 越来越多的业务需要都有对立的业务诉求，依照传统的形式，在开发、测试、保护上的老本都是乘以 N 的，体验也很难做到一致性，特地是简单的业务，实现老本高，导致性能不能很快的上线，各端侧对齐存在老本，综合来看，这样或者相似的业务基于研发效率等思考，抉择用跨平台的实现形式是十分有必要的。
多角色的经营，多场景的触发，多重能力的反对，导致咱们的音讯零碎非常的简单，历史倒退下的多通道音讯零碎底层因为历史倒退衍生出 3 个子系统别离是：BC 音讯 – 最早的阿里旺旺就是基于此 AMP 音讯 – 淘宝天猫的各类经营基于此，衍生进去的次要业务包含商家群、淘友、达人业务等，IMBA 音讯 – 次要是号方面相干的音讯，包含 BC 告诉类的音讯、达人经营，品牌号经营等 别离在不同的 BU 保护，而这些在多平台经营下都是须要的，比方多角色的交融，多载体运行的诉求，每个载体又有多种平台。基于以上背景，研发一个高可用、高复用、可定制的跨终端音讯模块是十分有必要的。对于语言的抉择 抉择编译型语言还是解释型语言，我感觉是没有相对而言的，具体抉择哪个要依据面对业务状态，适配的终端类型等多方面抉择而言，这里说下咱们抉择 C ++ 作为跨平台开发的首选语言一些背景。咱们团队自身是客户端的业务型团队，以后须要跨平台的业务次要是音讯以及音讯衍生业务的开发、保护和翻新。次要的终端包含挪动 IOS、挪动安卓、MAC、WINDOWS。次要载体包含淘宝 app、天猫 app、千牛 app、淘特 app、1688app、ICBU app 等等。C++ 作为人造的跨平台语言，能够高效无缝的调用零碎能力，有丰盛的技术生态，综合组内的技术栈，是比拟符合咱们的。其实也跟团体里其余几个有相似需要的团队聊过，目前抉择比拟多的也是 C ++ 技术栈，本文也将以 C ++ 作为跨平台选型语言为次要来讲述。即便是对于客户端而言，可抉择跨平台语言也是泛滥的，通常跟随着跨平台技术计划一起来看会比拟好一些，没有相对的对和错，只有是否适宜你。对于根底库的抉择 既然抉择了 C ++ 作为咱们跨平台开发的根底语言，那么面临的第一个问题是须要有一个性能较为齐备，且合乎以后诉求的根底库。咱们调研了市面上几个支流的根底库
再联合团体内过后的现状，特地思考挪动端的现状：包大小问题团体中多种中间件（mtop、db、accs 等）要不然未然跨终端，要不然在各端上都有较为优良的独立 sdk 提供，基于第一点思考，这一部分不须要在根底库里二次建设。综合以上因素，团体内没有适合的足够小的且满足需要的 c ++ 根底库，因而咱们过后决定自研一个基于 C ++ STD 的合乎挪动端现状的轻量级跨终端根底库。
这里是跨终端轻量级根底库 (LITE) 的一个性能汇合图，在对这部分进行设计的时候，次要思考的几个设计准则：根底能力要圈笼罩，综合思考包大小，性能 以及耗电量等除了提供默认实现外，当零碎层面有比拟好的能力、或更优解时时，复用端上的能力，通过对立的形式嫁接。举个例子，团体中间件 mtop，accs 等，亦或者诸如 Crypt 模块，咱们冀望用比较简单的形式去实现，调用了 Openssl 的加解密接口，相熟 Openssl 的同学都晓得他的库大小在 1M 左右，同时 IOS 零碎间接就提供 Openssl 能力，所以在做这一部分的时候咱们提供了默认实现，同时凋谢对立接口接入零碎能力，从而实现包大小最优。总结一下设计准则 9 个字：最小够用可扩大准则。平台包大小 (kb, 根底性能) 阐明 ANDROID43kb 动静库，v8aIOS116 动态库，理论占 app 大小 Windows47kbx86 包大小状况如图（未蕴含淘宝天猫根底客户端能力，蕴含后略减少 60k 左右）。目前 Lite 库曾经作为淘系 C ++ 根底库集成在团体的近 100 个 App 里，除了包大小劣势外，稳定性也极佳，百万分之 1 左右的解体率（淘宝双端统计），同时与淘宝天猫架构组合作，无缝提供淘宝天猫客户端根底能力（log、埋点、键值存储等）。对于跨平台的架构抉择 通常技术还是为业务服务，还是贴近业务来讲述，能更有体感一些，这样也更直观的把咱们遇到的问题和背地思考透漏给大家，作为参考，还是以音讯为例：咱们面临的问题和诉求：屏蔽通道，以对立的数据模型形式对外提供：底层须要对接 3 个服务端（多通道），同时每个 server 端提供的能力、性能又高度类似，须要形象后对立屏蔽提供给下层，此外相干数据须要跨通道或者屏蔽通道存储。调用方线程不对立：业务局部须要解决来自不同线程的高并发（于客户端而言）申请。多语言：接入层须要适配不同平台，ANDROID-JAVA，IOS、MACOS-Object C，WIN-C++。多维度反对定制：业务定制：业务上须要面对不同的 APP 能够有不同的性能定制，这里还包含反对通道的可配置，业务能力的可定制等，举个例子：在淘特里无群聊服务，然而在淘宝里这一部分又是须要的，在千牛里须要有商家群，但不须要有淘友关系群，等等基于业务、以及包大小思考的定制。线程调度定制：基于耗电量、系统资源、平台个性等思考，须要线程调度计划的可定制。在挪动端对耗电量比拟敏感且系统资源无限，然而 PC 端上对性能要求会更高一些，如何在对立的计划里反对线程调度的平台级、甚至是业务级别定制。网络流量治理定制：对网络能力一方面要有对立的监控，不便判断 MTOP 的各种 API 调用状况剖析，另一方面须要有对立的切面能力，在 MTOP 的调用上做二次业务级别的网络流量接口优化定制。DB 治理定制：基于 FD、平台特定等思考，须要 DB 治理能够依据不同的平台有不同的定制策略，在挪动端采纳单用户一库多表的模式，在 pc 端性能最大化采纳多库多表甚至须要反对不同 app 的不同 db 治理计划可定制。根底能力复用：对于团体通用的根底组件，须要有对立的能力从内部获取从而不便 c ++ 层应用。稳定性保障：是否不便做单元测试，设计上如何防止单元测试对外部代码的入侵。基于以上，咱们设计了 MessageSDK 的架构大抵如下：
来整体看下下面的设计是如何解决这些问题的。总体分 5 局部，Service 层，业务层，数据层，数据通道层以及根底服务层。从上到下看整个架构设计 Service 层：也就是咱们通常说的 Wrapper 层，其目标是为了翻译业务层 C ++ 的接口，提供三种形式的间接接入，Java，Oc，C++，须要阐明的是这一层不要做除语言转换外的任何代码，一来不便问题排查，wrapper 不做额定的解决和问题排查，二来业界也有不少自动化实现语言翻译的工具，无关这部分咱们前面局部具体聊。业务层：业务逻辑的一个组合，以音讯为例，按模块分为三个子模块第一个音讯模块，第二个 profile 模块，第三个群模块，模块与模块之间绝对独立，做强制隔离，代码无耦合，性能可定制化数据层：分为两局部本地存储以及网络存储，其目标是屏蔽数据起源以对立的形式提供给业务层，让业务不感知通道起源，同时在这一层还吃掉所有的耗时操作，IO 以及网络申请，其中 Adpter 次要是屏蔽通道之间的差别，这一部分反对整体可替换，目标进步扩展性，可定制接入三方通道数据通道层：这一部分就是数据起源的通道，次要有 SYNC，WXNet，DB 等根底服务层：是一个跨平台的 c ++ 根底库。其实客户端按层宰割的设计理念，无论是在 PC 时代还是当初的挪动互联，都不是什么不言而喻的事儿，次要关注下这外面的差别点也能够说是这种框架设计的长处。便捷：service 咱们只做语言层面的胶水，缩短前期排查问题的整个链路，不便前期排查和定位问题。同时自动化的实现也再次升高了保护老本。凋谢：上图右侧是 Openpoint 能力，次要是通过一些标准化的凋谢点去凋谢一些能力，让接入方做更多的业务属性，简略来说【每个业务有特定的凋谢点，用对立的模式凋谢进来】定制：业务定制：模块与模块之间互相齐全独立，代码无耦合，强制隔离，实现性能的可定制化，让业务方能够自在的进行业务状态组合的同时做到包大小最优，线程调度定制：对立线程调度解决计划，形象线程配置策略，多 app 可自在配置，下层可抉择平台级线程调度最优计划。网络流量治理定制：网络调用处对立切面解决，一方面对刹时雷同申请做拦挡合并，大幅度降低服务端压力，另一方面针对业务级别做原子调用的合并定制，缩小服务端查问量，此外切面处进行对立打点解决，不便客户端做调用流量监控。DB 治理定制：同线程调度定制，对立 DB 治理调配计划，形象库调配策略，多 app 可自在配置，下层可抉择平台级线程调度的最优计划。扩大：对外提供整体能力，又能够动静替换，目标是提供一种能力让接入方能够放入本人的数据通道，从而实现一个业务的扩大，此办法也极大的不便了前期做对立的单元测试。于 CPP 程序员而言，线程模型是十分重要的，好的设计能够从架构上就防止掉前期一系列隐秘的 bug，这里包含一系列问题，比方：在挪动端上，通常调用者不关怀调用线程，然而在数据层又须要做对立的数据批改和聚合能力业务层频繁调用，过多的锁除了可能会呈现死锁外，也不利于性能最大化。局部接口如果 IO、NET 工夫过长可能导致整个流程中断，或异样。来看下跨终端 SDK 架构设计的线程模型：
接入层：不限度调用线程，升高接入老本业务层 : 按模块做隔离，独自运行在本人的业务线程里，在 biz 层做业务无锁话的同时，做到单业务无锁化，多业务并行化 Model 层 : 次要是做 IO、网络操作，目标是为了业务线程 IO、网络无阻塞 整个线程模型的特点：纯异步，可定制，单业务无锁化，多业务并行化，IO 网络无阻塞。C++ 工程脚手架及 C ++ 工程标准化 C++ 作为人造的跨平台语言，能够高效无缝的调用零碎能力，有丰盛的技术生态。然而理论面向 Android、iOS、Windows、Mac 等多平台的开发过程并不顺滑，次要存在以下问题：平台个性差别、开发语言、开发工具链、编译打包等多平台下我的项目配置保护老本高胶水 (语言转换层) 代码人工接入老本高、重复性工作大、门槛高 (次要是对于 C ++ 开发者) 业务及技术框架选型艰难构建公布计划规范化较差、团体研发平台对跨平台构建公布的设计有余
咱们在想，SDK 开发流程是否能够是一个可被 SOP 的过程？如果有对立的跨平台 SDK 开发 SOP 流程，特地是对于新入此行的同学，当然是十分敌对的。想想 coder 如果能够上来就能够写业务代码，不必关怀框架，工程模型，打包计划等等，是不是美滋滋。为了解决上述共性问题，联合之前咱们在音讯 SDK 上的相干教训，咱们启动了 Eyas(雏鹰)我的项目。Eyas 旨在进一步联合团体技术能力，升高跨终端开发成本，为其提供标准化的作业流程，包含跨平台根底库组件化、业务框架通用化、配置一体化、语言转换层代码工具化，以及公布能力统一化等一整套解决方案，让开发者们能够在轻量级意识跨终端的同时，更专一于业务自身。Eyas 的中文是雏鹰，咱们心愿通过 Eyas，能够一起在跨终端的蓝海中摸索有限可能，同时能够孵化出更多跨平台的模块，让开发者低成本开发跨平台 SDK，保障多平台业务一致性，晋升业务开发效率的同时升高测试老本。为了让开发者能够更快的上手跨平台的开发，咱们拟定了一套跨平台 SDK 开发的作业流程，同时在每一步都提供了对应的解决方案，所有的解决方案均提供工具化的形式来高效、低成本的辅助开发者们进行跨平台 SDK 的开发。下图是 MTL4 上 C ++ 跨平台研发工作流：
其中 IDL(接口形容)的编写 以及 性能代码编写，须要开发者依据理论业务进行开发。咱们从我的项目创立、代码生成、编译选项和构建四个维度剖析。▐ 创立我的项目 跨终端团队在以往的桌面端开发中积攒了很多 SDK 开发教训，也有一套成熟的 SDK 框架代码，然而咱们在孵化新 SDK 时候，还是要花肯定工夫在 SDK 的通用代码的拷贝上，无奈疾速的复制出一个新的 SDK 我的项目。开发者都是懈怠的，为了尽可能的复用代码，晋升开发效率，开发者创造了宏，也创造了模板编程。为了反对复用 SDK 框架通用代码和我的项目配置，咱们提供了基于我的项目模板创立我的项目的工具，疾速实现我的项目工程从 0 到 1 的过程。其实对于刚涉足到跨终端开发的开发者，创立了能够编译不同平台产物的我的项目就曾经开启了跨平台的大门。
▐ 代码生成 代码生成即语言胶水层代码工具化，因为平台开发的语言差别，须要有一层胶水代码来进行语言的翻译，胶水代码自身是没有业务逻辑的，并且消耗开发成本，人工编写代码也会带来出错的危险。咱们应用胶水代码自动化来解决该问题。胶水代码自动化的原理: 依据接口的 idl 形容生成接口文件和胶水代码 JNI: C++ <-> Java 交互的胶水代码 ObjCPP: C++ <-> ObjC 交互的胶水代码
咱们基于 djinni（地址：https://github.com/dropbox/dj…）进行了二次开发，晋升安全性的同时减少了多项 feature，更容易对简单我的项目做模块定制化能力。
▐ 编译配置 + 依赖治理
反对以下能力：应用 GN 治理工程和源码文件，确保多端的 C ++ 我的项目配置统一。对立多平台业务模块定制化能力。反对多平台下不同 IDE 编码和调试。联合团体技术能力，对立依赖治理解决方案，反对通过一份配置文件治理多平台下的依赖。原文链接：http://click.aliyun.com/m/100… 本文为阿里云原创内容，未经容许不得转载。
