苹果应用内支付(iOS IAP)的流程与常用攻击方式

Jan 19, 2017

通过dns污染,让客户端通过假的apple_server进行verify,从而认为自己支付成功。这个主要针对**支付方式一**,如果是支付方式二,就没效果了。常见的iap hack软件@iAPFree @iAP Cracker 就是用的类似原理。

一.简介
什么是IAP，即in-app-purchase。(虚拟商品如：课程、视频、音乐等数字产品只能走apple 的内购)，苹果要扣除30%的销售额,再扣除一点相关的交易税，用户到手将不到7成。

官方参考文档

内购流程
1.获取内购列表（从App内读取或从自己服务器读取）
2.App Store请求可用的内购列表
3.向用户展示内购列表
4.用户选择了内购列表，再发个购买请求，收到购买完成的回调（购买完成后会把钱打给申请内购的银行卡内）
5.购买流程结束后, 向服务器发起验证凭证以及支付结果的请求
6.自己的服务器将支付结果信息返回给前端并发放虚拟产品
7.服务端的工作比较简单，分4步：
7.1.接收ios端发过来的购买凭证。
7.2.判断凭证是否已经存在或验证过，然后存储该凭证。
7.3.将该凭证发送到苹果的服务器验证，并将验证结果返回给客户端。
7.4.如果需要，修改用户相应的会员权限。
7.5.考虑到网络异常情况，服务器的验证应该是一个可恢复的队列，如果网络失败了，应该进行重试。
简单来说就是将该购买凭证用Base64编码，然后POST给苹果的验证服务器，苹果将验证结果以JSON形式返回。

二、流程
1.登录苹果开发者网站新建一个App应用:

2.填写协议、税务、银行信息:

3.创建内购商品:
(1).商品名称根据你的消费道具的实际意义来说明，比如“100颗宝石”，“100金币”等。

(2).产品ID是比较重要的，由项目自定义，只要唯一即可，我一般都是用App的bundleID加一个后缀来表示，这样既跟项目关联又具有唯一性。

(3).价格等级的话“查看价格表”中有对应的说明，可以对照着表中每个国家的货币价格与等级来选择。

4.添加沙盒测试者
沙盒测试环境下苹果不会抽成，购买成功后直接返回商品。

appid 需要时从未与apple id 从未关联过的账号
appid 可以是任何有效的邮箱地址

5.内购代码封装IapManager.swift：

//
// IapManager.swift
// tai_chi
//
// Created by vincent on 2019/10/9.
// Copyright © 2019 vincent. All rights reserved.
//

import Foundation
import StoreKit

//内购协议
@objc protocol IapManagerProtocol {

//商品请求结果回调
func productsResponse(_ response:SKProductsResponse?,error:Error?)

//交易成功回调
func completedTransaction(_ transaction:SKPaymentTransaction)

//交易失败回调
@objc optional func transactionFail(transaction:SKPaymentTransaction)

}

//内购管理
class IapManager : NSObject,SKProductsRequestDelegate,SKPaymentTransactionObserver {

private static var instance:IapManager?

var delegate:IapManagerProtocol?

var requestResponse:SKProductsResponse?

var requestErr:Error?

override init() {

super.init()
SKPaymentQueue.default().add(self)

}

//静态方法
static func shared() -> IapManager{

if instance == nil {
instance = IapManager()
}
return instance!
}

//判断app 是否允许apple pay
func canPayments() -> Bool{
return SKPaymentQueue.canMakePayments()
}

//请求商品
//productIds 内购商品id 集合
func requestProducts(productIds:Set<String>){
let request = SKProductsRequest(productIdentifiers: productIds)
request.delegate = self
request.start()

}

//购买商品
func addPayment(_ payment:SKPayment){
SKPaymentQueue.default().add(payment)
}

//监听商品返回信息，然后使用返回的商品信息发起购买请求
func productsRequest(_ request: SKProductsRequest, didReceive response: SKProductsResponse) {
print(“————–收到产品反馈消息———————“)
self.requestResponse = response

}

func request(_ request: SKRequest, didFailWithError error: Error) {
print(“————–收到产品反馈错误消息———————“)
print(error)
self.requestErr = error

}

func requestDidFinish(_ request: SKRequest) {
print(“————–反馈消息结束———————“)
self.delegate?.productsResponse(self.requestResponse, error: self.requestErr)
}

//获取内购成功后apple server 返回给客户端的数据
func receiptData() -> NSData? {

let url = Bundle.main.appStoreReceiptURL
var data:NSData? = nil

if url != nil {
data = NSData(contentsOf: url!)

}
return data
}

//监听购买结果
func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) {

for transaction in transactions{

if transaction.transactionState == .purchasing {
print(“————–updatedTransactions———————purchasing”)

}
else if transaction.transactionState == .purchased {
print(“————–updatedTransactions———————purchased”)
SKPaymentQueue.default().finishTransaction(transaction)
self.delegate?.completedTransaction(transaction)

}
else if transaction.transactionState == .failed {
print(“————–updatedTransactions———————failed”)
SKPaymentQueue.default().finishTransaction(transaction)
self.delegate?.transactionFail?(transaction: transaction)
}
else if transaction.transactionState == .restored {
print(“————–updatedTransactions———————restored”)
SKPaymentQueue.default().finishTransaction(transaction)

}
else if transaction.transactionState == .deferred {
print(“————–updatedTransactions———————deferred”)

}
}

}

