Jerry Lee

苹果内购

Mon, 01 Nov 2021 00:00:00 +0000

最近面试过程中，被面试官多次问到苹果内购相关的实现及遇到的问题，这里梳理以下，做个总结吧。

内购关键流程

1、客户端发起支付

2、客户端监听购买流程

3、苹果回调订单购买成功时，客户端把苹果给的receipt_data和一些订单信息上报给服务器

4、服务器拿到receipt_data向苹果服务器校验

5、苹果服务器返回status为0则表示发回成功

其他返回值也记录总结一下

21000 :App Store无法读取你提供的JSON数据

21002 :收据数据不符合格式

21003 :收据无法被验证

21004 :你提供的共享密钥和账户的共享密钥不一致

21005 :收据服务器当前不可用

21006 :收据是有效的，但订阅服务已经过期。当收到这个信息时，解码后的收据信息也包含在返回内容中

21007 :收据信息是测试用（sandbox），但却被发送到产品环境中验证

21008 :收据信息是产品环境中使用，但却被发送到测试环境中验证

6、服务器监发现订单校验成功之后，把该笔订单存起来，保存到数据库，可以防止同一笔订单多次发放商品

遇到的问题

1、丢单

2、双重验证

3、多次发放商品

解决方案

丢单问题大多分两种： 1、没有拿到凭证，支付成功，由于网络原因或各种原因没有返回transaction;

可以去查询苹果默认的[SKPaymentQueue defaultQueue]队列里面查询订单状态

2、支付成功后，拿到receipt凭证，上传服务器由于网络原因丢失

可以在支付之前让服务器创建订单，并把交易成功之后的交易凭证和订单保持数据库，用户下次登录之后验证

做双重验证的目的：

我们平时测试以及苹果审核的时候都要用沙盒账号测试，如何识别App端发过来的收据是沙盒测试还是正式环境用户的购买呢？这里可以用两种方案，即双重验证。

先把收据拿到正式环境的验证地址去验证，如果苹果的正式环境验证服务器返回的状态码 status 为 21007，说明当前收据是沙盒环境下产生，则再连接一次沙盒环境服务器进行验证，这样不管是我们自己采用沙盒账号测试还是苹果审核人员采用沙盒账号进行审核、或者用户购买都可以保证收据正常的验证成功。

判重方案解决多次发放商品：收到客户端上报的 transaction_id 后，直接MD5后去数据库查，能查到说明是重复订单，返回相应错误码给客户端，如果查不到，去苹果那边校验。服务器拿到苹果的校验结果之后，判断订单状态是不是成功，如果成功再发放内购商品。

设计模式生成器模式

Sat, 15 Dec 2018 00:00:00 +0000

定义

也叫创建者模式，它将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示

举例

生成器模式将复杂的创建逻辑进行分割，例如生产汽车，分步骤创建安装不同的零件。如果创建逻辑简单则没有拆分的必要。

优点

1、客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象；

2、每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象；

3、增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭原则”；

4、可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程

缺点

1、建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制；

2、如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

##代码举例##

@interface Builder : NSObject
+ (void)buildEngine;
+ (void)buildWheel;
+ (void)buildBody;
@end

设计模式单例模式

Mon, 10 Dec 2018 00:00:00 +0000

定义

单例模式确保某一个类只有一个实例，并提供一个访问它的全局访问点。

举例

单例模式下，对应类只能生成一个实例。就像一个王国只能有一个国王，一旦王国里的事物多起来，这唯一的国王也容易职责过重。

优点

1、提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它；

2、因为该类在系统内存中只存在一个对象，所以可以节约系统资源。

缺点

1、由于单例模式中没有抽象层，因此单例类很难进行扩展；

2、对于有垃圾回收系统的语言Java，C#来说，如果对象长时间不被利用，则可能会被回收。那么如果这个单例持有一些数据的话，在回收后重新实例化时就不复存在了。

##代码举例##

@implementation Singleton
+(instancetype)shareInstance{
static Singleton *shareInstance = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
    shareInstance = [[Singleton alloc]init];
});
return shareInstance;
}
@end

设计模式抽象工厂模式

Wed, 05 Dec 2018 00:00:00 +0000

定义

提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类，抽象工厂和工厂方法不同的地方在于，生产产品的工厂是抽象的。

