简单逆向天猫的思考

Posted 2020-07-02 MittyoO

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

一、架构级服务支持
    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各沙盒目录特性。

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

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

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