deinit {
SKPaymentQueue.default().remove(self)
}
}

6.交易相关代码:

ViewController

func completedTransaction(_ transaction: SKPaymentTransaction) {

let data = IapManager.shared().receiptData()
if data != nil {
//获取交易成功凭证
let base64Str = (data! as NSData).base64EncodedString()

//本地记录充值成功 以防后台请求失败时下次进入app 时再网络请求
UserDefaults.standard.set(base64Str, forKey: “iap_transaction_key”)

//网络通知服务器和苹果服务器验证是否交易成功 并给相关账号充值

}

}

AppDelegate 检测是否有漏单请求，并把漏单通知服务器

//用户内购成功后需要通知服务器，此过程可能网络请求失败
//检测是否有充值还未提交给服务器
if let pams = UserDefaults.standard.dictionary(forKey:”iap_transaction_key” ) {

//网络通知服务器

}

三.测试:
1.沙盒环境测试appStore内购流程的时候，请使用没越狱的设备。

2.请务必使用真机来测试，一切以真机为准。

3.项目的Bundle identifier需要与您申请AppID时填写的bundleID一致，不然会无法请求到商品信息。

4.退成App Store 账号:

测试截屏如下：

环境说明：

在wind7环境下，通过bat脚本将指定的文件上传到远程的Linux FTP服务器上。

上传文件目录：F:\crawlerServer

上传脚本：ftp-put.bat

上传脚本配置文件：ftp.cfg

Linux FTP服务器：192.168.13.21

1.ftp-put.bat脚本：

@echo off

set /p upload=请选择是否将打包后的文件上传到服务器中？(Y/N):

if %upload%==Y (
echo 开始上传文件……
ftp -n -s:”ftp.cfg” >> ftp1.log
echo 上传文件结束….
)
2.ftp.cfg配置文件：

此文件其实是一个ftp操作命令文件，一行就表示一个命令，如下所示：

open 192.168.13.21 #远程FTP服务器IP
user
liuzx #登录用户名
Password1 #登录密码
bin #传输类型 二进制传输：bin Ascii传输：ascii
cd public/docs/deploy_package/winmarket #切换远程FTP的目录，用于存放上传的文件，请确保上面的用户对该目录有写权限
put crawlerServer_0.0.0.1.tar.gz #上传文件
bye #结束与远程FTP服务器的连接

3.运行ftp-put.bat脚本：
效果如下：

4.查看ftp1.log日志文件，如下是部分日志信息：

230 Login successful.
ftp> bin
200 Switching to Binary mode.
ftp> cd public/docs/deploy_package/winmarket
250 Directory successfully changed.
ftp> put crawlerServer_0.0.0.1.tar.gz
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
ftp> 0.7710713.90bye
221 Goodbye.

5.如果对上面配置文件中的目录没有写权限，日志信息如下：
ftp> cd public/docs/deploy_package/winmarket
250 Directory successfully changed.
ftp> put crawlerServer_0.0.0.1.tar.gz
200 PORT command successful. Consider using PASV.
553 Could not create file.

ftp> bye
221 Goodbye.

新建bat文件

@echo off
:: 设置颜色
color b0
echo ‘上传中…’
:: 打印空行
echo.

