天猫网站内容架构分析(多Tab应用App使用中，第一个影响了用户使用欲望和整体评价)

　　天猫网站内容架构分析(多Tab应用App使用中，第一个影响了用户使用欲望和整体评价)

　　在多标签应用的使用中，首个实质性页面的渲染速度和操作体验极大地影响着用户的使用欲望和整体评价。对于电商应用来说，首页与产品推广和订单转化更直接相关。在所有页面中，首页的使用频率最高，停留时间最长。应用首页的最终优化和良好的布局是一项非常有利可图的任务。

　　作者从UI、代码等多个角度分析天猫iPhone App首页，一定程度上再现了编码逻辑。使用网络抓包、沙箱目录分析、揭示视图层次结构、dump头文件、IDA内存寻址、LLDB越狱联调等，对得到的信息进行简单的过滤整理，希望对童鞋们的应用开发或参考有所帮助。

　　一、架构级服务支持

　　1.图像缓存，完全托管的 SDWebImageCache。 SDWebImageCache在体验和性能上都做了很好的优化，长期开源维护。

　　2.HotFix 使用服务器发送 JSPatch 文件的方式，但不依赖 JSPatch 第三方库。 JSPatch 大约 1600 行 OC 和 90 行 JS 代码，提供了核心功能。

　　3.Hybrid，将H5全站预加载到沙箱中，使其可以快速从Nat​​ive切换到WebApp，并且可以在重大事件发生时实时监控维护界面而不崩溃。

　　4.营销支持，各个顶级Native View所在的VC，将WVWebView离屏（拟替代UCWebView）实例化，进行红包雨等营销活动。

　　5.数据本地持久化，符合Cache、Perference、Library、tmp、Document沙箱目录的特点。

　　二、数据源策略对用户体验的影响

　　首先基于这样一个前提：需要通过市场调研来改变首页的布局，并给出充分的理由；否则，首页的布局会在很长一段时间内略有或基本不变。

　　从这个前提出发，天安主播主页采用如下策略：1.用户在安装新应用时有预设数据；2.优先本地数据实例化UI组件和初步绘制；3.服务器数据到达后重绘； 4.完成一次服务端请求，下次打开时将修改后的布局文件持久化为最新的布局； 5.因为新布局可能在灰度测试中，新布局不一定存储在持久化存储位置（NCPersitentxxx），而是会存储在另一个位置（Preference），先使用。

　　首页的渲染减少了对服务器数据返回的必然依赖，是大多数热门应用的数据渲染选择。有几个好处： 1.增加了信息推荐的机会。用户即使在网络断开的情况下也可以浏览主页，或者至少浏览产品目录树。如果有图片缓存，可以获取更多信息； 2.优化界面渲染速度。在等待网络的过程中，可以完成所有对象的实例化和绘制（天猫首页此时不会重复使用实例化的对象或绘制。网络数据返回后，会重复实例化和绘制过程. 支持重用的属性）； 3.改善用户体验。无需在首页弹出中断交互的AlertController。事实上，大多数应用在断网时不会在首页弹出Alert或者只有一个空白页面。

　　根据这些情况，主要测试几个场景：1.全新安装，断网运行； 2.非全新安装，断网运行，不清除缓存； 3.非全新安装，断网清缓存； 4. 网络断开，其他页面网络恢复，页面切换回首页； 5. 运行正常。

　　场景1、3、天猫是一个空目录，但是可以查看目录树； 2有图片和目录； 1 是持久化布局，2 和 3 可能是新布局或持久化布局； 4 图片自动加载，需要手动刷新布局。

　　三、使用ScrollView实现一个lazilyScrollView必备

　　为了简洁，大部分app的首页使用tableView+采集View的主布局，但是这些都是重度控件，尤其是采集View。从这个考虑，需要降低视图层级，实现一个lazilyScrollView，这也是天猫首页的选择。

　　以及如何实现，使其可以在tableView这样的新屏幕中复用，并释放到屏幕之外，还有很多事情需要设计和考虑。而lazilyScrollView是天猫首页UI实现的精髓。

　　我希望在不久的将来忠实地复制它。但是很多属性的使用和很多方法的调用顺序还是需要猜测和汇编验证的。加油！