posted by wap, platform: Chrome
这不写得清清楚楚的

Use the form below to send us your comments. We read all feedback carefully, but please note that we cannot respond to the comments you submit.

posted by wap, platform: Chrome
一、苹果的电话客服基本是傻逼

二、这网站我还第一次看到，但看上去这也不是一个举报或者投诉网站，这是一个关于iTunes使用的反馈收集页面。下拉一下“I Have Feedback About:”这个菜单就知道它主要是用来干嘛的。电话客服提供这个网站给你的原因，我想只能参考第一条。

三、我上官网看了下，这个页面是不是靠谱一点？ http://www.apple.com/cn/support/ios/contact/

posted by wap, platform: Chrome

引用:

原帖由 @aweiwei  于 2015-8-4 17:01 发表
除了这个之外，当年迅雷看看也这么干过，当初号称关屏可以保持WiFi下载视频，就是靠着冒充音频。

iOS7以后就有正经的官方途径的后台下载方法了。比如我用的instacast，就可以后台静默下载最新的音频节目然后在通知中心通知用户。

关于iOS的后台机制，网上有很多文章的，有的人试图在2015年将伪装成音频说成是合理合法的后台手段，真不知道是啥情况：

在iOS7以前的系统中，App默认是不能后台运行的，如果要后台运行，可以采用以下两类方法：

  （1）使用beginBackgroundTaskWithExpirationHandler函数，向系统申请一段时间来执行需要后台运行的操作，这种方法的缺点是，后台操作最多只能运行10分钟，超过10分钟之后App会休眠。使用这种方法需要APPNAME-info.plist中设置Application does not run in background为NO，然后在适当的时间调用beginBackgroundTaskWithExpirationHandler函数。

（2）将App的后台运行模式设置为audio 、VOIP、location、Newstand等。使用这种方法，可以无限制的在后台运行，以audio为例，将plist中的Required background modes项目设置为App plays audio or streams audio/video using AirPlay，并且在进入后台时播放无声音乐，就可以让App一直运行。这种方法的缺点是，如果使用不当，可能会被AppStore拒绝。因为审核时是可以通过静态分析知道使用了哪些API的，如果一个程序本来就不是音乐类的，却使用了播放音乐的API后台播音乐，有可能就被拒绝，如果想要绕过这个限制，可以向APP增加播放音乐的功能，但这样实际是增加了无用功能。

    在iOS7以后，系统增加了两种后台的模式，一种是Background fetch ，另一种是Remote notification，下面分别介绍。

    Background fetch：  设置了这种后台方式之后，当App休眠之后，会隔一段时间被系统唤醒，从而执行一段短时间操作。唤醒的间隔由系统决定，App中可以设置[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:UIApplicationBackgroundFetchIntervalMinimum];，但即使设置了，间隔也不确定是多少。另外，App被唤醒后，可以执行操作的时间也不长，文档上描述的30秒左右（实际上更长也可以，但是可能会降低以后被唤醒的几率）。

  Remote notification：在iOS7以前，当系统收到推送消息后，会立即弹出消息提示用户，用户点击消息之后，就可以启动App，然后加载数据。使用了这种新的后台模式之后，当系统收到推送消息之后，会唤醒App，给App一个机会执行一部分操作，等操作之后才提醒用户，而且还支持silent模式，即执行完操作之后，完全不对用户做任何提醒，默默的就在后台把活干完了。

   除了增加了上述的两种新后台模式以外，ios7还增加了一下传输数据的方法，即Background Transfer service 。

（1）Background Transfer service概述

      这种方法的名字很容易让人误解，以为是App进入后台时，使用这种方法进行数据传输。实际上，这种方法与后台无关。 当App使用了这种方法后，可以将一个下载任务交给系统的独立进程去下载，不管App在前台、休眠、以及crash，下载过程都在进行，因为是系统的独立进程在为App进行下载。当系统的下载任务结束或者出错时，系统会唤醒App，调用其中的函数，让App做一部分处理，比如让App重新添加其他任务。这里有一个缺点就是，如果因为没有网络导致系统下载失败了，系统即使唤醒了App，App也是没有办法下载的，然后App会进入休眠，即使后面有了网络，系统也不会继续下载，因为只要系统向App发出了失败的信号，除非App 调用resume函数来恢复下载过程，系统是不会自己恢复下载的。这里就需要用到前面提到的fetch后台模式，让App过一段时间被系统唤醒，然后App就可以去检查网络，当有网时恢复下载过程。