:: pscp配置参数
:: -p 拷贝文件的时候保留源文件建立的时间。
:: -v 拷贝文件时，显示提示信息。
:: -pw 指定密码
:: -r 拷贝目录
:: 多文件 直接空格即可

:: 上传 ./index.html目录到/mnt/web目录下面
pscp -v -r -p -pw 123456 ./index.html root@192.168.1.10:/mnt/web

pause

pscp 是用来上传文件的，window默认是没有这个的，需要下载exe，并放到C:\WINDOWS\system32 目录

1.bat
1.1以管理员权限运行
%1 mshta vbscript:CreateObject(“Shell.Application”).ShellExecute(“cmd.exe”,”/c %~s0 ::”,””,”runas”,1)(window.close)&&exit cd /d “%~dp0″
1.2设置变量
title json转换脚本
set File_Path=%~dp0
set ip=”192.168.1.101″
set pw=”123456”
1.3检查网络
echo —检查远程服务器网络，请等待—
ping %ip% -n 2 > ping.txt
findstr “TTL” ping.txt
if %errorlevel% == 0 (
echo —network is ok—
goto ok
)
if %errorlevel% == 1 (
echo —网络连接失败，请检查与服务器网络—
pause
ping.txt
del /f /s /q ping.txt
exit
)
1.4解压压缩包
解压出json格式文件

“C:\Program Files\WinRAR\WinRAR.exe” x -ad *.zip *.json
2.putty
2.1通过putty上传文件
pscp.exe -P 22 -pw %pw% -l root %File_Path%poi.json root@%ip%:/opt/
pscp.exe -P <端口> -pw <密码> 文件 root@<ip>:<存放路径>

2.2远程执行脚本
plink.exe -l root -P 22 -pw %pw% -ssh -no-antispoof root@%ip% cd /opt/;sh switch.sh
2.3回传文件
pscp.exe -P 22 -l root -pw %pw% root@%ip%:/opt/cms.json %File_Path%
3.脚本
%1 mshta vbscript:CreateObject(“Shell.Application”).ShellExecute(“cmd.exe”,”/c %~s0 ::”,””,”runas”,1)(window.close)&&exit cd /d “%~dp0″
@echo off
title json转换脚本
set File_Path=%~dp0
set ip=”192.168.1.101″
set pw=”123456”
cd %~dp0
echo —检查远程服务器网络，请等待—
ping %ip% -n 2 > ping.txt
findstr “TTL” ping.txt
if %errorlevel% == 0 (
echo —network is ok—
goto ok
)
if %errorlevel% == 1 (
echo —网络连接失败，请检查与服务器网络—
pause
ping.txt
del /f /s /q ping.txt
exit
)
:ok
echo —开始解压—
echo —获取压缩包名称—
for /f “delims=” %%j in (‘dir /b/a-d/oN *.zip*’) do set name=%%~nj
echo 解压地图名为 %name%
echo ——-开始检查是否已存在地图文件—–
if exist %name% (
echo —存在—
echo —删除—
rd /s /q %name%
)

echo ——-开始检查是否已存在cms.json—–
if exist cms.json (
echo —存在—
echo —删除—
del /f /s /q cms.json
)

“C:\Program Files\WinRAR\WinRAR.exe” x -ad *.zip *.json
move %name%\semantics_poi_layer\poi.json

echo —删除地图文件夹—
rd /s /q %name%

echo —上传Json文件至服务器—
pscp.exe -P 22 -pw %pw% -l root %File_Path%poi.json root@%ip%:/opt/
echo —远程执行脚本—
plink.exe -l root -P 22 -pw %pw% -ssh -no-antispoof root@%ip% cd /opt/;sh switch.sh
echo —回传json文件—
pscp.exe -P 22 -l root -pw %pw% root@%ip%:/opt/cms.json %File_Path%
del /f /s /q poi.json
del /f /s /q ping.txt
echo 完成转换，按任意键退出
pause
cms.json

远程连接上传下载文件问题

上传文件
put filename

下载文件
get filename

下载文件夹
首先在远程新建一个文件（命名和本地相同） mkdir hello_python 并且cd到这个文件

接着切换到本机要上传的文件目录（我的这个是在桌面） lcd C:\Users\xiao\Desktop
上传文件夹 put -r hello_python
ls 显示上传成功

下载文件夹
文件夹一般不直接下载，可以先cd 到这个文件夹，然后get文件

