真机调试相关知识点

真机调试相关知识点

一.真机调试

1.真机调试简介

• 概念:将App项目运行到真机上进行测试,就叫真机调试
• 为什么要进行真机调试?
  • 因为真机和模拟器的环境有差异
  • 内存环境/网络环境
  • 传感器开发(磁力计/陀螺仪/距离传感器等)
  • 特定功能(拍照/打电话/发短信/蓝牙等)
  • 用户体验不一样
  • 在app发布之前一定要进行真机调试
• 如果做真机调试
  • Xcode7.0之前不是任何人,任何电脑,任何APP,任何真机设备都可以进行真机调试的(限制:开发者/电脑/app/真机设备)
  • Xcode7.0之后,做真机调试只需要拥有AppleID即可,会自动生成对应证书(并不是不需要以上限制)

2.Xcode7.0之前的真机调试

• 限制人(申请开发者账号)
  • 理论基础
    • 必须拥有AppleID
    • 加入开发者计划,升级为"开发者账号"
    • 开发者账号分类
      • 个人账号($99)
        • 功能:可以真机调试,打包测试,程序发布
        • 优点:申请速度/给钱就行/1-3个工作日即可
        • 缺点:iTunes查看到的是个人信息,无法间接为公司做宣传/无法创建管理自己的开发团队
      • 公司账号($99)
        • 功能:可以真机调试,打包测试,程序发布
        • 优点:iTunes可以查看企业信息,间接为公司做宣传/可以创建和管理自己的开发团队
        • 缺点:申请复杂,需要"邓白氏"认证/申请周期比较长(连同"邓白氏编码"申请,最好准备30天左右时间)
      • 企业账号($299)
        • 功能:可以真机调试,打包测试
        • 优点:可以在企业内部随意安装到苹果设备,不需要经过AppStore审核/可以创建和管理自己的开发团队/版本更新迭代比较快,不需要经过审核
        • 缺点:申请复杂,需要"邓白氏"认证/申请周期比较长(和申请公司账号时间差不多)/不能使用此证书,将App发布到AppStore
        • 使用场景:App是针对某一特定人群制定使用,只在企业内部安装,无需发布到AppStore供他人下载,同时也不能发布到AppStore
    • 小经验:尽量不要从网络渠道以及代申请的公司去申请"邓白氏编码"
      • 花钱多,而且申请下来的"邓白氏编码"不一定和苹果服务器数据库内一直,最终不可用,浪费时间和金钱
      • 正确做法是通过苹果客服电话,联系客服人员,沟通申请流程以及需要提交的材料
• 限制电脑(配置与电脑关联的cer证书)
  • 使用要进行真机调试的电脑生成CSR文件
    • CSR文件:证书签名请求文件
    • 作用:每台电脑生成的都不一样,能够唯一识别不同的电脑
  • 真机调试证书只能生成两个
    • 也就意味着,只能绑定两台电脑进行真机调试
    • 注意:如果别人已经配置了两个,而且正在使用,不能随便把别人的证书删除
    • 解决方案:
      • 此时只能使用从已配置证书的电脑中,导出P12文件,进行共享
      • 作用:让其他电脑设备不需要生成cer证书,也可以进行真机调试
  • 注意:证书是分类型的,不同的证书,有不同的作用(真机调试证书/打包测试证书/推送证书)
• 限制APP(配置需要真机测试APP的BundleID)
  • 区分不同App就是通过APP的唯一标识符:BundleID
  • 明确的BundleID:可以开发一些特定功能,比如内购
  • 模糊的BundleID:某些特定功能无法开发,但可以适配多个App
• 限制真机设备(配置需要真机测试的设备UDID)
  • UUID:苹果的每台设备都拥有的一个唯一标示
  • 测试的真机设备UUID最多只能添加100次,而不是100台
  • 也就是说,如果加够了100次之后,即使删除之前的设备名额,也无法继续添加
  • 解决方案:
    • 苹果会在下一年,给一次删除设备的机会,可以删除一些设备,来恢复一些名额
    • 但是,一旦添加了设备后,苹果则视为自动放弃添加设备
• 根据前面三项生成一个描述文件
  • 描述文件的作用:在本地验证各项配置是否正确
