Java Unified SDK 版本升级,老版本 Android SDK 和云引擎 SDK 将于 9 月底停止维护

我们在 2018 年 9 月推出了 Java Unified SDK,该 SDK 可以在 Java、Android 和 LeanCloud 云引擎三种环境下运行,支持数据存储、LiveQuery、即时通讯、云函数、推送和混合推送等全部核心功能,并且开放所有源代码(代码见这里)。本周我们对 Java Unified SDK 进行了小版升级,当前最新版本为 5.0.13,老版本 Android SDK 和云引擎 SDK 则将于 2019 年 9 月底完全停止维护。

由于不同平台的 SDK 版本众多,这里我们给大家梳理一下 Android/Java SDK 的版本分布以及将来的持续开发计划,帮助开发者快速升级或者选择到合适的 SDK 版本。

老 Android SDK

LeanCloud 服务上线之初,就推出了原生的 Android SDK,演变至今,因为功能的不同,老的 Android SDK 已经分为了多个 library:

  • 核心 SDK (cn.leancloud.android:avoscloud-sdk)
  • 推送和 RTM SDK (cn.leancloud.android:avoscloud-push)
  • 混合推送 SDK (cn.leancloud.android:avoscloud-mixpush)
  • FCM 推送 SDK (cn.leancloud.android:avoscloud-fcm)
  • 应用内搜索插件 (cn.leancloud.android:avoscloud-search)
  • 用户反馈插件 (cn.leancloud.android:avoscloud-feedback)

各个 library 依赖关系如下:

cn.leancloud.android:avoscloud-feedback/avoscloud-search
 +- cn.leancloud.android:avoscloud-sdk

cn.leancloud.android:avoscloud-fcm/avoscloud-mixpush
 +- cn.leancloud.android:avoscloud-push

cn.leancloud.android:avoscloud-push
 +- org.java-websocket:Java-WebSocket:1.3.9
 +- com.google.protobuf:protobuf-java:3.4.0
 +- cn.leancloud.android:avoscloud-sdk
    +- com.squareup.okhttp3:okhttp:3.8.1
    +- com.alibaba:fastjson:1.2.37

上面这些库都已经发布到了 Maven Central Repo,当前最新版本为 4.7.12,他们最终都会被新的 Java Unified SDK 所取代。

老版本云引擎 SDK

为了支持云引擎的功能,也因为 Android SDK 与 OS 绑定过于紧密,所以我们推出第一版云引擎 SDK 的时候,重新实现了 LeanCloud 核心 SDK 的功能,形成了云引擎运行环境使用的一套专用 SDK:leanengine-java-sdk(group: cn.leancloud, artifactId: leanengine),最新版本为:0.3.3。leanengine-java-sdk 的主要依赖如下:

cn.leancloud:leanengine
 +- cn.leancloud:java-sdk (LeanCloud Java Runtime SDK)
 |  +- cn.leancloud:fastjson-leancloud(*)
 |  +- org.json:json
 |  +- cn.leancloud:okhttp-leancloud(*)
 |  |  \- cn.leancloud:okio-leancloud(*)
 |  +- cn.leancloud:leancloud-common (LeanCloud 底层核心 SDK)
 |  +- cn.leancloud:android-stub (LeanCloud 模拟的 Android OS 接口层)
 |  +- org.apache.httpcomponents:httpcore
 |  \- org.apache.httpcomponents:httpclient
 +- javax.servlet:javax.servlet-api

基于 Java 运行时的云引擎项目,都需要依赖 leanengine-java-sdk(详见模版项目:java-war-getting-started)。

云引擎 SDK 是完全独立的 codebase,并且还依赖于几个 LeanCloud 自己 fork 的、版本较老且已不再维护的基础 library:

  • cn.leancloud:fastjson-leancloud
  • cn.leancloud:okhttp-leancloud
  • cn.leancloud:okio-leancloud

与 Android SDK 一样,云引擎 SDK 也会被新的 Java Unified SDK 所取代。

Java Unified SDK

为了降低维护复杂度,统一 Android / Java SE 运行环境同样接口的行为,我们在 2018 年 9 月推出了 Java Unified SDK,希望用一套代码,来支持多个平台,降低内部维护难度的同时,也可以较好地保证不同平台上接口和功能的一致性。

