原文

前言

在项目业务趋于稳定的时候,开发完迭代需求后,我们可能会无所适从,进入一段空白期,但是对于攻城狮来说闲暇不是件好事,所以我们可能总想学点什么,却又没有头绪。这个时候我们就可以考虑完善和优化我们的项目了。从中可以运用到一些底层RunLoop或者Runtime的知识,熟能生巧总是没错的????

1. 结构与架构

1.1 结构

这里说的结构大概有两点:1.文件目录分类 2.第三方库管理

1.1.1 文件目录分类

为了方便管理,最好将Xcode中的项目展示目录与实际的存储目录保持一致

此外,一般按业务模块分类,一级目录可以按照MVC格式,也可以按照业务模块划分

用最普遍的Model View Controller架构举例

  • 以一个基础的电商项目来解释,4个tabbarItem对应着四大模块,首页、分类、购物车、个人中心,往下每个还可以细分为MVC+Session层

  • 按项目架构来分

    最外层为Model、View、Controller、Session层,内部才是业务模块

    这一块无需多言,两者配合使用即可

1.1.2 第三方库

个人建议:时间允许的话自己多造造轮子,风险可控,好维护

如非必要,尽量不要直接使用已经编译好的三方库(framework/.a),最好自己去编译三方库(安全要求)

管理方面有三种方式:

  • 手动管理

    手动维护各种第三方库,适合于已经趋于稳定、极少Bug的三方库

  • CocoaPods

  • Carthage

这里更推荐使用Carthage,因为它对项目的侵入性最小,而且是去中心化管理,不需要等待漫长的pod update / install过程.不过各有各的好处,使用CocoaPods简单粗暴,基本不需要额外设置什么,看自己需求吧

1.2 项目架构

项目逻辑基本都围绕了一条主线时,我们采用MVC已经可以很好的满足我们的需求,但是当业务逻辑日渐复杂的时候,我们单纯的采用Model View Controller这种编程模式已经不能很好的将业务逻辑与代码分离开,也就是解耦Decouple.

为了更好的将ViewController解耦,产生了Model View ViewModel这种编程模式,ViewModel层其实做了一层Model与ViewController中间的桥接,有利有弊,该模式会产生很多胶水代码,但是配合响应式编程框架(如 ReactiveCocoa或者RxSwift),可以做到最大程度的解耦。,适合与自己实际项目业务复杂程度的模式才是好的编程模式。

引申 : <关于组件化编程>

如果项目业务很复杂、很多业务组件都通用,可以采用组件化编程,常用的一种就是采用CocoaPods将项目业务模块分拆成各种pod库,使用什么模块直接集成就好,再配合MVVM和响应式编程框架(如 ReactiveCocoa或者RxSwift),可以做到最大程度的解耦。

2. 崩溃&性能调优

当项目已经完成业务模块上线后,我们就可以开始考虑关于如何提高App的用户体验,举例一下几个问题:

1. 代码规范,定期code review了吗

2. 复杂列表的滚动时FPS可以保持在60帧左右吗?

3. 页面加载渲染的耗时能不能进一步减小?

4. 网络缓存有做吗,UIWebView / WKWebView的常用静态资源做缓存了吗

5. App的启动时间可以在保持最小业务逻辑的同时再减小一点吗?

2.1 UITest & UnitTest

当开发完新需求的时候,在提测之前我们最好编写下UITest和UnitTest,覆盖主业务流程即可,可以提高我们的提测质量,减小一些可见的Bug,再加上冒烟用例,最大程度上提高我们提测的质量(成为KPI之王 - ????),而且上线之后这些单元测试和UITest组件的脚本可以配合自动化测试定期进行回归测试,提高App的质量,减少崩溃率

2.2 NullSafe

绝大多数情况下,我们向NSNull对象发送消息,都会产生崩溃,NSNull对象常见于后台返回数据中可能会有null字段,很多JSON库都会转成NSNull对象,如下情况就会产生崩溃:

