简单逆向天猫的思考

    多Tab应用App使用中，第一个实质页面的呈现速度和操做体验，极大影响了用户使用欲望和总体评价。对于电商App而言，首页更直接关联商品推介和订单转化。全部页面中，首页使用频率最高，停留时间最长，极致优化良好布局App首页是收益极高的任务。
    笔者从UI和代码等多切点分析天猫iPhone App首页，在必定程度内复现编码逻辑 。使用了网络抓包、沙盒目录分析、reveal 视图层次、dump类头文件、IDA内存寻址、LLDB越狱联调等方式，将得到信息简单筛选梳理，但愿能对应用开发的童鞋有稍许帮助或者参考意义。

1、架构级服务支持
    1.图片缓存，全权托管SDWebImageCache。SDWebImageCache在体验和性能上都有很好的优化，并获得长期开源维护。
    2.HotFix，使用了服务器下发JSPatch文件的方式，但不依赖JSPatch三方库。JSPatch大约1600行OC和90行JS代码，提供了核心功能。
    3.Hybrid，预加载H5全站至沙盒，从而能快速从Native切换至WebApp，在重大活动时能够实时监控和维护界面而不至Crash。
    4.营销支持，每一个顶级Native View所在VC，均在屏幕外实例化WVWebView(计划替换UCWebView中)，以执行相似红包雨等营销活动。
    5.数据本地持久化，切合Cache、Perference、Library、tmp、Document各沙盒目录特性。

2、数据源策略对用户体验的影响
    先以这样一个前提条件为基础：首页的布局变更须要通过市场调研，给出充足理由；不然在很长一段时间内，首页的布局都是轻微或者基本不变化的。
     从这个前提出发，天锚首页采用了这样的策略：1.用户新安装App时有预置数据；2.优先本地数据实例化UI组件和初步绘制；3.服务器数据到达后从新绘制；4.完成一次服务器请求，变更的布局文件被持久化，以供下次打开时用最新布局；5.因为新布局可能在灰度测试中，新布局不必定存放至持久化存储位置(NCPersitentxxx)，但会存到至另一处(Preference)并优先使用。
    
    首页的绘制下降对服务器数据返回的必然依赖，是目前大部分流行App的数据绘制选择。有这样几个好处：1.增长信息推介机会。用户在断网状况下也能浏览主页，至少能浏览商品目录树，若有图片缓存可获更多信息； 2.优化界面呈现速度。等待网络过程当中，能够完成全部对象的实例化与绘制(天猫首页并无重用此时实例化的对象或绘制，在网络数据返回后，将重复一遍实例化和绘制过程。但各实例有canReuse属性以支持重用)；3.提升用户体验。不须要在首页弹出交互打断的AlertController，实际上大部分App断网时不会在首页弹出Alert或只有空白页。

    根据这些状况主要测试几个场景：1. 新安装，断网运行 ;  2.非新安装，断网运行，未清理Cache；3.非新安装，断网运行，已清理Cache；  4. 断网运行，其它页面网络恢复，切回首页；5.正常运行。
    场景一、3，天猫为空目录，但能看目录树；2有图片和目录；1为持久化布局，2和3多是新布局，也多是持久化布局；4图片自动加载，布局需手动刷新。

3、用ScrollView来实现一个lazilyScrollView的必要
    大部分APP的首页为了简便起见，使用了tableView+collectionView的主要布局，然而这都是很重的控件，尤为是collectionView。若是从这个考虑，减小视层图级出发，实现一个lazilyScrollView是有必要的，也是天猫首页的选择。
    
    而如何实现，使得更tableView同样有新入屏重用，出屏释放，须要设计和考虑的东西仍是不少的。而lazilyScrollView正是天猫首页UI实现的精髓所在。
    但愿能在近期内忠实的复现，然而不少属性的用途，众多方法的调用顺序，仍是须要猜想和汇编验证的，加油！