MeteorCat Blog

这里主要针对的是引入 AAR 之后需要区分启动之后的渠道包, 涉及到对引入 AAR 配置的重新打包, 也就是 CPS 包. CPS(Cost Per Sale): 按销售付费追踪包, 用于订单归因、数据上报、返佣计算、链接生成加载统计有效买量成本 比如你作为 发行商, 第三方 研发商 在平台上架游戏, 我们就可能会帮助生成指定渠道包给线下推广或者直播主来付费推广. 这时候的付费推广安装包必须在启动的时候就获得属于自己的 标识, 从而方便把后续登陆/支付(买量和付费成本)纳入分成统计. 这样处理可以方便统计以下数据: 指定渠道的获取用户绩效: 某些渠道拉取新用户多, 方便其渠道下面用户维护其注册用户 指定渠道的付费转化率: 某些渠道付费转化率优秀, 这部分可以转化成推广佣金分成 需要区分 CPS 和 渠道包 的差别, 这两者虽然都是有特殊标识, 但是作用是完全不一样的: 渠道包: 指定平台(比如抖音/快手/谷歌)会单独出个包额外做标识, 独有的渠道标识区分平台来源 CPS: 针对自己推广下的来源标识, 用于自身做统一的推广渠道佣金分成 这里有几种 ARR 注入 ...

注意: 需要前置学习 Quarkus 集成 Pekko 篇章配置 Quarkus + Pekko 作为服务端基础 这里的篇章暂时不涉及 集群 概念, 一旦引入集群概念可能 Actor 概念更加复杂. 参考之前说的 skynet 的源码配置就可以知道, 一般都会启动 socket 连接之后会动态创建 Actor 挂载: 连接建立时动态创建 Actor 并挂载 连接断开时销毁 Actor 所有业务逻辑通过 Actor 异步处理, 天然实现连接级别的隔离和并发安全 如果是初学者推荐采用 WebSocket 做网络数据交换成, 主要原因是: 协议简单: 内部已经做好数据分包, 不需要手动去将包划分 数据可视化: 数据内容可以比较直观通过客户端发送数据(Postman之类应用可以直接发送) 集成度广泛: 基本上全平台通用, 甚至于随便编写 html 页面也能作为客户端 而 WebSocket 的基本回调事件如下, 需要先提前封装对应事件信号(这里的生命周期名称可以随便修改): 生命周期名称 触发时机 核心作用 Actor 场景适配 Connect ...

如果要做比较高并发的游戏服务端, 单独采用以下技术栈会有以下问题: Quarkus: 作为集成框架缺少对应 Actor 底层游戏架构, 所以得自己手动实现 Pekko: 作为 Actor 缺少容器托管和快捷数据库 ORM 框架 所以需要将两者结合起来, 就能设计开发出稳定高效的游戏游戏服务端框架, 这里提供简单的 POM 项目依赖文件: 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451 ...

官方文档(需魔法工具): android-library AAR(Android Archive) 是 Android 专属的库归档格式, 可以理解为和后段的 Jar 包类似的格式: 特性 AAR（Android专属） Jar（通用Java） 包含内容 编译后的class文件 + 资源（布局/图片/字符串） + AndroidManifest.xml + 原生库（so） 仅编译后的class文件 + 清单（可选） 适用场景 Android组件封装（自定义View、Activity、带资源的工具库） 纯Java逻辑封装（无Android资源依赖） 依赖Android框架 强依赖（需Android SDK编译） 无依赖（可跨平台） 资源处理 自带资源打包，主工程可直接引用库内资源 无资源打包能力 本篇以 海外游戏上架 的 发行方 来说明 AAR 在其中起到什么作用, 其他相关扩展知识可以去网上获取 在现代化当中开发之中, 手机游戏上架涉及到以下方面: 游戏研发方: 负责开发游戏和生成 Android 应用 游戏发行方: 负责提供自己公司的 S ...

考虑到现有 spring-boot 框架内部冗余越来越多, 所以一直想找比较轻量级的网络框架. 在多次从易用性和轻量化考虑之后发现了 Quarkus 号称 极致优化启动速度、内存占用 的框架. 官方网站: Quarkus 主要选择有以下优点: 大厂背书: RedHat 主导开发, 有大厂做代码质量把控 GraalVM: 同时支持 JVM 模式和 Native Image 模式, 可以将应用打包成原生二进制 功能完备: 大部分 spring-boot 相关都有对应替代, 按照文档将需求切换过去问题不大 这里先生成基础的 POM 依赖配置: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810 ...

