【调研,感谢支持】大家经常接入的第三方库都有哪些?

Hello,大家好。

麒麟子最近在整理官方文档的过程中,发现第三方库接入的部分缺乏一些手把手教学和案例。

所以想请教各位,日常接入的第三方库都有哪些,以方便我做一些规划。

不同平台的库都需要,比如:JS 库, C++ 库, OC 库,JAR 库。

谢谢大家的支持。

3赞

之前做项目喜欢用 lodash,让代码变得非常简洁。

Lodash 是一个一致性、模块化、高性能的 JavaScript 实用工具库。

为什么选择 Lodash ?
Lodash 通过降低 array、number、objects、string 等等的使用难度从而让 JavaScript 变得更简单。 Lodash 的模块化方法 非常适用于:

  • 遍历 array、object 和 string
  • 对值进行操作和检测
  • 创建符合功能的函数

Lodash中文地址:https://www.lodashjs.com/

Android/iOS 微信登录 高德地图 Bugly

一、Android/iOS

我觉得这个问题操之过早。目前3.x,2.x 导出的原生项目工程(Android、iOS)结构上存在很多问题,几乎都需要先重构一遍项目结构,才可以正常接入对应平台的SDK

抛开项目结构上的问题,在海外平台上,几乎是标配的SDK

归因平台

  • Adjust
  • Appsflyer

广告平台

  • Mopub
  • Applovin
  • Admob
  • TopOn
  • Mintegral

登录方式

  • Facebook Login
  • Google Login
  • Apple Login

支付平台

推送

IM&语音

二、TS/JS

  • JS/TS 上,几乎都要用到的 crypto-js/crypto-es (实现网络通信上的正常加解密)
  • day.js:日期处理、时区、国际化
6赞

JS库 :JSZIP、protobuf、MD5、 QrCode
jar库: https://github.com/ChinaDragon01/CommonUtilsLibrary-master

guid-typescript 生成唯一id
astar-typescript 用来做寻路

原生的话,一坨,比如用来发海外的话,google play 支付、各种登录、appsflyer统计、admob广告。像楼上说的,做这些事情都要先调整一次生成的项目,后续creator就用来构建个assets,原生构建面板的编译和运行,几乎没用过。

1赞

如果官方可以做一个兼容层去兼容react native的plugin,那生态不就来了… :laughing:

我自己也接过好些 SDK, 并没有发现工程有问题。 能展开说说吗?

Oimo 吧,cocos自带的物理性能有点问题

多人协作

多人协作是一个很正常的项目需求,目前一般都是通过git来协同合作

以 Android 平台发布为例,一个项目是需要接入很多SDK的,可能是由多名同学共同完成下面功能

  • 接入新的SDK
  • review
  • 修bug
  • 加功能

那么第一步,所有同学得要获取到 完整的原生工程代码,但是按照现在Cocos的原生工程目录结构,用起来十分别扭

以 3.x 构建的 Android 工程为例

一、默认构建目录位置问题

Cocos 构建后的 Android 工程默认是在 build 目录,这个目录是不会被纳入版本管理的。不注意的情况下,是项目新增的SDK接入代码,默认是在 build 目录上,这些代码是不会上传到仓库中,其他同学是没法看到。当然我们肯定有很多办法解决这个问题,比如

  • 可以修改 .gitignore 文件
  • 可以修改构建输出目录
  • 修改 build.gradle ,重定向 sourceSet 目录

这就需要我们改一下 Cocos 的原生项目路径或者结构了

二、项目文件太过零散

Cocos 默认构建的 Android 工程是 站在能方便引擎升级 的角度去创建的,由此,一个默认构建的Android 工程目录会十分分散

  • build/android/proj:Android Studio 工程的位置
  • native/engine/common:多个原生工程通用的配置
  • native/engine/android:Android Studio 工程的 Module 配置(包括 app ,instant app)

到这里已经很难接受了。为什么呢?

正常的Android 工程,app module和 settings.gradle 都是一个目录的

而 cocos 这边却分开了两个地方

  • app module 在 native/engine/android
  • settings.gradle 在 build/android/proj

甚至 app module 所在的 native/engine/android 是一个 ignore 掉的目录

简单来说

  1. 你修改的 app icon,是不会同步到 git 仓库中
  2. 即便我们刚刚说的第一步「构建目录」位置不放在 build 目录了,放在其他能纳入版本管理的地方,还不行,因为你还必须处理 native/engine/commonnative/engine/android 这两个 ignore 掉的目录

那么

  1. 你要是移动了 native/engine 的目录,你还必须修改里面 CMake 文件的里面目录路径
  2. 你要是将 native/engine 目录纳入版本管理,那么势必和其他机器生成的 native/engine 产生冲突

怎么处理都是个麻烦事,但是还是得处理

这就需要我们改一下 Cocos 的原生项目路径或者结构了

三、大量绝对路径

像上面刚刚提及到的目录

  • build/android/proj:Android Studio 工程的位置
  • native/engine/common:多个原生工程通用的配置
  • native/engine/android:Android Studio 工程的 Module 配置(包括 app ,instant app)

里面的文件存在大量本机绝对路径的使用,这几乎又是一个难以做多人协作的项目生成方式

比如:build/android/proj/cfg.cmake

set(COCOS_X_PATH "/Applications/CocosCreator/Creator/3.7.1/CocosCreator.app/Contents/Resources/resources/3d/engine/native")

这样子的路径,如果我将这个提交上去,那么让同项目的 Windows 的同学怎么能跑起来呢?

那么肯定是我的使用方式不对。

可能在Cocos看来,多个同学开发 Android 游戏流程如下:

10个同学协同开发一个android游戏,那么这10个同学各自在自己机器上构建各自的Android 工程,去编译构建运行

但是,我觉得应该不是这样子的,正确的开发方式应该是这样子:

10个同学协同开发一个android游戏,应该是其中一个同学提交一份Android工程,然后10个同学共同维护这一份 Android 工程,在里面去协同开发

而现在实在是心情复杂

尽管如此,这个绝对路径的问题在Android上其实还好处理,不多,但是一到构建 iOS 的XCode 工程,实在是一言难尽

四、小总结

简单来说,我们主要是探讨怎么实现多人协作,具体一点是怎么将一个「完整」的Android工程提交,就这一点,已经是十分麻烦了

7赞

谢谢分享,我先对比分析分析。

官方终于觉悟了 像常见的平台(如字节 微信 小米 ov 苹果 谷歌 taptap)登陆 广告SDK 扫码(QRCODE)倒是其次

cocos的原生工程 我呵呵

其实个人觉得 安卓端的 不应该有引擎组去适配的 因为很多东西 都需要自己手动去调整的 就好比 每台机子的sdk都不一样 这个大可以找个专业的人去写好一个完整的安卓 同事在自己电脑换合适的路径 替换文件可以

Hello,大家好。 我补充说明一下。
我做这个调研,不是说要集成SDK到引擎中。
只是想了解一下大家的需求后,以合理的方案,让大家更容易集成和使用SDK。

这个有什么结论了吗

WalletConnect, 接入一直失败,求walletConnect 成功案例

众所周知,我们都没写过几行代码

总所周知, 我们都没写过几行代码

游戏开发里面需要json序列化映射类的这种基本上都是应用在配置文件的解析中吧