抽象工厂模式和工厂方法模式很相似，但是抽象工厂模式将抽象发挥的更加极致，是三种工厂模式中最抽象的一种设计模式。抽象工厂模式，也叫做Kit模式，提供了创建一系列相关抽象子类的接口，而无需指定它们具体的类型。

抽象工厂模式中定义了抽象工厂类，抽象工厂类中定义了每个系列的抽象子类创建所需的方法，这些方法对应着不同类型的抽象子类实例化过程。每个工厂子类都对应着一个系列，工厂子类通过重写这些方法来实例化当前系列的抽象子类。

抽象工厂模式包含四部分：

抽象工厂类：定义创建抽象子类的具体行为，根据系列中不同类型的抽象子类可能会有多种行为。

工厂子类：继承自抽象工厂类，根据当前抽象子类对应的系列，重写父类定义的对应行为。对应的抽象子类系列不同，行为的实现方式也不同。

抽象类：定义当前类型抽象子类的操作，子类继承父类完成具体的操作。在抽象工厂模式中，可能会有多种抽象类的定义。

抽象子类：根据当前类型继承自对应的抽象类，并根据系列的不同重写抽象类定义的实现。

和工厂方法模式有什么不同

在工厂方法模式中，工厂子类负责抽象子类的实例化，每个工厂子类对应着一个抽象子类，且具有唯一性。而在抽象工厂模式中，一个工厂子类代表一个系列，工厂子类根据当前系列对不同类型的抽象子类进行创建。工厂方法模式中工厂子类对应的是一个类型的抽象子类，抽象工厂模式对应的是一个系列的抽象子类。工厂方法模式一个工厂子类对应一个抽象子类的设计，会有很大的浪费，产生了过多的类。而抽象工厂模式更好的利用了工厂子类，使每个工厂子类对应着一个系列的抽象子类，这种设计非常适用于两个具有相同结构关系，但是分属于不同系列的系列之间的切换。总之就是，工厂方法模式是针对单个类型的抽象类，而抽象工厂模式是针对具有相同结构的一系列类型的抽象类。

举例

可口可乐公司生产可乐的同时，也需要生产装可乐的瓶子和箱子，瓶子和箱子也是可口可乐专属定制的，同样百事可乐公司也会有这个需求。这个时候我们的工厂不仅仅生产可乐饮料的工厂，还必须同时生产同一主题的瓶子和箱子，所以它是一个抽象的主题工厂，专门生产同一主题的不同商品。

优点

1.具体产品在应用层代码隔离，不需要关心产品细节。只需要知道自己需要的产品是属于哪个工厂的即可；

2.当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是一种非常常用的设计模式。

缺点

规定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口；

##代码举例##

@implementation CocaColaFactory
+(Cola *)createCola{
return [CocaCola new];
}

+(CocaColaBottle*)createBottle{
return [CocaColaBottle new];
}

+(CocaColaBox*)createBox{
return [CocaColaBox new];
}

@implementation PesiColaFactory
+(Cola *)createCola{
return [PesiCola new];
}

+(PesiColaBottle*)createBottle{
return [PesiColaBottle new];
}

+(PesiColaBox*)createBox{
return [PesiColaBox new];
}

设计模式工厂方法模式

Wed, 21 Nov 2018 00:00:00 +0000

定义

又称为工厂模式，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，即通过不同的工厂子类来创建不同的产品对象；

工厂方法模式和简单工厂模式十分类似，大致结构是基本类似的。不同在于工厂方法模式对工厂类进行了进一步的抽象，将之前的一个工厂类抽象成了抽象工厂和工厂子类，抽象工厂定义一个创建抽象子类的接口，抽象工厂的子类实现这些接口并决定实例化哪个抽象子类。工厂子类决定着创建哪个抽象子类，外界决定着创建哪种工厂子类，抽象子类和工厂子类是一一对应的。

在工厂方法模式中，和简单工厂模式一样，对外隐藏了抽象子类的创建过程，外界只需要关心工厂类即可，负责实例化的工厂子类决定着最后的结果。

工厂方法模式主要包含四部分：

工厂抽象类：定义创建抽象子类的接口，通过接口返回具体的抽象子类。

工厂子类：继承自工厂抽象类，并重写父类的方法来创建对应的抽象子类。

抽象类：定义抽象子类所需的属性和方法，子类通过继承自抽象类获得这些方法。

