用户增长是一件个性化非常强的事情，淘宝在增长中执行的诸多策略或许拿到其他场景就完全没有效果。但另一方面，这些策略背后的思考路径和执行过程中总结的经验，是有参考意义的，有机会给读者在日常增长工作中带来一些提示。所以，本文不会出现太多实现细节，更多关注在策略制定背景和设计逻辑上。 所以本文从我们对用户分层的定义开始，重点分享淘宝过去一段时间在“拉新”和“召回”两个方面的思考和经验。

    相信读者已经看过很多大神们对GCD深入浅出的分析，这也是老生常谈的一个多线程的实现方式了，所以我也就不再啰嗦其理论。但是到底有多少方法是我们日常编程中常用的？又有多少是你不知道的？今天，我就来例举一些GCD的方法，绝对让你看一眼就会正确得使用。

    无疑Native的动态化能力较Web要弱很多，很多操作是依赖版本节奏的。这就导致在Native App上许多决策无法快速验证，对存在不足的逻辑没办法快速修正。受到这些条件的限制，那个唯快不破的铁律在Native App上遭遇到了尴尬。每一个产品决策会变得异常谨慎，因为一个错误的决策要持续整个版本周期可能被修复。慢慢的我们就会发现，不出错会成为做出决策的重要因素，而有意义却退居二线。 所以具备快速验证和及时修正这两个能力就显得非常重要，打造这样的能力需要一个完整的解决方案。我们认为，这个方案是一个以A/B测试为核心，结合周边多个系统能力，共同组成的一个试错平台。在这个平台上，我们的团队，不管是业务方还是工程师，都可以快速应变，不畏惧出错，变得灵动起来。

    如果用户在当前页面下载了应用，安装之后直接跳转到刚才浏览的界面，不仅可以将这一部分流量引回客户端，还可以让用户获得完整的用户体验。下面提出一种方案来满足这个业务需求。

    LazyScrollView 继承自ScrollView，目标是解决异构（与TableView的同构对比）滚动视图的复用回收问题。它可以支持跨View层的复用，用易用方式来生成一个高性能的滚动视图。此方案最先在天猫iOS客户端的首页落地。

    闭包的风险: 1、由于闭包会使得函数中的变量会被更长时间保存在内存中，消耗很大，所以不能滥用闭包，否则会造成网页的性能问题，在IE中更是可能导致内存泄露。解决方法是，在退出函数之前，将不使用的局部变量全部删除。 2、闭包会在父函数外部，改变父函数内部变量的值。所以，如果你把父函数当作对象（object）使用，把闭包当作它的公用方法（Public Method），把内部变量当作它的私有属性（private value），这时一定要小心，不要随便改变父函数内部变量的值。