看了眼 tinyfool 经常提的日历控件

先贴上源码地址：Here 代码是是 08 年写的，这点还是非常服的，这个时候我还在上高中。 08 年到现在 OC 在一些特性上改进很多，其中使用的CFGregorianDate相关 api 在 iOS 8.0 之后也不建议使用了，所以这里我只说我确认不是好的实践的部分。

先来看下头文件:

//
//  CalendarView.h
//  ZhangBen
//
//  Created by tinyfool on 08-10-26.
//  Copyright 2008 __MyCompanyName__. All rights reserved.
//

#import <UIKit/UIKit.h>

@protocol CalendarViewDelegate;

@interface TdCalendarView : UIView {
	CFGregorianDate currentMonthDate;
	CFGregorianDate currentSelectDate;
	CFAbsoluteTime	currentTime;
	UIImageView* viewImageView;
	id<CalendarViewDelegate> calendarViewDelegate;
	int *monthFlagArray; 
}

@property CFGregorianDate currentMonthDate;
@property CFGregorianDate currentSelectDate;
@property CFAbsoluteTime  currentTime;

@property (nonatomic, retain) UIImageView* viewImageView;
@property (nonatomic, assign) id<CalendarViewDelegate> calendarViewDelegate;
-(int)getDayCountOfaMonth:(CFGregorianDate)date;
-(int)getMonthWeekday:(CFGregorianDate)date;
-(int)getDayFlag:(int)day;
-(void)setDayFlag:(int)day flag:(int)flag;
-(void)clearAllDayFlag;
@end



@protocol CalendarViewDelegate<NSObject>
@optional
- (void) selectDateChanged:(CFGregorianDate) selectDate;
- (void) monthChanged:(CFGregorianDate) currentMonth viewLeftTop:(CGPoint)viewLeftTop height:(float)height;
- (void) beforeMonthChange:(TdCalendarView*) calendarView willto:(CFGregorianDate) currentMonth;
@end

代码格式我就不说了，空格写的很随意，大小写对于我这种强迫症来说也很受不了。最重要的是我认为稍微参考下苹果 framework 中函数的命名方式，就不会写出协议中这么扯淡的命名。 interface 中的命名大多数都还不错，但是-(void)setDayFlag:(int)day flag:(int)flag;这个是什么鬼，我认为- (void)setFlag:(int)flag forDay:(int)day;更好。

下面来看下源文件：

源文件中定义了全局的几个变量：

const float headHeight=60;
const float itemHeight=35;
const float prevNextButtonSize=20;
const float prevNextButtonSpaceWidth=15;
const float prevNextButtonSpaceHeight=12;
const float titleFontSize=30;
const int	weekFontSize=12;

这几个变量主要是来控制试图的大小、字体的大小，只有在这个文件内部试哟哦难过，没有用static修饰，不是很明白，可能 tinyfool 记忆里好，不会再工程中其他地方使用相同名字的变量。

学 C 语言的时候，大概都做过这么一个练习：获取某年某月的天数。来看看 tinyfool 的实现：**

-(int)getDayCountOfaMonth:(CFGregorianDate)date{
	switch (date.month) {
		case 1:
		case 3:
		case 5:
		case 7:
		case 8:
		case 10:
		case 12:
			return 31;
			
		case 2:
			if((date.year % 4==0 && date.year % 100!=0) || date.year % 400==0)
				return 29;
			else
				return 28;
		case 4:
		case 6:
		case 9:		
		case 11:
			return 30;
		default:
			return 31;
	}
}

interesting ，自行体会一下。

实现中有很多类似的实践（个人认为这不是好的实践）：

- (void)movePrevMonth{
	if(currentMonthDate.month>1)
		currentMonthDate.month-=1;
	else
	{
		currentMonthDate.month=12;
		currentMonthDate.year-=1;
	}
	[self movePrevNext:0];
}

再来看下这个类的析构函数：

- (void)dealloc {
    [super dealloc];
    free(monthFlagArray);
}

Excuse me. 这里虽然不太可能出现崩溃的情况，但不是应该先释放子类持有的资源？

最后，总结一些 tinyfool 的变量命名风格：title_Month、weekfont、tabHeight、s_width。

我观察到的是，如果有人在微博上反驳他什么，他通常的回应是毫无道理（有道理的时候也有，少），其他的不想评价，怕被喷。

tinyfool

2016-11-28 10:41:22 +08:00

@holyghost 没错，这是常识，不过我懒得细看你的实现。

我做了一个简单的 benchmark 你可以看看

//
// main.m
// testleapyear
//
// Created by Peiqiang Hao on 2016/11/28.
// Copyright © 2016 年 Peiqiang Hao. All rights reserved.
//

#import <Foundation/Foundation.h>

int main(int argc, const char * argv[]) {
@autoreleasepool {
// insert code here...

NSTimeInterval t1 = [[NSDate date] timeIntervalSince1970];

for (int i = 0; i< 1000000; i++) {

int year = i;
int leapYear = (year & 3) == 0 && ((year % 25) != 0 || (year & 15) == 0);
}
NSTimeInterval t2 = [[NSDate date] timeIntervalSince1970];
NSLog(@"%g",t2-t1);

t1 = [[NSDate date] timeIntervalSince1970];
for (int i = 0; i< 1000000; i++) {

int year = i;
int leapYear = ((year % 4==0 && year % 100!=0) || year % 400==0);
}
t2 = [[NSDate date] timeIntervalSince1970];
NSLog(@"%g",t2-t1);

}
return 0;
}

结果是：

2016-11-28 10:37:54.885253 testleapyear[16140:987950] 0.00339603
2016-11-28 10:37:54.893403 testleapyear[16140:987950] 0.00789499

在 100 万次调用下，你的实现比我快了 4 个毫秒。在我看来，这样的优化，千万不要做，得不偿失。当然如果你觉得我的测试条件写错了，你可以改，我可以再跑一次。运行环境是我的 rmbp 15 寸低配，去年中期的配置。

tinyfool

2016-11-28 11:07:05 +08:00

@holyghost 我没有说你的知识不对的意思。包括 @EagleB 。

高德纳老师有句话叫做“过早优化是万恶之源。”，原文， We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

当你关心了一个明显不是性能攸关的点的时候，我就担心你的大局观了。刚才说了求月日数，一次翻页才调用一次，闰年判断也如此。这根本不是性能攸关点。

其次，一个操作比另外一个操作快，是很常见的。这很正常，但是，按照刚才的 benchmark 在当前测试条件下快了不到一倍。如果本身很耗时，不到一倍也是不错的回报。问题是运行 100 万次都才 7 个 ms ，这快了一倍叫做没有收益。

在实战的性能优化里面，我们关心的第一是运行多次的，性能攸关点。复杂度的增长速度。以及那些差异到了 100-1000 倍，甚至更大的操作。比如内存和硬盘，有了 SSD 没差那么远了，但是仍旧很大。比如硬盘的连续读写和随机读写，比如硬盘，内存和网络。

现在的问题是，卡马克的某个优化很牛逼，某个图形算法里面乘除 2 用位运算（不管是图形算法啦，系统库里面多了去了），这些都没错。

但是人家也不是每句话，都要把乘除 2 改为位运算的。计算机发展的早期，确实有很多这么干的，但是慢慢的都认识到了，有些优化要做，某些最好不做，最好不早做。