抽象子类：继承自抽象类，实现具体的操作。

为什么要用工厂方法模式？

在简单工厂模式的代码中，如果我们没有使用反射机制，只是标准的简单工厂模式代码。会有一个问题，就是如果新增加其他运算功能，需要创建一个抽象子类，但是还需要修改工厂类中的代码逻辑，这种设计是不符合开放封闭原则的。开放封闭原则对于修改是关闭的，对于扩展是开放的。而且将所有的操作子类的判断和实例化都由一个工厂类完成，如果业务比较复杂会导致工厂类负担较重。

工厂方法模式将之前负责生成具体抽象子类的工厂类，抽象为工厂抽象类和工厂子类组成的一系列类。每创建一个抽象子类，就需要创建一个工厂子类，并且一一对应，由工厂子类去生成对应的抽象子类，由外界使用方来决定生成哪个工厂子类。这样在增加新的需求时，就不需要对工厂抽象类进行修改，而是对应新增的抽象子类创建对应的工厂子类即可。

举例

工厂方法和简单工厂有一些区别，简单工厂是由一个代工厂生产不同的产品，而工厂方法是对工厂进行抽象化，不同产品都由专门的具体工厂来生产。可口可乐工厂专门生产可口可乐，百事可乐工厂专门生产百事可乐。

优点

1.用户只需要关心其所需产品对应的具体工厂是哪一个即可，不需要关心产品的创建细节，也不需要知道具体产品类的类名；

2.当系统中加入新产品时，不需要修改抽象工厂和抽象产品提供的接口，也无需修改客户端和其他的具体工厂和具体产品，而只要添加一个具体工厂和与其对应的具体产品就可以了，符合了开闭原则；

缺点

当系统中加入新产品时，除了需要提供新的产品类之外，还要提供与其对应的具体工厂类。因此系统中类的个数将成对增加，增加了系统的复杂度；

代码举例

+(Cola*)createCola{
return [Cola new];
}

+(Box*)createBox{
return [Box new];
}

+(Bottle *)createBottle{
return [Bottle new];
}

Cola *pesiCola = [PesiColaFactory createCola];
Cola *cocaCola = [CocaColaFactory createCola];

设计模式简单工厂模式

Tue, 20 Nov 2018 00:00:00 +0000

定义

专门定义类(工厂类)来负责创建其他类的实例。可以根据创建方法的参数来返回不同类的实例，被创建的实例通常都具有共同的父类。

简单工厂模式中定义一个抽象类，抽象类中声明公共的特征及属性，抽象子类继承自抽象类，去实现具体的操作。工厂类根据外界需求，在工厂类中创建对应的抽象子类实例并传给外界，而对象的创建是由外界决定的。外界只需要知道抽象子类对应的参数即可，而不需要知道抽象子类的创建过程，在外界使用时甚至不用引入抽象子类。

简单工厂模式将抽象子类的创建，和关于抽象子类相关的业务逻辑分离，降低对象间的耦合度。由于工厂类只是为外界创建对象，所以并不需要实例化工厂类对象，只需要为外界提供类方法即可。外界需要什么类型的抽象子类，只需要传递对应的参数即可。外界不需要知道具体的抽象子类，只需要使用抽象类即可。

简单工厂模式主要包含三部分：

工厂类：根据外界的需求，决定创建并返回哪个具体的抽象子类。

抽象类：定义抽象子类所需的属性和方法，子类通过继承自抽象类获得这些方法。

抽象子类：继承自抽象类，是具体操作的实现者，根据需求重写父类继承过来的方法。

业务场景

简单工厂模式主要适用于抽象子类的业务逻辑相同，但具体实现不同的情况。不同的操作子类执行同样的方法，最后的结果却是不同的，这也是多态的一种表现方式。

优点

1.使用者只需要给工厂类传入一个正确的约定好的参数，就可以获取你所需要的对象，而不需要知道其创建细节，一定程度上减少系统的耦合；

2.客户端无需知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，减少开发者的记忆成本；

缺点

1.如果业务上添加新产品的话，就需要修改工厂类原有的判断逻辑，这其实是违背了开闭原则的；

2.在产品类型较多时，有可能造成工厂逻辑过于复杂。所以简单工厂模式比较适合产品种类比较少而且增多的概率很低的情况；

代码举例