1
2
id obj = [NSNull null];
NSLog(@"%@", [obj stringValue]);

但是向nil对象发送消息则不会产生崩溃,这些可以参考NullSafe中的处理方法,重写

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector和- (void)forwardInvocation:(NSInvocation *)anInvocation这两个方法将没能力处理消息的方法签名转发给nil对象则不会产生崩溃

此外,常见的崩溃比如,NSArray取值越界,NSDictionary传了nil对象,这些问题产生的崩溃可以使用Runtime中的Method Swizzle,将原生的方法hook掉,如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
@implementation NSMutableDictionary (NullSafe)
 
- (void)swizzleMethod:(SEL)origSelector withMethod:(SEL)newSelector
{
    Class class = [self class];
 
    Method originalMethod = class_getInstanceMethod(class, origSelector);
    Method swizzledMethod = class_getInstanceMethod(class, newSelector);
 
    BOOL didAddMethod = class_addMethod(class,
                                        origSelector,
                                        method_getImplementation(swizzledMethod),
                                        method_getTypeEncoding(swizzledMethod));
    if (didAddMethod) {
        class_replaceMethod(class,
                            newSelector,
                            method_getImplementation(originalMethod),
                            method_getTypeEncoding(originalMethod));
    else {
        method_exchangeImplementations(originalMethod, swizzledMethod);
    }
}
 
+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        id obj = [[self alloc] init];
        [obj swizzleMethod:@selector(setObject:forKey:) withMethod:@selector(safe_setObject:forKey:)];
 
    });
 
}
 
- (void)safe_setObject:(id)value forKey:(NSString *)key {
    if (value) {
        [self safe_setObject:value forKey:key];
    }else {
        NullSafeLogFormatter(@"[NSMutableDictionary setObject: forKey:], Object cannot be nil")
    }
}
 
@end

这种解决方法可以避免诸如数组取值越界、字典传空值、removeObjectAtIndex等错误,如下的崩溃就可以避免:

1
2
3
id obj = nil;
NSMutableDictionary *m_dict = [NSMutableDictionary dictionary];
[dict setObject:obj forKey:@"666"];

2.2 监控系统

目前大多数App都集成了第三方统计库,常见的比如腾讯的Bugly、友盟的U-App等等,在这介绍下如何自建性能监控库

可以使用PLCrashReporter或者KSCrash库解析崩溃日志并符号化,再上传至后台,自己做收集加统计,顺带提一下,我们使用了PLCrashReporter,后端使用了Laravel,很方便的开发了一套简单的崩溃及各种性能参数收集的系统,所以如果要自建,可以考虑这个组合

  • CPU、内存、FPS记录及保存

1
    `CPU`、`FPS`、`Memory占用`网上都有现成的方法获取到这三个参数,这三个属于性能监控,可以定时记录,比如10S记录一次到本地文件中,每次打开App上传昨天的日志。这就要自己制定日志上传的策略了
  • 卡顿日志收集

    用户能感受到的卡顿一般都是因为在主线程做了耗时操作,举几个会发生卡顿的例子:

  1. viewDidLoad中 for循环中初始化10000个UILabel实例

  2. cellForRow代理方法中手动休眠usleep(100*1000)