新版 Unified SDK 发布之后,经过了多轮迭代,目前已经稳定并且被发布到了 Maven Central Repository

新的 RxJava 风格 API

老版本 SDK 所有的网络请求都是通过 Callback 方式实现的,在实现多轮前后衔接的业务逻辑时会导致代码嵌套层级过多,影响阅读,同时在 Java 开发环境下这种异步的方式也不太友好。为此,Java Unified SDK 的存储接口完全基于 RxJava 来构建(同时也兼容老的 Callback 方式),通过函数式编程风格的改变,给业务开发带来更多便利。

新 SDK 层次与依赖

Java Unified SDK 主要包含以下几个 library,其层次结构以及平台对应关系如下(完整列表见这里):

  • 基础包(可以在纯 Java 环境下调用)
    • storage-core:包含所有数据存储的功能
    • realtime-core:部分依赖 storage-core library,实现了 LiveQuery 以及即时通讯功能
  • 云引擎使用的包
    • engine-core:是 LeanCloud 云引擎项目需要依赖的包。
  • Android 特有的包
    • storage-android:是 storage-core 在 Android 平台的定制化实现,接口与 storage-core 完全相同。
    • realtime-android:是 realtime-core 在 Android 平台的定制化实现,并且增加 Android 推送相关接口。
    • mixpush-android:是 LeanCloud 混合推送的 library,支持华为、小米、魅族的官方推送。
    • leancloud-fcm:是 Firebase Cloud Messaging 的封装 library,供美国节点的 app 使用推送服务。

如何使用新 SDK

获取 SDK

获取 SDK 有多种方式,较为推荐的方式是通过包依赖管理工具下载最新版本。具体可参考文档:获取 SDK

Android 开发环境 Sample

云引擎 Sample

在公开的云引擎模版项目上,我们新建了一个分支,用来完成 Java Unified SDK 的集成,具体可以参考代码 java-war-getting-started(v5.x 分支)

6 月 10 日起即时通讯和推送 REST API 将开启请求频率限制

尊敬的开发者,

2019 年 6 月 10 日起,我们将对开发版和商用版应用开启直接调用 REST API 进行消息操作(包含即时通讯及推送)的频率限制,以此来提升处理效率和鼓励更合理的设计。客户端通过 LeanCloud SDK 产生的行为不受此限制的约束。商用版应用如有合理的需求希望突破此限制,请联系 support@leancloud.rocks 了解相关的付费方案。

在单位时间内超限的 REST API 请求会被云端拒绝,并返回 429 错误码。因此,请您及时检查应用逻辑,并依据以下列出的最大限制做好相关的适配工作。

限制详情

LeanCloud 云端将所有应用的消息请求放入队列逐一处理。当某一个应用突然大量调用接口发送消息时,该共享队列就会被长时间占用,进而影响其他应用的消息到达速度。为了解决这个问题,我们将对以下请求的频率进行限速。

即时通讯服务

普通消息

1.1 版本:

1.2 版本:

单聊群聊消息接口:

聊天室消息接口:

限制:

商用版 开发版
每应用 1800 次/分钟 每应用 120 次/分钟

所有接口共享以上额度。超过额度限制后一分钟内 LeanCloud 会拒绝请求持续返回 429 错误码,一分钟后会重新处理请求。

订阅消息

1.1 版本:

1.2 版本:

限制:

限制 商用版 开发版
频率限制 每应用 30 次/分钟 每应用 10 次/分钟
总量限制 全天最多 1000 次 全天最多 100 次

所有接口共享以上额度。超过频率限制后 1 分钟内 LeanCloud 会拒绝请求持续返回 429 错误码,一分钟后会重新处理请求;超过总量限制后当天会拒绝之后的所有请求并返回 429 错误码。

广播消息

1.1 版本:

1.2 版本:

限制:

限制 商用版 开发版
频率限制 每应用 10 次/分钟 每应用 1 次/分钟
总量限制 全天最多 30 次 全天最多 10 次

所有接口共享以上额度。超过频率限制后 1 分钟内 LeanCloud 会拒绝请求持续返回 429 错误码,一分钟后会重新处理请求;超过总量限制后当天会拒绝之后的所有请求并返回 429 错误码。

推送服务

商用版 开发版
每应用 600 次/分钟 每应用 60 次/分钟

超过频率限制后 1 分钟内 LeanCloud 会拒绝请求持续返回 429 错误码,一分钟后会重新处理请求。

如果您有任何问题,请联系 support@leancloud.rocks。感谢您的配合。

从 React Native 到 Flutter,移动跨平台方案的真相

作者:LeanCloud 工程师郑鹏

2018 年 12 月,Google 发布了 Flutter 1.0 正式版,似乎再次点燃了人们对移动跨平台开发的热情。上一次出现类似的情况,是在 15 年年初,Facebook 发布 React Native 的时候。四年不到的时间里,有两家大公司相继推出了自己的移动跨平台方案(当然还有 16 年的时候,微软收购了 Xamarin,不过没有前两个那么引人注目罢了),同时这些方案也受到了市场的追逐。这些现象,似乎预示着,跨平台开发才是移动开发的未来,或者说,跨平台开发才是一种更好的开发方式。

既然它是热点,那肯定有可以讨论的地方。不过,在说 React Native 和 Flutter 之前,我觉得要先谈一谈「跨平台开发」。

移动跨平台方案

那什么是「跨平台开发」呢?

通常意义上来说,如果你想在 iOS 以及 Android 系统里,提供有相同内容的 App,那么使用 Apple 提供的构建工具,开发一个 App,然后上架到 AppStore,同时使用 Google 提供的构建工具,开发一个 App,然后上架到 Google Play。这两个 App 的实现,除了使用的工具不同之外,大部分业务逻辑是相同的。你可以发现,在这个过程中,产生了「重复」。

在重构时,如果项目里有大量的重复代码,或者重复逻辑,我们一般会将这些代码或逻辑以函数,模块或库的形式做封装,这个过程最大化的消除了重复的代码,最终达到简化项目的代码这一目的。

所以在我看来,「跨平台开发」也是基于这个思想而产生的,人们想要一套减少甚至不用写重复逻辑的解决方案,然后市场给予了人们期望的方案。跨平台方案的最大特点,可以用 Sun 当年在推广 Java 时,所使用的一句口号:」Write once, run anywhere」 作为总结。这一句话,也被如今的 React Native 以及 Flutter 引用或继承。

React Native

React Native 是由 Facebook 所主导的跨平台方案,得益于 Javascript 以及 ReactJS 的流行,React Native 在推出时,便受到了大量的追捧。除了跨平台的特性,React Native 最大的特点就是,可以使用 Javascript 来构建移动应用,并且最终应用的表现形式,可以做到和使用原生开发套件开发的应用相差无几。

React Native 能做到这些的核心原理就是 JavaScriptCore,一个 JavaScript 虚拟机。通过 JavaScriptCore,Javascript 能和其它语言互相转义,同时 JavaScriptCore 能运行在 iOS,Android 以及其它平台上,这些可能性放在一起,就成为了 React Native 的基底。有了这个基底之后,Facebook 便在这个基础之上,封装了各平台的应用层接口,定义了 Javascript 和封装后的接口之间的通信协议,最终,实现了使用 JavaScript 在不同平台开发具有原生体验的应用。

从实现原理以及架构上来看,React Native 似乎是一个不错的跨平台方案,只要封装好各平台的 API,那么我们有理由去相信,人们能够使用 React Native 开发出品质优秀的应用。但是事实上,理想和现实,还是有差距的。在 18 年,Airbnb 以及 Udacity 相继发表了博文,声明全面放弃 React Native,转向原生应用的开发。他们在文章中,提到的最多的就是,React Native 是一个不成熟的方案,虽然它有许许多多的优点,但是这些并不足以去弥补它的缺点带来的损失。AirBnB 以及 Udacity 可能是因为各种预期的理由而放弃了 React Native,不过在我看到 Discord 团队发表的 Why Discord is Sticking with React Native 博文后,算是彻底打消了我在生产环境使用 React Native 的念头。整篇文章看下来,让 Discord 团队仍然继续使用 React Native 的最大原因,似乎就是项目已经使用了它,骑虎难下了。

JavaScriptCore 的局限性,Facebook 在项目管理上的不成熟,以及不断出现的放弃声明,最终让人们发现,React Native 是一个有趣的方案,但并不是一个成熟稳定的方案。

