Android 推送 SDK(精简版)发布|五月汇报

产品动态

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

2019 年 7 月 1 日起,我们将对推送和即时通讯服务中调用 REST API 进行消息操作开启频率限制(请注意,客户端通过 LeanCloud SDK 产生的行为不受此限制的约束),以此来提升服务质量和鼓励用户更合理的使用服务。在限制正式生效之后,单位时间内超限的 REST API 请求会被云端拒绝,并返回 429 错误码。因此,请您注意检查应用逻辑,并就最大限制做好相关的适配工作。接口详情请参考博客

为什么要增加这一限制呢?推送服务我们之前基本是免费使用的,后来虽然把它加入到了商用版套餐中,但是对于用量还是没有任何限制,这样导致的问题就是平台实际成本非常高,而开发者使用上毫无节制还会让平台峰值压力比均值高出百倍以上,直接影响服务的整体稳定性。因此我们现在才需要对使用方式进行一些限制,通过经济手段来引导大家合理的使用公有云的服务。商用版应用如有合理的需求希望突破此限制,请联系 support@leancloud.rocks 了解相关的付费方案。

关于限制门槛以及付费的阶梯方案,根据我们的统计数据来看,对 97% 的商用版用户来说都没有实质影响,而剩下的 3% 用户,也可能通过技术的平滑处理让请求频率降到限制之下,从而不需要额外付费。不管怎样,开发者都可以享受到更稳定的服务,这也能让系统峰值压力有所减缓,让服务提供方的成本有所降低,这实际上是一种「双赢」,是为了业务稳定和可持续发展而不得不进行的转变,希望开发者可以理解并支持我们,谢谢!

云引擎定时任务功能升级

我们重新设计了云引擎的定时任务功能,新的定时任务是接下来会发布的「云队列(Cloud Queue)」的一部分,它兼容之前的绝大部分用法,还添加了一些新特性:

  • 新的定时任务将不再有个数限制。
  • 新的定时任务可以向云函数传递自定义的参数(JSON 形式),可以配置在超时情况下的行为(重试或放弃)。
  • 新的定时任务在控制台界面上会显示上次运行结果和下次运行时间。
  • 新的定时任务被触发时会在云引擎日志中打印日志(包括执行结果)。
「云队列」功能预告

云引擎发布以来,经常会有用户跟我们提出「任务队列」一类的需求,在此之前我们都是推荐大家使用云缓存 Redis 的「Pub/Sub」功能来自己实现,现在考虑到需求的一般性和队列服务的高可靠性要求,我们决定在平台层面提供「云队列」的服务。「云队列」基于云引擎已有的云函数概念实现了重试、去重、结果查询、延时任务、定时任务等功能,是对云函数功能的一个补充。尚未运行的任务会以一种可靠的方式暂存在云队列,即使你的云引擎实例因部署、过载、崩溃而重启,任务也不会丢失,云队列会等待你的云引擎实例恢复正常后继续运行它们。

具体进展和使用方法,可以关注我们的博客和论坛公告。

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

本月我们发布了 Swift SDK 即时通讯功能的正式版(16.0.0),在 3 月份 beta 版基础上增加了本地缓存的功能,提升了效率和稳定性。同时,我们也同步推出基于新 SDK 开发的全新 Chat 应用,Chat 应用支持最新的 iOS 系统以及最近的三个 OS 大版本,它以开源 Demo 的形式推出,其主要目的是展示如何使用 Swift SDK 来实现各种聊天功能。

Android 推送 SDK(精简版)发布

LeanCloud 已经发布了一个标准版本的推送 SDK: LeanCloud Push SDK ,该 SDK 除了推送服务之外,还支持即时通讯和 LiveQuery 服务(共享同一个 WebSocket 长链接),并且由于即时通讯中对文件、图片、音视频消息等功能的支持,它还必须依赖于 LeanCloud 核心 SDK,因此整体上体积会稍大一些。

对于那些只使用我们推送服务的客户来讲,其实只需要提供设备注册(AVInstallation 存储)和消息接收(PushService)的相关操作即可,标准版 SDK 中大部分功能可能反而显得冗余。现在,我们有一些 VIP 客户正在优化产品移动端体验,安装包大小和启动时间是评测中的重要指标,为了协助他们做好优化,我们专门推出了这一精简版 SDK。

与标准版 SDK 相比,精简版 SDK 在体积和启动时间上的优化效果如下:

内容分享

每天我有多少时间可以写代码?