如何监听这些事件呢?查看下源代码,核心方法CFRunLoopRun简化后的逻辑如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
    int32_t __CFRunLoopRun()
{
    //通知即将进入runloop
    __CFRunLoopDoObservers(KCFRunLoopEntry);
 
    do
    {
        // 通知将要处理timer和source
        __CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
        __CFRunLoopDoObservers(kCFRunLoopBeforeSources);
 
        __CFRunLoopDoBlocks();  //处理非延迟的主线程调用
        __CFRunLoopDoSource0(); //处理UIEvent事件
 
        //GCD dispatch main queue
        CheckIfExistMessagesInMainDispatchQueue();
 
        // 即将进入休眠
        __CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);
 
        // 等待内核mach_msg事件
        mach_port_t wakeUpPort = SleepAndWaitForWakingUpPorts();
 
        // Zzz...
 
        // 从等待中醒来
        __CFRunLoopDoObservers(kCFRunLoopAfterWaiting);
 
        // 处理因timer的唤醒
        if (wakeUpPort == timerPort)
            __CFRunLoopDoTimers();
 
        // 处理异步方法唤醒,如dispatch_async
        else if (wakeUpPort == mainDispatchQueuePort)
            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()
 
        // UI刷新,动画显示
        else
            __CFRunLoopDoSource1();
 
        // 再次确保是否有同步的方法需要调用
        __CFRunLoopDoBlocks();
 
    while (!stop && !timeout);
 
    //通知即将退出runloop
    __CFRunLoopDoObservers(CFRunLoopExit);
}

我们可以看到在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting等待时间过长即可判定为卡顿,具体怎么算作卡顿,我们都知道FPS为一秒60帧左右最好,FPS即为Frames Per Second,严格意义上一秒60帧算流畅,也就是一帧需要1s/60 = 16.6ms,考虑会有其他的一些事件影响,可以用连续几次50ms或者单次耗时过长判定为卡顿。判定为卡顿之后,我们可以使用PLCrashReporter或者KSCrash生成日志记录,可以存储到本地

我们可以使用CFRunLoopObserverRef来实时获取NSRunLoop状态值的变化,一下为一个样例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
@interface LagCollectionTool ()
{
    int timeoutCount;
    CFRunLoopObserverRef observer;
    BOOL observeLag;
@public
    dispatch_semaphore_t semaphore;
    CFRunLoopActivity activity;
}
 
@end
 
 
@implementation LagCollectionTool
 
+ (instancetype)shareInstance {
    static dispatch_once_t onceToken;
    static LagCollectionTool *tool = nil;
    dispatch_once(&onceToken, ^{
        tool = [[LagCollectionTool alloc] init];
    });
    return tool;
}
 
- (void)lanuch {
    if (observer)
        return;
 
    // 信号
    semaphore = dispatch_semaphore_create(0);
 
    // 注册RunLoop状态观察
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    observer = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                       kCFRunLoopAllActivities,
                                       YES,
                                       0,
                                       &runLoopObserverCallBack,
                                       &context);
    CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
 
    // 在子线程监控时长
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        while (YES)
        {
            long st = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC));
            if (st != 0)
            {
                if (!observer)
                {
                    timeoutCount = 0;
                    semaphore = 0;
                    activity = 0;
                    return;
                }
 
                if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting)
                {
                    timeoutCount++;
                    //                    NSLog(@"%d", timeoutCount);
                    if (timeoutCount < 5)
                        continue;
                    NSLog(@"----------------卡爆了!----------------");
 
                    PLCrashReporterConfig *config = [[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeBSD
                                                                                       symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll];
                    PLCrashReporter *crashReporter = [[PLCrashReporter alloc] initWithConfiguration:config];
 
                    NSData *data = [crashReporter generateLiveReport];
                    PLCrashReport *reporter = [[PLCrashReport alloc] initWithData:data error:NULL];
                    NSString *report = [PLCrashReportTextFormatter stringValueForCrashReport:reporter
                                                                              withTextFormat:PLCrashReportTextFormatiOS];                                                                                  
                    //上传卡顿日志文件
 
                }
            }
            timeoutCount = 0;
        }
    });
 
}
 
static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info)
{
    LagCollectionTool *tool = (__bridge LagCollectionTool *)info;
    tool->activity = activity;
 
    dispatch_semaphore_t semaphore = tool->semaphore;
    dispatch_semaphore_signal(semaphore);
}
  • 从容崩溃,上传崩溃日志