Flutter

就在 React Native 的人气不断下跌的时候,Google 在一个恰到好处的时机,推出了一套跨平台方案:Flutter,将人们的目光再次聚集到跨平台开发上面。

Flutter 使用 Dart 这门较为冷门的语言来做开发,底基引擎主要由 Skia 和 Dart runtime 构成。Flutter 通过 Skia 和各平台的底层图形库对接,同时提供丰富的基于 Skia 的控件,来实现跨平台的开发。React Native 采用的方式是封装各个平台的应用层接口,而 Flutter 则直接打造了一套跨平台的应用层的开发套件。对这两种不同的方式,我们可以有一个直觉上的判断,Flutter 在性能上是要优于 React Native 的。因为 Flutter 的这种实现方式,其实早已被大量并广泛的使用了,最明显的例子就是游戏引擎。

种种对比和迹象表明,似乎 Flutter 是一个比 React Native 更好的跨平台方案。目前 Flutter 仍旧处于一个上升的势头,也有如阿里巴巴这种大厂给 Flutter 背书,颇具野心的底基框架让开发者有理由相信,只要投入足够的人力,Flutter 可以做到和原生开发一样好。

然而,Flutter 的缺点,也是源于它自行打造了框架,在很多平台特性上,诸如密码管理,选择光标等,Flutter 目前并不能支持,未来能否支持也要打上大大的问号,平台的特性可能和原生组件深度绑定,且目前没有其它接口,所以 Flutter 在现在这种状态下,只能是放弃这些特性的支持。需要提一点的是,React Native 在这方面没有太大的问题。

尽管有一些问题,不过 Flutter 表现出的潜力,还是让人们觉得,这是一个值得一试的方案,只要 Google 给予足够的支持。所以 Google 会吗?

结语

那么,我该选择哪种方案呢?答案:It depends on you.

事实上就是,没有一个完美的方案,任何方案都有利弊和取舍。想使用 Javascript 开发应用,那么就使用 React Native;想构建高性能的跨平台应用,Flutter 是个不错的选择;想最大化平台特性,那自然是原生的开发方式。

除了跨平台方案之间的比较之外,跨平台方案也在和原生开发方式竞争,而且这种竞争往往是不平等的,跨平台方案在新特性的支持上,始终要慢于原生开发方式,所以在市场占有率方面,原生开发方式就有天然的先发优势,这种差距很难被抹平。最终,你可能会发现,也许原生开发方式才是最合适的,因为除了「重复」外,原生开发方式相比跨平台方案,没有其它缺点了。

附记:之前我在 2019 年 3 月的 RTC Dev Meetup 北京站交流过上面的想法,感兴趣的读者可以查看演讲视频和 slide。

题图:Chris Sabor

如何能够保证自己应用数据的安全?|四月汇报

产品动态

应用归档自助激活

为了节省后端数据库的存储空间,我们会自动对近期(最近 30 天内)无数据 API 访问的应用进行归档,开发者要再次使用该应用,则需要联系技术支持进行手动激活。现在,我们在应用控制台上线了「自助激活」的功能,以方便大家使用。

如果有应用被归档了,打开控制台,会看到如下新的变化:

开发者可以点击「激活」按钮,并按照提示完成操作。一般而言,恢复一个归档应用大约需要 10-30 分钟,稍作等待之后您就可以正常使用了。

云引擎支持 MySQL 数据库

LeanCloud 云引擎作为一个带运维的托管平台,其实可以完成很多功能。现在我们计划让云引擎支持 MySQL 数据库,在底层数据存储上与 LeanCloud 存储服务解耦合,使之可以适用更多的业务场景,譬如自定义的业务后台、开源的 CMS 系统,等等。

使用方式上,增加一个 MySQL 数据库实例,其操作流程与云缓存类似:

MySQL 数据库的支持会首先在华北节点上线,之后会逐步扩大到其他节点,以后我们还会支持 MongoDB 数据库,敬请期待。

推荐内容

2019 前端框架对比及评测

测评名单中有没有你正在使用的框架,来看看它的成绩吧!

微信小程序 unionid 登录解决方案

如何在小程序中支持 unionid 登录,既能得到 unionid 登录机制的灵活性,又保留一键登录功能的便利性。

如何保护您的服务器免受黑客攻击