• 真机调试以及注意事项
  • 完成了上述步骤以后,会生成两个文件.cer文件和.MobileProvision文件,只需双击安装即可(cer文件被添加到钥匙串中/描述文件被安装到Xcode中(资源库->MobileDevice->Provisioning Profiles))
  • 必须保证cer证书和描述文件一致(Xcode->targets->build setting->code signing)
  • 创建一个APP,并确认BundleID与配置一致,如果不一致,修改Xcode项目的BundleID,保持与配置一致
  • 真机运行时,如果发现真机设备无法选中,查看项目最低部署版本是否过高,大于真机设备的系统版本.如果真机设备系统版本过高,则无法选中真机进行运行
  • 真机调试最终需要的文件(补充)
    • cer文件(或p12文件):双击安装,安装后存放在钥匙串
    • MobileProvision文件:双击安装,安装后存放在Xcode中(路径:~/Library/MobileDevice/Provisioning Profiles)

3.Xcode7.0之后的真机调试

• 只需要AppleID即可,在Xcode->preference->Account中添加即可
• 然后直接连接手机进行调试,会弹出一个框,提示缺少描述文件和证书,直接点击"Fix issue"选项,Xcode会自动请求苹果服务器生成对应的描述文件和证书
• 注意事项:
  • AppID必须是没有和某个公司开发者账号关联(没有被添加到某个开发团队)
  • iOS9之前版本的真机也可以通过这种方式进行真机调试,但是最好把App BundleID改成英文的,不要带有汉字转换后的
• 常见问题
  • The account xxx has no team with ID xxx
    • 直接进入苹果开发者技术支持,联系客服人员
  • An App ID with identifier xxx is not avaliable.Please enter a different string
    • 可能是别人已经使用了该BundleID,只需要更换一个即可
  • Count not launch xxx.process launch failed:Security
    • 进入手机设置->通用->设备管理->信任设备

二.打包测试

1.简介

• 打包测试:将项目打包成.ipa的压缩包,供指定设备安装测试
• 打包测试目的:
  • 项目进入测试阶段,需要专门的测试人员对app进行测试,此时需要将app安装到测试人员的测试设备上,此时的最佳方案就是直接将项目打包成.ipa包,供测试人员下载测试
  • 如果是外包公司,当开发完app时,想给客户展示,此时最佳方案也是打包测试
• 如何进行打包测试?
  • 限制人
  • 限制电脑/限制app/限制真机设备,根据这三个限制条件,重新生成打包测试的描述文件
  • 安装证书和描述文件
  • 打包成ipa包
  • 安装测试

2.证书生成/描述文件的配置/证书安装

• 限制人:
  • 必须拥有AppleID,并加入开发者计划,升级为开发者账号
• 限制电脑:
  • 重新配置一个打包测试证书(Ad Hoc)
  • 需要使用打包测试的电脑生成的csr文件(证书签名请求文件)
• 限制App:
  • 配置需要进行真机调试的BundleID(通过BundleID区分不同的app)
• 限制真机设备:
  • 配置需要真机调试的UDID(每台真机设备都有一个唯一标识)
• 根据限制条件,生成打包测试的描述文件
• 分别安装cer证书和对应的描述文件

3.测试

• 运行设备选择真机后,选择Product->Archive
• 证书失效导致的打包错误
  • Missing iOS Distibution signing identity for xxx
  • 系统的Apple World Wide Developer Relations Certificate Authority证书过期
  • 安装到钥匙串中的证书失效(原因:系统根证书/中级证书颁发机构过期)
  • 解决方案:重新下载证书,并安装

三.程序发布以及发布前Beta版本测试(TestFlight)

1.简介

• 程序发布:指将App发布到AppStore,供指定区域用户下载
• 目的:赚钱
• 程序发布的步骤:
  • 进行打包,和打包测试不同的是,在程序发布阶段,由于是发布到AppStore,所以不会对设备进行限制
  • 在开发者中心新建App,并添加App相关的信息
  • 运行设备选择真机后,选择Product->Archive
  • 选择submit打包项目,上传构建版本
  • 提交审核

2.在iTunes Connect上创建一个APP Record

• 填写app信息,以便在AppStore中显示app的预览图片,app版本以及功能简介等信息

3.上传构建版本

• BundleID:和发布证书配置时的设置保持一致
• 程序启动图标
• 启动图片
• 程序版本
  • Bundle versions string,short是正是的,跟iTunes上的版本号保持一致
  • 有固定格式要求,不能超过三段
  • Bundle Version可用作内部版本时使用,无格式要求
  • 当Bundle Version String缺省时,Bundle Version替代Bundle Version String的功能,同时也继承他的限制(比如格式,位数等),需与itunes上的版本号保持一致
