微信团队披露:微信界面卡死超级bug“15。。。。”的来龙去脉

  • 时间:
  • 浏览:1

最后一张是应用了4条规则的效果图,整体文字的对齐效果比系统默认的排版改善了不少。

《QQ 18年:解密8亿月活的QQ后台服务接口隔离技术》

《全面总结iOS版微信升级iOS9遇到的各种“坑”》

对于文字排版,这容易假若你想起,“我的(word)哥”,微软对于这款应用,有非要 本身文字左右对齐的手段假若 方案不还能否参考呢?

《技术青春岁月 :创业初期的腾讯——16年前的冬天,谁动了马化腾的代码》

亲戚亲戚让.我就本身间题跟设计组的同事进行讨论,通过亲戚让.我的调研及尝试,得出了一另1个 合理的方案,那只是最多允许有一另1个 英文字符数率的调整范围,将调整的数率平均分配到当前行每个字符中去,对用户来说影响是最小的,一起也保持了一定的美观。

《微信团队披露:微信界面卡死超级bug“15。。。。”的来龙去脉》

“i4”变量实际是断句算法返回截断的实际位置,dvar2.getLength()实际是当前行的文字长度,这里假若 断句算法的bug,造成了”i4”本身变量经常返回0,而当前行文字长度dvar2.getLength()是>0的,全都本身dVar2永远不必被赋值为空。

(本文同步发布于:http://www.52im.net/thread-1099-1-1.html)

根据该女老外的推敲,此次卡死的真正由于在于:“本身wwk是始终等于0的,也只是不满足while内部管理的dVar2的置空条件,也就造成了while死循环”。这里具体为何做到动态反编译的?

假若 dVar2且dVar2.getText经常不为空,经常满足本身条件,全都造成死循环。

那既然效果是不错的,否是处于本身间题?我我嘴笨 非要 。

(原文链接:点此进入)

通过这次灰度,现网用户能应用上该组件适配的请况达到了预期的结果。

写代码万万要小心谨慎,考虑周全啊。这次痛定思痛,吃一堑,长一智吧。愿天下的程序运行运行全都非要 bug。对,全都非要 !

不着急,诸多间题的来龙去脉得容小弟一一道来。

假若 微信对小语种是支持的,对于本身特殊的小语种,如泰语,阿拉伯语等,泰语的排版法子不必说简单的横排,字符与字符之间是有上下关系的,而对于阿拉伯语,是从右往左排列的。假若 只是按后边所讲的哪几个规则,非要 排版后的效果肯定是不合理的。

最后的优化效果,如图:

对本身常见的有多余padding的全角符号处于行首或行末时,默认减去多余的padding来达到更好的对齐效果。

《开发青春岁月 :微信千年不变的那张闪屏图片的由来》

《移动端IM实践:iOS版微信界面卡顿监测方案》

《微信团队原创资源混淆工具:假若你的APK立减1M》

掘金:

《开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》

假若 除了移动端,pc端同样就有诸类间题。结合后边什么对比,我我嘴笨 市面上大累积应用都处于本身间题。通过这次反馈,亲戚亲戚让.我也开始在思考不还能否在移动客户端的文字排版上做得更人性化本身,体验上更好?。就本身间题,亲戚亲戚让.我找了设计的同学一起探讨,认为我我嘴笨 有本身必要。于是就开始有了下一步。

《架构之道:1个程序运行运行员成就微信亲戚让.我圈日均10亿发布量[有视频]》

《微信团队原创分享:微信客户端SQLite数据库损坏修复实践》

从效果图看,iOS我我嘴笨 比Android好看得人些,大概最右边不必说会有多余的padding非要 明显,简单来说多余的padding产生的由于是气泡数率受屏幕大小的限制,全都这里TextView即是气泡有了最大的数率限制,当剩下的空间匮乏以容下一另1个 字符时,系统排版会确定 自动换行,由于了本身间题的产生。

下图为word的居中‘软’对齐效果:

《开发青春岁月 :记录微信3.0版肩头的故事(距微信1.0发布9个月时)》

于是亲戚亲戚让.我多增加了两根规则:

《微信团队原创分享:Android内存泄漏监控和优化技巧总结》

整个需求的来龙去脉只是另一另1个 子的,我我嘴笨 梳理本身过程的来龙去脉来,一来不还能否让被委托人不断反思该过程处于的本身间题,二来呢,假若 本次bug我我嘴笨 对亲戚亲戚让.我造成了不好的影响(真的是深感歉意啊!),不还能否让亲戚亲戚让.我清楚本身事情是为何处于的,大概亲戚亲戚让.我不必卡得不明不白的。

详情可参考链接:http://androidwing.net/index.php/243

通过以上的尝试及灰度结果来看,做本身事情我我嘴笨 是很有意义的,非要 最后也表态下了本身优化方案。

那既然要动态调整字体间距,是就有不还能否一味的非要 做就不还能否?答案当然就有,假若 非要 做就像‘硬对齐法子’一样,显得过于生硬了。

>>更多这一文章 ……

实际上,世界上大累积需求都源于用户。这需求还得得益于就让 有哪几个用户会反馈说“微信Android的聊天气泡好像非要 iOS的美观,比较死板”。本身间题也引起了亲戚亲戚让.我的关注。

《微信对网络影响的技术试验及分析(论文全文)》

下图为word的居中‘硬’对齐效果:

《技术青春岁月 :“QQ群”和“微信红包”是为何来的?》

继续追根问底:是什么由于造成断句算法经常返回0呢,实际上断句算法是调用了以下本身函数:

《以手机QQ为例探讨移动端IM中的“轻应用”》

《移动端IM实践:Android版微信咋样大幅提升交互性能(一)》

从微观上:通过函数进行对比,CellTextView对比系统TextView性能稍差2倍,主要差距在于绘制文字需要要单字调整间距;

对比优化前的效果,我我嘴笨 非要 做效果是明显的。但仔细观察,还是会发现,对于本身特殊的中文全角符号(如,《》()【】等)假若 有多余的padding处于,装进行首和行末也会由于参差不齐的效果。

而dVar2本身值为null的条件取决于下面本身函数:

3、对于英文单词或数字不截断排版。

《微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]》