cmd常用命令

get 获取、下载远程文件
put 远程上传文件
mget 一次性批量下载远程文件
mput 远程上传批量文件
ls 显示目录中文件名字的列表
rm 删除文件
mv 重命名文件或将它移到新的目录
cd 切换到想要的目录
pwd 查看远程主机所在的确切路径
lcd 切换本地目录
lpwd 查询本地目录
close 终止SFTP会话，但不会退出PSFTP
open 建立到给定主机的STFP连接

连接服务端

另一种方式，打开cmd程序，进入到mysql安装目录的bin目录下

1. 1、进入mysql的bin目录
2. cd C:\Program Files (x86)\MySQL\MySQL Server 5.1\bin
4. 2、连接mysql
5. mysql -uroot -p

数据库
查看所有数据库
show databases;
使用数据库
use 数据库名;
查看当前使用的数据库
select database();
创建数据库
create database 数据库名 charset=utf8;
例：
create database ceshi charset=utf8;
删除数据库
drop database 数据库名;
例：
drop database ceshi;
数据表
查看当前数据库中所有表
show tables;
查看表结构
desc 表名;
查看表的创建语句

show create table 表名;
例：
show create table students;
备份
以管理员身份运行cmd程序

运行mysqldump命令
cd C:\Program Files (x86)\MySQL\MySQL Server 5.1\bin

mysqldump –uroot –p 数据库名 > ceshi.sql

# 按提示输入mysql的密码
恢复
先创建新的数据库
mysql -uroot –p 新数据库名 < ceshi.sql
# 根据提示输入mysql密码

Context相信所有的Android开发人员基本上每天都在接触，因为它太常见了。但是这并不代表Context没有什么东西好讲的，实际上Context有太多小的细节并不被大家所关注，那么今天我们就来学习一下那些你所不知道的细节。

Context类型

我们知道，Android应用都是使用Java语言来编写的，那么大家可以思考一下，一个Android程序和一个Java程序，他们*大的区别在哪里？划分界限又是什么呢？其实简单点分析，Android程序不像Java程序一样，随便创建一个类，写个main()方法就能跑了，而是要有一个完整的Android工程环境，在这个环境下，我们有像Activity、Service、BroadcastReceiver等系统组件，而这些组件并不是像一个普通的Java对象new一下就能创建实例的了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。

下面我们来看一下Context的继承结构：

Context的继承结构还是稍微有点复杂的，可以看到，直系子类有两个，一个是ContextWrapper，一个是ContextImpl。那么从名字上就可以看出，ContextWrapper是上下文功能的封装类，而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity。

那么在这里我们至少看到了几个所比较熟悉的面孔，Activity、Service、还有Application。由此，其实我们就已经可以得出结论了，Context一共有三种类型，分别是Application、Activity和Service。这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。

那么Context到底可以实现哪些功能呢？这个就实在是太多了，弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等等等都需要用到Context。由于Context的具体能力是由ContextImpl类去实现的，因此在*大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊，比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android是不允许Activity或Dialog凭空出现的，一个Activity的启动必须要建立在另一个Activity的基础之上，也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出（除非是System Alert类型的Dialog），因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。

Context数量

那么一个应用程序中到底有多少个Context呢？其实根据上面的Context类型我们就已经可以得出答案了。Context一共有Application、Activity和Service三种类型，因此一个应用程序中Context数量的计算公式就可以这样写：

上面的1代表着Application的数量，因为一个应用程序中可以有多个Activity和多个Service，但是只能有一个Application。

Application Context的设计

基本上每一个应用程序都会有一个自己的Application，并让它继承自系统的Application类，然后在自己的Application类中去封装一些通用的操作。其实这并不是Google所推荐的一种做法，因为这样我们只是把Application当成了一个通用工具类来使用的，而实际上使用一个简单的单例类也可以实现同样的功能。但是根据我的观察，有太多的项目都是这样使用Application的。当然这种做法也并没有什么副作用，只是说明还是有不少人对于Application理解的还有些欠缺。那么这里我们先来对Application的设计进行分析，讲一些大家所不知道的细节，然后再看一下平时使用Application的问题。

首先新建一个MyApplication并让它继承自Application，然后在AndroidManifest.xml文件中对MyApplication进行指定，如下所示：