11

大家好,我是老王,程序员一枚,也是 LeanCloud 团队家属。家属因为工作原因,经常以调研(diao cha)为由咨询(shen wen)我一些问题,这次问题是「每天实际有多长时间是用来写代码的」。

常见问题

【推送】同一个账号在两个设备登录过,两个设备都会收到推送信息吗?

推送的时候是根据推送查询条件,在 _installation 表中查找符合条件的目标设备来推送。只要查询条件能包含这两个设备,则两个设备都能收到推送。

如果是登录即时通讯系统,如果没有开启单点登录,用户在登录两个设备后,如果用户不在线会尝试给这两个设备都发离线消息推送。

【推送】Android 非混合推送,控制台推送记录中显示推送成功,但 Android 设备实际没有收到推送,是什么原因?

对于 Android 非混合推送设备,当返回的记录成功数为 1 时,表示一定收到了 SDK 确认收到该消息的回应。即此条推送消息一定是到达了设备。
建议检查推送是否使用了自定义 Receiver 功能(消息中是否有 action 字段),消息到达后 SDK 会直接将消息转交给自定义 Receiver,由自定义 Receiver 完成推送提醒。这种情况需要检查自定义 Receiver 实现逻辑排查消息到达后为什么没有弹出提醒。

【云引擎】新推出的 LeanDB 是什么产品,是用来做什么的?

这是一项新推出的功能,为了满足应用对关系型数据库的需求。目前 LeanDB 提供了 mysql 数据库,可以使用任何支持 mysql 的库来访问它。

接入文档请参考:LeanDB MySQL 使用文档

》》更多使用疑问请点击这里

每天我有多少时间可以写代码?

大家好,我是老王,程序员一枚,也是 LeanCloud 团队家属。家属因为工作原因,经常以调研(diao cha)为由咨询(shen wen)我一些问题,这次问题是「每天实际有多长时间是用来写代码的」。

于是,我对自己的日常工作内容进行了一些梳理。

早上七点半起床洗洗刷刷偶尔刮胡子,风驰电掣的穿好鞋,八点出门。挤地铁换乘,一般需要一个半小时到达公司,偶尔遇到特殊情况会在地铁楼梯台阶上改半个小时的代码。上班花费时间约 2 小时。

我每天会开很多会,开发需求跟产品开会、项目方案沟通会、新人转正评审会、出了故障要开总结会、小组周会、部门周会、团队分享会等若干会议。一天中会议一般会占用 3-6 小时。

每天我还需要一些时间在日常沟通上:

「Hi, 可以帮我看看,这个问题是什么情况吗?」

「王 x,现在有时间吗?新功能什么进度了」

「王 x , 约的面试的人到了」

中午,食堂,便利店,还是外卖,纠结吃什么也会花掉一些时间。排队,找座位,边吃边跟同事聊聊最近热门的游戏,1 个小时也就过去了。

为了避免出现加班加点做大量无用功,产品下需求必须要花一些时间了解,遇到疑问还会与产品反复沟通,这部分工作大约也需要 1 小时。

到晚上,花半小时解决下晚饭,没有意外情况的话,一般会在 21 点下班,十点半到家。回家后打开电脑再花半小时写日报跟工作总结。收拾洗个澡,十二点关灯睡觉,除去 7.5 小时的睡眠时间(在没有半夜突发故障的情况下),一天实际花在写代码上的时间大约为 4 个小时。

忘记提,作为一个十分讲究的程序员,以前我还要花半小时在每天穿什么的问题上,格子衫因为被黑太多不敢穿了,优衣库的卡通短袖又不符合我稳重的开发者气质,感觉衣柜里缺了一件不需要思考万能百搭的短袖。

于是家属给我推荐了她厂新款:LeanCloud 10x 程序员 T 恤。

10x 程序员
搭配

纯棉透气,百搭任意色系长短裤型,自此,我每天写代码时间又多出来了半小时。据说新款上架,购买就送 10x 程序员笔记本一本,活动截止至 6 月 10 日。

点击此处直接购买

以上人物时间均为虚构,如有雷同纯属巧合。

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 分支)

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

尊敬的开发者,

2019 年 7 月 1 日起,我们将对开发版和商用版应用开启直接调用 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 次/分钟
每日推送总量 免费 150 万推送人次/天 免费 10 万推送人次/天

超过频率限制后 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 与我们联系,我们会对符合条件的应用重新开放在线参数的访问入口。

点击查看更多常见问题