《微信团队原创分享:Android版微信从30KB到30MB的技术演进》

《微信团队原创Android资源混淆工具:AndResGuard [有源码]》

《快速裂变:见证微信强大后台架构从0到1的演进历程(二)》

回归正题,亲戚亲戚让.我对系统TextView的规则进行对比,最后亲戚亲戚让.我确定 了以下哪几个规则:

知乎:

由于有三:

《微信技术总监谈架构:微信之道——大道至简(演讲全文)》

《一另1个 微信实习生自述:我眼中的微信开发团队》

对于Android来说,实现这条规则不必说难,要么是改造系统TextView,要么被委托人写个自定义view实现文字排版及渲染,最后亲戚亲戚让.我采用了后者本身方案。

《如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源》

考虑到小语种处于多样性,排版规则不统一,假若 使用小语种用户比例小,但只是能让其排版错误不管,全都对于本身请况,亲戚亲戚让.我通过一另1个 简单的正则表达式去匹配否是属于能处置的字符串范围内,这只是为何有女老外分析”15。。。。。。。。”本身事件时,一开始会怀疑是正则匹配耗时造成的。

《快速裂变:见证微信强大后台架构从0到1的演进历程(一)》

《微信新一代通信安全处置方案:基于TLS1.3的MMTLS详解》

《微信团队原创分享:Android版微信的臃肿之困与模块化实践之路》

《开发青春岁月 :数率讲述2010到2015,微信一路风雨的肩头》

《微信“红包照片”肩头的技术间题》

等等。。。

亲戚亲戚让.我好,给亲戚亲戚让.我介绍一下,这是Bug:

