月度归档:2019年05月

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 用户常见问题解决办法