通过使用NSSetUncaughtExceptionHandler注册自己的异常处理回调,发生崩溃时让程序显示的从容一点,不会直接闪退,可以弹出自己的崩溃异常界面,可以参考Bilibili的界面,比如说前方遇到高能反应之类,程序需要重启之类的,不会让用户感觉到很突兀得闪退了,也可以在收到崩溃日志后手动维护Runloop,下面是一个样例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// 1. 注册ExceptionHandler
 
+ (void)installUncaughtExceptionHandler {
    NSSetUncaughtExceptionHandler(&HandleException);
 
    signal(SIGHUP, SignalHandler);
    signal(SIGINT, SignalHandler);
    signal(SIGQUIT, SignalHandler);
 
    signal(SIGABRT, SignalHandler);
    signal(SIGILL, SignalHandler);
    signal(SIGSEGV, SignalHandler);
    signal(SIGFPE, SignalHandler);
    signal(SIGBUS, SignalHandler);
    signal(SIGPIPE, SignalHandler);
}
 
// 2. 处理崩溃信息
void SignalHandler(int signal) {
    // 1. 获取调用栈
    // 2. 处理异常
 
    // 3. App保活
    BOOL isContiune = TRUE; // 是否要保活
    CFRunLoopRef runLoop = CFRunLoopGetCurrent();
    CFArrayRef allModes = CFRunLoopCopyAllModes(runLoop);
 
    while (isContiune) {
        for (NSString *mode in (__bridge NSArray *)allModes) {
            CFRunLoopRunInMode((CFStringRef)mode, 0.001, true);
        }
    }
    CFRelease(allModes);
    signal(SIGABRT, SIG_DFL);
    signal(SIGILL, SIG_DFL);
    signal(SIGSEGV, SIG_DFL);
    signal(SIGFPE, SIG_DFL);
    signal(SIGBUS, SIG_DFL);
    signal(SIGPIPE, SIG_DFL);
}

延伸:

监控系统不光局限于性能、崩溃率,也可以将统计策略延伸到网络请求连通率或者一些业务层面,更好的把控App的质量

2.3 性能调优&App体验优化

前面我们介绍了如何有效地减少崩溃及优雅地处理崩溃,下面来看看解决性能问题需要注意几点。

2.3.1 懒加载的利与弊

懒加载适用于一些可能不会加载的页面,比如弹框、空数据页面之类的,使用得当可以避免内存暴涨,使用不好,比如在必定会弹出的页面中使用懒加载可能会在增加页面响应时间,所以使用懒加载一定要注意使用场景,避免产生副作用

2.3.2 避免使用重绘

重写 drawRect 或者 drawReact:inContext方法会默认创建一个图层上下文,图形上下文所需要的内存为图层宽 * 图层高 * 4字节,图层每次进行重绘时都需要抹掉内存重新分配,会产生巨大的性能开销

UIView类实际上是对CALayer的封装,关于UI层面的性能优化有很多东西,可以看看iOS CoreAnimation 核心动画高级编程中关于图层性能的一章

2.3.3 App体验优化

谈起App体验优化,其实这是个玄学,你需要在性能与体验上找到一个平衡点,常见的糟糕的体验包括:

  • UITableViewCell 使用不当造成滑动卡顿

  • 大量cornerRadius和maskToBounds一起使用造成的离屏渲染造成的性能问题

  • 网络请求操作没有任何状态展示,比如加载框、按钮置灰等

  • 网络请求没有进行缓存

这些问题只是App的细节,但是从细节入手才能更显的专业~

我们重点谈谈网络请求优化:

2.3.3.1 手动维护DNS解析

www.manoboo.com来举例,通过域名访问首先会寻找DNS解析服务器,然后才会映射到自己的服务器IP上。我们直接使用IP请求接口访问网络资源,可以避免很多问题,但是有利有弊,需要自己维护DNS映射,在直接比如:

  1. 运营商DNS流量劫持,具体表现在你的H5网页莫名其妙的被加了广告(关于这个问题,也可以做域名白名单,非本域名资源禁止请求,或者H5方面做处理),也有

  2. DNS服务商(如万网)解析出现故障造成的大批量用户无法正常使用App,按天计算。。

  3. DNS解析延迟过高造成的加载超时导致用户体验差