• 设置签名证书

4.经验补充

• 证书失效导致的打包错误
• 常规审核周期:审核周期2天左右,节假日放假
• 苹果审核规则文档:如果不遵循这些规则,就不允许app上架
• 加急审核:联系苹果审核人员,跟他们说明理由,让他们优先给自己审核
• 加急审核注意事项:
  • 加急审核,审核更加严格
  • 首次发布,一般加急审核不给审批
  • 加急审核申请一定要理由足够强大(一般是上线后发现重大Bug)
  • 申请加急审核通过,那么只要app没有上架,就会一直处于加急审核的状态,直到上架为止,此次加急审核才算结束
  • 加急审核有次数限制(一年好像有3次机会)

5.额外补充(TestFlight/Beta版本测试)

• 概念
  • TestFlight最初是一个独立的测试分发平台,支持iOS和Android
  • 在2014年2月份被苹果收购,在iOS8中,苹果发布了TestFlight,并集成到iTunes Connect,用于将Beta测试流水平
• 作用
  • 对发布之前应用程序,做测试分发
• 与打包测试对比
  • 打包测试的步骤(弊端):
    • 测试者需要提供他们设备的UDID(如果测试者不知道怎么获取,或更加麻烦)
    • 测试者需要用软件读取他们设备的UDID(Xcode/iTools)
    • 测试者把设备标识码发送给开发者
    • 开发者把测试者的设备假如他们的账号中(并且有100次限制)
    • 开发者需要重新配置证书和描述文件
    • 开发者需要重新打包app
    • 开发者将应用程序发布给测试者
    • 测试者还要使用工具才能安装ipa包
  • TestFlight测试步骤:
    • 测试者提供他们的邮箱
    • 开发者登录iTunes Connect,给测试者发送邮件邀请
    • 测试者接受邀请,通过TestFlight软件下载安装程序
  • TestFlight的优势:
    • 不需要采集用户的UDID,只需要邮箱账号即可
    • 没有了最多100台的限制,内部测试25名,外部测试2000名
    • 不需要配置证书
    • 不需要手动分发ipa包
  • 打包测试更多的还是针对公司内部测试人员,TestFlight更多的是面向真正的用户
• 使用步骤
  • 在iTunes Connect上创建一个APP record
  • 在TestFlight中填写基本信息
  • 上传构建版本
    • 配置"发布证书"和"发布描述文件"
    • 在本地创建APP
    • 打包构建版本并上传
  • 设置需要构建的测试版本
    • 内部测试构建版本(不需要审核)
    • 外部测试构建版本(需要审核,但审核周期短)
  • 创建测试人员(iTunes Connect->我的App->用户和职能)
    • 创建内部测试人员(需要在iTunes Connect用户选项中添加)
    • 创建外部测试人员
  • 添加测试人员
  • 测试人员收到邮件
    • 按照提示下载TestFlight应用
    • 按照提示使用TestFlight应用下载测试App
  • 额外补充
    • 可以实现集成一些"应用内统计"的第三方SDK,例如友盟统计(行为统计/留存统计/界面统计/崩溃日志统计)
    • 这才是测试的主要目的

四.内购

1.简介

• 什么是内购
  • 在iOS中,专指苹果内购,就是在app内购买某件商品时,使用"苹果的支付方式"进行购买
  • 苹果规定:如果在app中销售的商品,跟app功能相关,那么,必须得通过内购方式购买
    • 比如:游戏中,开发关卡或者某个道具需要付费才能使用/QQ会员等
  • 内购的缺点:
    • 从商家角度来看:需要分成给苹果,分成比例过高,内购分成3:7
    • 从用户角度来看,内购支付,第一次需要绑定银行卡,操作流程相对来说比较复杂
    • 内购商品的价格,不能自定义,只有固定的级别
• 为什么做内购
  • 开发者创收的一种模式:free+内购
    • 直接收费:不符合国人的消费习惯
    • 广告:收取广告商的钱
    • 内购:free+内购,可以引发用户购买兴趣,提高用户付费概率,比如植物大战僵尸游戏
  • 某些业务必须使用内购
    • 如果销售的商品应该使用"苹果内购",而没有使用,app将不允许上架

2.内购的流程(类似于商场的购物流程)