之前 传奇类MMORPG 游戏都会去裸写二进制数据来交换, 但是需要客户端去定制处理包装二进制数据. 这种一般和客户端交换数据比较麻烦, 比如定义格式: 12345请求协议二进制: [int32] MSG_ID: 代表对应协议ID[int32] SID: 代表服务器ID, 比如 '游戏1服', 滚服的时候 id 增长很快[int64] UID: 代表数据库用户ID[int32|byte[]] TOKEN: 代表登陆用户的TOKEN, 字符串由 int32(定长的长度) + byte[](顶长二进制) 合并 后续为了出于开发效率和性能大部分采用通用 Google Protobuf 来做数据协议交换: 中文文档 英文文档 因为其广泛跨语言和跨平台特性在游戏应用也很广, 这里主要是选择 Java 版本来引入和生成. 目前的 Protobuf 有以下版本: proto 2: 很早期的版本, 基本上处于维护, 官方不推荐采用 proto 3: 常规维护版本, 追加比较新特性, 移除部分特性实现 proto ...

官方网站: Pekko 在网络开发中, Actor(参与者模型) 是一种并发编程模型, 核心思想是将程序拆分为一个个独立和自治的 Actor 实体, 每个 Actor 拥有自己的状态和行为, 仅通过异步消息传递进行通信, 互不直接共享内存, 带有以下特性: 独立性: 每个 Actor 都是独立的执行单元且有自己的私有状态, 外部无法直接修改其状态, 只能通过发送消息触发 Actor 内部逻辑来改变状态 异步消息传递: Actor 之间的通信是异步和非阻塞的( 发送方把消息丢给接收方的消息队列后就继续执行,接收方按照消息到达顺序依次处理) 单线程处理: 一个 Actor 在同一时间只会处理一条消息, 天然避免了多线程共享状态的竞态问题, 不需要加锁(如synchronized) 地址与标识: 每个 Actor 有唯一的地址, 发送消息时只需指定地址, 无需关心 Actor 的物理位置(本地或远程), 这为分布式系统提供了天然支持 传统多线程模式需要手动处理锁、线程池、资源竞争, 否则容易出现死锁、数据不一致等问题 Actor 主要解决的问题: 共享状态的并 ...

在 Java 项目开发中, 多模块(Multi-Module) 是基于 Maven|Gradle 等构建工具实现的项目结构设计模式, 主要核心是将一个大型项目拆分为多个功能独立和职责单一的子模块(Module), 通过构建工具管理模块间的依赖和打包流程. 看起来很理想, 将代码合并在共同项目下复用大量的功能逻辑从而避免重复开发, 可以减少大项目之后大量冗余代码. 但是实际操作问题点很多, 最终在大量现实问题当中只能直接放弃 Java 的多项目管理, 这里说下主要踩坑的点: 无法单独项目独立: 项目都是寄放在同个 git 仓库, 也就是代表 clone 就能把所有业务秘密全导出(加密哈希和字段检验方式) 循环交叉依赖: 有时候业务很容易出现双方模块做交叉依赖, B 项目交叉用到 A 项目的验证库, C 项目也依赖 A 项目, 升级都要跟随升级 模块编译复杂度提升: 因为归到同个 git 库(比如区分 user/pay 等业务), 某个业务增加新业务提交上去一变动就要全部检测编译 业务堆叠在相同版本库: 所有业务都集中在一个版本库, 日积月累所有人提交版本导致堆叠在一起, ...

最新版本版本的 nginx 相关源(debian 及其发行版)已经集成 Nginx 的 Lua 扩展, 不需要再去手动编译处理相关依赖就能让 Nginx 运行些简单的 Lua 服务: 123456789# 安装 nginx 和 nginx-lua 扩展sudo apt install nginx nginx-extras libnginx-mod-http-lua# 确认是否配置完成, 有输出即可ls -l /usr/lib/nginx/modules/|grep lua# 生成测试配置, 后续在此操作sudo mkdir -p /etc/nginx/lua.d/lib # 生成被 nginx 调用的目录 sudo touch /etc/nginx/conf.d/lua.conf # 测试访问 Lua 功能配置 首先必须要要提醒一下: 不要将日常需求业务在网络基建实现! 能够在 nginx 运行 lua 也就代表能够运行业务代码, 但是这种操作是具有毁灭性的; 业务代码大部分时候逻辑复杂且需要用到大量现代技术(线程池|连接池等), 而内部的 Lua 模块仅仅作为内迁脚本系统是无法实现复 ...