13518219792
一，iOS端开发。
创新互联公司专注为客户提供全方位的互联网综合服务，包含不限于网站设计、成都做网站、宿迁网络推广、微信平台小程序开发、宿迁网络营销、宿迁企业策划、宿迁品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联公司为所有大学生创业者提供宿迁建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com
如果购买成功，我们需要将凭证发送到服务器上进行验证。考虑到网络异常情况，iOS端的发送凭证操作应该可以持久化，如果程序退出，崩溃或网络异常，可以恢复重试。
二，服务器端开发。
服务器后台的工作比较简单，分为4步：
1，接收iOS端发来的购买凭证。
2，判断凭证是否已经存在，是否验证过，然后，存储该凭证。
3，将该凭证发送到苹果的服务器验证，并将验证结果返回给客户端。
4，如果需要，修改用户相应的会员权限。
考虑到网络异常的情况，服务器的验证应该是一个可恢复的列队，如果失败了，应该进行重试。
程序退到后台，并不会一直运行。在10分钟后苹果会自动结束这个程序。但在10分钟内还是可以一直向服务器发送请求的。退到后台在appdelegate中有一个uiapplication的中国方法，可以检测到程序已退到后台的动作，这时可以重新创建一个线程去请求服务器
iOS是由苹果公司为iPhone开发的操作系统。它主要是给iPhone、iPod touch以及iPad使用。就像其基于的Mac OS X操作系统一样，它也是以Darwin为基础的。原本这个系统名为iPhone OS，直到2010年6月7日WWDC大会上宣布改名为iOS。iOS的系统架构分为四个层次：核心操作系统层，核心服务层，媒体层，可轻触层
iOS 7中，实际上APP拥有四种后台模式，无论是哪一种后台机制，均需要利用苹果给予的相应后台接口实现。新系统中，开发者可以灵活利用多种后台接口（API）实现更加智能的应用操作。
无后台仅推送
第一种后台方式为传统的无后台操作，仅有苹果推送机制，这种方式出现在iOS 3.x以下的大部分系统版本上。这个方式下，应用在按下Home键后即会关闭退出，其数据通过苹果搭建的推送服务器传输，并不需要应用后台运行。这种方式不太好的原因在于，每次推出后，重新进入均需要重新加载，虽然推送能够统一解决数据和信息的传输，但遇到需要频繁进入应用（如聊天APP）的时候便会显得体验不好。墓碑式
第二种方式为墓碑式的后台机制，这在iOS 4后被大量采用，也就是人们所说的伪多任务。这方式相比较第一种改进的地方在于，按下Home键至主界面后，应用随即进入后台，但其被冻结，并不能进行任何操作。
智能调度后台
第三种为系统智能调度的后台，iOS 7新增的background fetch，这个后台接口在苹果WWDC 2013上有提及，其会根据用户行为自动调整达到效率最优的后台模式，能够处理不是很有时效性的信息获取。例如一些社交、新闻类的应用的后台信息更新，iOS系统便会根据应用启动频率、时间和当前网络和电量的状况来智能分配每个应用的后台获取频率和启动时长。
由于拥有该接口的应用的数据后台刷新操作是统一调度的，因此系统可以在一个进程里面获得多个应用的数据，类似统一的推送机制，这样就能够最大限度地省电。不过这个方式也有一个缺点，那便是开发者不能设定数据具体什么时候更新，因此这个后台方式只能应用在一些时效性和敏感度不高的地方。
真后台
第四种方式便是真后台机制，但iOS的真后台与Android的后台机制是不一样的，为了兼顾系统体验和统一进程管理，iOS在这上面加入了众多的限制。
差不多这样，如果还有要理解的继续说就好了
我最近也在做后端，Python，Ruby，Node 都用了一下，最后选择 NodeJS。
在选择时，Ruby on Rails，Django 第一个出局，因为考虑到 API 应该轻，快。
Python 曾经用过 Flask，考虑过 Bottle。不过两者的 Extensions 的功能都无法需求。
Ruby 的 Sinatra 是最好用的。选择 Sinatra + Mongoid，一个星期可以搞出来（我自己的情况）。
现在选择用 NodeJS 的 ExpressJS ＋ Mongoose 搭配。从 Ruby 转成 Node，主要是因为看上 NodeJS 的性能。Request per Second 的话，NodeJS 7000 左右，ExpressJS 3000 左右，Sinatra 900 左右，Ruby on Rails 300 左右。
我写 JavaScript 都是用 CoffeeScript 写的，所以写起来就像写 Ruby 或 Python 一样，非常 Lisp。
ExpressJS 的开发也是这些框架里面，最活跃的。
用一套安全的，将来也不会被禁用的设备识别体系，就可以了。其实TalkingData早在iOS 6发布的时候就已经开始着手研究相关解决方案了，不用UDID，不需要提取MAC地址，也不用夸应用访问公共剪切板，更不需要借助Safari Cookie，就可以轻松实现独立设备的识别--这套体系就是TIID(TalkingData Independent ID)。目前TIID已经可以做到不受IDFA、IDFV影响，始终保持一致，即便是用户刷机，但只要恢复数据，即可保持TIID前后一致。唯一会导致TIID发生改变的情况就是用户彻底重置设备且放弃恢复备份的数据--对于一个iOS用户来说，这种事件的发生几率极小，即便是更换新的设备，用户也大多会选择从之前的设备备份数据恢复到新设备上。