指定完成后，当我们的程序启动时Android系统就会创建一个MyApplication的实例，如果这里不指定的话就会默认创建一个Application的实例。

前面提到过，现在很多的Application都是被当作通用工具类来使用的，那么既然作为一个通用工具类，我们要怎样才能获取到它的实例呢？如下所示：

可以看到，代码很简单，只需要调用getApplication()方法就能拿到我们自定义的Application的实例了，打印结果如下所示：

那么除了getApplication()方法，其实还有一个getApplicationContext()方法，这两个方法看上去好像有点关联，那么它们的区别是什么呢？我们将代码修改一下：

同样，我们把getApplicationContext()的结果打印了出来，现在重新运行代码，结果如下图所示：

咦？好像打印出的结果是一样的呀，连后面的内存地址都是相同的，看来它们是同一个对象。其实这个结果也很好理解，因为前面已经说过了，Application本身就是一个Context，所以这里获取getApplicationContext()得到的结果就是MyApplication本身的实例。

那么有的朋友可能就会问了，既然这两个方法得到的结果都是相同的，那么Android为什么要提供两个功能重复的方法呢？实际上这两个方法在作用域上有比较大的区别。getApplication()方法的语义性非常强，一看就知道是用来获取Application实例的，但是这个方法只有在Activity和Service中才能调用的到。那么也许在*大多数情况下我们都是在Activity或者Service中使用Application的，但是如果在一些其它的场景，比如BroadcastReceiver中也想获得Application的实例，这时就可以借助getApplicationContext()方法了，如下所示：

也就是说，getApplicationContext()方法的作用域会更广一些，任何一个Context的实例，只要调用getApplicationContext()方法都可以拿到我们的Application对象。

那么更加细心的朋友会发现，除了这两个方法之外，其实还有一个getBaseContext()方法，这个baseContext又是什么东西呢？我们还是通过打印的方式来验证一下：

哦？这次得到的是不同的对象了，getBaseContext()方法得到的是一个ContextImpl对象。这个ContextImpl是不是感觉有点似曾相识？回去看一下Context的继承结构图吧，ContextImpl正是上下文功能的实现类。也就是说像Application、Activity这样的类其实并不会去具体实现Context的功能，而仅仅是做了一层接口封装而已，Context的具体功能都是由ContextImpl类去完成的。那么这样的设计到底是怎么实现的呢？我们还是来看一下源码吧。因为Application、Activity、Service都是直接或间接继承自ContextWrapper的，我们就直接看ContextWrapper的源码，如下所示：

由于ContextWrapper中的方法还是非常多的，我就进行了一些筛选，只贴出来了部分方法。那么上面的这些方法相信大家都是非常熟悉的，getResources()、getPackageName()、getSystemService()等等都是我们经常要用到的方法。那么所有这些方法的实现又是什么样的呢？其实所有ContextWrapper中方法的实现都非常统一，就是调用了mBase对象中对应当前方法名的方法。

那么这个mBase对象又是什么呢？我们来看第16行的attachBaseContext()方法，这个方法中传入了一个base参数，并把这个参数赋值给了mBase对象。而attachBaseContext()方法其实是由系统来调用的，它会把ContextImpl对象作为参数传递到attachBaseContext()方法当中，从而赋值给mBase对象，之后ContextWrapper中的所有方法其实都是通过这种委托的机制交由ContextImpl去具体实现的，所以说ContextImpl是上下文功能的实现类是非常准确的。

那么另外再看一下我们刚刚打印的getBaseContext()方法，在第26行。这个方法只有一行代码，就是返回了mBase对象而已，而mBase对象其实就是ContextImpl对象，因此刚才的打印结果也得到了印证。

使用Application的问题

虽说Application的用法确实非常简单，但是我们平时的开发工作当中也着实存在着不少Application误用的场景，那么今天就来看一看有哪些比较容易犯错的地方是我们应该注意的。

Application是Context的其中一种类型，那么是否就意味着，只要是Application的实例，就能随时使用Context的各种方法呢？我们来做个实验试一下就知道了：

这是一个非常简单的自定义Application，我们在MyApplication的构造方法当中获取了当前应用程序的包名，并打印出来。获取包名使用了getPackageName()方法，这个方法就是由Context提供的。那么上面的代码能正常运行吗？跑一下就知道了，你将会看到如下所示的结果：

