一次iOS App优化(踩坑)之旅

微信上看到这一有趣的文章,贴出来和大家分享一下,原文链接如下:
一次iOS App优化(踩坑)之旅

未经深思熟虑的优化是bug之源,这句话做过深度优化的同学一定能明白其中的辛酸。今天和大家分享下博主一次优化CoreText的填坑经历。记得那时候,iPhone 4s还算市面上的主流机型。

优化起因

当时正在做一款IM App,产品经理觉得每次第一次进入聊天界面的时候有点慢,而且进入之后的第一次滑动有点卡。正是由于,导致了后面一系列的优化。在开始介绍优化方案之前,先说下「首次体验问题」。

首次体验问题

首次体验是个经典的场景,很多App都有类似的问题存在。它描述的是,App新进入一个场景,由于第一次必要的资源加载,逻辑运算等所带来的延迟,而导致的用户体验延迟。
比如大家Kill进程后重新打开微信,如果快速滑动会话列表,能感觉到明显的滑动动画卡顿,而且这种卡顿只会经历一次,再次往返滑动的时候又完全流畅了。大部分的耗时是因为头像文件的磁盘io读取,和圆角绘制。资源准备好加入cache后耗时就消失了,当然头像可以异步到子线程中去绘制,但是会导致用户能看到头像“由默认头像变为真实头像”的过程,体验稍差,显然微信采取了同步绘制的机制。
当然这并不是个大问题,现在的硬件足够快,功能场景也多,偶尔一秒以内的体验延迟完全可以忍受。
回到刚才产品经理所说的慢和卡,其实也是经典的首次体验问题。第一次进入聊天界面时有很多资源需要准备:

创建Controller及相关类

读取消息列表
渲染消息

通过Instrument Profile过后,发现当时App有相当一部分时间花费在了CoreText的渲染上。当时App的文本消息是使用CoreText绘制的,而CoreText整个绘制流程当中有一步占比最重:文本消息的高度宽度计算及超链接检测。
当时脑袋一拍,就有了方案,以空间换时间,把文字高宽度和超链接的信息都存入databae,这样下次启动的时候不用重新计算,所以就有了如下代码:

BOOL needDetectLink_calculateSize = false;
if (textMsg.textWidth == 0) {  
  needDetectLink_calculateSize = true;
}if (needDetectLink_calculateSize) {  
  textSize = [_Msg_Helper calcuteSizeOfAttributedMessageText:textMsg.attributedMsgString withFrame:textMsg.ctFrame lastLineWidth:&lastLineWidth];    textMsg.isDirty = true;
}else{    
textSize = CGSizeMake(textMsg.textWidth, textMsg.textHeight);}

计算完之后,再启动一个后台任务在子线程当中把计算好的信息(dirty message)存入database。优化好之后交给产品经理体验,产品经理发现确实比之前快了不少,很满意,皆大欢喜。
第一个坑:
原本优化任务开心结束了,直到一年多后测试同学突然拿着手机给我看了一条奇怪的消息:



最后一个字看起来被截掉了一小部分,一番调试之后,发现是之前缓存的文字宽度信息不对了,又花了几个小时调查为何宽度会不对,代码上看不出任何问题,而且有些文本消息展示没有问题,只有特定的消息才会出现,直到不小心瞥见手机系统的语言是日语,猛的想到会不会是这两种系统语言下中文字体不同,一调查果不其然。
先使用中文系统发送文本消息,再切换到日语系统就能大概率重现上述问题,虽然场景比较少,毕竟是个bug,还是修一修:

BOOL needDetectLink_calculateSize = false;
if (textMsg.textWidth == 0 || preSysLanguage != curSysLanguage) {   
 needDetectLink_calculateSize = true;
}

心想还是挺简单的,判断下渲染时的系统语言就可以了。

第二个坑:

又过了一年多,iOS 9发布,测试同学又过来给我看了如下画面:



我第一反应是不是换语言了,可是换语言的场景我处理过了,根据之前的思路很可能是换了字体,顺着思路一想,哦,原来是iOS 9系统换了中文字体。所以按常理我应该把代码改成这样:

BOOL needDetectLink_calculateSize = false;
if (textMsg.textWidth == 0 || preSysLanguage != curSysLanguage || preiOSVersion != curiOSVersion) {  
  needDetectLink_calculateSize = true;
}

这样总可以了,或者更保险一点,我判断前后两次渲染所用的字体是否一致。可连续两次的意外让我对这段代码产生了怀疑,最后抚摸着我手里丝滑顺畅硬件指数爆表的iPhone 5s,我想到了一个更好的方案。

最终方案:

我把优化关闭了。

不知道,大家看到这里,是什么赶脚,总之我是乐了。。。。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,189评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,577评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,857评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,703评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,705评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,620评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,995评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,656评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,898评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,639评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,720评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,395评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,982评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,953评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,195评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,907评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,472评论 2 342

推荐阅读更多精彩内容