Telegram连接MTProxy时一直connecting问题

 linux  Telegram连接MTProxy时一直connecting问题已关闭评论
12月 272019
 

我们一般使用Telegram的时候,都需要先爬Qiang,这样还是比较麻烦的,而在Telegram最新版本中内置了MTProxy代理,占用小,耗电量也小,只需要我们简单设置下,就可以让Telegram和本地应用一样,即开即用,而不需要额外的爬Qiang了。

什么是Telegram MTProxy

Telegram MTProxy是Telegram官方出的一个轻量级的代理工具,可以直接配置在Telegram客户端中,不需要开启其他代理就可以直连Telegram。官方地址:Telegram MTProxy

Telegram MTProxy安装

MTProxy具体搭建过程见:https://github.com/TelegramMessenger/MTProxy

如果觉得麻烦也可以使用一键安装方式:https://github.com/FunctionClub/MTProxy-Bash

 

MTProxy 一直Connecting问题排查

情况说明:

  • Google Cloud Platform (GCP) 安装了MTProxy并正常启动(<secret>、proxy-secret、proxy-multi.conf为上面安装步骤中产生的对应文件或字符)。
./mtproto-proxy -u nobody -p 8888 -H 8443 -S <secret> --aes-pwd proxy-secret proxy-multi.conf -M 1
  • gcp上打开了8443入口的访问

 

但启动telegram客户端使用mtproxy代理时输入ip、host和secret后,始终在connecting状态,在gcp上可以看到对应端口的连接都有,但就是连接不上。

  1. 网上一种说法是:因为gcp时间与运行telegram客户端机器时间不同步,可在gcp上安装个ntp服务同步时间解决,但不适用与我这边的情况。
  2. 我这里通过下面步骤解决:使用阿里云服务器或者AWS服务器或GCP搭建Telegram MTProxy时,发现这个MTProxy绑定的是内网IP,解决方案也很简单,使用NAT模式就行,指定内网IP和外网IP, 启动命令行里需要加入  –nat-info <intranet ip>:<public ip>, 上面的启动命令变为:

./mtproto-proxy -u nobody -p 8888 -H 8443 -S <secret> –nat-info <intranet ip内网ip>:<public ip外网ip> –aes-pwd proxy-secret proxy-multi.conf -M 1

UIViewContentMode 中ScaleToFill、AspectFit、AspectFill等区别

 swift  UIViewContentMode 中ScaleToFill、AspectFit、AspectFill等区别已关闭评论
12月 262019
 

UIViewContentMode/ content Mode 中ScaleToFill、AspectFit、AspectFill有什么区别,见下面两张图就一目了然了:

awk中字符串与数字间连接操作、字符串与数字互相转换

 awk  awk中字符串与数字间连接操作、字符串与数字互相转换已关闭评论
12月 252019
 

awk使用中经常会有这样的需求, 字符串怎么与数字拼接连成一个新字符串?

1.字符串转数字(字符串+数字,字符串与数字拼接)

o-u-u$ awk ‘BEGIN{a=”90″; b = “10aaa10”; print (a+b+0)}’
100

o-u-u$ awk ‘BEGIN{a=90; b = “10aaa10”; print (a+b)}’
100

以上实例可以看到当字符串与数字进行拼接时,字符串中非数字部分及后面部分都被忽略了

 

2.数字转字符串(数字+数字,数字间拼接)

o-u-u$ awk ‘BEGIN{a=90; b=10; print (a””b)}’
9010

以上实例可以看到只要使用””连接即可。

 

3.字符串间拼接
o-u-u$ awk ‘BEGIN{a=”90″; b=”10″; print (a”–“b)}’
90–10

以上实例可见只要使用””符号即可, “”中间可以使用自己定义的拼接字符串,如上面使用了”–”

swift 下 init()与init?()区别

 swift  swift 下 init()与init?()区别已关闭评论
12月 252019
 

swift 的类代码里,init()是正常初始化类,但如果初始数据不满足要求,或需要返回nil时,怎么处理呢? init?()就是派这个用场地!

引用https://www.hackingwithswift.com/example-code/language/whats-the-difference-between-init-and-init的内容,下面说的很详细,也有例子举例,大家一看就明白:

It’s the job of a regular Swift initializer to create a fully fledged instance of a new type, however sometimes the data that has been provided is insufficient or incorrect, and creation can’t proceed.

For example, consider this code:

struct Person {
    var ssn: String