此时我们可以考虑自己手动做DNS解析,简单点可以在网络请求时将URL中的域名替换掉,或者在Objective-C中实现NSURLProtocol(Swift中为URLProtocol)的子类对应的方法,做全局替换URL

不过也有些弊端:

  1. 需要手动维护DNS解析表,解析出错后需要一套容错方案,保证接口的畅通

  2. HTTP请求可以通过设置header中的host字段进行网络请求,HTTPS请求还需额外配置,受限于篇幅原因,详细的弊端和解决方法可以阅读下这篇文章HTTPDNS在iOS中的实践

2.3.3.2 网络请求缓存优化

适用场景:一些更新频率较低的场景:比如个人中心

关于网络请求缓存,App端的网络请求对面到后端更多的是增删改查,这个方面需要和后端配合,是否资源改变即后端是否需要重新检索或修改数据,这个时候我们就需要一个value比如时间戳Last-Modified或者标识ETag来告知服务器自己当前的资源标记,目前常用的策略为:

以时间戳Last-Modified为例

  1. App端第一次请求接口,服务端返回成功,HTTP Status为200,并且在返回的Header中用Last-Modified表明服务器中该资源最后被修改的时间

  2. App端第二次请求该接口,Header中传递本地缓存的Header中的Last-Modified,如果服务器端的资源并未发生变化,则会返回HTTP Status为304,我们直接可以使用本地的缓存,传输流量更少,相对而言,用户的等待时间会更短

注:

量化而非猜测,这是我们开发过程中的一个原则,当遇到性能问题时,我们可以使用instruments来测量实际运行过程中的各个参数,找到问题所在(建议真机调试而不是模拟器,真机才能更高的还原性能问题)

instruments工具常见功能

点击右上方加号还有更多工具+

instruments中工具都有各自的用处,比如可以使用Leask查看App运行过程中的内存泄露,使用TimeProfiler查看App启动耗时或者方法耗时,或者偷懒一点可以使用CACurrentMediaTime()两次的差值计算方法耗时

结语

受限于篇幅原因,有些点也是一概而过,iOS中如何优化一个项目,这是一门很深的学问,知识点范围很广,我也只是涉及到了一部分,学无止境嘛,完成工作的同时我们也可以做一个酷酷的程序员,学学Haskell去体验下函数式编程思维的乐趣,或者搞搞LLDB更好得做个Debugger

最后,非常感谢您阅读这篇文章,如果我的文章产生了帮助,可以给一个小小的红心??,欢迎去我的小站www.manoboo.com拍砖啦,我会努力创作更好的文章

文中引用到的文章如下:

CocoaChina - iOS 实时卡顿监控

iOS Core Animation: Advanced Techniques 中文译本

文中所涉及到的开源库如下:

PLCrashReporter

KSCrash

MBNullSafe ManoBoo编写的NullSafe库,会进一步拓展功能

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

