苹果推送机制APNs(一)
推送是解决轮询所造成的流量消耗和电量消耗的一个比较好的解决方案,在Android上,虽然Google提供了GCM(之前为C2DM),但在国内基本等于没用,各大Android应用基本都自己架设推送Server或是使用第三方推送平台,例如新浪微博使用第三方推送平台“个推”(非广告大笑)。今天要学习的是苹果提供的推送服务APNs(Apple Push Notification services)基本原理和工作流程。
苹果的推送服务APNs基本原理简单来说就是苹果利用自己专门的推送服务器(APNs)接收来自我们自己应用服务器的需要被推送的信息,然后推送到指定的iOS设备上,然后由设备通知到我们的应用程序,设备以通知或者声音的形式通知用户有新的消息。推送的前提是装有我们应用的设备需要向APNs服务器注册,注册成功后APNs服务器会返给我们一个device_token,拿到这个token后我们将这个token发给我们自己的应用服务器,当有需要被推送的消息时,我们的应用服务器会将消息按指定的格式打包,然后结合设备的device_token一并发给APNs服务器,由于我们的应用和APNs维持一个基于TCP的长连接,APNs将新消息推送到我们设备上,然后在屏幕上显示出新消息来。整个过程基本就这样,下面我们看一下设备注册APNs的流程图:
上图完成了如下步骤:
1.Device连接APNs服务器并携带设备序列号
2.连接成功,APNs经过打包和处理产生device_token并返回给注册的Device
3.Device携带获取的device_token向我们自己的应用服务器注册
4.完成需要培推送的Device在APNs服务器和我们自己的应用服务器注册
执行顺序如下所示:
这里要提到的一点是,我们的设备和APNS服务器之间的通讯是基于SSL协议的TCP流通讯,二者之间维持一个长连接,当从APNS服务器注册成功后,一定要将device_token发送给我们的应用服务器,因为在推送过程中,首相是由我们的应用服务器(上图中Provider)将需要推送的消息结合device_token按指定格式(后面会提到)打包然后发送给APNS服务器,然后由APNS服务器推送给我们的设备。
好了,注册设备的过程完成了,接下来就是如何推送了:
推送的过程经过如下步骤:
1.首先,安装了具有推送功能的应用,我们的设备在有网络的情况下会连接苹果推送服务器,连接过程中,APNS会验证device_token,连接成功后维持一个长连接;
2.Provider(我们自己的服务器)收到需要被推送的消息并结合被推送设备的device_token一起打包发送给APNS服务器;
3.APNS服务器将推送信息推送给指定device_token的设备;
4.设备收到推送消息后通知我们的应用程序并显示和提示用户(声音、弹出框)
比较直观的流程参照下图:
上图显示了我们的应用服务器将消息推送到我们的App的完整路径,其实真正完成推送的是APNS服务器,我们自己的应用服务器只是将需要推送的消息告诉苹果服务器,至于如何维护消息队列或如何保证消息能被推送到指定的设备上,这些都由苹果APNS给我们做完了。
我踏上了新路
如何在mac上安装cocos2d-x-2.2
[译]特殊的Xamarin Libgdx 0.9.9预发布版本
[译]Libgdx和子弹物理RoboVM iOS上通过
[译]Xamarin的问题和构建变更
[译]欢迎你的新领地:Gradle
I’ve been sick the last few days, and figured i’d learn Gradle. I created a Gradle based libgdx template, which you can start using now. It will eventually replace our current Setup-UI to make my life more enjoyable. IT will also allow you to build and run your libgdx projects on the CLI, Eclipse, IntelliJ and even Netbeans. And on top of that, you’ll not have to juggle any JARs or native libraries anymore, everthing is taken care off for you. You can update to different version of gdx, and easily include extensions or other 3rd party libraries. So, what is this magical Gradle?
我最近几天一直在生病,设想我学习Gradle.我创建了一个基于libgdx模板的Gradle,你现在能启动。它现在就可以开始使用,它最终将替代我们目前的setup-ui,使我的生活更有趣。它也将允许你构建和允许你的libgdx工程在CLI,Eclipse,IntelliJ和Netbeans.而最重要的是,你将不必在任何JARs或者更多本地库之间周旋,每一件事情将为你小心关闭。你能更新到不同libgdx版本,并且容易包含扩展的或其他第三方库。那么,这个神奇的Gradle是什么呢?
Gradle is a build and dependency management system, using Groovy and some domain specific language sugar. A build system is responsible for compiling your application and packaging it up. A dependency management system allows you to define which 3rd party libraries you want to use, and the system will automatically pull those libraries in for you. Provided the libraries are available in some sort of repository. The most established type of repository in Java land are Maven repositories, with Maven Central being the global central hub to which almost all things get published to.
Gradle是构建和依赖管理系统,用Groovy和一些特定域的语言sugar.构建系统是负责编译你的应用程序和打包。一个依赖管理系统允许你定义你想用的第三方库,且系统将自动为你放那些库。准备的库是可用的在一些资源库里。历史最悠久的库在Java领地和Maven资源库,Maven中央仓库,几乎所有的事情都发布在全球中央仓库。
Here’s what defining such dependencies looks like in Gradle for a libgdx project that also uses the FreeType and Bullet extensions (no GWT and iOS yet):
下面是定义了一个libgdx工程在Grdle的许多依赖是什么,也用于FreeType和Bullet扩展(还没有GWT和iOS)。
[译]第一个基于RoboVM/Libgdx应用上架AppStore
For about 2-3 weeks now i’ve been actively switching our libgdx game dev framwork’s iOS efforts over from Xamarin/IKVM to RoboVM. For those of you who missed the last few weeks of libgdx updates, here’s a breakdown what RoboVM is and why we use it.
大约2-3周,现在我一直积极地切换我们的libgdx游戏开发引擎的iOS从Xamarin/IKVM到RoboVM.对于哪些近几周未更新最新版libgdx,这儿有一个详细说明为何我们要用RoboVM.
##What’s RoboVM?
##RoboVM是什么?
The promise of RoboVM is a fully workable ahead-of-time compiler for JVM bytecode for iOS (and 32-bit Linux/Mac if you fancy that). RoboVM uses Soot and LLVM to transform the bytecode to native x86 or thumbv7 ARM code. RoboVM employs Android’s latest runtime class library iteration, making it compatible with pretty much any JVM library/language out there. RoboVM also comes with a set of bindings to the ObjC APIs of iOS. These bindings are realized via a custom Java-to-native bridge called Bro, and generated automatically from header files, with minor manual intervention. JNI is of course also supported, pending some more esoteric features.
RoboVM许诺它是一个完全可运行的ahead-of-time编译为JVM字节码iOS(和32位的Linux/Mac,如你看中的那个)。RoboVM使用Soot和LLVM转换字节码为本地X86货thumbv7 ARM代码。RoboVM采用Android的最新运行类库迭代,使其兼容几乎任何JVM库/语言。RoboVM还带有一组绑定iOS的ObjC API.这些绑定实现通过一个自定义JAVA到本地的桥叫弟兄,并自动生成头文件,有轻微的人工干预。当然也支持JNI,处理一些更深奥的功能。
##Libgdx, Xamarin & RoboVM Previously we leveraged [Xamarin iOS] plus a port of IKVM by Michael Bayne of PlayN fame to get our Java based game dev framework to work on iOS. This combination worked, but had its flaws. For one, not all of the Java runtime classes were supported, most prominently the java.net package. Also, some parts we heavily rely on in libgdx, like JNI, were extremely slow with the Xamarin/IKVM hack. Note that this is not an issue with Xamarin iOS itself, but due to the nature of the IKVM port. Xamarin have been extremely helpful and gave us a few licenses at a very low discount for development. All this limitations also meant that running anything complex was always a gamble, and using other JVM languages was pretty much out of the question.
之前我们利用Xamarin iOS附加PlayN的Michael Bayne开发的IKVM的部分整合我们的基于Java游戏开发框架工作在iOS上。这种组合工作,但是有它的缺陷。例如,不能支持所有的Java运行时类,特别显著的是java.net包。此外,一些地方我们严重依赖于libgdx,像JNI,Xamarin/IKVM极其缓慢。注意这个不是Xamarin iOS自身的问题,而是归咎于IKVM端口的性质。Xamarin一直有非常有帮助,给了我们几个很低折扣的开发许可证。所有这个限制也意味着运行任何复杂的都是一场赌博,并使用其他JVM语言几乎都出问题。
RoboVM fixes many of these issues. The JNI bridge is considerably faster, there are less layers of abstractions, all of the Android runtime classes are available, it will allow us to write games in Scala and JVM languages other than Java, and best of all, it’s entirely open-source under Apache 2. Libgdx development on iOS thus becomes essentially free, apart from the Apple tax (developer license, need for a Mac). Note that Trillian AB will eventually have to start looking into options to further fund RoboVM. If we get a chance as a community to help fund RoboVM, we should definitely do so. RoboVM is shaping up to be an excellent tool, and i think it’s worthwhile to support, just like Xamarin.