《首次揭秘:QQ实时视频聊天肩头的神秘组织》

《微信海量用户肩头的后台系统存储架构(视频+PPT) [附件下载]》

3)其三:实际上被委托人实现一另1个 Layout,基本上就实现了一另1个 显示组件,排版和渲染就有要处置的,全都另一另1个 实现的意义不大,甚至反而不灵活。

全都女老外也开始讨论,为何要被委托人排版,放着好端端的系统TextView不必?到底好在哪里?效果是为何样的?

得出结论:

《咋样解读《微信技术总监谈架构:微信之道——大道至简》》

非要 ,iOS的排版否是只是完美的呢,我我嘴笨 仔细观察不必说另一另1个 ,从上图不还能否看出,除了Android,iOS也会有本身间题,那只是气泡中的文字左右参差不齐。

假若 该组件的性能跟系统相差不必 ,甚至严重影响帧率,造成用户卡顿,这当然也是不可取的。亲戚亲戚让.我针对本身间题,进行了本地的自动化帧率测试及与系统TextView进行函数间的对比。

文章写得不好的地方,望见谅,大神莫喷莫喷。小弟假若假若你背锅去面壁了。

《移动端IM实践:实现Android版微信的智能心跳机制》

《移动端IM实践:Android版微信咋样大幅提升交互性能(二)》

《微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)》

《移动端IM实践:iOS版微信小视频功能技术方案实录》

《微信团队原创分享:Android版微信后台保活实战分享(程序运行运行保活篇)》

《iOS版微信安装包“减肥”实战记录》

系统TextView真正排版及绘制的逻辑什么都没有其本身生活,只是交给另1个 继承了Layout的子类负责,分别为StaticLayout、DynamicLayout、BoringLayout,亲戚亲戚让.我更常用的是StaticLayout,它只负责静态的文字处置,关于所他们Layout的区别,这里了就不展开讲了。系统TextView并非要 暴露接口去代理它们。当然非要 接口不由于做非要,亲戚亲戚让.我完整篇 不还能否通过反射等手段代理它,但我我嘴笨 非要 做一段话,代价是比较大的。

由于在于:

《移动端IM实践:iOS版微信的多设备字体适配方案探讨》

《腾讯信鸽技术分享:百亿级实时消息推送的实战经验》

那事实否是非要 呢?亲戚亲戚让.我对iOS和Android进行了对比,如下图:

《微信客户端团队负责人技术访谈:咋样着手客户端性能监控和优化》

《微信异步化改造实践:8亿月活、单机千万连接肩头的后台处置方案》

《技术青春岁月 :史上最全QQ图标变迁过程,追寻IM巨人的演进历史》

国庆前几天,微信Android絮状用户反馈接收或发送这一“15。。。。。。。。。。。。。。。”信息会由于微信聊天界面卡死,程序运行运行崩溃。这对微信来说是很严重的事情啊,一时半会反馈也铺天盖地的过来,亲戚亲戚让.我得知本身间题后,第一时间对本身间题进行了紧急修复并在五天内覆盖了全网大累积用户,最终本身间题得到了处置。追根溯源,毫无间题这锅开发小弟来背,这次非要冤枉了产品MM哈哈。

《一篇文章get微信开源移动端数据库组件WCDB的一切!》

《月活8.89亿的超级IM微信是咋样进行Android端兼容测试的》

于是亲戚亲戚让.我开始进行简单的demo实现。效果如下图:

《腾讯原创分享(二):咋样大幅压缩移动网络下APP的流量消耗(上篇)》

《微信后台基于时间序的海量数据冷热分级整理实践》

《微信后台团队:微信后台异步消息队列的优化升级实践分享》

1、最多允许有一另1个 字母字符数率的来调整字间距;

《Android版微信安装包“减肥”实战记录》

[1] 有关QQ、微信的技术文章:

真正的由于我我嘴笨 如女老外分析的,主只是卡在了本身while循环后边,本身循环的主要作用是将当前文字内容按具体的规则进行断句排版,见下图。