1. 商户(App客户端)创建时,告诉商场(苹果服务器),自己都卖哪些东西(在App端展示所销售的商品)
2. 商户向总代理(公司服务器)发送请求进货
3. 商场(苹果服务器)验证商品是否可以销售
4. 客户(APP用户)在客户端购买商品,并开具小票(供以后恢复内购使用)
5. 客户拿着小票去商场交钱,到收银台需要排队(交易队列)
6. 交费后给用户回执,使用Transcation Observer监听交易的活动行为

3.内购演练

• 创建一个可以内购的BundleID(明确的AppID即可)
• 在app管理中心,创建一个app并填写app信息
• 创建内购商品,并添加到app,指定此app可以销售哪些商品
  • 注意事项:添加内购商品时,需要保证税务信息的完整,如果不完整,产品信息不全,内购功能无法测试
  • 内购产品的类型
    • 非消耗品(Nonconsumable)
      • 买了就一直有,不会消耗,例如开启关卡
      • 一般指的是在游戏中一次性购买并拥有永久访问权的物品或服务
      • 非消耗物品可以被用户再次下载,并且能够在用户的所有设备上使用
    • 消耗品(Consumable)
      • 买了就用,用了就没
      • 转为支持可消耗的物品或服务设计的,消耗品购买不可被再次下载
      • 消耗品不能再用户的设备之间跨设备使用,除非自定义服务在用户的账号之间共享这些信息
    • 其他类型
      • 免费订阅(Free subscriptions)
      • 自动续费订阅(Auto-renewing subscriptions)
      • 非自动续费订阅(Nonrenewing subscriptions)
      • 以上三种类别在iBooks中使用,目前iboos不支持大陆市场
• 创建app项目,开始开发
  • 配置BundleID为内购时配置的AppID
  • 导入框架StoreKit.framework
  • 从app服务器请求数据列表,冰箱苹果服务器请求可以销售的商品列表
  • 在代理方法中获取并显示可销售列表(productsRequest:didReceiveResponse)
  • 判断当前环境是否可以购买,用户购买商品,并监听商品的交易状态
    • 取出商品:SKProduct *product = self.products[indexPath.row];
    • 判断能否支付:[SKPaymentQueue canMakePayments];
    • 购买商品:SKPayMent *payMent = [SKPayment paymentWithProduct:product];
    • 把凭证加入到队列,等待用户付款:[[SKPaymentQueue defaultQueue] addPayment:payMent];
    • 设置监听者,监听整个交易状态:[[SKPaymentQueue defaultQueue] addTransactionObserver:self];
  • 实现监听交易状态方法
    • 交易状态发生变化时调用
    • paymentQueue:updatedTransactions
  • 恢复购买
    • SKPaymentQueue.defaultQueue().restoreCompletedTransactions()
• 开始测试,并添加用于测试内购的测试账号
  • 创建测试账号(测试账号必须是不存在的AppID)
    • 进入用户和职能
    • 创建沙箱技术测试人员
  • 注意事项
    • 测试时,最好使用真机进行测试,而且测试账号一定要使用添加的测试账号

4.查看内购销售情况

• 登录iTunes Connect(https://itunesconnect.apple.com/)
• 进入"销售和趋势"模块,查看内购的销售情况

五.广告

1.广告的作用

• 属于创收的一种方式,在APP内展示广告,苹果会付费给开发者,分成从原来的4:6到3:7

2.如何展示广告

• 导入框架:iAd.framework
• 添加控件:ADBannerView
• 实现代理:ADBannerViewDelegate,优化用户体验

3.注意

• 加载的广告内容是自动从苹果服务器获取,不需要开发者自己编写代码实现
• 广告的内容,一般根据app分类进行推送

4.苹果广告平台地址

• https://iadworkbench.apple.com

六.如何在必须使用内购的商品中,绕过苹果审核,使用第三方支付方式?

• 直接不接入内购,在审核时隐藏相应的购买模块.至于根据什么条件去隐藏,有如下方法:
  • 后台提供接口,判断是否在审核状态.这样会有一个问题,就是审核状态中,如果使用同一接口,之前上架的版本也会隐藏购买模块,需要为每个版本提供一个单独的接口,故不采纳.
  • 请求接口之前,可以先判断时间,如果时间在某个区间内,就进行请求操作,否则就认为是在非审核状态.
  • 接入内购,同样需要一个接口,在审核时使用内购付款,通过后使用其他方式付款.
  • 比较当前提交的版本号和AppStore中应用的版本号,如果新版本号>=旧版本号,肯定是审核状态,如果新版本号==旧版本号,就是通过审核的状态.