iOS 如何优化项目的更多相关文章

  1. 【腾讯Bugly干货分享】微信读书iOS性能优化

    本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://dev.qq.com/topic/578c93ca9644bd524bfcabe8 “8小时内拼工作,8小时外拼成长 ...

  2. iOS性能优化:Instruments使用实战

    iOS性能优化:Instruments使用实战   最近采用Instruments 来分析整个应用程序的性能.发现很多有意思的点,以及性能优化和一些分析性能消耗的技巧,小结如下. Instrument ...

  3. IOS 性能优化的建议和技巧

    IOS 性能优化的建议和技巧 本文来自iOS Tutorial Team 的 Marcelo Fabri,他是Movile的一名 iOS 程序员.这是他的个人网站:http://www.marcelo ...

  4. 2018 Unite大会——《使用UPA工具优化项目》演讲实录

    2018年5月11日至13日,腾讯WeTest与Unity联合打造的移动游戏性能分析工具(Unity Performance Analysis,以下称为UPA)正式亮相2018 Unite大会,为Un ...

  5. IOS客户端Coding项目记录导航

    IOS客户端Coding项目记录(一) a:UITextField设置出现清除按键 b:绘画一条下划线  表格一些设置 c:可以定义表头跟底部视图(代码接上面) d:隐藏本页的导航栏 e:UIEdge ...

  6. iOS 滑动性能优化

    iOS 滑动性能优化 目录 一. 减少图层的Blend操作 1. UIView的背景色避免使用clearColor 2. 控件贴图避免使用带alpha的图片 3. UIImageView 使用时避免半 ...

  7. iOS 静态类库项目的建立与使用

    iOS 静态类库项目的建立与使用   新建 Xcode workspace 打开 Xcode , 选择 File -> New -> Workspace , 将 Workspace 命名为 ...

  8. Tair LDB基于Prefixkey中期范围内查找性能优化项目总结

    "Tair LDB基于Prefixkey该范围内查找性能优化"该项目是仅一个月.这个月主要是熟悉项目..以下从几个方面总结下个人在该项目上所做的工作及自己的个人所得所感. 项目工作 ...

  9. Tair LDB基于Prefixkey找到如何提取一系列性能优化项目key的prefix_size

    眼下项目已快截止,编码任务也基本完毕.如今主要是性能測试. 项目是依照"Tair LDB基于Prefixkey的范围查找性能优化项目提议方案"的步骤一步步完毕的,首先先介绍第一个关 ...

随机推荐

  1. python实现八皇后问题

    import random def judge(state, nextX): #判断是否和之前的皇后状态有冲突 nextY = len(state) for i in range(nextY): if ...

  2. HDU 4821 String(BKDRHash)

    http://acm.hdu.edu.cn/showproblem.php?pid=4821 题意:给出一个字符串,现在问你可以找出多少个长度为M*L的子串,该子串被分成L个段,并且每个段的字符串都是 ...

  3. 初步接触ES6

    Babel---ES6转码器 ES6 声明变量的六种方法 ES5 只有两种声明变量的方法:var命令和function命令. ES6除了添加let和const命令,另外两种声明变量的方法:import ...

  4. PHP Warning: Module 'memcache' already loaded in Unknown on line 0

    出现类似PHP Warning: Module * already loaded in Unknown on line 0,一般是可能因为升级php导致的组件重复加载,解决就是 1.vi /etc/p ...

  5. RedHat(Linux)下安装Python3步骤

    1. 下载解压.$ wget https://www.python.org/ftp/python/3.4.1/Python-3.4.1.tgz$ tar zxvf Python-3.4.1.tgz 2 ...

  6. 浅谈Linux文件系统

    Linux 与其他类 UNIX 系统一样并不区分文件与目录:目录是记录了其他文件名的文件.使用命令 mkdir 创建目录时,若期望创建的目录的名称与现有的文件名(或目录名)重复,则会创建失败. Lin ...

  7. Java 多条件复杂排序小结

    前言 今天下午做了拼多多在牛客网上的在线笔试题,感觉自己的智商被鄙视到了···不过其中一道题的某一部分引起了我极大的兴趣,感觉可以总结一下,做好积累~ 题目的部分我拍照如下所示 这里面最复杂的就是第3 ...

  8. 学习笔记56—Endnote参考文献格式调整

    论文写作

  9. 在浏览器端用es6,babel+browserify打包

    写得最清楚的是这个系列: 一个普通的写网页的人如何过渡到ES6 (一) 感觉比babel官网写得还清楚点. 看完这个才有点理解node原来不只是用来起express后端web server,更主要用途 ...

  10. Python pip 常用命令

    使用了这么就pip命令,但是一直是简单使用,很多命令都是用了查,查了用,今天把常用的命令汇总一下,方便使用. 命令: pip 由上图可以看到 pip 支持一下命令 Commands: install ...