应用程序一启动就立刻崩溃了，报的是一个空指针异常。看起来好像挺简单的一段代码，怎么就会成空指针了呢？但是如果你尝试把代码改成下面的写法，就会发现一切正常了：

运行结果如下所示：

在构造方法中调用Context的方法就会崩溃，在onCreate()方法中调用Context的方法就一切正常，那么这两个方法之间到底发生了什么事情呢？我们重新回顾一下ContextWrapper类的源码，ContextWrapper中有一个attachBaseContext()方法，这个方法会将传入的一个Context参数赋值给mBase对象，之后mBase对象就有值了。而我们又知道，所有Context的方法都是调用这个mBase对象的同名方法，那么也就是说如果在mBase对象还没赋值的情况下就去调用Context中的任何一个方法时，就会出现空指针异常，上面的代码就是这种情况。Application中方法的执行顺序如下图所示：

Application中在onCreate()方法里去初始化各种全局的变量数据是一种比较推荐的做法，但是如果你想把初始化的时间点提前到*致，也可以去重写attachBaseContext()方法，如下所示：

以上是我们平时在使用Application时需要注意的一个点，下面再来介绍另外一种非常普遍的Application误用情况。

其实Android官方并不太推荐我们使用自定义的Application，基本上只有需要做一些全局初始化的时候可能才需要用到自定义Application，官方文档描述如下：

但是就我的观察而言，现在自定义Application的使用情况基本上可以达到100%了，也就是我们平时自己写测试demo的时候可能不会使用，正式的项目几乎全部都会使用自定义Application。可是使用归使用，有不少项目对自定义Application的用法并不到位，正如官方文档中所表述的一样，多数项目只是把自定义Application当成了一个通用工具类，而这个功能并不需要借助Application来实现，使用单例可能是一种更加标准的方式。

不过自定义Application也并没有什么副作用，它和单例模式二选一都可以实现同样的功能，但是我见过有一些项目，会把自定义Application和单例模式混合到一起使用，这就让人大跌眼镜了。一个非常典型的例子如下所示：

就像单例模式一样，这里提供了一个getInstance()方法，用于获取MyApplication的实例，有了这个实例之后，就可以调用MyApplication中的各种工具方法了。

但是这种写法对吗？这种写法是大错特错！因为我们知道Application是属于系统组件，系统组件的实例是要由系统来去创建的，如果这里我们自己去new一个MyApplication的实例，它就只是一个普通的Java对象而已，而不具备任何Context的能力。有很多人向我反馈使用 LitePal 时发生了空指针错误其实都是由于这个原因，因为你提供给LitePal的只是一个普通的Java对象，它无法通过这个对象来进行Context操作。

那么如果真的想要提供一个获取MyApplication实例的方法，比较标准的写法又是什么样的呢？其实这里我们只需谨记一点，Application全局只有一个，它本身就已经是单例了，无需再用单例模式去为它做多重实例保护了，代码如下所示：

getInstance()方法可以照常提供，但是里面不要做任何逻辑判断，直接返回app对象就可以了，而app对象又是什么呢？在onCreate()方法中我们将app对象赋值成this，this就是当前Application的实例，那么app也就是当前Application的实例了。

4、Context的应用场景

start activity ：    需要提供一个task  除了activity其他的context都没有task,     如果在intent 的flag 添加NEW_TASK  属性创建一个新的task，其他context也是可以start activity的

show dialog  ：    dialog需要依附一个窗口 只有activity自带一个窗口，如果设置dialog为system.alert  使dialog依附系统窗口 ，其他context也是可以show dialog的

layout inflate ：   在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，因为只有activity 是继承的ContextThemeWrapper带有theme。

其他context可以通过ContextThemeWrapper mContextThemeWrapper = new ContextThemeWrapper(context, theme);

创建一个带theme的context对象ContextThemeWrapper使用，这样其他context也可创建带theme的layout

大家注意看到有一些NO上添加了一些数字，其实这些从能力上来说是YES，但是为什么说是NO呢？下面一个一个解释：

数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。

数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。

数字3：在receiver为null时允许，在4.2或以上的版本中，用于获取黏性广播的当前值。（可以无视）

注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因为在其内部方法中都有一个context用于使用。

好了，关于Context的介绍就到这里吧，内容还是比较简单易懂的，希望大家通过这篇文章可以理解Context更多的细节，并且不要去犯使用Context时的一些低级错误。