    init(socialSecurityNumber: String) {
        self.ssn = socialSecurityNumber
    }
}

let person = Person(socialSecurityNumber: "111-11-1111")
print(person)

That defines a Person struct that can be created using a nine-digit social security number, then creates an instance of that struct.

But what should happen here?

let person = Person(socialSecurityNumber: "FISH")

In that instance we’re passing an invalid social security number, so really we expect creating a Person to fail.

This is where failable initializers come in: they are written as init?(), and can return nil rather than a value if something goes wrong during creation. For example, we could write a quick check to make sure the social security number is more or less correct like this:

struct Person {
    var ssn: String

    init?(socialSecurityNumber: String) {
        if socialSecurityNumber.count < 11 {
            return nil
        } else {
            self.ssn = socialSecurityNumber
        }
    }
}

Notice the initializer is now called init?() to reflect that it returns an optional – the process might return nil if the creation fails. The logic is pretty simple: if there are 11 digits we assume it’s correct, otherwise we return nil. Note: if you really wanted to validate that number you’d need to use a regular expression.

XCODE中不同添加方式下获取文件/图片的路径的方法(Bundle.main.path,Bundle)

 swift, xcode  XCODE中不同添加方式下获取文件/图片的路径的方法(Bundle.main.path,Bundle)已关闭评论
12月 202019
 

XCODE中获取添加的文件的路径的3个方法,以下以显示图片测试获取图片路径的方法:

 

测试的UIViewController的demo源码(TestImageViewController.swift),注释中详细描述3个不同添加文件方式下获取路径的方法,GOOD LUCK!

 

import AVFoundation

 

class TestImageViewController: UIViewController {

    

    lazy var imageView: UIImageView = {

       

        let imageView = UIImageView(frame: CGRect(x: 0, y: 0, width: UIScreen.main.bounds.width, height: UIScreen.main.bounds.height))

        //方法1:  选择Targets中项目 –> build Phases中 –> copy Bundle Resources点击下面的+ 直接添加的alalay.jpg

        //let testImage = UIImage(contentsOfFile: Bundle.main.path(forResource: “alalay”, ofType: “jpg”)!)

        

        //方法2:  新建目录任意命名如imgs,将测试图片alalay.jpg文件拖入imgs目录后,将imgs目录名称修改为imgs.bundle,将这个imgs.bundle拖入xcode项目

        //let testImage = UIImage(contentsOfFile: Bundle.main.path(forResource: “imgs”, ofType: “bundle”)! + “/” + “alalay.jpg”)

        

        //方法3:   将alalay.jpg图片放在Assets.xcassets中

        let testImage = UIImage(named:“alalay.jpg”)!

        

        imageView.image = testImage

        imageView.contentMode = .scaleAspectFit

        return imageView

    }()

    

    override func viewDidLoad() {

        super.viewDidLoad()

        view.addSubview(imageView)

    }

}

GPUImage2(GPUImage swift版本) 使用pod安装

 swift  GPUImage2(GPUImage swift版本) 使用pod安装已关闭评论
12月 192019
 