关于断点续传

   （1）由于下载过程是由系统在处理，即使App被杀死也不影响下载，因此App无需在断网或者退出时记录当前的下载位置。

   （2）当下载过程开启后，只要系统没有发出失败信号，即使断网了、系统关机了，等恢复网络或者系统重启之后，系统会继续下载，此时app只需要创建与上次相同id的session，即可接收到下载进度信息。如果app收到了失败信号，需要从nserro中通过userinfo来获取resumedata，从而在下次恢复下载时，使用downloadTaskWithResumeData函数来创建task，这样就可以断点续传，而不是用downloadTaskWithRequest来创建task，后者会开启一个新的下载。

posted by wap, platform: Chrome

引用:

原帖由 @jun4rui  于 2015-8-5 09:33 发表
我怀疑你自己都没看你帖的东西，里面只有后台放音乐才是长期驻留后台并活动的唯一方式，其它要么有时间限制，要么需要系统唤醒啥时候唤醒都不确定有个毛用啊。

贴这个文章是说明苹果不但不是像某些人说的就是不肯给第三方app后台功能，而是随着iOS的版本升级不断地在给，从后台播放音频，后台下载报刊杂志，后台VOIP，到后台任务完成，后台下载。但像安卓那样无限制的随便app怎么整的后台是不可能给的，系统不控制，就靠app自己控制，问题太多，体现在用户身上，就是手机耗电忽然就尿崩了。

有时间限制的后台执行是iOS6的模式，600秒，当用户按下home键退出app以后，用这600秒来完成一些未完成的任务，这不是真正意义的后台。
iOS7以后的真后台唤醒时间是由系统决定的，如果当前网络状况不好或者用户电量很低，频繁后台会导致更多的耗电。而且iOS一贯有很靠谱的通知中心系统，真正重要的东西app完全可以通过通知来提示用户。
后台下载才是iOS7之前真正的痛，开着app看着它下载不是好的体验，所以在iOS7以后增加了后台下载的功能，由于是系统级的通道，即使app被清出内存，下载依然是继续的，比你app自己常驻后台下载还要靠谱（app自己还可能因为内存不够被清出内存）

后台音频的模式也不是万能的，只要用户用别的app播放音频，之前那个程序就歇了。这种方法，即便在2013年以前也不算什么好办法，只是当时没办法。

posted by wap, platform: Chrome

引用:

原帖由 @jun4rui  于 2015-8-5 10:06 发表
因为真的后台可以做很多工作，不只有下载、通知之类的，苹果这种做法就是把几个常用的后台场景独立出来，做成系统服务供APP调用。

这样做确实能解决很多的问题，但是还是没办法解决一些问题。系统功能说真的iOS的还是太初级太基本了，举个例子，Windows的IE自带了下载功能，甚至也能够续传，但是基本没人会用这个，因为这功能太弱了。

以后普及2G RAM后，iOS应该会推出新机制，但是现在来说，这玩意只能在一些方面解决一些初级问题。

苹果要的就是有限制的后台，不然一切就不可控了。新机制肯定会继续增加，但也不会是无限制的。

在这个人性恶的社会，无限制就是群魔乱舞，你道高一尺，我魔高一丈，LBE、绿色守护、360极客版、耗电终结者轮番上阵，玩呗。

posted by wap, platform: Chrome

引用:

原帖由 @cynic0522  于 2015-8-5 10:13 发表
非也，不符合规定但能过审的例子太多了。

技术层面的不说，单说ASO方面前有摩根书院后有喜马拉雅听。

都是人工审核，漏网之鱼是必然的，360也是先上架后下架的。

posted by wap, platform: Chrome

引用:

原帖由 @Pires  于 2015-8-5 10:29 发表
腾讯塞钱给苹果不就行了，只要有钱苹果吃屎都乐意

听上去有一种腾讯比苹果有钱的多的感觉呢