背景
总所周知,iPhone的电池容量本身比较小。所以iOS系统本身为了弥补这一短板做出了一个重大的优化 —— 『伪后台』。
这一机制是在iPhone在续航上发挥重大的作用,但是也因为『伪后台』限制了一些更灵活的App响应。
原来早在iOS4开始,iOS为音乐、定位、viop、下载数据等功能提供后台启动的条件,从此以后不管是大到『微信』『QQ』『支付宝』,小如『摩拜』单车这样的应用都获取用户的『定位服务』权限,然后通过它在后台『 无限重启』,也就是那个时候大家都说『更耗电了』。
 
实例
 
 
发现了吗,漫山遍野的后台活动。尤其是『TIM』『Chrome』和『斗鱼』;我只是无意中点到这个应用然后随意看一下,结果发现几分钟的前台工作竟然有十几分钟乃至半个小时的后台活动,这大概就是为什么耗电量越来越大并且iOS越来越卡的根源了把!
 
机制
 
『IOS 后台运行定位介绍及解决办法』
这篇文章为我们讲述了,如何利用定位在后台运行的方法。
 
第一部分
1.先说说iOS 应用程序5个状态:
  1. 停止运行-应用程序已经终止,或者还未启动。
  2. 不活动-应用程序处于前台但不再接收事件(例如,用户在app处于活动时锁住了设备)。
  3. 活动-app处于“使用中”的状态。
  4. 后台-app不再屏幕上显示,但它仍然执行代码。
  5. 挂起-app仍然驻留内存但不再执行代码。
按下Home键时,app从活动状态转入后台,绝大部分app通常在几秒内就从后台变成了挂起。
在内存吃紧的时候,iphone会首先关闭那些挂起的app。
从 iOS 4 开始,应用就可以在退到后台后,继续运行一小段时间(10 分钟);
2.还可以把自己声明为需要在后台运行,就能不限时地运行了。
不过限制为播放音乐、使用 GPS 、voip、。 值得一提的是,有的应用为了达到后台不限时运行的目的,在后台播放无声的音乐(审核不一定会被发现)。
iOS 5 开始又多了一种类型:下载报刊杂志。
然后 iOS 7 则可以下载各种玩意和定时抓取。
iOS 7 需要注意的区别:iOS 7 以前,应用进入后台继续运行时,如果用户锁屏了,那么 iOS 会等待应用运行完,才进入睡眠状态。而在 iOS 7 上,系统会很快进入睡眠状态,那些后台应用也就暂停了。如果收到事件被唤醒(例如定时事件、推送、位置更新等),后台应用才能继续运行一会。因为处理过程变成了断断续续的,因此下载时也要使用 NSURLSession 来处理(即下文中的 Background Transfer Service)。
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后台
1.当前项目特点:
a. 在保存长连接的情况下,用户一直在线,才能即时接收到消息;
b. 在初始化连接的时候,需要做很多处理,如果经常连接,必然很耗电, 所以尽力在后台的时候,不是时常断开后又连接;
2. 通过以上分析,改选用何种方式来保存app后台运行
voip不行;
静音播放,不清除这种方式,是否可以通过审核;
vpns推送,可取的方式,(具体方法: 用户在登录后,发送一个设备的tokenid; 在发送消息时,平台根据对方是离线还是在线,来判断要不要发推送消息)
3.background fetch在该项目中的应用
由于该app在初始化时,需要耗点时间,最好的方式就是通过  后台获取  来处理该工作,这样能保证用户的流畅体验。
 
第二部分:保持程序在后台长时间运行
iOS为了让设备尽量省电,减少不必要的开销,保持系统流畅,因而对后台机制采用墓碑式的“假后台”。除了系统官方极少数程序可以真后台,一般开发者开发出来的应用程序后台受到以下限制:
1.用户按Home之后,App转入后台进行运行,此时拥有180s后台时间(iOS7)或者600s(iOS6)运行时间可以处理后台操作
2.当180S或者600S时间过去之后,可以告知系统未完成任务,需要申请继续完成,系统批准申请之后,可以继续运行,但总时间不会超过10分钟。
3.当10分钟时间到之后,无论怎么向系统申请继续后台,系统会强制挂起App,挂起所有后台操作、线程,直到用户再次点击App之后才会继续运行。
当然iOS为了特殊应用也保留了一些可以实现“真后台”的方法,摘取比较常用的:
1.VOIP
2.定位服务
3.后台下载
4.在后台一直播放无声音乐(容易受到电话或者其他程序影响,所以暂未考虑)
5….更多
其中VOIP需要绑定一个Socket链接并申明给系统,系统将会在后台接管这个连接,一旦远端数据过来,你的App将会被唤醒10s(或者更少)的时间来处理数据,超过时间或者处理完毕,程序继续休眠。
后台现在是iOS7引入的新API,网上实现的代码比较少,博主也没有细心去找。
由于博主要做的App需要在后台一直运行,每隔一段时间给服务器主动发送消息来保持帐号登陆状态,因而必须确保App不被系统墓碑限制。
博主最先尝试了很多方法,包括朋友发来的一个Demo,每180s后台时间过期就销毁自己然后再创建一个后台任务,但是实际测试只有10分钟时间。最后因为考虑到VOIP对服务端改动太大,时间又太紧,所以选择了定位服务的方法来保持后台。
 
究竟有多耗电
图1:
 
图2:
 
这段代码说道每180s则会触发一次后台监听,每60s则会开启一次『定位服务』并且在下一秒停止『定位服务』
这就是说每个APP为了实现『无限后台』的功能,再不做任何额外事务的情况下,每60s就必须开启一次『定位服务』。
具体的时间我是算不来但总觉得挺耗电的。。。
 
『支付宝』的行经
当我关闭了App的『定位服务』后,基本上所有的App的后台活动都受到了限制,但唯独只有支付宝例外,这让我很生气!
我也定要找到原因,等着。。。
 
暂时找不到。。。
 
首先用 retriever 把淘宝与支付宝的 info.plist 配置文件读出,发现确实在 UIBackgroundMode 加入了 audio 的后台权限(谁会用支付宝与淘宝后台听歌?如何过 apple store 审核的?和苹果有 python 交易?)已经具备后台播放无声文件的条件。
在关闭所有权限,正常使用情况下,支付宝和淘宝 2min 的前台时间一般带有 10 到 20min 的后台时间。在没有 fetch 和 remote push 的权限下能达到这么久,只有依靠那 180s 的临时后台和无声文件播放吧,显然前者没法提供这么久的后台时间。
微信与 qq 虽然都有此权限,但是因为带有 voip 与播放音乐功能,也属于正常权限。是否有知道内幕的来证实一下?

版权声明:本文为apem原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/apem/p/11423273.html