GPUImage2常见的安装方法是project导入和静态库方法,实在太麻烦了,在GPUImage2 github的issue中有人提供了一个pod安装方法(详见:https://github.com/BradLarson/GPUImage2/issues/1):

 

在Podfile文件所在的同级目录下新建一个podspec文件,如:GPUImage2.podspec, 并且输入下面内容:

Pod::Spec.new do |s|
s.name = ‘GPUImage2’
s.version = ‘0.1.0’
s.license = ‘BSD’
s.summary = ‘An open source iOS framework for GPU-based image and video processing.’
s.homepage = ‘https://github.com/BradLarson/GPUImage2’
s.author = { ‘Brad Larson’ => ‘[email protected]’ }

# This commit on that fork of GPUImage should contain just upgrades needed for Swift 4 compatibility. See https://github.com/BradLarson/GPUImage2/pull/212
# Replace with https://github.com/BradLarson/GPUImage2.git when merged
# into BradLarson’s repository.
s.source = { :git => ‘https://github.com/andrewcampoli/GPUImage2’, :commit => ‘148c84e6b4194daeba122e77449f5ee9c8188161’ }

s.source_files = ‘framework/Source/**/*.{swift}’
s.resources = ‘framework/Source/Operations/Shaders/*.{fsh}’
s.requires_arc = true
s.xcconfig = { ‘CLANG_MODULES_AUTOLINK’ => ‘YES’, ‘OTHER_SWIFT_FLAGS’ => “$(inherited) -DGLES”}

s.ios.deployment_target = ‘8.0’
s.ios.exclude_files = ‘framework/Source/Mac’, ‘framework/Source/Linux’, ‘framework/Source/Operations/Shaders/ConvertedShaders_GL.swift’
s.frameworks = [‘OpenGLES’, ‘CoreMedia’, ‘QuartzCore’, ‘AVFoundation’]

end

 

并且在Podfile中加入:
pod ‘GPUImage2’, :podspec => ‘./GPUImage2.podspec’

 

然后pod install 即可

supervisord管理python进程时print(stdout)日志输出不及时,甚至有缺失问题解决

 python, supervisord  supervisord管理python进程时print(stdout)日志输出不及时,甚至有缺失问题解决已关闭评论
12月 192019
 

使用supervisord管理python进程,代码中print()打印的日志在使用tail -f查看时输出总是不及时,甚至有缺失问题,网络上有下面的几种方式解决:

If you are also using Supervisor to monitor and heal your long running Python projects and observed that output of your program is not being logged to stdout_logfile, it is because Python print statement does not automatically flush output to STDOUT.

One solution is using sys.stdout.flush() frequently to flush the output or if you are using Python 3.3, print(msg, flush=True) is another solution. However, a better solution is to run python with -u parameter (unbuffered mode).

以上总结方法:

  1. 频繁使用sys.stdout.flush()
  2. python3.3以后版本,print使用print(msg, flush=True)
  3. supervisord配置文件里command命令行添加-u参数(这个是最推荐的方法)

举例:

[program:analysis]
command = python -u AnalysisTest.py -port=70%(process_num)02d

S3fs在Amazon EC2 Linux实例上挂载S3存储桶后,使用ls出现“cannot open directory alert/: Operation not permitted”解决办法

 aws  S3fs在Amazon EC2 Linux实例上挂载S3存储桶后,使用ls出现“cannot open directory alert/: Operation not permitted”解决办法已关闭评论
12月 182019
 

利用S3fs在Amazon EC2 Linux实例上挂载S3存储桶请见下面文章
https://aws.amazon.com/cn/blogs/china/s3fs-amazon-ec2-linux/

 

在挂载了s3存储桶后,使用ls命令列出存储桶目录时,出现“cannot open directory alert/: Operation not permitted”,可以使用下面的方式解决:

在进行挂载时,添加当前用户的uid,gid及umask参数(关于当前用户的uid及gid查看可以使用id命令):
-o uid=1000 -o gid=1000 -o umask=0077

objective-c中categories和extentions简介

 objective-c  objective-c中categories和extentions简介已关闭评论
12月 132019
 

网上很多关于objective-c中categories和extentions的介绍都很含糊,但下面这篇文章自己觉得写的很好,虽然内容有些老了,但不影响你理解categories和extentions,来自:https://code.tutsplus.com/tutorials/objective-c-succinctly-categories-and-extensions–mobile-22016

Categories are an Objective-C language feature that let you add new methods to an existing class, much like C# extensions. However, do not confuse C# extensions with Objective-C extensions. Objective-C’s extensions are a special case of categories that let you define methods that must be declared in the main implementation block.

These are powerful features that have many potential uses. First, categories make it possible to split up a class’ interface and implementation into several files, which provides much-needed modularity for larger projects. Second, categories let you fix bugs in an existing class (e.g., NSString) without the need to subclass it. Third, they provide an effective alternative to the protected and private methods found in C# and other Simula-like languages.

category is a group of related methods for a class, and all of the methods defined in a category are available through the class as if they were defined in the main interface file. As an example, take the Person class that we’ve been working with throughout this book. If this were a large project, Person may have dozens of methods ranging from basic behaviors to interactions with other people to identity checking. The API might call for all of these methods to be available through a single class, but it’s much easier for developers to maintain if each group is stored in a separate file. In addition, categories eliminate the need to recompile the entire class every time you change a single method, which can be a time-saver for very large projects.

Let’s take a look at how categories can be used to achieve this. We start with a normal class interface and a corresponding implementation:

// Person.h
@interface Person : NSObject
@interface Person : NSObject
@property (readonly) NSMutableArray* friends;
@property (copy) NSString* name;
- (void)sayHello;
- (void)sayGoodbye;
@end
// Person.m
#import "Person.h"
@implementation Person
@synthesize name = _name;
@synthesize friends = _friends;
-(id)init{
    self = [super init];
    if(self){
        _friends = [[NSMutableArray alloc] init];
    }
    return self;
}
- (void)sayHello {
    NSLog(@"Hello, says %@.", _name);
}
- (void)sayGoodbye {
    NSLog(@"Goodbye, says %@.", _name);
}
@end

Nothing new here-just a Person class with two properties (the friends property will be used by our category) and two methods. Next, we’ll use a category to store some methods for interacting with other Person instances. Create a new file, but instead of a class, use the Objective-C Category template. Use Relations for the category name and Person for the Category on field:

Figure 28 Creating the PersonRelations class
Creating the Person+Relations class

As expected, this will create two files: a header to hold the interface and an implementation. However, these will both look slightly different than what we’ve been working with. First, let’s take a look at the interface:

// Person+Relations.h
#import <Foundation/Foundation.h>
#import "Person.h"
@interface Person (Relations)
- (void)addFriend:(Person *)aFriend;
- (void)removeFriend:(Person *)aFriend;
- (void)sayHelloToFriends;
@end

Instead of the normal @interface declaration, we include the category name in parentheses after the class name we’re extending. A category name can be anything, as long as it doesn’t conflict with other categories for the same class. A category’s file name should be the class name followed by a plus sign, followed by the name of the category (e.g., Person+Relations.h ).

So, this defines our category’s interface. Any methods we add in here will be added to the original Person class at run time. It will appear as though the addFriend:removeFriend:, and sayHelloToFriends methods are all defined in Person.h, but we can keep our functionality encapsulated and maintainable. Also note that you must import the header for the original class, Person.h. The category implementation follows a similar pattern:

// Person+Relations.m
#import "Person+Relations.h"
@implementation Person (Relations)
- (void)addFriend:(Person *)aFriend {
    [[self friends] addObject:aFriend];
}
- (void)removeFriend:(Person *)aFriend {
    [[self friends] removeObject:aFriend];
}
- (void)sayHelloToFriends {
    for (Person *friend in [self friends]) {
        NSLog(@"Hello there, %@!", [friend name]);
    }
}
@end

This implements all of the methods in Person+Relations.h. Just like the category’s interface, the category name appears in parentheses after the class name. The category name in the implementation should match the one in the interface.

Also, note that there is no way to define additional properties or instance variables in a category. Categories have to refer back to data stored in the main class (friends in this instance).

It’s also possible to override the implementation contained in Person.m by simply redefining the method in Person+Relations.m. This can be used to monkey patch an existing class; however, it’s not recommended if you have an alternative solution to the problem, since there would be no way to override the implementation defined by the category. That is to say, unlike the class hierarchy, categories are a flat organizational structure-if you implement the same method in two separate categories, it’s impossible for the runtime to figure out which one to use.

The only change you have to make to use a category is to import the category’s header file. As you can see in the following example, the Person class has access to the methods defined in Person.h along with those defined in the category Person+Relations.h:

// main.m
#import <Foundation/Foundation.h>
#import "Person.h"
#import "Person+Relations.h"
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        Person *joe = [[Person alloc] init];
        joe.name = @"Joe";
        Person *bill = [[Person alloc] init];
        bill.name = @"Bill";
        Person *mary = [[Person alloc] init];
        mary.name = @"Mary";
        [joe sayHello];
        [joe addFriend:bill];
        [joe addFriend:mary];
        [joe sayHelloToFriends];
    }
    return 0;
}

And that’s all there is to creating categories in Objective-C.

To reiterate, all Objective-C methods are public-there is no language construct to mark them as either private or protected. Instead of using “true” protected methods, Objective-C programs can combine categories with the interface/implementation paradigm to achieve the same result.

The idea is simple: declare “protected” methods as a category in a separate header file. This gives subclasses the ability to “opt-in” to the protected methods while unrelated classes use the “public” header file as usual. For example, take a standard Ship interface:

// Ship.h
#import <Foundation/Foundation.h>
@interface Ship : NSObject
- (void)shoot;
@end

As we’ve seen many times, this defines a public method called shoot. To declare a protected method, we need to create a Ship category in a dedicated header file:

// Ship_Protected.h
#import <Foundation/Foundation.h>
@interface Ship(Protected)
- (void)prepareToShoot;
@end

Any classes that need access to the protected methods (namely, the superclass and any subclasses) can simply import Ship_Protected.h. For example, the Ship implementation should define a default behavior for the protected method:

// Ship.m
#import "Ship.h"
#import "Ship_Protected.h"
@implementation Ship {
    BOOL _gunIsReady;
}
- (void)shoot {
    if (!_gunIsReady) {
        [self prepareToShoot];
        _gunIsReady = YES;
    }
    NSLog(@"Firing!");
}
- (void)prepareToShoot {
    // Execute some private functionality.
    NSLog(@"Preparing the main weapon...");
}
@end

Note that if we hadn’t imported Ship_Protected.h, this prepareToShoot implementation would be a private method, as discussed in the Methods chapter. Without a protected category, there would be no way for subclasses to access this method. Let’s subclass the Ship to see how this works. We’ll call it ResearchShip:

// ResearchShip.h
#import "Ship.h"
@interface ResearchShip : Ship
- (void)extendTelescope;
@end

This is a normal subclass interface-it should not import the protected header, as this would make the protected methods available to anyone that imports ResearchShip.h, which is precisely what we’re trying to avoid. Finally, the implementation for the subclass imports the protected methods and (optionally) overrides them:

// ResearchShip.m
#import "ResearchShip.h"
#import "Ship_Protected.h"
@implementation ResearchShip
- (void)extendTelescope {
    NSLog(@"Extending the telescope");
}
// Override protected method
- (void)prepareToShoot {
    NSLog(@"Oh shoot! We need to find some weapons!");
}
@end

To enforce the protected status of the methods in Ship_Protected.h, other classes aren’t allowed to import it. They’ll just import the normal “public” interfaces of the superclass and subclass:

// main.m
#import <Foundation/Foundation.h>
#import "Ship.h"
#import "ResearchShip.h"
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        Ship *genericShip = [[Ship alloc] init];
        [genericShip shoot];
        Ship *discoveryOne = [[ResearchShip alloc] init];
        [discoveryOne shoot];
    }
    return 0;
}

Since neither main.mShip.h, nor ResearchShip.h import the protected methods, this code won’t have access to them. Try adding a [discoveryOne prepareToShoot] method-it will throw a compiler error, since the prepareToShoot declaration is nowhere to be found.

To summarize, protected methods can be emulated by placing them in a dedicated header file and importing that header file into the implementation files that require access to the protected methods. No other files should import the protected header.

While the workflow presented here is a completely valid organizational tool, keep in mind that Objective-C was never meant to support protected methods. Think of this as an alternative way to structure an Objective-C method, rather than a direct replacement for C#/Simula-style protected methods. It’s often better to look for another way to structure your classes rather than forcing your Objective-C code to act like a C# program.

One of the biggest issues with categories is that you can’t reliably override methods defined in categories for the same class. For example, if you defined an addFriend: class in Person(Relations) and later decided to change the addFriend: implementation via a Person(Security) category, there is no way for the runtime to know which method it should use since categories are, by definition, a flat organizational structure. For these kinds of cases, you need to revert to the traditional subclassing paradigm.

Also, it’s important to note that a category can’t add instance variables. This means you can’t declare new properties in a category, as they could only be synthesized in the main implementation. Additionally, while a category technically does have access to its classes’ instance variables, it’s better practice to access them through their public interface to shield the category from potential changes in the main implementation file.

Extensions (also called class extensions) are a special type of category that requires their methods to be defined in the main implementation block for the associated class, as opposed to an implementation defined in a category. This can be used to override publicly declared property attributes. For example, it is sometimes convenient to change a read-only property to a read-write property within a class’ implementation. Consider the normal interface for a Ship class:

Included code sample: Extensions

// Ship.h
#import <Foundation/Foundation.h>
#import "Person.h"
@interface Ship : NSObject
@property (strong, readonly) Person *captain;
- (id)initWithCaptain:(Person *)captain;
@end

It’s possible to override the @property definition inside of a class extension. This gives you the opportunity to re-declare the property as readwrite in the implementation file. Syntactically, an extension looks like an empty category declaration:

// Ship.m
#import "Ship.h"
// The class extension.
@interface Ship()
@property (strong, readwrite) Person *captain;
@end
// The standard implementation.
@implementation Ship
@synthesize captain = _captain;
- (id)initWithCaptain:(Person *)captain {
    self = [super init];
    if (self) {
        // This WILL work because of the extension.
        [self setCaptain:captain];
    }
    return self;
}
@end

Note the () appended to the class name after the @interface directive. This is what marks it as an extension rather than a normal interface or a category. Any properties or methods that appear in the extension must be declared in the main implementation block for the class. In this case, we aren’t adding any new fields-we’re overriding an existing one. But unlike categories, extensions can add extra instance variables to a class, which is why we’re able to declare properties in a class extension but not a category.

Because we re-declared the captain property with a readwrite attribute, the initWithCaptain: method can use the setCaptain: accessor on itself. If you were to delete the extension, the property would return to its read-only status and the compiler would complain. Clients using the Ship class aren’t supposed to import the implementation file, so the captain property will remain read-only.

#import <Foundation/Foundation.h>
#import "Person.h"
#import "Ship.h"
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        Person *heywood = [[Person alloc] init];
        heywood.name = @"Heywood";
        Ship *discoveryOne = [[Ship alloc] initWithCaptain:heywood];
        NSLog(@"%@", [discoveryOne captain].name);
        Person *dave = [[Person alloc] init];
        dave.name = @"Dave";
        // This will NOT work because the property is still read-only.
        [discoveryOne setCaptain:dave];
    }
    return 0;
}

Another common use case for extensions is for declaring private methods. In the previous chapter, we saw how private methods can be declared by simply adding them anywhere in the implementation file. But, prior to Xcode 4.3, this was not the case. The canonical way to create a private method was to forward-declare it using a class extension. Let’s take a look at this by slightly altering the Ship header from the previous example:

// Ship.h
#import <Foundation/Foundation.h>
@interface Ship : NSObject
- (void)shoot;
@end

 

Next, we’re going to recreate the example we used when we discussed private methods in the Methods chapter. Instead of simply adding the private prepareToShoot method to the implementation, we need to forward-declare it in a class extension.

// Ship.m
#import "Ship.h"
// The class extension.
@interface Ship()
- (void)prepareToShoot;
@end
// The rest of the implementation.
@implementation Ship {
    BOOL _gunIsReady;
}
- (void)shoot {
    if (!_gunIsReady) {
        [self prepareToShoot];
        _gunIsReady = YES;
    }
    NSLog(@"Firing!");
}
- (void)prepareToShoot {
    // Execute some private functionality.
    NSLog(@"Preparing the main weapon...");
}
@end

The compiler ensures the extension methods are implemented in the main implementation block, which is why it functions as a forward-declaration. Yet because the extension is encapsulated in the implementation file, other objects shouldn’t ever know about it, giving us another way to emulate private methods. While newer compilers save you this trouble, it’s still important to understand how class extensions work, as it has been a common way to leverage private methods in Objective-C programs until very recently.

This chapter covered two of the more unique concepts in the Objective-C programming language: categories and extensions. Categories are a way to extend the API of existing classes, and extensions are a way to add required methods to the API outside of the main interface file. Both of these were initially designed to ease the burden of maintaining large code bases.

The next chapter continues our journey through Objective-C’s organizational structures. We’ll learn how to define a protocol, which is an interface that can be implemented by a variety of classes.

xcode下已经使用 “Automatically manage signing”,还提示“is automatically signed, but provisioning profile 1fe1af09-c71e-4300-94d8-76d14cec2eb4 has been manually specified. Set the provisioning profile value to “Automatic” in the build settings editor, or switch to manual signing in the Signing & Capabilities editor.”解决方案

 开发  xcode下已经使用 “Automatically manage signing”,还提示“is automatically signed, but provisioning profile 1fe1af09-c71e-4300-94d8-76d14cec2eb4 has been manually specified. Set the provisioning profile value to “Automatic” in the build settings editor, or switch to manual signing in the Signing & Capabilities editor.”解决方案已关闭评论
12月 092019
 

xcode项目签名已经使用 “Automatically manage signing”,但还是提示如下:

XXXXXX is automatically signed, but provisioning profile 1fe1af09-c71e-4300-94d8-76d14cec2eb4 has been manually specified. Set the provisioning profile value to “Automatic” in the build settings editor, or switch to manual signing in the Signing & Capabilities editor.

记录下自己错误提示中黑体字位置部分的文字:“1fe1af09-c71e-4300-94d8-76d14cec2eb4”

试下下面的方法:

  1.  右键点击 项目文件  xxxx.xcodeproj –> 显示包内容(Show Package Contents)–> 打开并编辑 project.pbxproj
  2. 在project.pbxproj 搜索“1fe1af09-c71e-4300-94d8-76d14cec2eb4”,找到对应的行,删除
  3. 再次进入xcode,使用“Automatically manage signing”,Done!