Discuz!Q iOS版APP 首页UI处理耗时优化方案

Discuz Q 手机客户端还在开发中，目前3.0接口的第一个版本，基本属于收尾阶段，此文，仅为在App开发过程中遇到的一个问题和处理过程，写下来，作为备忘。（前期只顾着蒙眼狂奔，欠下不少坏账）
首先，首页的UI展示如图1，（抱歉，没找到图文混排图片）：
最定格的是几个置顶文章，之后就是正常的文章列表。目前移动端的展示逻辑是：
1、调用列表接口，拉取一页数据（pagesize = 20）
2、模型化返回数据，（json转为端上可使用的模型对象RootModel : X）
3、格式化数据（时间戳改为“x小时前,x天前,xx年xx月xx日”，以及一些其他适配端上UI展示的数据格式处理=> XFormatter）
4、布局对象计算（⚠️重点来了：根据上面生成的模型对象: XFormatter 生成对应的列表布局DZQStyle对象 ：style）
5、刷新界面，渲染UI到屏幕。（此时用户看到了内容）
目前遇到的问题是，这个【推荐】tab作为用户开屏看到的第一个页面，理想状态下，从网络请求开始到渲染UI结束，自然是耗时越短越好。但据目前测试发现，仅仅首页最定格的一条主题【我的3个月和我的1850个社区种子用户-上篇】的网络请求 + 本地布局计算的耗时就非常可怕：
针对上面 DZQStyle 对象生成的几个关键点，打点统计如下：
2021-12-04 21:08:28.350210+0800 迪斯卡斯[64260:2507883] WBS ===time==out= 001
2021-12-04 21:08:28.350469+0800 迪斯卡斯[64260:2507883] WBS ===time==out= 002耗时1：253982
2021-12-04 21:08:28.604451+0800 迪斯卡斯[64260:2507883] WBS ===time==media= 001
2021-12-04 21:08:28.604821+0800 迪斯卡斯[64260:2507883] WBS ===time==media= 002耗时2：7867
2021-12-04 21:08:28.612688+0800 迪斯卡斯[64260:2507883] WBS ===time==media= 003
2021-12-04 21:08:28.612971+0800 迪斯卡斯[64260:2507883] WBS ===time==media= 004
2021-12-04 21:08:28.613198+0800 迪斯卡斯[64260:2507883] WBS ===time==out= 003
2021-12-04 21:08:28.613441+0800 迪斯卡斯[64260:2507883] WBS ===time==out= 004耗时3：253
2021-12-04 21:08:28.613694+0800 迪斯卡斯[64260:2507883] WBS ===time==out= 005
总耗时：263484
自己粗略计算一下，可以明显看到 中间的耗时1、2、3，是自己计算的比较大的几个时机，需重点关注。
首屏整页的总耗时大约为5秒，想象一下，app启动打开，首页loading小菊花开始旋转，4秒多之后才可以看到内容，那该是一种怎样的崩溃体验。
不行，这种垃圾体验，太对不起我熬夜掉的头发！
开始分析：
1、耗时最大的 【耗时1】为253982，发生在主题内容的布局上，改文章正文大约4000字（见图2），但是我的首页，置顶主题不展示内容，非置顶主题，最多展示140个汉字（图片，影音等，不占用字符数）。3.0的接口在列表请求接口中就返回了文章的全部内容，这样在布局计算的时候，如果不加处理，势必造成时间上的浪费。
**改造方案：**list接口请求中无法直接限制返回，那么就在返回后，优先做好字符串截取（最大300字，考虑到会有其他占用字符的特殊对象，故大于140个字符做好预留）
2、【耗时3】为7867，该部分主要是生成正文html文本展示预排版对象DZHtml，该排版对象，最早是针对2.0接口的htmlContent字段做的，2.0的content是直接返回了html字符串，针对表情和图文信息做了预下载和排版计算处理，同时还有一部分针对表情包展示的Css字符串的查询替换。虽然在3.0接口中没有了图文预下载，但当字符串较大时，字符串的各种处理，也增加了较多的耗时。
**改造方案：**针对接口做版本判断，3.0的接口不再做Css的字符串检查，对于DZHtml内的Html字符串的校验和处理逻辑做适当的必要删减。
3、【耗时2】为253，该部分是为图片九宫格，影音，红包等附加内容做的布局计算，接口中并没有可以明确得知会有那些附加内容和数量，所以在布局中可能存在大量的冗余高度，间距计算以及多次的数据遍历判断，造成了一定的耗时
改造方案 ：考虑到该部分的布局方案计算比较固定，在布局中针对一些重复性较高且且固定的属性增加布局缓存，每次在计算前，优先使用缓存的内的值。
三项优化方案完成，打点耗时如下：
2021-12-04 21:34:45.449417+0800 迪斯卡斯[64549:2533216] WBS ===time==out= 001
2021-12-04 21:34:45.449652+0800 迪斯卡斯[64549:2533216] WBS ===time==out= 002耗时1：198
2021-12-04 21:34:45.449850+0800 迪斯卡斯[64549:2533216] WBS ===time==media= 001
2021-12-04 21:34:45.450090+0800 迪斯卡斯[64549:2533216] WBS ===time==media= 002耗时2：255
2021-12-04 21:34:45.450345+0800 迪斯卡斯[64549:2533216] WBS ===time==media= 003
2021-12-04 21:34:45.450574+0800 迪斯卡斯[64549:2533216] WBS ===time==media= 004
2021-12-04 21:34:45.450796+0800 迪斯卡斯[64549:2533216] WBS ===time==out= 003
2021-12-04 21:34:45.450988+0800 迪斯卡斯[64549:2533216] WBS ===time==out= 004耗时3：215
2021-12-04 21:34:45.451203+0800 迪斯卡斯[64549:2533216] WBS ===time==out= 005
总耗时：1786
整体收益：性能提升：（263484 - 1786）= 261698 ，当前耗时仅为原来耗时的 0.0067。测试了一下，虽然还没有做不到秒开，但收益是指数级的！
后期等数据库完成之后，考虑将整个首页做一次本地缓存和启动页的预加载，相信除了网络延迟，基本上可以做到秒来了！
最最最后的一句话是：3.0的主题列表接口，就将正文全部返回，官方有官方的考虑，但作为开发者，希望可以增加字段，可以选择部分返回（140字或者220字等等）。