虽然我是一名经验丰富的开发人员,但在注册服务器两周后却遭到了黑客入侵。

常见问题

【数据安全】如何能够保证自己应用数据的安全?

最灵活的保护应用数据安全的方式是通过访问控制列表(Access Control List),通常简称为「ACL 机制」。ACL 背后的机制是将每个操作授权给一部分 用户(User)或者 角色(Role),只允许这些用户或角色执行这些操作。对 ACL 机制和数据安全方面更详细的解释可以参考文档:数据和安全

【控制台】控制台创建应用时,有两种应用计费方式:开发版与商用版。我该怎么选择创建何种应用?

开发版是针对开发测试阶段的项目或个人项目的解决方案。由于开发版是免费的,所以不提供数据备份恢复服务,在集群的设计上是不对可用性和数据的可靠性做保证的。

商用版应用底层使用的是高性能、高可用的基础设施,有更好的冗余和 SLA 保证。除了性能和稳定性方面的保证外,商用版用户还将免费得到工单技术支持、域名备案和绑定、自助数据恢复、自定义 SSL 证书、云引擎性能管理等增值服务。

综上,个人开发或者测试阶段可以选择「开发版」应用,商用项目建议选择「商用版」应用。

【绑定域名】文件不绑定自定义域名有什么影响?云引擎服务不绑定自定义域名有什么影响?

如果没绑定自定义域名,使用 LeanCloud 提供的公用域名,由于受到网络法规的管控与限制,我们无法 100% 保证该公用域名随时可用。为确保您的应用体验不会受到影响,请前往控制台 > 存储 >设置 >文件 设置好自定义文件域名。在控制台 > 个人中心 > 账号设置 > 域名绑定 中绑定云引擎域名。

点击查看更多 LeanCloud 用户常见问题解决办法

2019 年劳动节 LeanCloud 放假通知

LeanCloud 将于 2019 年 5 月 1-4 日按照国家法规放假四天,5 月 5 日周日恢复正常工作。放假期间运维团队仍将在线值班,以应对可能的突发情况,保障服务稳定。

放假期间 LeanCloud 工程师会部分时间在线,处理紧急事件和回复工单。购买了技术支持的用户仍可以通过工单系统来提交问题,我们会尽快回复,但无法保证在一天之内完全解决。若有遗漏我们会在节后第一时间进行处理,希望大家体谅。

如若发生紧急情况,请联系值班人员电话 186-2503-8918,我们会及时响应处理。

2019 前端框架对比及评测

Jacek Schae 原作,授权 LeanCloud 翻译。

我们将基于 RealWorld 示例应用对比前端框架。RealWorld 示例应用的特点:

  • RealWorld 应用

    比待办事项类应用更复杂。通常待办事项类应用不足以传达足够多的知识见解构建实际应用。

  • 标准化

    项目遵循特定规则。提供后端 API、静态标记语言、风格、API 规范。

  • 专业人士编写、审阅

    理想情况下,会是高一致性、高真实度的项目,由使用该技术的专业人士编写或审阅。

比较的库和框架

撰写本文时,RealWorld 示例应用仓库共包括 18 个 Conduit(Medium.com 克隆应用)实现。

本文不考虑框架的流行程度,RealWorld 仓库中列出的前端框架皆纳入对比范围。

RealWorld 前端框架

测度

性能

应用显示内容、可以使用需要花多久?

尺寸

应用有多大?我们只比较编译后的 JavaScript 文件大小。所有应用使用同样的 CSS 样式文件,CSS 文件加载自 CDN。所有应用使用的 HTML 也是一样的。这些框架都支持编译或转换为 JavaScript,所以我们仅仅测量 JavaScript 文件大小。

代码行数

根据规范创建 RealWorld 应用需要多少行代码?公平地说,某些实现的功能要略微多一点,但这应该没有什么显著的影响。我们仅仅测量每个应用的 src/ 目录。

性能

我们将使用 Chrome 的 Lighthouse Audit 测试性能。Lighthouse 返回 0 至 100 间的评分。0 为最低分。
继续阅读

微信小程序 unionid 登录支持来啦

第三方登录模块使开发者能快捷灵活的拥有自己的用户系统,是 LeanCloud 最受欢迎的功能之一。随着第三方平台的演化,特别是微信小程序的流行,LeanCloud 第三方登录模块也一直在改进:

  • v2.0*:增加微信小程序一键登录功能。支持开发者不写任何后端代码实现微信小程序用户系统与 LeanCloud 用户系统的关联。
  • v3.6:增加 unionid 登录接口。支持开发者使用 unionid 关联一个微信开发者帐号下的多个应用从而共享一套 LeanCloud 用户系统。

这两个功能各自都非常简单可靠,但是其中重叠的部分需求却是一个难题:「如何在小程序中支持 unionid 登录,既能得到 unionid 登录机制的灵活性,又保留一键登录功能的便利性」。

在最近发布的 JavaScript SDK v3.13 中包含了微信小程序 unionid 登录支持。我们根据不同的需求设计了不同的解决方案,详情请参考 《在微信小程序与小游戏中使用 LeanCloud · 用户系统》。欢迎在我们的 社区 提出反馈和建议。

*这里的版本指开始支持该功能的 JavaScript SDK 版本。

Swift SDK 即时通讯功能(beta 版)发布|三月月报

产品更新

Swift SDK 即时通讯功能(beta 版)发布

3 月份我们发布了新版本的 Swift SDK(v16.0.0-beta),该版本包含了即时通讯的绝大部分常用功能,已经可以满足多数应用场景的需求,大家可以通过 CocoaPods 安装使用:

# Podfile sample
platform :ios, '10.0'
use_frameworks!

target 'YOUR_APP_TARGET' do # 替换 YOUR_APP_TARGET 为你的应用名称。
    pod 'LeanCloud'
end

下个月我们计划发布正式版,在 beta 版基础上会增加本地缓存、安全签名、黑名单和用户权限管理功能。同时,我们也会同步推出基于新 SDK 开发的全新 ChatKit 应用,新 ChatKit 会支持最新的 iOS 设备以及最近的三个 OS 大版本,它不会再以库的方式集成,而是以开源 Demo 的形式推出,其主要目的是展示如何使用 Swift SDK 来实现各种聊天功能。

除了即时通讯之外,Swift SDK 接下来也会加入 LiveQuery 功能,以及支持 Carthage 和 Swift Package Manager 两种集成方式,敬请期待。

vivo 混合推送(beta 版)发布

这一次我们采用了源码配 demo 的形式来公开这一功能:

vivo 混合推送 SDK 源代码:可参照这里
vivo 混合推送 demo:可参照这里
具体接入的流程可参考文档:vivo 混合推送

欢迎感兴趣的开发者试用,也期待大家给我们更多的反馈。

发票申请变化

从 2019 年 4 月 1 日起,我们将为普通发票申请额在壹万元以下的(含壹万元)用户开具增值税电子普通发票,超过壹万元的开具增值税纸质普通发票,电子发票将默认发送到用户信息中的邮箱。如果您有特殊要求(如必须要纸质发票或者发送到其他指定邮箱),请在申请发票备注栏里写明。

内容推荐

游戏出海技术指南:海外网络实践及优化专场

4 月 20 日,围绕海外市场趋势及网络优化等问题,一起来现场听听他们的实践经验。

 

七款酷炫的 Mac 屏保

你的桌面屏保是什么?

常见问题

【推送】为什么我收不到离线消息推送,该如何排查原因?

消息推送收不到的排查步骤如下:

  • 检查消息是否正常发送到服务器
  • 检查接收者用户是否离线,是否在 _Installation 表中有关联的设备记录
  • 检查是否有设置推送内容
  • 使用控制台推送在线发送工具实际发推送给目标设备查看推送是否出错,比如 iOS 证书不匹配,设备 Token 过期,设备 Token 和推送环境不匹配等

排查问题更具体的细节可以参考文档:为什么我收不到离线消息推送

【在线参数】统计服务下线以后,有办法给我单独开启在线参数功能吗?

作为统计服务的一个附属功能,在线参数已经和统计服务一同下线了。但为了不影响客户的线上业务,我们云端还支持在线参数的读取(4 月底才彻底下线)。

我们建议自行切换到存储服务里面来继续使用在线参数的功能,并且建议应用数特别多的时候将所有应用的在线参数合并到一个应用中,通过不同的名字或属性区分,这样可能最多也只需要开通一个商用版应用了。