+(Cola *)createColaWithType:(NSInteger)type{
switch (type) {
    case 0:
        return [CocaCola new];
        break; 
    case 1:
        return [PesiCola new];
        break;
    default:
        return nil;
        break;
} }

Cola *cocaCola = [SimpleFactory createColaWithType:0];
Cola *pesiCola = [SimpleFactory createColaWithType:1];

深入理解runloop

Sat, 10 Nov 2018 00:00:00 +0000

RunLoop简介

运行循环，在程序运行过程中循环做一些事情，如果没有Runloop程序执行完毕就会立即退出，如果有Runloop程序就会一直运行，并且时时刻刻在等待用户的输入操作。
RunLoop可以在需要的时候自己跑起来运行，在没有操作的试试就停下来休息。充分节省CPU资源，提高程序性能。

RunLoop基本作用

1.保持程序持续运行程序一启动就会开一个主线程，主线程一开起来就会跑一个主线程对应的RunLoop,RunLoop保证主线程不会被销毁，也就保证了程序的持续运行;

2.处理App中的各种事件比如定时器事件，触摸事件，Selector事件;

3.节省CPU资源，提高程序性能程序运行起来时，当什么操作都没有做的时候，Runloop就会告诉CPU，现在没有事情做，我要去休息，这时CPU就会将其资源释放出来去做其他的事情，当有事情做的时候Runloop就会立马起来去做事情。

RunLoop内部运行原理：

RunLoop和线程之间的关系

1.每条线程都有唯一的一个与之对应的RunLoop对象;

2.RunLoop保存在一个全局的Dictionary里，线程作为key,RunLoop作为value;

3.主线程的RunLoop已经自动创建好了，子线程的RunLoop需要主动创建;

4.RunLoop在第一次获取时创建，在线程结束时销毁。

RunLoop启动流程

UIApplicationMain函数内启动了RunLoop,程序不会马上退出，二是保持运行状态。因此每一个应用必须要有一个RunLoop,我们值得主线程一开起来，就会跑一个和主线程对应的RunLoop，那么RunLoop一定在程序的入口main函数中开启。

我们看一下UIApplicationMain的API

Kvo的本质

Tue, 07 Aug 2018 00:00:00 +0000

KVO的全称是Key -Value Observing,即“键值监听”，可用于监听某个对象属性值的改变

代码实现

结果输出

可以看到我们只监听了person1属性值改变，所以只输出person1的改变。那问题来了，我们给person1,person2都改变了age属性的值，本质都是调用了LGPerson类中setAge这个方法，那么为什么person1会走到oberveValueForKeyPath这个方法，person2不会呢？ KVO底层实现分析 ——— 我们断点打印一下person1和person2的isa，看一下他们实例对象isa指向的类对象是什么？

person1的isa指针打印出的是NSKVONotifying_LGPerson，person2的isa指针打印出的是LGPerson 如果不监听person1的属性，我们看一下person1的isa指针

person1和person2都是实例对象，所以person1和person2的isa指针指向的都是类对象。通过对比我们发现两者isa指针指向的对象发生了变化，现在我们再做深一步的研究，添加监听之后两者调用的setAge方法有没有变化呢

果然和我们猜想的一样，监听之后调用方法变成了_NSSetIntValueAndNotify 如果定义的属性是类型是double，则调用的是_NSSetDoubleValueAndNotify(),那么我们可以推测Foundation框架中有许多此类型的函数比如_NSSetBoolValueAndNotify，_NSSetCharValueAndNotify，_NSSetFloatValueAndNotify，通过属性的不同类型调用不同的函数。

NSKVONotifying_LGPerson内部结构解析

打印结果：通过上述代码我们发现NSKVONotifying_LGPerson中有4个对象方法。分别为setAge: class dealloc _isKVOA

验证didChangeValueForKey:内部会调用observer的observeValueForKeyPath:ofObject:change:context:方法

打印结果：通过打印内容可以看到，确实在didChangeValueForKey方法内部已经调用了observer的observeValueForKeyPath:ofObject:change:context:方法。

多线程gcd(一)

Thu, 02 Aug 2018 00:00:00 +0000

(一)各种队列的执行效果

1.常见的多线程方案 2.同步和异步的主要影响:能不能开启新的线程同步:在当前的线程中执行任务，不具备开启新线程的能力异步:在新的线程中开启任务，具备开启新线程的能力

