V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
EagleB
V2EX  ›  程序员

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

  •  
  •   EagleB · 2016-11-27 18:49:43 +08:00 · 8552 次点击
    这是一个创建于 2954 天前的主题,其中的信息可能已经有所发展或是发生改变。

    先贴上源码地址: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_MonthweekfonttabHeights_width


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

    第 1 条附言  ·  2016-11-27 23:44:50 +08:00
    上边有些地方表达不当,让大家误会了。 sorry
    63 条回复    2016-11-28 20:56:42 +08:00
    Lonely
        1
    Lonely  
       2016-11-27 19:05:05 +08:00 via iPhone   ❤️ 1
    你是说那个整天讲鸡汤的那个胖子吗
    missdeer
        2
    missdeer  
       2016-11-27 19:27:35 +08:00 via Android
    求闰年的算法好像错了
    acoder2013
        3
    acoder2013  
       2016-11-27 19:27:43 +08:00   ❤️ 1
    tiny fool 是小笨蛋?
    EagleB
        4
    EagleB  
    OP
       2016-11-27 19:28:25 +08:00
    @Lonely 嗯,是
    Nexvar
        5
    Nexvar  
       2016-11-27 19:46:26 +08:00 via Android   ❤️ 2
    技术圈有点小知名度的,有干货的还是不多
    zonghua
        6
    zonghua  
       2016-11-27 19:49:34 +08:00
    @Nexvar 有个小女友的那位?
    miao1007
        7
    miao1007  
       2016-11-27 20:03:56 +08:00 via Android   ❤️ 1
    买了那本书,感觉鸡汤感太浓
    tinyfool
        8
    tinyfool  
       2016-11-27 20:05:36 +08:00
    之前其实 V2EX 吐槽这个控件的人还蛮多。不过我很久不怎么上 V2EX ,甚至有时候搜索东西的时候,偶然发现自己被长篇大论的批判了一番都不知道,所以也都没回应。当然,之前包括吐槽这个插件的人,也都是一句话说写得烂,我也不知道该咋回应,所以,看到了也只好由他去了。

    既然你这么认真的写,我就聊两句。

    我写过一篇文章,其实提到过这个插件的前因后果,楼主包括其他人也都说我经常提到这个插件。没错,提过很多次,我好像没有说过这个东西有多牛逼。我只是说,在那个时候,大概是 IOS SDK 发布了几个月以后,没有啥日历插件可用,我就做了一个。

    刚有 SDK 的时候,我其实并没有 iOS 设备,虽然很喜欢,但是确实买不起 iPhone ,很多人可能也记得当年 iPhone 其实也并不好买,那时候国内还没有行货呢。我的一个朋友的公司的活动上,抽奖,偏向我让我得到了一个 iPod touch 。我就想写个东西,写啥呢,就想写个记账软件,毕竟月月月光,也希望可以存点钱。设计的思路是首页有个日历,来显示最近一个月啥时候有收支。所以,就需要一个日历控件,当时并没有。就大概花了一个晚上做了一个吧。现在找不到原始的代码库, Google Code 的代码库好像也看不了修改历史了。细节我记得不了,反正这就是一个晚上或者几个晚上搞出来的东西,我那时候的主业是做搜索,基于 lucene 。

    后来,做了两个星期,也就是学 iOS 两个星期后,有个大概样子了。这时候有道词典的人,通过新浪的一个朋友,找到了霍炬,辗转找到了我。他们当时想迅速做一个 iOS 版本占领市场,当时好像金山已经发了版本。但是有道那边,没有有 Mac/iOS 经历的工程师。于是我就答应帮他们做。

    然后,做了一个月上线。我自己的记账软件就搁置了,一直到了 2013 年,我在上海的时候,才想起来,有这么一个搁置了多年的软件,找我的 CTO 补了个结尾,修改了一点 UI ,就上架了。以前有文章写过这个故事。

    这个代码,我没记错的话,就是闰年有个 bug 改过一次,发布过就没改过了。
    watzds
        9
    watzds  
       2016-11-27 20:14:05 +08:00 via Android
    😮
    tinyfool
        10
    tinyfool  
       2016-11-27 20:16:06 +08:00
    好,说说代码风格。

    我代码风格一般。写这个代码的时候,我日常写三种语言, Java , Php 和 OC 。代码风格混合,混乱肯定是有的。这个锅我的,我背。总体上是准备走 Apple 风格的,某些部分懒得改了,估计就比较乱了。

    const 是常量,不是变量,不过这里确实比较没有怎么考虑。一开始是没准备开源的,做完了就直接开了。这锅也是我的。

    getDayCountOfaMonth 的实现我没看出来锅在哪里。

    movePrevMonth ,本来就是一个简单的功能,没啥太复杂的思考。

    dealloc 的问题,你可能不知道,在早期 SDK 的时候, bug 比较多,我们要实验各种方法避免内存泄漏,有些写法比较诡异,但是在某个版本下,反而效果是好的。到了今天 SDK 也还是会出现一些问题。

    这个东西开源完了以后的大概 2-3 年,很火,每天都有邮件来咨询各种问题,最早版本,甚至没有 demo 代码和事例。后来问的人多了,就加上了(在项目说明里面,不过 google code 已经把这些部分都吃掉了,维护过 google code 项目的人应该知道)。

    后来,系统提供了一个什么方法我记不得了,而且开源的日历比较多,而且都比这个好看,这个慢慢就无人问津了吧。

    最搞笑的是,曾经有个人想把这个东西汉化(操,不知道用什么词好,本地化?)成老挝语,还是柬埔寨语来着,但是代码不是完全看得懂,还写了长篇大论来问我。

    不过,我好像从来没有说过这个日历有多牛,这个日历甚至都没有任何的图片资源,一切都是用字符和画线的方式画的。我的所有描述大概应该都是,在最早的时候, iOS 程序员连日历控件都没有,我需要用的时候怎么办呢?那就自己写一个吧。
    pasturn
        11
    pasturn  
       2016-11-27 20:26:15 +08:00 via iPhone
    @tinyfool 该用国际化这个词
    tinyfool
        12
    tinyfool  
       2016-11-27 20:28:46 +08:00
    @pasturn 只加了某一国而已,而且当时也没有国际化的基础,代码都是写死的,他也想直接换,但是不会
    FrankFang128
        13
    FrankFang128  
       2016-11-27 20:31:50 +08:00   ❤️ 1
    你这样发帖好么……
    谁不知道 Code Review 的体验:

    EagleB
        14
    EagleB  
    OP
       2016-11-27 20:46:23 +08:00
    @tinyfool getDayCountOfaMonth :我认为在查表的方式好一点;
    getDayCountOfaMonth : if/else 花括号,不是啥问题,个人喜好吧
    EagleB
        15
    EagleB  
    OP
       2016-11-27 20:53:17 +08:00
    @FrankFang128 没事想跟前辈学下,就随便看看。
    tinyfool
        16
    tinyfool  
       2016-11-27 20:57:27 +08:00
    @EagleB

    我觉得你看问题太浮于表面了,这个代码不是不能挑问题,问题很多。

    问题是,去挑 1 个 500 行,在 iOS 包括苹果官方,大多数编码规则还在形成期的代码的风格问题,唉。

    在那个时间阶段,比较像现在 Swift ,每次升级 iOS SDK ,里面项目模版的写法都会变的一塌糊涂,连苹果的风格都没稳定下来。

    关注些更有意义的事情,和更有意义的人吧。

    如果你能看到,有道词典 iOS 版第一版的代码,估计你也会觉得很烂。

    没错,确实不怎么样,可惜我都找不到了,否则说不定我也可以开源出来(有道同意的话)。不过它的意义在于,让有道至少早了几个月到半年,发版本。对有道的开发者也是一个对 iOS 开发祛魅的过程,原来这么简单就行,这么烂的代码也可以上线,而且下载量这么凶猛,哈哈。
    tinyfool
        17
    tinyfool  
       2016-11-27 21:03:50 +08:00
    我一直懒得开源,我们实现的 iBookAuthor 解析器和 Cocoa touch Android 版,不过回头等我懒癌结束了,欢迎你们去看你,不过请不要揪着代码风格。看看内容,看看具体实现,看看架构,那两个东西蛮好玩的。

    前者还好。后者光把环境搭起来,编译好全部的依赖可能就需要一个小时。

    要是真有天我们开了,欢迎去研究研究。


    另外,我最近扒了一个 Google 的库,改造成了 Cocoa 的接口,拖延症不加剧的话,也许 1-2 个月会开源,到时候有兴趣可以看看。
    EagleB
        18
    EagleB  
    OP
       2016-11-27 21:08:59 +08:00
    @tinyfool 嗯,我没有别的意思,只想学习一下。 08 年 10 月, iOS 才发布一年多,苹果风格不稳定,这个问题没考虑到。
    tinyfool
        19
    tinyfool  
       2016-11-27 21:14:03 +08:00
    July 11, 2008 iPhone OS 2.0 Final 发布,同时才有的 App Store 。
    Allianzcortex
        20
    Allianzcortex  
       2016-11-27 21:19:12 +08:00
    @missdeer ?(能被 4 整除且不能被 100 整除)或(能被 400 整除)
    acros
        21
    acros  
       2016-11-27 21:23:17 +08:00 via iPhone
    角度不太对。
    评价软件应该看他优点多突出,对于净挑毛病的,应该没几个人有底气....
    l0wkey
        22
    l0wkey  
       2016-11-27 21:27:46 +08:00
    想起了 Dash 的 iOS 版
    missdeer
        23
    missdeer  
       2016-11-27 22:58:58 +08:00
    @Allianzcortex 手机上只看到 date.year % 4==0 这一截。。。电脑上看到完整的没问题
    kevinreadonly
        24
    kevinreadonly  
       2016-11-27 23:02:00 +08:00
    @zonghua 恩,那个有钱的死胖子 2333333
    xcodebuild
        25
    xcodebuild  
       2016-11-27 23:29:07 +08:00 via Android   ❤️ 3
    大家都看得出来你什么意思,即使你不停的说『没有别的意思』。
    Sirormy
        26
    Sirormy  
       2016-11-28 00:42:46 +08:00 via Android
    找上门来不好意思说了,哈哈哈哈哈
    onlyhot
        27
    onlyhot  
       2016-11-28 00:51:25 +08:00 via iPhone
    气氛有点怪
    crisfun
        28
    crisfun  
       2016-11-28 03:07:52 +08:00 via iPhone
    若要补刀应该让我们见识下什么是经常提
    daniellu
        29
    daniellu  
       2016-11-28 08:16:55 +08:00
    无可厚非啊,肯开源,就已经很了不起了。
    挑毛病,谁不会,从头到尾的起一个控件、写好、开源啊,再说, ios 刚发布的那时候,国内连资料都很少,更加别说开源控件了。
    有时间翻翻自己 N 年前写的代码呗,每个人都是在不停的成长的,对不对?
    juice
        30
    juice  
       2016-11-28 09:07:30 +08:00
    @tinyfool 该续费了
    tommyzhang
        31
    tommyzhang  
       2016-11-28 09:17:05 +08:00   ❤️ 2
    code review 别人几年前的代码 然后说 low 相信楼主不是傻逼 就是二百五脑袋被驴提过了
    LedChang
        32
    LedChang  
       2016-11-28 09:21:36 +08:00
    我觉得楼主说的没毛病
    LedChang
        33
    LedChang  
       2016-11-28 09:22:37 +08:00
    不知道你们在喷什么,看看当时的代码指出来有问题怎么了,谁不是一点点成长起来的
    tinyfool
        34
    tinyfool  
       2016-11-28 09:40:00 +08:00   ❤️ 2
    真的不是不能批评,不过,我觉得,做性能优化,我经验比楼主多多了,我就在多少两句吧。关于,那个不用查表,用 Switch-Case 的问题。

    这么说话都是半瓶子咣当,性能优化不是教条,不是说,老师说这么写对的就这么写。性能优化是一个一直在变的东西,唯一可以相信的是 profile 。

    第一,不要过早优化。
    第二,这是一个有限条件选择,不涉及到问题增长速度。
    第三,编译器如果觉得这里值得优化成一个 table 会动手的。
    第四,性能优化,要理解一个代码调用频度场景。这个函数会被调用几次呢?大概,只在日历初始化的时候,调用一次,翻页的时候,调用一次。翻一次页,人工都设置了一个动画, 0.5 秒,还是多少记不得了。然而,这里用 Switch-Case 还是查表性能差异可能对产品性能产生影响么?

    写代码的时候,第一优先是可读性。这个代码其实可读性也一般,因为说过了,基本上就是一晚上随手写的,后来也没改过。性能一定要在 profile 的前提下去做。我们的学校教育,教育出来一堆纸上谈兵的性能知识,很多还是错的。比如很多类似的技巧,在编译器优化前提下,根本不存在了。比如当年谭浩强的书里面给你讲了一堆,在某个编译器可能成成立,在另外一个编译器不能成立的技巧。

    我不是说,我这么说一定比查表好。而是,这不是你该关心的问题。如果 profile 说明这里是一个性能攸关点,你做各种尝试都是合理的。在这时候,我觉得想太多。跟讨论回有几个写法差不多。
    imsoso
        35
    imsoso  
       2016-11-28 09:51:26 +08:00
    好久没见到楼主活人了, mark 一记
    muziki
        36
    muziki  
       2016-11-28 09:57:08 +08:00 via iPhone
    Year & 3 == 0 && ( year % 25 != 0 || year & 15 == 0)
    判断闰年会快一些
    hotdogwc
        37
    hotdogwc  
       2016-11-28 09:58:15 +08:00
    虽然不爱被灌鸡汤,但是讲道理,刚才把代码看了一遍, SDK 发布几个月,资料各种缺失的情况下写出这个东西,我是服的。我觉得“没别的意思”的人应该想想在那个情景下是不是可以写的比这个好,反正我不能。
    greatghoul
        38
    greatghoul  
       2016-11-28 10:00:08 +08:00
    楼主你其实是嫉妒人家有个漂亮可爱的女朋友而已吧。。
    hotdogwc
        39
    hotdogwc  
       2016-11-28 10:00:49 +08:00
    @l0wkey Dash 代码我也草草的看了一遍,没看到什么槽点,难道我的代码洁癖严重不足?
    htfy96
        40
    htfy96  
       2016-11-28 10:02:35 +08:00 via Android
    为什么 getDayOfMonth 一定要查表,感觉这么写也挺清晰的
    jun0205
        41
    jun0205  
       2016-11-28 10:03:33 +08:00
    早期 iOS 开发和现在差别太大,那时候资料少,开源的更少,什么东西都得自己写。
    不像现在什么各种优秀的资源都有,没法比较。
    tinyfool
        42
    tinyfool  
       2016-11-28 10:13:47 +08:00   ❤️ 1
    @muziki 这个谁要写这个代码在我的项目里面,我要打不及格。

    第一,不见得快,这个可以跑一个测试,比如比较 100 万次,试试看,我估计不见得快,或者说不见得有显著的性能收益。
    第二,可读性下降。
    第三,什么场景需要快速计算闰年,全人类才走了几千年,枚举一边,用最慢的算法,也很快出结果。这么去追求效率得不偿失。
    tinyfool
        43
    tinyfool  
       2016-11-28 10:21:13 +08:00
    @juice 续啥费?
    alexsunxl
        44
    alexsunxl  
       2016-11-28 10:22:50 +08:00
    @LedChang 喷一喷代码其实没问题, 但总体上感觉楼主太针对人, 这就不太好了。
    所以 tiny 叔才不得不出来解释一通
    holyghost
        45
    holyghost  
       2016-11-28 10:24:22 +08:00
    & 3 比 % 4 快难道不是常识么

    我咋就这么瞧不上这些技术圈的网红呢,还有那个什么 justjavac
    wanttofly
        46
    wanttofly  
       2016-11-28 10:40:25 +08:00
    @LedChang “代码格式我就不说了,空格写的很随意,大小写对于我这种强迫症来说也很受不了。最重要的是我认为稍微参考下苹果 framework 中函数的命名方式,就不会写出协议中这么扯淡的命名。 interface 中的命名大多数都还不错,但是-(void)setDayFlag:(int)day flag:(int)flag;这个是什么鬼,我认为- (void)setFlag:(int)flag forDay:(int)day;更好。” 态度有问题,说啥都是白扯。内容没毛病,但是比如说可以小声的告诉“ hi ,你裤子好像有点问题”的情况下为什么要拿着喇叭打声的说“我靠,你的前开门没拉”呢
    tinyfool
        47
    tinyfool  
       2016-11-28 10:41:22 +08:00   ❤️ 1
    @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 寸低配,去年中期的配置。
    caiyouzai
        48
    caiyouzai  
       2016-11-28 10:47:09 +08:00
    小码农提一句,这种实际上现实中每天调用都不会超过 5000 次的接口,代码可读性,比那 0.0001 秒的优化有意义多了把
    tinyfool
        49
    tinyfool  
       2016-11-28 10:50:21 +08:00
    @caiyouzai 对的。我以前做搜索, 1 个 ms 都很重要。但是,不是每个代码的 1 个 ms 都要去揪。要找到核心代码,去压榨一点点性能改善,但是调用比较少的,对整体影响不大的,连看都不看。
    tinyfool
        50
    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 改为位运算的。计算机发展的早期,确实有很多这么干的,但是慢慢的都认识到了,有些优化要做,某些最好不做,最好不早做。
    tinyfool
        51
    tinyfool  
       2016-11-28 11:19:37 +08:00   ❤️ 1
    全文是 We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. 刚才少引用了最后一句。

    跟我之前做 Java 性能优化的体验一致,一个日撑 10 万次请求的服务,我优化到了 30 万,后来 300 万,后来 3000 万。其实没改多少代码,每一步的核心都是找当年的性能瓶颈在哪里。

    我们家 CTO 当年优化的一个 iOS 的地图点聚合问题,源代码是苹果 WWDC 的一个 Demo 代码,从全屏 5000 个点,聚合一次需要 22 秒,优化到了几十毫秒,他优化了 7-8 个不同的地方,但是优化的代码量并不大。核心还是找出关键问题。
    tommybiteme
        52
    tommybiteme  
       2016-11-28 12:03:30 +08:00
    @tinyfool tiny 大神好 6 啊
    sumstain77
        53
    sumstain77  
       2016-11-28 13:15:17 +08:00
    @zonghua
    ren2881971
        54
    ren2881971  
       2016-11-28 13:24:56 +08:00
    我觉得这是一个圈粉帖。。。
    holy_sin
        55
    holy_sin  
       2016-11-28 13:25:55 +08:00
    不要把时间花在指责上
    Jaylee
        56
    Jaylee  
       2016-11-28 14:10:11 +08:00   ❤️ 1
    @holyghost justjavac 就是一个 sb, 见一次骂一次
    timeship
        57
    timeship  
       2016-11-28 14:55:46 +08:00
    某位成功把话题转到了优化上
    tinyfool
        58
    tinyfool  
       2016-11-28 15:03:12 +08:00
    @timeship 嗯,成功转移了
    isaced
        59
    isaced  
       2016-11-28 15:17:53 +08:00   ❤️ 1
    “正在看这个贴,老大默默走到我的身后,一巴掌拍向我的脑袋说道:少说话,多做事!”
    tinyfool
        60
    tinyfool  
       2016-11-28 15:25:57 +08:00
    @isaced 嗯,这个代码才 500 行,目前这个帖子应该早就超过 500 行了吧
    fukual66
        61
    fukual66  
       2016-11-28 16:51:50 +08:00
    莫名想起了当年激动人心的演讲,我在现场,听得我瑟瑟发抖,找回当时评价的链接[地址]( https://www.zhihu.com/question/44019457)
    zengcool
        62
    zengcool  
       2016-11-28 20:11:37 +08:00
    我一直以为,敢于开源自己项目的人都是勇士。觉得 tinyfool 解释的那么清楚,算是非常认真负责了。我想想自己写过的代码,哎呀,让我死了算了。哈哈~
    sopato
        63
    sopato  
       2016-11-28 20:56:42 +08:00
    翻出多年前的代码来找刺,确实有点过分了哈~~~~~
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2821 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 14:25 · PVG 22:25 · LAX 06:25 · JFK 09:25
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.