现在还有多少人做 C++跨平台移动开发？

[cyxcw11]

我们部门现在想用 C++做跨平台移动开发，底层业务逻辑用 C++写，上层 UI 源生。
大家有类似的经验么？有多少坑？

[missdeer]

@crayygy 从你的 id 和回复记录看，我猜你是 Android team 的 Guangyu Yang ？

[cyxcw11]

@FrankHB 我是想既然用 C++那么痛苦，两边直接用源生可以了。
如果是轻量级的 APP 再考虑跨平台技术，如 Flutter、RN

[cyxcw11]

@missdeer 大佬，我认为招人难这点就很致命了，你们团队是不是长期存在严重的人力缺口？或者说某些业务 /项目，因为人力的问题，不得不采用源生方案？

[cyxcw11]

@damngood Dropbox 都这么说，仍然有很多人不信邪的，我也很不理解。

[missdeer]

@cyxcw11 确实一直在招人，内部推荐的奖励也越来越高，但是还是很难招到人，当然也不能排除学历门槛和薪资吸引力不够的原因。不过我们 C++的 code base 很大，我能预见的未来被换掉的可能性极低。。。

[mmdsun]

做过 Xamarin 跨平台 App 开发。

[cyxcw11]

@missdeer 学历门槛是必须的，薪资如果比平时的移动端开发，高出太多的话，公司 HR 也会不爽。
我觉得难招的主要原因，还是 C++从业者很少投移动开发，现在大多数是后台、游戏引擎、人工智能方向。你一个移动端方向除了要 C++技能还需要 Android(Java)/iOS(OC)技能，别人优先会不考虑。
靠应届生补充的话，依然不是很靠谱，C++要求素质太高了，应届生都要培养好一段时间才能保证不经常踩坑。

我觉得能做到新项目新业务，不继续陷入 C++的这种假跨平台方案，已经够 hold 得住场面的了。

[taogen]

一般的应用，客户端的逻辑有很复杂吗？不是 UI + call HTTP API 吗

[MarkTonyFromMars]

有一篇 slack team 的文章, 供参考 https://slack.engineering/client-consistency-at-slack-beyond-libslack-c9cfbe778fb7

[dosmlp]

这种模式没啥不好的，但是人不好找，离职成本也很高，有时候都找不到接手维护的。。。。。

[NonClockworkChen]

成本不划算啊，前期 20%，后期 80%。。。还不如招原生。
这种跨平台项目，不失败，我是觉得很难。 不知道，大佬都是怎么想的。。。做过一段时间 RN 的菜鸡，留。

[feelapi]

规模很大，有多大？我接触的一个跨平台的（ win，mac，ios，android ），几百万行的 cpp，无界面。界面开始是一个自己开发的库，js 驱动，后来放弃了。现在改成 node.js 方案。cpp 部分成为 node。界面部分是 js。
开发人员主要是由二十个左右的，有三十年 cpp 开发经验的人员组成。产品已经在全球运行了几年。用户很多。
这种项目，优先考虑不是语言，是你有没有合适的人和研发组织。找不到人，人员变动大，研发组织混乱，什么语言都没用。
那这个平台为什么能成？很简单，开发组由公司老板领导，成员都是几十年的老员工，老板第一线写代码，开发组没有沟通问题，没有协作障碍。需求清晰，技术路线变革很稳健。这些都是必要条件，没有的话只能自求多福了。

[crayygy]

@missdeer yes，您是？

[lzihua]

可以的 有些业务逻辑 用 C++构建 输出.a 库 iOS 可以接入使用的

[rainymorn]

@missdeer 商业使用时,以 lgpl 动态链接库的形式,不需要买授权吧

[somebody]

https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android

[xsen]

楼上很多人若无大型应用的经验就不要随便给建议，也包括对 C++一知半解的人

1. 大型应用
若都用原生开发的话，成本是极高的（包括不限于人力、开发与测试等等），当然，最大的是后期的维护成本。你要知道，就一端就有可能需要 5-10 个人的研发团队。光移动端就有 iOS/Android 主流的这两个。

而对于大型应用，一般根据公司的长远产品规划，逐步支持非移动端及智能硬件上也是会初步处于规划中的，比如 Window/OSX/Linux，以及智能硬件（如嵌入式的），若是这样的话使用原生的开发对于后续的运维与扩展（新功能、新平台）基本是不可行的，而且成本极高

而且还可能需要提供 sdk 给第三方（有这样的需求的）

2. 小型应用
这样的，随便是原生或是 h5 的方案或别的跨平台方案都是随便的，这个可以根据公司内部已有人员的技术栈选择就可以

3. C++跨平台应该怎么构建
对于这个的话，参考 google 维护的 WebRTC 就可以了——一个平台源码包括构建工具 >10GB

一般的做法，都是“C++库 + 平台接口层 + 原生（一般做 UI 与简单业务）”

稍微有些不一样的就是这个平台接口层的做法某，
a ） 比如可以直接用各个平台的原生语言封装一层提供接口
这种是目前主流的做法，WebRTC 也是这样。比如 Android 则是用 jni 封一层提供接口，iOS 就是 OC 一层；对于 Linux/OSX/Window 等，也是类似的做法。每个平台封装一层做接口

b ）可以网络的方式（如 IPC/MQ/RPC ）
这种更为灵活，这个做服务端是很成熟的做法；对于做大型客户端，有但是不太多

对于具体那种做法，是要根据业务进行综合评估的。

4. 对于 Qt 框架
其实 Qt 之前主要的应用场景是工业或嵌入式（如汽车电子、工控、各种智能设备）这些，对于跨平台这块，若 Qt 敢称第一，应该没有别的框架敢说第二。别拿基于 h5 的方案来说事，不是一个级别上的东西（包括性能、支持的平台等等这些）

做客户端，基于 Qt 好处的地方就是，
a ）提供统一的开发环境与构建方式
QtCreator + qmake/cmake，基本可以应付绝大多数场景与开发环境（ Linux/Window/OSX ）
输出根据自己的方案，可以是动态库或执行文件，都是没有问题的

b ）封装完善的基础功能
包括不限于常见的数据结构、网络（ http/ws 这些）、硬件接口等。简单点就是，很多基础功能不用自己维护，也不需要自己构建或寻找第三方的库（这个可以省事很多）

简单点就是，常用的基本都有提供


其实这最大的困难的地方就是，要用 C++做跨平台，团队内需要有非常资深的人可以 hold 得住整个框架，只要能够确保这一点，基本是不会有问题的。

另外，C++真的没有如外界所传的那么难。很多时候说难用，其实就是缺乏把握框架与方向的人，因为特性诸多，很容易给滥用。其实不管是什么语言，都存在这个问题，只是 C++更为明显而已。


注：本人维护过基于 C++/Qt 跨平台的客户端软件，源码量 > 50W 行以上，所以对于这块有足够的发言权。

[xsen]

其实若 go 再成熟下（对不同平台的支持——主要是移动平台），做跨平台的客户端 go 应该是最合适的做法。UI 层与业务层通过 RPC/MQ 这样的方式提供接口或服务

UI 用各个平台的原生来做，也可以用 h5 的方式（如 electron 或 flutter ）

[jsun]

ui 可以参考 cocos 2d 那套框架，但是移动端开发真心不建议 c++，开发和维护成本太高

[dabaibai]

会用一部分。