如果不能短时间内完成迁移,可以走付费延长「在线参数」这一功能的方案,有此需求的用户可以发邮件至 support@leancloud.rocks 与我们联系,我们会对符合条件的应用重新开放在线参数的访问入口。

点击查看更多常见问题

游戏出海技术指南:海外网络实践及优化专场 | 北京

点击此处报名

国内对游戏版号的限制,让「出海」成了游戏行业的热门词汇。但一款游戏如果想要平稳出海却不是件容易的事,无论是文化、设备还是推广方式都有着明显的差异。而技术方面,单海外网络一项就让不少游戏开发人员感到头疼。

本期活动,我们邀请了资深媒体人罗斯基、IPIP.NET 创始人高春辉、LeanCloud 运维工程师缪思源以及 UCloud 互动娱乐事业部架构师沈皓,围绕海外市场趋势及网络优化等,分享他们的实践经验。

01 活动流程

13:20 – 14:00 签到开场

14:00 – 14:40 游戏出海那些事(海外市场、渠道、产品以及趋势机会判断)

14:40 – 15:20 网络地理之东南亚篇

15:20 – 15:30 茶歇

15:30 – 16:10 海外网络优化及故障排除实践

16:10 – 16:50 出海游戏那些坑(出海及全球服游戏的技术要求及门槛)

16:50 – 17:10 现场抽奖交流

继续阅读

游戏实时对战及排行榜服务将于 4 月 9 日开通商用方案

LeanCloud 游戏实时对战服务及排行榜服务自上线以来受到了众多开发者的青睐,大家熟知的 Google 小游戏《猜画小歌》就是我们游戏服务的用户之一。鉴于商业用户对于云端服务稳定性的要求,我们将于 4 月 9 日起为这两项服务提供免费和付费两种方案,具体如下:

实时对战

实时对战服务从 CCU 和流量两个维度来统计使用量和计费。

  • CCU:同时在线用户数,以当天最高的同时在线用户数为准进行收费。最高支持 5000 CCU,超过 5000 CCU 需使用企业版。收费单位为每 500 CCU,不足 500 按 500 计算。
  • 流量:通信过程中所使用的流量。数据体积越大,通信频率越高,产生的流量也会越大,按照实际用量进行计费。

华北/华东节点

开发版 商用版
CCU 免费 20 CCU / 天 ¥ 25 / 500 CCU / 天
流量 免费 1 GB / 天 ¥ 0.8 / 1 GB / 天

国际节点

开发版 商用版
CCU 免费 20 CCU / 天 $ 4 / 500 CCU / 天
流量 免费 1 GB / 天 $ 0.1 / 1 GB / 天

您可以前往 LeanCloud 控制台 > 游戏 > 实时对战 > 统计 页面查看应用当前的用量。

注:付费方案仅涉及实时对战通讯云部分,Client Engine 服务将继续免费使用。

排行榜

排行榜服务按照请求数量和存储空间来统计和计费。

  • 请求数量:调用排行榜相关接口的请求总数量。收费单位为 1 万次请求,不足 1 万按 1 万次计算。
  • 存储空间:
    • 按照榜单内的总记录数进行收费,包括当前版本的总记录数,以及可选保留的上一个版本总记录数。例如您有一个排行榜 world,除了当前版本的榜单外,还选择保留一份历史版本数据供客户端查询,当前版本的榜单内有 2 万条数据,上一个历史版本中有 1 万条数据,总记录数为 2 万 + 1 万 =  3 万条数据。
    • 收费单位为 1 万条,不足 1 万按 1 万条记录计算。

华北/华东节点

开发版 商用版
请求数量 免费 1 万次请求 / 天 ¥ 2.5 / 万次请求 / 天
存储空间 免费 1 万条榜单记录数 ¥ 0.05 / 1 万条榜单记录 / 天

国际节点

开发版 商用版
请求数量 免费 1 万次请求 / 天 $ 0.4 / 万次请求 / 天
存储空间 免费 1 万条榜单记录数 $ 0.01 / 1 万条榜单记录 / 天

您可以前往 LeanCloud 控制台 > 统计 > 排行榜 > 统计 页面查看该服务的使用量。

如果您有任何疑问,请发邮件至 support@leancloud.rocks  或提交工单来咨询。