bios是不是启动的时候就会用到,他是软件还是硬件??_百度知道
bios是不是启动的时候就会用到,他是软件还是硬件??
我有更好的答案
boss是主板，你般是说硬件，但是开机的boss这个设置是说boss内置的一个软件系统
开机后在有提示按DEL进入时，你就进入BIOS 看看
实践一下 就知道了
Bios是基本输入输出系统，是软件，电脑开机时，自动运行，用来访问硬件，并为其他操作系统的启动做好准备。它包括对电脑硬件的一些基本设置。存放Bios的硬件通常是CMOS，是一种金属氧化物半导体材料。
其他1条回答
为您推荐：
其他类似问题
您可能关注的内容
bios的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。目前SQL Server数据库作为微软一款优秀的RDBMS，其本身启动的时候是很少出问题的，我们在平时用的时候，很少关注起启动过程，或者很少了解其底层运行过程，大部分的过程只关注其内部的表、存储过程、视图、函数等一系列应用方式，而当有一天它运行的正常的时候突然启动不起来了，这时候就束手无策了，能做的或许只能是重装、配置、还原等，但这一个过程其实是一个非常耗时的过程，尤其当我们面对是庞大的生产库的时候，可能在这火烧眉毛的时刻，是不允许你再重搭建一套环境的。
所以作为一个合格的数据库使用者，我们要了解其启动、运行过程的事情，一旦发生问题，我们也能及时定位，迅速解决。
闲言少叙，我们进入本篇的正题。&
SQL Server本身就是一个Windows服务，每一个实例对应的就是一个sqlserver.exe进程。这是一个可执行的文件，默认就放在SQL Server的安装目录下，当我们启动的时候，就是直接调用这个文件，然后启动这个服务。&
第一部分、SQL Server实例启动的方法和启动所发生的问题
& SQL Server实例分为下面几种启动方法：
（1）在Windows服务控制台里手动启动，或者自动启动（默认），这个也是最常用的方式
（2）第二种方式是SQL Server本身自己提供的启动方式，我们这里可以手动启动
（3）在SQL Server的SSMS里面手动启动它，这个方式一般大部分利用这种方式进行手动重启
（4）通过Windows命令窗口，用'net start'命令手动启动，这种方法也可以用
以上这几种方式都可以启动SQL Sever,并且都会在SQL 日志信息中有所记录。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第二部分、SQL Server实例启动的详细过程以及所发生的问题项
第一步、检查注册表项
当一个sqlserver.exe文件开始启动的时候，首先要干的第一件事就是先检查它的配置信息存放于注册表的值项
比较重要的几个键值有下面几个：
AuditLevel:其实就是SQL 如何记录用户登录记录；
LoginMode:是SQL Server服务器身份验证方式等；
BackupDirectory:默认的备份路径等信息；
关于注册表信息简要了解即可，不建议做任何修改，当然这些值的信息默认在SQL Server中都能设置：
在不修改注册表的情况下，一般这一步的启动顺序一般不会出现问题，当然出现问题了也通常没有办法解决，大部分的解决方式只有重装了。
但这一步骤，通常出现以下两个个问题通常是可以解决的：
&1&启动账号权限问题
如果我们启动SQL Server的进程使用的账号连读注册表的权限都没有，那这个服务是怎么也启动不了的，通常这时候连SQL 的错误日志都没有能力生成出来。
这时候我们该如何发现呢，虽然这时候它没有能力创建SQL 的错误日志，但是它在Windows层面留下了痕迹，我们来看：
我将服务启动账号设置成gust来宾账号，来启动该服务
这时候会产生以下错误信息：
在Windows的日志信息里也会产生一条错误日志记录：
这里的拒绝访问指的就是拒绝访问注册表信息了。
解决方法：
此问题的解决方式就很简单了，只需要将当然的用户提权到SQL Server服务的启动账号就行了，提权的方式也很简单，只需要添加到SQL的本地用户的启动服务组就可以了。
当然，也可以直接换一个更高级别的用户登录。一般默认都用的超级管理员账户。
&2&访问日志和文件夹出现问题
默认在SQL Server启动的时候会创建一个启动日志文件，记录所有正确的日志信息，当然也包括错误的日志信息，如果这时候找不到这个日志信息的路径，或者已经存在一个日志，但是日志被锁定了（某些NB的杀毒软件擅长干这个），这时候这个服务也是启动不了的，同样也创建不出SQL Server的日志文件，这时候我们还得借助于Windows平台本身，来解决。
SQL Server启动的创建的日志文件路径，同样存在于注册表项里，我们来看这个参数：
这里我们故意改成一个错误的路径，来启动下看看：
会产生以下错误
系统的错误日志信息
错误说明的很清楚。
解决方法：
这个问题解决起来也很简单，只需要检查好该路径，确保路径下的文件正确就可以。
不过有一点需要注意，当SQL Server还没启动起来的时候，有部分错误信息日志需要检查Windows平台下的系统日志。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
&第二步、检查系统配置环境，包括硬盘、内存与CPU等
当我们进行完第一步的时候，SQL Server已经读取完注册表信息，完成了它的errorlog文件的创建，然后开始进行第二步的进行，这一步骤所有的信息就会按照顺序依次记录到errorlog文件中，我们可以通过查看该文件来详细跟踪这一步骤的进行，根据上一步的注册表信息，我们先来手动清空下这个日志，然后重启一下SQL Server服务，查看下这个日志记录
我们简单大致分了以下几大步骤：
一、首先检查系统的软件环境，包括OS版本、电脑信号、内存、硬盘、注册表基础配置项是否正确等
二、启动系统数据库master
三、开始利用服务用户登录系统、启动系统资源数据库、检查数据库版本信息等
四、启动系统数据库model
五、开始网络配置进行连接，对外提供服务，使用的默认的1433端口
我们接着分析下面的日志：
六、其实完成上面的第五步之后，也就开始启动msdb系统数据库
七、这时候开始真正的启动用户数据库，并且完整各个库的完整性校验，并且在启动用户数据库之前，先将系统库的tempdb进行清空
八、在搭建完成之后，才开始启系统的另外一个数据库tempdb
上面的整个SQL& Server系统启动的过程产生了详细的日志记录，我们下面会依次按照该步骤进行详细的进行逐步分析。
在检查系统软硬件环境的过程中，基本不会发生什么致命错误。比较常见的问题就是内存配置问题，其实在上面的日志记录中有一句特别重要，它反映的就是SQL Server利用内存的情况，我们来看：
这句话的意思是将所有的数据页锁定到内存中，作为大部分数据库而言，内存就是生命线，SQL Server同样也是，如果系统（64bit中）没有内存压力的情况下，才能将数据页正常的锁定到内存中，如果内存压力过大，系统内存是不允许将数据页也加入到内存中，而这样导致的问题就是SQL& Server严重的性能问题。
很多用户希望限制SQL Server内存使用，并且有些客户机将它限制到服务都不能启动的情况，这时候在SQL Server的日志中是这样展现的，我们来看：
可以看到，该错误的原因还是挺清楚的，修复该错误的解决方法也很简单，将内存配置调大就可以。
跟内存有关的还有一种特殊的情况，就是SQL Server的启动账号在服务器上没有Lock page in memory的权限，如果没有这个权限，在明细日志中查看不到上面的日志记录，该问题的解决方法也很简单，只需要将需要权限加上就可，加权限的方式如下：
经过上面的步骤基本，完成数据的软硬件检测过程。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
&第三步、启动系统数据库master
master数据库是SQL Server系统启动过程中的第一个系统库，是非常关键的数据库。如果这个库不能被正常打开，则SQL Server就不能正常启动。
和其它数据库一样，master数据库也分为数据文件和日志文件，启动的过程是依次打开，然后做恢复动作，如果这个过程没问题的话，在Errorlog日志文件中，我们会看到如下的这句话：
如果这个过程出现了任何问题，SQL Server的启动过程都会被中断，启动过程失败。
而这个过程发生的错误，无非就集中以下几种情况，我们来分析一下：
&1&在指定的路径找不到master数据的数据文件或日志文件
关于这个SQL Server的最主要的系统数据库的路径，它是以注册表形式存在的，在一下注册表项，可以看到
如果在该路径下找不到这个系统数据库的话，服务是启动不了的，并且会产生相应的错误日志信息，我们来模拟下，关掉服务，将这两个文件移除走，然后启动看一下：
首先，该服务是启动失败的
我们来看一下系统日志
看Errorlog的日志信息
可以看到，该问题提示错误信息还是挺详细的。我们来看第二种情况
&2&文件找到了，但是没有权限访问，或者不能以排他的方式打开该文件（默认的是独占锁进行文件打开的）
此种情况也是有可能产生的，比如某些NB的杀毒软件就可以干这个事，让你的系统库无法访问，这样同样也是启动不了的，我们这样来看，提示的错误的信息有哪些：
来看Errorlog的错误记录：
&3&文件找到了，访问权限也有，但是文件有问题，就是说是数据库损坏了
这个问题也经常出现，比如磁盘坏掉了，恢复后发现文件有问题，不能正常打开，这种问题我们来看错误信息：
日志中的信息
关于master系统库的启动过程，基本就是上面的三种错误，关于这三种问题，我们该如何解决呢？
解决方法：首先如果根据错误日志定位出问题的性质，如果是前两种问题其实是挺好解决的，比如文件没找到、权限项不对等，这些问题相应的去解决就可以，最棘手的就是第三种情况，出现这种情况最理想的情况是master数据库进行了备份，通过备份文件进行恢复就可以，一切就可以正常，当然通过暴力的停掉服务，拷贝文件进去也可以解决。
最揪心的就是这个库就没备份，那该如何解决呢？这种方式的解决就得借助SQL Server的安装程序，进行重建master数据了，但是这种方式重建的master数据库会导致以前的SQL Server的设定全部清空掉。
清空的信息包括：所有的账户信息（意味着需要重建）、msdb中的所有job信息等（也需要重建）、用户数据库信息（必须全部重新附加attch上）
而这一系列过程如果是一个生产库，可能会是一个非常大的工作量！
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
&第四步、启动系统资源数据库，并检查数据版本信息
资源数据库是SQL Server2005中引入的逻辑数据库，在实例下是看不到的，但是有它的物理文件，主数据库默认名称为：mssqlsystemresource.mdf、日志名称为：mssqlsystemresource.ldf
如果该数据库启动的过程中也出现了问题，那SQL Server也不能正常启动。
这个系统数据库比较特别，它是一个只读数据库，完全由SQL Server自己维护，用户是不能更改的，所以我们只要保证它的是数据库文件和日志完好就可以，不需要对它进行任何的跟踪和维护。
当然如果非要看这个数据库，可以通过单用户的DAC方式进行连接。
所以这个数据库在一般情况下不会发生意外，基本上是能正常启动，不过特殊情况下，不能启动的情况就以下两种：
&1&数据库文件不存在，无法访问，或者文件坏掉了
其实它的报的错误信息，类似于上面的master数据库，我来截个图，看一下：
这个是errorlog记录的错误信息
在windows层面也有它自己的错误日志信息：
&2&资源数据库的版本和SQL Server的版本不一致
这个有可能是人为的更改了这个资源数据库，导致现有的资源数据库文件和数据库版本不一致，这样的话也会导致错误的形成
windwos平台也记录下了该错误的信息，看下面的图片：
解决方法：
关于资源库的这两个问题解决方法，非常的简单。只要找到和这台服务器上的SQL Server的版本一致的数据库，拷贝过来就行。
当然最好的预防措施是：每当安装完SQL Server或者打完补丁之后，就及时的备份这个两个文件，放在安全的地方，用的时候拷贝过来就行，备份是数据库管理员的天职
当然有时候在紧急的情况下，找不到相同版本的数据库，理论上这个库是只读的，所以不会发生任何改变，我们随便找一台机器，安装一下同版本数据库，然后拷贝过来就行，当然一定注意的是这里面是相同版本。&
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第五步、启动系统数据库model
model系统数据库同样也是SQL Server启动过程中用到的一个非常关键的数据库，如果这个库损坏，SQL Server启动也会失败，关于model数据不能启动的原因基本和master的类似，同样也是两种：1、数据库文件早不到或者不能访问；2、数据库文件能访问但是是损坏的文件。
诊断此种问题的方式也和上面的两种方式一样，查看启动过程产生的errorlog文件或者windows系统日志，这里我们就不重现该问题了。
我们只给出此种问题的解决方法：
1、如果该库我们已经做过备份，那最直接也是最有效的解决方式就是直接还原，这里的还原方式可能和普通库的还原方式不一样，因为SQL& Server实例还没有启动，我们恢复过程采取以下过程：
a.用参数启动SQL Server，在命令提示行中执行以下命令，这样的话SQL Server启动就会跳过model数据库恢复这一步
net start MSSQLSERVER /f /m /T3608
b.现在恢复model数据库，打开SSMS，直接输入
RESTORE DATABASE model FROM DISK ='G:\data\model.bak'
MOVE 'modeldev' TO 'E:\dataDefaultFileManger\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.mdf'
MOVE 'modellog' TO 'E:\dataDefaultFileManger\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.ldf'
c.恢复成功后，直接重启SQL Server既可以。
2、将SQL Server关闭，然后直接采取暴力的方式将model数据文件拷贝回来就可以，这种方式简单有效，但是非常规操作
3、还有一种方式是利用setup安装文件，重建该数据库，过程缓慢，稍显复杂，很不推荐。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第六步、开始网络配置进行连接，对外提供服务，使用的默认的1433端口
当上面的几个重要的系统库都已经启动完成之后，下一步就是开始检查网络环境，进行网络服务的配置，对外进行提供服务了，一般来讲，在SQL Server中利用的网络启动协议有三种：Shared Memory、Named Pope和TCP/IP，其实在日常我们最常用的就是TCP/IP这种方式了，并且默认开启的是1433端口。
我们来看一下正常启动过程中，该部分的详细日志：
这里面的Shared Memory是专供本地连接通过LPC(Local Procedure Call)技术向SQL Server做的连接。它不走网络层，所以他是速度最快的连接方式。正常启动后会显示上面的正常日志。
Named Pipe方式正常启动，也会显示出上面的日志。可以看到。
这其中我们最常用的TCP/IP这种方式，也正常的启动了，并且指定了两种访问方式，ipv4/ipv6，然后后面加上了1433端口号。
在这个过程中最常出现的问题就是，1433端口被其它程序占用，这样就导致TCP/IP协议无法正常启动，这样我们会看到如下日志信息
并且在windows 系统日志中也会有记录
解决方法：
其实这里出现的问题还是挺好解决的，只需要找到占用这个端口的应用程序，采取措施让它把这个端口给让出来就可以。
当然出现这些问题就意味着客户端已经无法通过TCP/IP这种远程连接的方式进行连接访问了。
这时候一般管理员可以采用SQL Server给其提供的&专用管理员连接&（DAC）进行连接，这种方式我们以后再介绍。
当然，在SQL Server启动的过程中，一般出现这种网络问题，或者协议不能成功加载，SQL Server会报出错误信息，但是一般情况下是不会影响SQL Server的正常启动的。受影响的可能只是出问题的那种协议功能。
我们只需要根据日志，定位问题，然后解决掉，重新启动就可以了。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第七步、开始启动msdb系统数据库
关于msdb这个系统数据库，它是被安排在系统库中接近最后一个了，除了用户数据库和临时库tempdb之外，当启动过程中已经进行到这一步的时候，其实我们的实例就已经启动起来了，并且能够连接。
我们知道msdb这个库中主要的存储的信息是应用各个库的备份信息，各种job的历史跑批信息等，其实诸多的都是来自于用户数据库所产生的一些客观数据。
我们来看一下这个库出现了问题会产生什么现象：
我将这个库文件移除走，然后重新启动服务，启动过程中没有报任何错误，并且能够顺利启动，我们用SSMS直接连接过去，也可以正常连接
但是当我们点击开数据的时候，其实是看不到任何用户数据库的，并且会产生一个错误提示：
看来是不能使用的，我们来查看一下错误日志：
虽然这个库的重要性比起master之类的库重要性要稍显差一些，但是缺少了它我们的SQL Server虽然能启动，但是依然不能使用。
解决方法：
要解决这个问题其实方式就很多种了，因为到此我们的SQL Server实例已经能够正常启动了，我们可以采取：
1、利用备份还原该库，参考文章前面的方式（推荐）
2、关掉服务，利用暴力的拷贝文件的方式进行恢复，简单有效，非常规操作
3、找台相同的环境，找到相同的文件，直接拷贝过来使用
4、利用安装文件进行恢复（不推荐）
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第八步、启动用户数据库，并且完整各个库的完整性校验，并且在启动用户数据库之前，先将系统库的tempdb进行清空
本步骤所遇到的问题层出不穷，各种样式，我打算再重新组织一篇文章，专门列举，此篇就不介绍了。
但有一点需要记住：在这一步之前SQL Server会将tempdb这个系统库清空掉，也就是说，每次的重启操作，系统都会将tempdb清空，然后重建，这一步一般不会发生异常，成功之后会出现以下日志信息：
第九步、开始重建系统的另外一个数据库tempdb
tempdb这个库比较特殊，每次重启的时候都是重新创建的，SQL Server会根据master数据库里的记录的信息以model数据库为版本进行创建。所以只要我们保证model数据库没有问题，然后硬盘没有问题，tempdb的数据库文件就应该没有问题。
关于temdb这个库的所有配置信息是存储于master的数据库中的，里面的内容信息是存储于model系统库中的
这样就带来了一个问题，有时候我们的master的库是从别的机器下面备份下来的，所以它里面会记录这个tempdb这个库在原来机器上的路径，这样在启动创建的时候就会报错。
所以我们需要执行以下命令更改这个库路径
a、用参数启动SQL Server
net start MSSQLSERVER /f
b.修改数据文件和日志文件路径
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:\right path....\temdb.mdf');
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:\right path....\temdblog.ldf');
c.正常启动数据库既可以
还有一种情况，就是创建该文件的时候，提供的硬盘空间不足，或者权限不够，我们也是根据上面的方式，修改到一个正确的路径，并且确保权限正确。
也可以更改temp文件的大小，默认是4M，代码如下：
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,SIZE=100MB);
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,SIZE=100MB);
至此，如果上面的整个过程都没出问题的话，一个正常的SQL Server就可以启动成功的。
本篇文章到此结束了.....此篇耗时三天.....为了尽可能的呈现出所有的问题现象，我对本地的SQL Server进行了多种无情的蹂躏、各种的摧残，力求能够重显各种不同的应用场景问题现象，然后尽可能的找到合适的解决方案，当然还有很多的情况没有展现出来，后续遇到，会一一补充进来，当然有遇到不能解决的，也可以留言，我们一起分析解决。
关于用户数据库启动过程，这个过程是一个问题较易发生的步骤，神马质疑、恢复中、不可用等等现象，我后续的文章中列举分析。
已经补充出该篇的关联篇：
如果您看了本篇博客,觉得对您有所收获，请不要吝啬您的&推荐&。&
阅读(...) 评论()iOS进入后台的以及可以后台执行的应用的了解 - 简书
iOS进入后台的以及可以后台执行的应用的了解
Background Execution （后台执行）
当用于没有-启动应用，系统移到后台状态。对于很多应用，后台状态只是一个简短的停留方式。悬挂程序是一个种方式去提高电池寿命，它同样允许系统去专注于重要系统资源用于一个新的前台程序当用于关注的时候（触发的时候）。
大多的应用可以很容易移动到悬挂状态但是同样也有很合适的理由去继续运行在后台。一个徒步的应用可能想去跟踪用户的位置所以它嫩巩固显示具体的位置在地图上面。一个音频的应用可能需要继续播放音乐在锁频的时候。其他应用可能需要下载内容在后台，所以它能够
最小的言辞显示内容给用户。当你发现你需要保持你的应用在后台运行，iOS帮助你有效和不需要系统资源或者用户的电池。技术提供iOS 进入下面三个范畴：
（1）应用安康市一个简短的任务在前端能够询问时间去完成任务当应用移到后台。
（2）应用提示下载在前段能够退卡管理这些下载到系统，因此允许你应用被悬挂或者终止当下载继续。
（3）应用需要运行在后后台去支持指定任务类型能够声明他们支持一个或者多个后台执行模式。
总是尝试去避免做一些后台的工作除非提供用户的提亚。一个应用可能移到后台因为用户启动不同的应用应为用户锁定设备并且没有使用它现在。在两种状态下，用户显示你的应用不需要做一些有意思工作现在。继续运行这些环境将不会使用设备的电池并且可能导致用户强制退出应用。这么有意思的工作你可以在后台处理和避免它当你能够。
Executing Finite-Length Tasks （执行一个有限的任务）
应用移到后台被执行是将它们进入到不活跃的状态（尽可能），所以，它们能够被系统悬挂。如果你的应用在中心任务和需要一些额外的时间去完成任务，你可以调用beginBackgroundTaskWithName:expirationHandler: 或 beginBackgroundTaskWithExpirationHandler:应用方法去请求额外的时间。调用这些方法中的一个去暂时延长你的应用，给一些维阿的时间去完成它的工作。在完成工作，你的应用必须调用endBackgroudTask: 方法去让系统知道它完成能够被悬挂。
没个调用 beginBackgroundTaskWithName:expirationHandler: or beginBackgroundTaskWithExpirationHandler:
方法都会产生一个唯一标示去联系对应的响应任务。当你完成了任务，你必须调用endBackgroundTask:
相应标识（token） 去让系统知道任务已经完成了。调用endBackgroundTask：方法失败将导致应用终端。如果你提供了截止处理当你开始任务，系统调用处理和给你最后一个机会去结束任务和避免终止。
你不需要去等待知道你的的应用移到后台去指定后台任务。已给更有意思的设备就是去调用beginBackgroundTaskWithName:expirationHandler: 或 beginBackgroundTaskWithExpirationHandler:
在开始任务并且调用endBackgroundTask: 尽可能在你结束的时候。
你甚至可以遵循这个模式当你的应用程序是在前台执行。
下面的代码就是展示了怎么开始一个long-running 任务但你的应用转到后台。在这个例子中，
Listing 3-1 shows how to start a long-running task when your app transitions to the background. In this example,请求去开启后台任务包括截止处理因为任务太长了。任务它本身提供发送队列异步操作，所以pplicationDidEnterBackground: 方法能够返回正常。使用block简单的代码需要支持应用其他重要变量。例如：后台任务标识（background task identifier）。 后台变量是一个类白能量，嫩巩固存储指针指向当前后台任务标识并且初始化权限是用这个方法。
在退出程序的时候执行的一些任务
注意：总是提供额外的处理当启动一个任务的时候，但是如果你想知道多长时间程序剩下能够运行，通过backgroundTimeRemaining （UIApplication）这个属性。
在你的自己的额外处理中，你能够包括额外的代码需要去关闭你的任务。然而，其他代码你包括必须不能够花费太长时间去执行因为通过额外的处理时间被调用，你的应用已经非常接近时间限制了。对于这个原因，最小清除你的状态信息并且结束任务。
Downloading Content in the Background （在后台下载内容）【下面的内容转化或者传输都是transfers】
当下载文件的时候，应用应该使用NSURLSession 对象去开启下载，因此系统能够控制下载的进程在应用被悬挂或者终止的案例中。当你配置NSURLSession对象对于后台转化，系统管理这些转化在区分进程和报告状态到你的应用使用普通的方式。如果你爹应用终止当转化还在持续，系统继续转化在后台并且合适的启动你的应用当转化【传输】完成或者当一个或者更多的任务需要的你应用关注。 去支持传输，你必须配置NSURLSession 合适，去配置回话，你必须第一个是创建NSURLSessionConfigurationobject 配置对象和设置几个属性为合适的值。你然后传递配置对象到合适的初始化方法(NSURLSession的)当创建你的会话。
创建配置对象支持后台下载步骤如下：
（1）创建配置对象使用 backgroundSessionConfigurationWithIdentifier:
（NSURLSessionConfiguration）方法
（2）设置配置对象的值通过sessionSendsLaunchEvents 这个属性为yes；
（3）如果你的应用工开始传输当在前台，它推荐你也设置任意属性去配置为yes；
（4）配置其他属性去创建NSURLSession对象。
（5）使用配置对象去创建NSURLSession对象
一旦皮遏制，你的NSURLSession对象无间隙的处理上传和下载任务到系统在合适的时间。如果任务完成党你的应用仍然在运行（在前端或者后端），回话对象通知它的代理用一般的方式。如果用户终止你的应用，系统取消任意的其他的待解决的任务。
当所有的任务连接到后台会话完成，系统重新启动一个终止应用（估计sessionSendsLaunchEvents 属性设置为yes，用户不会强迫退出应用）并且调用代理的application:handleEventsForBackgroundURLSession:completionHandler:
这个方法。（系统可能也重启应用去处理验证挑战或者其他关联时间要求应用关注）。在你实现的代理方法中，使用提供的表示去创建一个新的NSURLSessionConfiguration 和NSURLSession 对象带有相同的配置。系统重新连接你新的会话对象到先前的任务和去报告他们的状态到会话的对象代理中国。
Implementing Long-Running Tasks （实现长运行任务）
对于需要更多执行时间的实现，必须制定允许运行他们不被悬挂，在iOS 中，只有制定appo类型运行在后台运行；
（1）播放的内容能够听得见的类型应用云心在后台运行
（2）录制音频内容的应用在后台
（3）保吃用户的位置信息实时，例如导航应用
（4）Voice over Internet Protocol (VoIP) 支持（网络语音）
（5）应用需要下载和通话层的新内容的进程。
（6）应用接受合理的更新从额外的附件
应用实现这些服务必须宣告服务系统支持用户的系统库区实现关联他们服务的方面。宣告这些服务让系统知道哪些服务可以使用，但是在一些案例中在系统库阻住你的应用被悬挂。
Declaring Your App’s Supported Background Tasks （声明你的应用支持后台任务）
支持后台执行的一些类型，必须设置高级声明在应用上。在xcode5以及之后，在应用设置中声明你的的应用具有后台支持运行的能力。UIBackgroundModes 关键字在info.plist中设置为启动。选择一个或者复选框汇总增加响应后台模式的值到关键字汇总。下面的后台模式你可以指定和xcode中设置对应的关键字值在info.plist文件中。
可以在后台执行的应用列表
每一个在前面的系统中让系统知道你的应用应该被唤醒或者启动在一个合适的时间去相应关联的事件。例如：应用开始播放音乐并且然后渠道后台仍旧需哟啊执行时间去前冲输出缓存。audio模型启动告诉系统库他们应该继续回调到应用在合适的间隔时间。如果应用没有选择这个模式，音频可能被播放或者录制通过应用停止当应用移到后台的时候。
Tracking the User’s Location （跟踪用户的位置）
有几种方式去最终用户的位置在后台，实际上并不是要求你的应用在后台继续运行：
（1）重要改变位置服务（推荐）
（2）只是前台定位服务
（3）后台定位服务
重要改变位置服务被强烈推荐不要高精确的位置数据。通过这个服务，位置更新被产生只是在位置发生了重大的改变。所以，对于本地应用或者应用提供给用户本地关联的非关键的。如果应用被悬挂当更新发生的时候，系统将会唤醒它然后处理更新。如果应用启动这个服务并且它然后终止，系统将会自动重启当一个新的位置是有效的。服务有效是在ios 4 之后，这个只是在设备上有效包括窝蜂音频。
只是前台和后台位置服务都可以用在标准的位置核心定位服务去获取位置数据。只是在前台的定位服务停止传递更新如果应用曾经被悬挂，有可能会发生如果应用没有支持其他后台服务或者任务。只是前台定位服务计划就是用于在程序在前台的时候只需要的定位数据。你启动定位支持从后台模型选择中的能力在xcode项目中（你同样也能够使它支持包括后台模式 的key去设置定位的值）。
启动模式不会阻住系统悬挂引用，但是它能够告诉系统它可以唤醒应用当新的位置数据传递过里。所以，这个关键字嫩巩固有效的让应用在后台运行去更新位置当他们发生的时候。
重点：建议尽量少用标准服务，或者使用重点位置地址服务替代。位置服务要求启动用户的iOS设备在radio硬件上。在硬件上继续运行能够消费一系列能量。如果你的应用不需要提供精确和吃持续的位置信息给用户，最好是最小化使用位置服务。
关于怎么使用每个不同的位置服务在你的应用上，看：Location and Maps Programming Guide.
Playing and Recording Background Audio （播放和录制后台音频）
一个应用持续播放或者录制能够注册那些任务在后台（甚至当应用在后台运行）。在xcode项目上进行设置支持模式。你同样能够支持包括UIBackgroundModes 关键字在info.plist 文件中。应用可以播放音频在后台而不会静音。
典型的后台音频引用包括：
（1）音乐播放应用
（2）音频记录应用
（3）应用支持音频和在airPlay中重播
（4）VoIP 支持音频和视频在airPlay上。
当UIBackgroundModes 包括了audio的值，当程序进入后台的时候，系统的媒体库不会让应用被悬挂。当程序播放音频和视频内容，应用将继续运行到后台。然而，如果录制或者播放停止，系统就会悬挂程序。
你可以使用这些系统音频库区在后台音频内容工作和进程使用这些库当库没有变化。因为你的应用不会被悬挂当播放媒体文件，调用正常处理当你的应用在后台的时候。在你的回调中当你的只要提供数据给播放。例如，一个媒体音频需要下载音乐流数据从服务器中或推送当前的音频样品到播放中。应用不应该执行其他任何的无关任务和没有关联的的播放。
多余一个应用支持音频，系统支持哪一个应用允许播放和音频录制在给定的时间。前台应用同样有权限操作音频。可能不止一个应用允许在后台播放音频，基于基础配置决定每一个应用的音频会话。你应该合适的皮遏制你的应用音频回话和小心使用系统库处理中断和类型的音频相关的通知。怎么配置音频会话对象在后台执行。查看《Audio Session Programming Guide》
Implementing a VoIP App (是吸纳VoIP应用)
语音网络接口应用允许用于让用户去使用手机调用使用网络连接体态设备中的窝蜂服务。例如已给应用需要支持持久的网络连接到它关联的服务中所以它能够接收输入的调用和其他关联的数据。不是保持着VoIP应用的一直醒着，系统允许他们被悬挂并且提供场所去控制他们的sockets给他们。当输入被检测到，系统会唤醒VoIP应用去返回到socket控制它。
配置VoIP应用，需要以下操作：
（1）支持ViOP在后台模式下博播放,需要在info.plist中设置UIBackgroundModes 关键字
（2）配置app套接字中对VoIP是可用的
（3）在移到后台之前，调用setKeepAliveTimeout:handler:
这个方法去安装一个处理去周期性执行，你的应用能够使用这个处理去支持它的服务连接。
（4）配置你的音频会话去出里转换和用户启动。
包括voip 值在UIBackgroundModes 关键字汇总让系统知道它应该允许程序去运行在后台当需要去管理网络套接字的时候。带有和这个key的应用也可以重新启动在后台当系统boot去确定VoIP 服务是有效的。
大多的VoIP也需哟啊去配置作为后台音频应用去传递音频当在后台的时候。所以，你应该包括音频和voip值设置到UIBackgroundModes 关键字汇总。如果你没有处理这个，你的应用不能够播放或者记录音频当在后台。对于更多信心关于 UIBackgroundModes key, see Information Property List Key Reference.
执行信息关于步骤，你必须实现VoIP应用：see Tips for Developing a VoIP App.
Fetching Small Amounts of Content Opportunistically （取少量内容的机会）
应用需要周期性检查好新内容然后请求系统去唤醒他们，所以他们能够开始获取操作内容。要启动这个功能需要在info.plist 文件中进行设置。
启动了这个模式不是一个保证，系统将会提供给你的应用一些时间去在后台执行。系统必须平衡你的应用需要去获取应用需要的内容和系统本身。获取到信息之后，系统给供给应用一些时间当他们有更好的机会去处理。当一个好的应用产生，系统会换新或者启动你的应用到后台并且调用应用代理
application:performFetchWithCompletionHandler:
这个方法。使用方法去检查新的内容和开始下载操作。当你完成下载新内容，你必须执行提供完成的处理块，传递结果去只是内容是否合理。 执行这个快去告诉系统它能够移动你的应用到悬挂状态并且评估它的电量的使用。应用下载小数目的内容很快，并且能够快速响应当他们有内容下载合理的时候，更像是执行时间在接下来花费很多时间去下载他们的内容或者声明内容是有效的然后没有下载内容。当下载内容，推荐使用NSURLSession类去初始化和管理你的下载。关于怎么使用使用这个类，管理上传和下载任务。查看 URL Session Programming Guide
Using Push Notifications to Initiate a Download （使用通知去初始化下载）
如果服务器发送通知到用户的设备当新的内容是有效的对于你的应用，你能够循环系统去运行你的应用在后台，所以，你能够马山开始下载新的内容。
后台模式计划去最小化消耗的时间流逝在当用户看到通知和当用户能够展示内容之间。应用能够典型地唤醒在粗略相同的花四溅，用户看到通知当时仍然给你很多时间你可能有。支持后台运行 ，需要在info.plist 中设置。
对于发送通知去触发下载，通知的负载必须包括内容有效关键字和它的值是1.当关键字显示，系统会唤醒后台程序并且调用app delegte中的application:didReceiveRemoteNotification:fetchCompletionHandler: 方法。你应该下载相关的内容去集合到你的应用中。
当下载内容，推荐你使NSURLSession类去开始和管理下载。更多信息关于上传和下载看： URL Session Programming Guide.
Downloading Newsstand Content in the Background （在后台下载新的内容）
一个新闻报刊引用下载新的杂志或者报纸问题能够注册去执行这些下载在后台。你能够支持newstands下载从后台模式在你的xcode项目中设置。当你的key有的时候，系统启动你的应用，如果没有准备运行，这样她能够开始下载对于新的事件。当你使用Newstand kit 库区开始一个下载。系统处理下载的进度对于你的应用。系统能够继续下载文件甚至如果你爹应用被悬挂或者终止。当下载操作完成，系统将你的文件传输到沙盒中并且通知你的应用。如果应用没有运行，通知唤醒应用给机会它进入新的下载文件。如果他们有错误在下载的过程中，你的应用类似唤醒处理他们。
newstand 可关注： see Newsstand Kit Framework Reference.
Communicating with an External Accessory
与外部附件通信
应用和外部附件通讯能够唤醒如果需要传输更新的时候当应用被悬挂。支持重要的类型对于外围设备传送数据在已给有规律的间隔，例如心率控制。你能够支持额外附件交流从后台模式（需要在xcode中进行配置）。当你启动这个模式，内外设备库不会关闭活动的会话（ios 4之后，这些会话自动关闭当应用悬挂）。当新的数据从外围设备中到来，库会唤醒你的应用所以它能够处理数据。系统也能够唤醒应用去促进外围设备的链接和断开连接。
应用支持后台外围设备的更新必须跟踪几个基础指导：
（1）应用必须提供一个界面允许用于去开始或者停止外围更新事件的传输。这个接口应该打开或者关闭外围设备会话。
（2）被唤醒，应用有大概10秒钟事件去处理数据。确切的，它应该尽可能快的处理数据并且允许它本身被再次悬挂。然而，如果需要更多的事件就使用beginBackgroundTaskWithExpirationHandler: 这个方法（这种方式大概有150秒左右，由系统决定的）。
Communicating with a Bluetooth Accessory （和蓝牙外围设备进行交流）
应用在和蓝牙外围设备进行工作的时候，如果蓝牙更新信息发过来，程序应该会被唤醒。这个支持对Bluetooth-LE在间断时间传递数据很重要，例如：蓝牙检测心率等（可以在xcode的info.plist 中进行配置）。当你启动这个模式，Core Bluetooth framework保持绘话响应外围设备。额外的，新数据从外围设备到达区唤醒陈旭，因此它能够处理数据。系统也能够唤醒应用去处理外围设备的连接和断开连接。在iOS 6 ，一个应用也能够操作在外围模式下和蓝牙外围设备。蓝牙设备（在xocde的info.plist中进行设置），启动和这个模式， Core Bluetooth framework
能剪短唤醒后台程序处理接受的关联请求。程序被唤醒应该处理这些时间然后尽可能的返回因为程序能够被再次悬挂。任意应用支持后台进程对于蓝牙数据必须在会话基础上遵循以下指导：
（1）应用必须提供一个界面允许用户去开启和停止蓝牙传输事件。接口应该开启和关闭会话在合适的时候。
（2）别唤醒，应用大概有10秒中去处理数据。确切的，它应该尽可能快的处理数据允许它自己被悬挂。然而，就如果需要更多时间就必须使用beginBackgroundTaskWithExpirationHandler: 方法去请求更多的时间。
Getting the User’s Attention While in the Background （在后台获取用户的关注）
通知对于被悬挂的应用是一种方式，它是在后台而不是运行当获取到用户的关注（提醒；通知）。应用能够使用本地通知去展示警告，播放声音，应用的icon微章或者三个综合。例如：一个警告时钟能够用本地通知去播放警告声音和显示一个警告。当一个通知被传递给用户，用户必须决定返回前台。（如果应用已经在前台运行，本地通知默认是传递给应用而不是用户）
计划的传输本地通知，创建一个UILocalNotificaiton对象，配置通知参数和触发使用应用方法。本地通知对象信息包括信息传递（声音，警告，badge）和时间（适当）在传递给它。UIApplication类方法提供了选择去立即传输通知或者计划时间。
下面真实了一个例子；
这个例子只是配置一个一次性闹钟并且取消以前的闹钟（你自己的应用不能够有128个本地通知活动在一个时间和取消过去的闹钟在这个新的之前）。
闹钟自己包括了警告箱和一个声音文件被播放如果一个应用不运行或者在后台运行当警告开始。如果应用是活动的并且运行在前台，app delegate application:didReceiveLocalNotification: 方法收到信息。
本地通知使用声音文件有相同的请求当这些用在推送通知上。自定义声音文件必须定位在应用main bundle和支持如下格式中的一个：Linear PCM, MA4, u-Law, or a-Law.你可以指定 UILocalNotificationDefaultSoundName
常量指定去播放默认的警告信息对于设备。当通知被发送的声音播放，系统也触发颤动。你可以取消计划的通知或者获取通知列表使用应用类的方法。更多信息是关于这些方法，查看 UIApplication Class Reference。额外的信息配置本地通知，查看：Local and Remote Notification Programming Guide.
Understanding When Your App Gets Launched into the Background（明白程序从启动到后台）
程序支持后台执行可能会被启动通过系统处理输入事件。如果一个被终止由于已卸载原因而不是强迫退出，系统启动应用当下面的一个事件发生。
（1）对于位置的应用
1）系统接收到一个位置更新（遇到程序配置标准对于传递）
2）设备进入或者退出一个注册区域（预备是被位置地理化区域或者地理栅栏）
（2）对于音频的而程序，音频库需要程序处理一些数据（音频程序包括播放音频和使用麦克分）
（3）蓝牙应用
1）一个应用作为中间的角色获取数据从连接的外围设备上
2）一个外围设备从中间设备中接收到命令。
（4）后台下载应用
1）一个通知到达和通知的payload中的值是1（有用）
2）系统唤醒应用在一个随机的时刻去开始下载新的内容。
3）对于使用NSURLSession类去下载内容，所有的任务连接到会话对象成功或者失败。
4）一个下载的被初始化通过一个新闻报刊完成。
很多情况下,系统不会重新启动在用户强制退出。一个例外是位置应用，在iOS 8 或者之后被启动在用户强制退出的时候。其他案例，虽然，用户必须显示启动程序或者重启设备在应用被自动启动进入后台通过系统。当设备的密码保护开启，系统不会启动一个应用在后台当用户第一个解锁设备的时候。
Being a Responsible Background App （成为一个可靠的后台应用）
前台程序比后台程序性使用硬件和系统资源的优先权高，后台运行的应用程序需要为这种差异做好准备，并在后台运行时调整它们的行为.
尤其是程序移到后台的时候需要遵循下面的指导：
（1）Do not make any OpenGL ES calls from your code. （不要有opengl处理调用的代码）
在后台的程序是不能够创建EAGLContext 对象或者使用OpenGL ES绘画的一些命令在后台程序，应用调用这些命令立即会被杀掉。程序必须确定前面提到的这些命令被杀掉在进入后台之前，关于如何处理当从进入后台或者从后台出来查看： Implementing a Multitasking-aware OpenGL ES Application in OpenGL ES Programming Guide for iOS （在直播的时候应该也是需要处理图像的）
（2）Cancel any Bonjour-related services before being suspended. （移除bonjour的关联）
当你移到后台程序时在被悬挂之前，需要移除bonjour的注册和关闭socket链接网络服务。一个悬挂的应用不能够响应任何服务进来的请求。关闭这些服务阻住它们显示是可用的当实际上是不可用的（也就是显示和实际发生的错乱）。如果你没有关闭Bonjour服务，系统将会自动关闭当程序被悬挂的时候.
Be prepared to handle connection failures in your network-based sockets.
（准备好处理基于网络套接字的连接故障）
系统可能会拆毁套接字的链接你的应用汇悬挂（由于一些原因），例如当一个丢失的信号或者网络转变，都可能造成不常见的问题。当你的应用重启的时候，可能会遇到错误使用socket，简单的方式就是重新连接。
（4）Save your app state before moving to the background.
（保存程序的状态在移到后台程序之前）
在低内存中环境下，后台程序可能会被清洗掉从空闲的地方。悬挂的程序首先会被清洗掉和在清洗掉之前没有任何通知。结果，应用程序会使用ios6以及后面的系统版本去保存它们接口的装填到硬盘上。关于怎么样支持这个特点，查看:Preserving Your App’s Visual Appearance Across Launches.
（5）Remove strong references to unneeded objects when moving to the background。（移除没有需要的强引用对象）
如果你的应用有大量的缓存对象（尤其是图片），会移除所有的强引用缓存对象在移到后台之前。更多信息查看：Reduce Your Memory Footprint
（6）Stop using shared system resources before being suspended （停止使用分享系统资源在悬挂之前）
与程序有交互的分享系统资源，例如： 相册或者日历数据库应该停止使用这些资源在悬挂之前。这些资源的访问权限都是前台程序。当你的程序悬挂了，如果你的程序被发现在使用分享资源，就会被kill掉。
（7）Avoid updating your windows and views. （避免更新你的windows和views）
因为程序的window和views 是不可见的当你的程序在后台，你应该免费更新他们。异常会出现当你需要更新window的内容和window的等级给程序镜像。
（8）Respond to connect and disconnect notifications for external accessories （响应链接和不连接通知对于额外的附件）
当程序在和额外的资源交流的时候，系统自然发送一个断开连接的通知当应用移到后台的时候。应用必须注册这个通知和使用它去关闭当前的附件回话。更多信息是处理附件连接和断开通知。查看External Accessory Programming Topics.
（9）Clean up resources for active alerts when moving to the background.
（清除资源对于激活的而警告当移到后台）
为了保存上下文当交换程序的时候，系统没有自动解除sheets（UIActionSheet） 或者alert 视图（UIAlertView）但你的程序移到后台。会提供一个写清楚的行为权限去移到后台。例如：你可能想取消action sheet或者alert view 或者保存足够的上下文信息去存储视图（后来）【在这个用例中你的程序会被中断】。
（10）Remove sensitive information from views before moving to the background. 从view上移除敏感信息
当程序转化为后台的时候，，系统会镜像当前主要的window，会有简单的系那是当程序返回到前台。在返回你的applicationDidEnterBackground:
这个方法之前，你应该隐藏或者使密码复杂化和其他敏感的个人细腻可能被获取在镜像的时候。
（11）**Do minimal work while running in the background. **（做一些最小的工作在后台）
执行时间对于后台程序来说会有更多的限制对于前台程序。程序花费很多时间去执行在后台可能被减速或者终止。
如果你的是后台音频程序，或者其他类型的程序允许运行在后台，你的程序应该响应输入信息在任何方式。换句话，系统可能通知你的程序低内存警告当他们发生的时候。系统需要去终止程序去释放更多的内存，程序会调用它的代理方法applicationWillTerminate: 去执行最后的任务在退出之前。
Opting Out of Background Execution (选择退出后台执行)
如果你根本就不想程序在后台执行，直接明确在info.plist 文件中设置UIApplicationExitsOnSuspend （key）的值为yes；
当我们选择了退出后台执行的这种设置，在not-running、inactive、active states 从来不会进入到后台或者暂停或者悬挂状态。
这个时候，当用户点击home键的退出应用时，applicationWillTerminate: （app delegate方法）被调用，应用大概有5s的时候去清除和退出再程序终止和移到没有运行的状态之前。
选择退出后台执行不推荐使用，但是可能在特定条件下选择。尤其是如果在后台执行中添加重要复杂的代码，终止应用可能是一个解决方法。同样，如果你的小号很多内存和不能够很容易释放，系统可能会杀掉当期的应用将空间让给其他应用。所以，选择终止而不是到后台可能会产生相同的结果和保存你的开发和努力。
Information Property List Key Reference info.plist 设置
认真的人改变自己，执着的人改变命运！！！
仔细、认真很重要
死磕！！！
匠心！！！
良好心态、持之以恒！！！
人生总有纠结的事情！！！
当你有怀疑时，就用暴力破解！！
如何高效掌握一门新技术！！！
以马为梦，不负韶华！！！
如果你一生只有一次翻身的机会，就要用尽全力！
后台执行 当用户没有主动使用您的应用程序时，系统将其移动到后台状态。对于许多应用程序，后台状态只是暂停应用程序的一个短暂停留。暂停应用程序是提高电池寿命的一种方式，它还允许系统将重要的系统资源投入到引起用户关注的新前台应用程序中。 大多数应用程序可以轻松变换到暂停状态，但是...
用两张图告诉你，为什么你的 App 会卡顿? - Android - 掘金Cover 有什么料？ 从这篇文章中你能获得这些料： 知道setContentView()之后发生了什么？ ... Android 获取 View 宽高的常用正确方式，避免为零 - 掘金相信有很多朋友...
用两张图告诉你，为什么你的 App 会卡顿? - Android - 掘金 Cover 有什么料？ 从这篇文章中你能获得这些料： 知道setContentView()之后发生了什么？ ... Android 获取 View 宽高的常用正确方式，避免为零 - 掘金 相信有很多...
IOS开发之----详解在IOS后台执行
文一 我从苹果文档中得知，一般的应用在进入后台的时候可以获取一定时间来运行相关任务，也就是说可以在后台运行一小段时间。 还有三种类型的可以运行在后以， 1.音乐 2.location 3.voip 文二 在IOS后台执行是本文要介...
机会地获取少量内容 需要定期检查新内容的应用程序可以要求系统将其唤醒，以便它们可以启动该内容的提取操作。要支持此模式，请在Xcode项目的“功能”选项卡的“后台模式”部分中启用“后台提取”选项。（您也可以通过在应用程序的Info.plist文件中包含带有fetch值的UIB...
文/张宏涛 上个月，我打算建个心理学学习群，向喜欢心理学的人分享：如何在生活中运用基础心理学里提到的各种理论。 每周分享三次，每次花一两个小时。不费很多时间，还可以和大家交流，我也可以因此好好总结一下我所掌握的心理学的技能。我打算一共讲108个心理学基础知识如何在现实生活中...
真正的缘分是不管历经多少岁月，你我都会以彼此最好的姿态遇见！真正的爱情是即使相隔千山万水，我依然有奋不顾身奔向你的勇气！ 嗯，原来是你…… 作者|迷糊的豆芽儿 我跟闺蜜S小姐是高中同学，高中毕业以后我们就失去了联系。直到毕业后来到同一所城市工作，才发展了一段可歌可泣的革命友...
近来善感，此心清透，多捕即逝之转瞬，常为点滴落泪，又观锦鳞畅游而悦。南邻龙湖之窗，可赏朝夕日出西落，日度四季之恍惚，一梦华胥之离乱。 阅典论今，英雄暮迟，儿女情短，丝丝缕缕沁入善敏之心，或悲切掩面，或喜尽畅怀。抬头望，日落茶凉又一梦，岁序更迭无人见，唯有红颜华发落镜边~
在《英雄联盟》中有很多令人神烦的技能，这些技能往往会让玩家陷入尴尬而绝望的处境。今天小编就罗列出了玩家心中最烦的10大技能，一起来看看吧！（排名不分先后） 哨兵之殇-杜朗石像 在开团的瞬间，开起大招，让所有人都攻击自己(抖M必玩的啊)而且还是强制性的攻击。打你越疼，伤害就越...