3.并发和串行的主要影响:任务的执行方式并发:多个任务并发(同时)执行串行:一个任务执行完毕之后，再执行下个任务队列的类型包括: 并发队列，串行队列，主队列(也是一个串行队列) 决定了任务的执行方式(并发，串行)

(二)常见的死锁案例

使用sync函数往当前串行队列中添加任务，会卡住当前的串行队列(产生死锁)

1.产生死锁

NSLog(@"任务1");

dispatch_queue_t mainQueue = dispatch_get_main_queue();
dispatch_sync(mainQueue, ^{
    NSLog(@"任务2");
});
NSLog(@"任务3");

2.不会产生死锁

NSLog(@"任务1");

dispatch_queue_t mainQueue = dispatch_get_main_queue();
dispatch_async(mainQueue, ^{
    NSLog(@"任务2");
});
NSLog(@"任务3");

3.产生死锁(sync并且是串行队列粗体文本)

    NSLog(@"任务1");
dispatch_queue_t queue = dispatch_queue_create("myqueu", DISPATCH_QUEUE_SERIAL);
dispatch_async(queue, ^{
    NSLog(@"任务2");

    dispatch_sync(queue, ^{
        NSLog(@"任务3");

    });
    NSLog(@"任务4");

});
NSLog(@"任务5");

4.不会产生死锁(不是同一个队列)

  NSLog(@"任务1");
dispatch_queue_t queue = dispatch_queue_create("myqueue", DISPATCH_QUEUE_SERIAL);
dispatch_queue_t queue2 = dispatch_queue_create("myqueue2", DISPATCH_QUEUE_SERIAL);
dispatch_async(queue, ^{
    NSLog(@"任务2");
    dispatch_sync(queue2, ^{
        NSLog(@"任务3");

    });
    NSLog(@"任务4");
});
NSLog(@"任务5");

5.不产生死锁(并发队列)

 NSLog(@"任务1");
dispatch_queue_t queue = dispatch_queue_create("myqueu", DISPATCH_QUEUE_CONCURRENT);
dispatch_async(queue, ^{
    NSLog(@"任务2");
    dispatch_sync(queue, ^{
        NSLog(@"任务3");
    });
    NSLog(@"任务4");
});
NSLog(@"任务5");

Cocoapods创建私有库(二)

Sat, 02 Jun 2018 00:00:00 +0000

接着上篇文章，用Cocoapods创建私有库,完成了我们自己的私有库制作，在接下来的开发工作中，可能会根据需求去更新我们的私有库，本篇文章分享下更新私有库的经历。

一.更新

具体做法是将要添加的源文件放到Pod/Classes中，然后编辑.podspec文件。

编程完成后，本地验证下

本地验证通过之后，就可以推送到远端了。这里面有个坑，就是要push tag,由于我漏了这一步，出现了一下问题。

可以尝试如下代码

git tag -m “update tag” 1.0.1

git push –tags

然后再重新执行pod repo push ** **.podspec –allow-warnings

二.查看

上面的更新操作完成之后，就可以在~/.cocoapods/repos目录下查看

执行pod search 查看

如果想要删除一个私有Spec Repo，只需要执行一条命令即可

pod repo remove **

当然我们还可以通过一下命令添加回来。

pod repo add ** git@coding.net:** / **.git

Jerry Lee

苹果内购

内购关键流程

遇到的问题

解决方案

设计模式 生成器模式

定义

举例

优点

缺点

设计模式 单例模式

定义

举例

优点

缺点

设计模式 抽象工厂模式

定义

和工厂方法模式有什么不同

举例

优点

缺点

设计模式 工厂方法模式

定义

举例

优点

缺点

代码举例

设计模式 简单工厂模式

定义

业务场景

优点

缺点

代码举例

深入理解runloop

RunLoop简介

RunLoop基本作用

RunLoop和线程之间的关系

RunLoop启动流程

Kvo的本质

代码实现

NSKVONotifying_LGPerson内部结构解析

多线程gcd(一)

(一)各种队列的执行效果

(二)常见的死锁案例

Cocoapods创建私有库(二)

一.更新

二.查看

设计模式生成器模式

设计模式单例模式

设计模式抽象工厂模式

设计模式工厂方法模式

设计模式简单工厂模式