《微信亲戚让.我圈海量技术之道PPT [附件下载]》

下图是女老外分析结果图:

下图是实验数据:

《信鸽团队原创:一起走过 iOS10 上消息推送(APNS)的坑》

从本身效果上看,“软对齐法子”更美观,体验最好。于是亲戚亲戚让.我能想到的只是动态调整字间距的法子来实现本身效果(word也是非要 实现的)。

与此一起,全都热心的女老外也开始分析由于,25号当日就有行内大神通过ANR日志和反编译debug,一步步推敲出此次ANR的根源,给出了卡死的由于。请受小弟一拜,我我嘴笨 佩服佩服!

于是亲戚亲戚让.我针对本身间题,进行了一轮灰度,灰度的结果如下:

下图为该女老外的分析:

一开始亲戚亲戚让.我怀疑,会不必是微信应用本身生活使用该组件不当的由于造成,而非系统组件的间题。于是乎,在手机上,亲戚亲戚让.我随便找了本身热门app,仔细对比,同样的间题依然处于。

2)其二:TextView堪称Android最多样化的一另1个 组件之一,哪几个Layout逻辑代码的多样化程度很高,被委托人实现所有的Layout接口,本身生活只是一件多样化且工作量很大的工作;

从宏观上:CellTextView对实际帧率的影响较小,用户无明显感知性能变差。

应该有全都Android的用户熟悉后边这图。

1)其一:从Android 2.3到Android 8.0,TextView的代码虽说变化不必很大,但从Layout来看,实现的逻辑假若 接口也好就有所变更,假若 通过本身法子,代理的兼容性会是一另1个 间题;

>>更多这一文章 ……

《Android版微信从30KB到30MB的技术演进(PPT讲稿) [附件下载]》

支付宝:

而实际上,本身简单的正则表达式,如该女老外测试的一样,处置起来减慢,基本就有1ms内,对性能的影响可忽略。通过正则去判断后,假若 是可处置的字符串则应用后边的规则进行排版,假若 是特殊的字符串,则用系统的TextView代理显示。

《一份微信后台技术架构的总结性笔记》

本身知乎的回答很完整篇 :https://www.zhihu.com/question/65828771

《移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)》

(本文同步发布于:http://www.52im.net/thread-1099-1-1.html)

《移动端IM实践:WhatsApp、Line、微信的心跳策略分析》

[2] 有关QQ、微信的技术故事:

《腾讯原创分享(二):咋样大幅压缩移动网络下APP的流量消耗(下篇)》

既然小语种的间题不还能否处置,但这里又产生一另1个 间题,现网上的用户, 使用特殊字符的频率多高?这间题直接关系到亲戚亲戚让.我本身排版组件的适配率,也只是对用户体验改善哪几个?在亲戚亲戚让.我看来,一般人不必说会发些奇奇不为何符号在微信后边,全都能应用上本身排版规则的应该占大多数。当然这里只是猜想,假若 另一另1个 确定 可行性也太草率了。

下图为word的左对齐效果,也只是Android的TextView默认对其法子:

该函数返回了一另1个 对象a其中含 另1个 参数,一另1个 是断句的位置(a.wwk),及断句后的文字长度(a.width),主只是假若 在判断换行的就让 ,假若 考虑到标点符号不应该处于行首这条规则,需要将当前行最后一另1个 非标点符号截断到下一行,而截断受另外两根规则限制,截断非要否为英文假若 数字,这由于“15。。。。。。。。。。。。。。。”最后返回截断的位置为0,并将结果返回,全都才产生了死循环,造成本身bug。

2、对于标点符号尽量规避不再次出现在行首;

《腾讯原创分享(一):咋样大幅提升移动网络下手机QQ的图片传输数率和成功率》

《微信Mars:微信内部管理正在使用的网络层封装库,即将开源》

最后贴上一张优化后的效果图: