淘宝拍照测试皮肤功能淘宝皮肤怎么设置在哪

淘宝皮肤怎么设置近几年无线端崛起，业务重点开始向无线终端偏移（目前不能叫偏移，基本以无线为主了），所以淘宝 PC 端首页的流量也有削减，不过即便如此，它的日均 PV 依然相当高。
淘宝首页一向是内部平台和技术的试验田，它一直在变化着。最新的框架和系统都会找淘宝首页试点，可以试想下，如果某一项需要推动的升级或者优化措施在淘宝首页已经上线，并且拿到了良好的数据和稳定性，其他业务还有什么理由不去尝试和更迭呢？同时，去年一年身在淘宝前端的技术架构组，自然而然也会主动去 push 一些实验性的内容到业务上。
淘系的站点页面包括首页、其他频道页和活动页等，这些页面并不都由淘宝前端一行一行的代码码出来，业务如此之多，这种玩法即便人数 double 也忙不过来。事实上，大多数页面都是依托内部的搭建平台一一运营或者前端通过模块搭建的方式一一构建的，而前端 focus 的重点在于搭建平台的建设自身以及模块的通用性和复用率的保障，当然，还有一些工程化的东西。
使用搭建平台搭建的页面，前端只需要考虑组成页面的原子模块的开发，整体的渲染由搭建平台提供的统一脚本全权负责。而在淘宝首页上，考虑到页面模块数量巨多，加上还有少量跨部门、跨团队的沟通，渲染模型略微不同。
2
淘宝首页的整体变迁
背景中提到，淘宝首页依托于内部搭建平台，它的变迁自然也是跟着搭建系统的变化而变化的。
1. PHP 下的淘宝首页
接手淘宝首页不久，便遇到了一年一度的改版，那时它还运行在 PHP 环境中。这里需要说明的是，淘宝首页的所有代码完全由前端掌控，前端不会直接跟数据库打交道，其数据来源分为两部分。
数据来源
一是运营填写的数据。采用前端挖坑的形式，预留坑位让运营获取填写数据，如（伪代码）：

文章插图
上面的代码会产生一份 PHP 的模板和info字段对应的表单坑位，这个过程简称“挖坑” 。

文章插图
运营填写这些坑位就会产生这份 PHP 模板对应的数据，最后渲染出来就是一个完整的 HTML 片段（实时性渲染）。

文章插图
旧版搭建系统中就是通过这种方式构造一个子模块。我描述得十分简单，但作为一个平台它需要考虑的东西还有很多很多的，比如数据顺序的控制、定时发布、回滚机制、过滤机制、筛选机制、数据的同步、数据的更新、版本控制、权限控制、其他系统的引用等。
二是后端或者个性化平台提供的数据。不同的业务有不同的诉求。一些业务有自己的后端，他们要求使用自己业务产出的数据；有的业务希望用户看到的内容不一样，千人千面，期望接入算法；一些业务跟卖家直接打交道，期望使用招商数据；而有些业务期望采用运营从数据池筛选出来的数据……总之，淘宝首页需要对接形形色色的系统，接口繁多。后面会提到对动态数据源的整合。
并且这些系统对应的域名是不一样的，JSONP 格式自然也就成了首选。但一些特殊的系统，比如广告，它的渲染并不是一个简单的 JSONP 请求，可能它还要干预整个广告的渲染流程，比如加载他们的 JS，把渲染的控制权交过去。
页面的架构
上面介绍了数据的来源和子模块的结构，那么整个页面又是如何构成的呢？模块的搭建分为两种，一种是可视化搭建，运营或者前端可以将开发好的模块（或者模块库中选取的模块）拖拽到容器内，形成一个页面。

文章插图
当然，上图也只是一个模型，作为一个系统需要考虑的问题还有很多很多，如页面的布局、多终端适配、模块的临时隐藏、位置调整、皮肤选择、模块的复制等。
也可以通过如下源码搭建的方式（伪代码）：

文章插图
通过模块 id 将模块引入，并且添加一些类似 lazyload 的标记，方便控制渲染节奏和数据入口。源码搭建和模块搭建的区别在于，前者更易于控制模块的结构以及模块的渲染顺序。
动态数据源
首页面对一大堆接口和平台，对接几十个业务方，接口是个很大的问题，由于后台系统的差异，基本没有办法统一数据源的格式，一旦运营哪天心血来潮要换一个他自己觉得用的更爽的或者数据更好的系统，前后端估计又得沟通和对接几次。所以出现了下面这张图：

淘宝拍照测试皮肤功能 淘宝皮肤怎么设置在哪

秒懂生活扩展阅读

淘宝拍照测试皮肤功能淘宝皮肤怎么设置在哪