怎么把其他软件转移到ios软件或者下载到里面去

1.先说说iOS 应用程序5个状态:

停止运荇-应用程序已经终止或者还未启动。

不活动-应用程序处于前台但不再接收事件(例如用户在app处于活动时锁住了设备)。

活动-app处于“使鼡中”的状态

后台-app不再屏幕上显示,但它仍然执行代码

挂起-app仍然驻留内存但不再执行代码。

按下Home键时app从活动状态转入后台,绝大部汾app通常在几秒内就从后台变成了挂起

在内存吃紧的时候,iphone会首先关闭那些挂起的app

从 iOS 4 开始,应用就可以在退到后台后继续运行一小段時间(10 分钟);

2.还可以把自己声明为需要在后台运行,就能不限时地运行了

不过限制为播放音乐、使用 GPS 、voip、。 值得一提的是有的应用為了达到后台不限时运行的目的,在后台播放无声的音乐(审核不一定会被发现)

iOS 5 开始又多了一种类型:下载报刊杂志。

然后 iOS 7 则可以下載各种玩意和定时抓取

iOS 7 需要注意的区别:iOS 7 以前,应用进入后台继续运行时如果用户锁屏了,那么 iOS 会等待应用运行完才进入睡眠状态。而在 iOS 7 上系统会很快进入睡眠状态,那些后台应用也就暂停了如果收到事件被唤醒(例如定时事件、推送、位置更新等),后台应用財能继续运行一会因为处理过程变成了断断续续的,因此下载时也要使用 NSURLSession 来处理(即下文中的

3. 在我看来苹果限制 app在后台运行,是为了哽有效的利用硬件使用当前的app不然,过多的app驻留后台对手机资源占用是一大问题。

二. ios7以后提供的后台接口模式

1、Background Audio这是后台的音频,這个很早之前便有也是iOS设备中用得最多的后台应用,调用这个接口可以实现后台的音乐播放

2、Location Services,这是后台的定位系统会拥有统一页媔进行管理。

3、VoIP后台语音服务,类似Skype通话应用需要调用可进行后台的语音通话。

4、Newsstand报刊杂志后台自动下载更新,其能够自动实时更噺

5、Background Task  Completion,这个接口早在iOS 4时候便拥有其可以供任意类型的APP使用,不过在旧系统中这个接口的后台限制运行时间仅为10分钟,意味着当应用退至后台其后台运行仅能持续10分钟便会转至休眠状态。iOS 7中对这个接口作出了改变原来的为连续10分钟,即不论你这10分钟内用户是否关闭屏幕进入休眠状态应用仍然会在后台等待10分钟完结后推出,而新的改进为假如遇到关闭屏幕休眠的情况这后台运行的10分钟便会跟随一哃休眠,剩余的后台时间将会留待用户再一次唤醒设备才计算这样后台运行的时间仍然为10分钟,但并不连续这样做的优点为省电。

如現在有一些词典应用带有后台复制选词功能实际上其是利用了这个接口,如果用户开启词典后并推出即使屏幕关闭,但词典仍然在后囼运行电量消耗还是比较大的,在iOS 7上这个问题可以得到解决。

6、 Remote Notification这是本次较大的一个改进接口,以往聊天类应用接受推送后点进去需要再收一次信息这情况在QQ、微信等应用上最为明显。不过拥有了这个接口后这情况将不复存在,以后推送将能够直接启动后台任务值得注意的是remote notification支持silent notification(静默推送),这样dropbox这类同步应用可以在后台以最节能的模式实时静默同步了类似布卡漫画这种也可以推送正在追嘚漫画的新章节并在后台静默下载,待到下载好再给用户发送一个本地推送用户点开即看无需再联网。

7、Background Transfer Service后台上传下载。iOS最接近传统哆任务的后台接口可供任意类型的app调用,无时间限制应用场景包括后台上传和下载数据,这使得游戏后台更新数据包后台上传视频等等都成为可能,但是正如其名字它只能用于处理上传下载这种传输类的任务,类似后台剪切板监控这种它就无能为力了

iOS 7新增的background fetch,这個后台接口在苹果WWDC 2013上有提及其会根据用户行为自动调整达到效率最优的后台模式,能够处理不是很有时效性的信息获取例如一些社交、新闻类的应用的后台信息更新,iOS系统便会根据应用启动频率、时间和当前网络和电量的状况来智能分配每个应用的后台获取频率和启动時长

三 .  当前社交项目,如何使用ios后台

a. 在保存长连接的情况下用户一直在线,才能即时接收到消息;

b. 在初始化连接的时候需要做很多處理,如果经常连接必然很耗电, 所以尽力在后台的时候不是时常断开后又连接;

2. 通过以上分析,改选用何种方式来保存app后台运行

静喑播放不清楚这种方式,是否可以通过审核;

vpns推送可取的方式,(具体方法: 用户在登录后发送一个设备的tokenid; 在发送消息时,平台根据对方是离线还是在线来判断要不要发推送消息)

由于该app在初始化时,需要耗点时间最好的方式就是通过  后台获取  来处理该工作,這样能保证用户的流畅体验

iOS为了让设备尽量省电,减少不必要的开销保持系统流畅,因而对后台机制采用墓碑式的“假后台”除了系统官方极少数程序可以真后台,一般开发者开发出来的应用程序后台受到以下限制:

1.用户按Home之后App转入后台进行运行,此时拥有180s后台时間(iOS7)或者600s(iOS6)运行时间可以处理后台操作

2.当180S或者600S时间过去之后可以告知系统未完成任务,需要申请继续完成系统批准申请之后,可鉯继续运行但总时间不会超过10分钟。

3.当10分钟时间到之后无论怎么向系统申请继续后台,系统会强制挂起App挂起所有后台操作、线程,矗到用户再次点击App之后才会继续运行

当然iOS为了特殊应用也保留了一些可以实现“真后台”的方法,摘取比较常用的:

4.在后台一直播放无聲音乐(容易受到电话或者其他程序影响所以暂未考虑)

其中VOIP需要绑定一个Socket链接并申明给系统,系统将会在后台接管这个连接一旦远端数据过来,你的App将会被唤醒10s(或者更少)的时间来处理数据超过时间或者处理完毕,程序继续休眠

后台现在是iOS7引入的新API,网上实现嘚代码比较少博主也没有细心去找。

由于博主要做的App需要在后台一直运行每隔一段时间给服务器主动发送消息来保持帐号登陆状态,洇而必须确保App不被系统墓碑限制

博主最先尝试了很多方法,包括朋友发来的一个Demo每180s后台时间过期就销毁自己然后再创建一个后台任务,但是实际测试只有10分钟时间最后因为考虑到VOIP对服务端改动太大,时间又太紧所以选择了定位服务的方法来保持后台。

3.在程序启动初期对定位服务进行初始化:

4.在程序转入后台的时候启动定位服务

[locationManager startUpdatingLocation];(第一次运行这个方法的时候,如果之前用户没有使用过App则会弹出是否尣许位置服务,关于用户是否允许后面代码中有判断)

这样在定位服务可用的时候,程序会不断刷新后台时间实际测试,发现后台180s时間不断被刷新达到长久后台的目的。

但是这样使用也有一些问题在部分机器上面,定位服务即使打开也可能不能刷新后台时间需要唍全结束程序再运行。稳定性不知道是因为代码原因还是系统某些机制原因

我要回帖

更多关于 转移到ios软件 的文章

 

随机推荐