2015年7月24-25日，作为中国***影响的移动领域技术大会——WOT2015移动互联网开发者大会在北京富力万丽酒店圆满落幕，这也是51CTO从2012年至今举办的第七届技术大会。大会以“洞察移动互联网用户行为 分享移动应用研发实践”为主题，共设立“架构与设计”、“平台与技术”、“MDSA创新与创业”、“移动游戏”、“算法分析”、“HTML5专场”、“运维安全”、“新浪微博技术”等八大技术专场，并垂直整合了技术和体验，深度服务于参会者与讲师。
会上，来自阿里的高级无线技术专家徐昭先生带来了关于《以小见大，见微知著 亿万级APP架构演进之路》的精彩演讲，并在会后接受了51CTO记者的采访。
徐昭于2012年加入天猫成为技术核心，前后带领过天猫卖家&导购详情等多支技术团队，亲身打造并见证双11成为电商行业的重要节日。现任手机淘宝卖家生态团队技术负责人，主要负责无线店铺、微淘、小铺、开放等卖家链路的技术架构及研发工作。目前专注在无线整体架构、大型复杂移动应用构建框架及无线技术开放等领域，同时关注新技术和开发模式在移动互联网产品中的演进和落地。
采访实录如下：
51CTO：首先非常感谢您作为讲师来参加本届WOT峰会，请您介绍一下阿里无线事业部这个部门以及您所负责的主要工作。
徐昭：阿里无线事业部目前是承载整个阿里集团无线技术基础架构以及以手机淘宝为代表的APP研发为主的一支技术团队，这支团队的主要使命主要有两个：一是，提供整个阿里集团无线化的基础设施以及技术服务能力；二是，在APP层面上我们以手机淘宝为核心构建整个大淘宝业务生态下的全新移动端业务平台，并进而打造新的移动业务开放生态体系。
51CTO：在您的演讲中主要是说亿万级APP架构的演进之路，在这个演进过程中，阿里是如何保证大规模研发体系的效率和质量的呢?
徐昭：这个过程也是逐步摸索和演进的过程。在早期阶段，团队规模相对较小，采用的是一个统一集成、整合迭代的研发模式。随着PC业务的整体迁移、更多业务团队无线化的参与以及整个研发人数和团队规模的扩大，我们逐渐遇到一些瓶颈。包括整个发布周期、研发效率，最终产出的APP和功能模块的质量标准、用户体验等方面。在这个过程中，我们通过不同路径的尝试，最终采取客户端组件化的架构模式。通过对客户端容器架构的改造和工程拆分，延伸到整个研发的配套工具、发布体系、监控平台等一整套完整的链路改造，最终支撑了大规模、分布式的研发模式。
51CTO：具体进行了哪些改造呢?
徐昭：在核心改造方面，首先将移动端上的业务模块和基础中间件归一化处理，基于端侧容器拆分成多个组件的模式。这个过程相当于把不同的业务和技术团队所负责开发的业务模块、基础技术模块进行拆分解耦。基于此，底层运行时容器能够统一加载并管理不同组件的生命周期，从而促使上层业务团队得以按照自身的节奏独立研发、测试、集成。并基于这个模式来进一步实现整个研发过程的高效迭代、动态部署、智能发布等创新成果。
51CTO：在您看来现在的无线架构和之前的PC架构存在哪些差异性?
徐昭：我们的总结和思考可以归纳为五个方面：
首先，在整个部署模式上存在差异。我们知道服务端传统的互联网B/S架构下，基本上整体研发方式上比较自由，能够做到随时开发、实时发布、灵活部署。在移动端，目前谷歌和苹果代表了两大核心的技术生态阵营，这两个阵营***的移动终端技术体系下，APP的发布模式是受限的，承载APP的终端呈现碎片化现象，研发模式在较大程度上也依赖于整个APP开发框架，这就意味着需要将业务功能组装成完整的APP，通过发布到对应生态的应用市场，来完成业务功能的发布和消费者触达。在这个体系里怎么样更好的执行类似于服务端体系时代的灵活发布和部署机制，怎么样能够实现在线问题、在线BUG、在线故障的动态修复和快速响应，在这个维度上如何综合利用native和web技术合理解决今天APP研发模式的效率和体验问题，这是***部分区别。
第二，整个移动终端的碎片化带来的挑战。安卓阵营更为典型，设备本身碎片化严重，不同的厂商、不同的生态可能对Android体系都有一定的定制改造。在这个体系里面我们怎么样能够更好的利用研发技术支撑更高的研发效率，同时保证我们的应用程序在多样化的终端设备上有相对稳定和一致的用户体验，以及确保应用多端适配的兼容性(包括native以及h5两个角度)。相对PC时代的浏览器兼容，适配是一个更富挑战和琐碎的工作。
第三，今天移动设备之所以是移动设备，本身跟PC传统的浏览器是大大不同的，在这个体系里怎么样更好地利用移动设备本身的一些硬件能力，怎么样提供原有的PC时代不具备的体验。
第四，更多是从质量体系考虑，因为今天用户在手持设备的场景下更关心的不仅仅是网页能不能打开，够不够快，同时也很关注手机是不是发热，流量是不是够低，本身这个应用是不是经常会Crash，他会关注这些外延维度的一些特性的质量，这些怎么样更好的监控和怎么样确保质量持续提升。
***，行为的差异。用户不再像原来PC时代一样，我们说PC时代的用户是上网的过程，需要坐在电脑前浏览冲浪，但今天在移动端每个用户的设备就代表背后的人，这个人本身是随时在线，随时可被触达的，今天这种场景下怎么更好地利用终端能力去形成新的交互体验。这几个维度是我们概括下来移动时代在架构、在整个技术体系里跟PC时代***的不同。#p#
51CTO：您刚刚提到在线的APP出现BUG需要进行处理，怎么样更好的在用户感觉不到的情况下处理这个BUG呢?或者是APP出现某个安全问题之类的，怎么做到用户无感知呢?
徐昭：这是很好的问题，在早期阶段技术很难去突破，因为移动端研发的特性和苹果、谷歌的操作系统以及它的APP框架限制，我们发现了问题以后必须要重新迭代修复问题以后，生成一个新的应用安装包，以用户下载和应用更新的方式，升级安装这个APP包以后才能修复问题，但是这个过程本身首先是没有办法保护用户体验(频繁的应用升级提醒)，同时没有保证用户的触达率和更新覆盖率，因为这是用户自己选择下载的过程，从流量考虑需要用户确认，很多情况下无法简单地系统主动去更新。第二，这个更新周期非常漫长。苹果的APP Store的整个审核过程是非常漫长的，所以这里有很多技术上和商业形态绝对的一些局限性。在这个过程中，我们尝试的方式是尽可能考虑如何能够通过动态化的方式去在运行期改变代码的逻辑，使得能够类似于微软Windows热补丁的方式，可以把补丁通过推送的方式，推送到终端的APP容器，形成一个增量的修复机制。在这个背景和技术方向的思考指引下，我们在安卓和iOS上分别实现了不同的动态加载机制。在安卓上，我们利用JAVA动态类加载器的机制，基于Android的DexClassLoader，实现运行时组件模块的动态热加载，具体实现可以参考github社区阿里开源项目Dexposed。在iOS有其他一些类似的方案在做这个事情，但机制上和JAVA稍有不同。
51CTO：APP在更新迭代时可能会增加一些新代码，或者是以前功能不用了对应的代码没有删除，这时候出现了APP的臃肿。阿里是怎么为APP消肿呢?怎么能回到您所提到的APP时代的敏捷呢?
徐昭：这里是两个问题，***个问题是怎么样实现增量的推送，第二是怎么保证APP的瘦身效果，其实这两个问题并不冲突。我们认为***个问题里动态推送这个事情上也是分两个不同场景，***是今天有两个新的功能模块上线，原来的版本的APP没有这个模块，这个模式我们叫做动态部署，这里的场景其实是APP本身新加一个功能模块推送到客户端上去。另外的场景可能是替换老的功能模块，这两种场景都存在。可能会导致应用最终的在线包会发生一些变化，但这是正常的过程。每次迭代APP新的版本出来，其新增或变更功能都会导致包容量大小的变化。刚才说的另一种热补丁模式其实更适用在问题代码修复的场景，因为我们热补丁只是针对有问题的代码进行替换，不是新增或改动功能。所以这部分的代码量本身也控制的很小，所以我们会把补丁和动态部署两个场景分开来看，虽然底层的技术会有一些共性。
关于瘦身的问题，目前来说这里不完全是技术上的因素决定的，因为本身可能跟业务增长有关。我们今天需要新增业务模块，需要新增技术中间件，需要新增用户体验的创新功能，比如说虚拟化VR的一些场景功能。这里不可避免会引入一些新的代码和资源进来。在这个角度上我们在策略上跟业务结合，一方面看今天在代码的复用度上，怎么样尽可能的去复用代码模块，比如说不同的业务功能模块，设备基础能力、端侧公共API等沉降在中间件的层面上，尽量在底层复用这些能力。另一方面，如果需要新增的情况下我们会经过严格的审核，本身这个功能是否是最合理的，一方面在业务上能够带来效果，另一方面在技术上它的包大小是否控制到***的限制，我们会有一个栅栏集成体系，在整个持续集成的过程中对整体包大小做严格的管控。我们也综合考虑今天作为这么大量级的业务平台，业务与功能模块非常多，这个体系不可避免有很多功能模块无法一次性完全集成为一体化的应用安装包。一方面部分非核心或者对用户体验要求没有那么高的功能，可能我们会用H5页面的方式去支撑，减少包的大小。另外一个策略可能在一些产品下有一些原生的功能，比如在虚拟试装的过程当中需要加载一些动画库，需要加载一些动态的模型和数据，这个过程中我们会基于动态下载的机制，通知用户是否需要使用这个功能，然后自己选择是否下载，将选择权交给用户。这是几种模式和手段的结合。
51CTO：移动电子商务用户常利用手机在碎片时间完成即兴的浏览、比价、社会化推荐、收藏、快速购买，比如上班路上、下班路上、看电视、躺在床上、入睡前。那么阿里是如何解决***在线问题，并保证碎片化使用，从而实现用户随时随地的无线购物?
徐昭：用户的行为确实是非常有趣的现象。在无线化之后，手机淘宝的用户量，增长超过了PC之后用户行为比较大的变化，你会发现用户行为的确是非常碎片化的。以前用户在网购的场景下的访问时段、访问时长非常固定，可能到天猫、淘宝一逛就是十几到几十分钟。但是，在移动端上，用户行为是变成一天来多次，每次可能只是3到4分钟，所以这是一个非常有意思的变化。今天，移动互联网的特性决定了用户就是随时在线的，移动终端和移动互联网本身的便利性决定了这样的行为习惯，我们更多是技术上确保服务可用和体验***。
我们考虑的更多是如何利用这些不同的场景，感知到用户在不同场景和不同时段下使用的一些诉求，能够如何更好的提供更多的内容，更适应场景化的内容和服务，去提高用户逛的效率，保证更好的用户体验。在这个层次上我们也结合了很多移动端特有技术进行了尝试，包括我们的地理围栏系统，包括个性化的推荐和场景的选择，这里面会综合结合多个维度，依托云端数据分析和客户端用户状态反馈，尝试做到给用户推送的内容会发生相应的合理变化。
51CTO：你们是怎么感知到用户是在坐车，或者是在上班，亦或是在家呢?
徐昭：这个技术上可以结合多种手段实现。包括基于大数据进行综合的分析考虑。一方面我们会结合端上的一些特性和传感器的功能，比如手持设备上的陀螺仪功能，访问的时段特性，以及本身带有的GPS定位信息等等综合分析。在这里面我们在技术上会做大量创新和优化，例如定位更多是一个被动定位的模式。我们会构建一个地理围栏的概念，基于特定信号源节点围出一个特定区域出来，只有用户触发这些区域边界的时候我们会进行一个被动的感知，确定用户所处位置场景等，同时也确保他的隐私信息不会被滥用时此外这个过程当中我们会严格控制用户设备的功耗，而不是始终开着GPS不断更新和扫描他的位置，这里面会结合商用场景和用户体验、用户隐私各个综合的维度去看。类似在家里或者上班等具体场景化的分析，我们更多考虑可以基于大数据进一步结合，从云端再去进行发掘，用户行为所处不同的时段以及日期可能本身已经反映其通常所处的环境，这里面可以有相应的模型计算、算法对比以及多个维度叠加判断的过程，所以这是一个场景化数据化的技术体系。
51CTO：您在无线客户端框架设计及研发当中曾经遇到***的困境是什么，您是如何解决的呢?
徐昭：不同的阶段应该困境会不一样，可能在前期阶段我们整体上的很大问题在于研发模式。如何能够尽可能的提升效率，如何将大规模研发团队从职能上合理划分，在研发模式上能够支撑到不同的业务团队之间有不同的迭代速度、不同的迭代控制力，能够更高效更快速的响应业务需求。展望未来，新的挑战依然是前面说的移动架构和PC架构维度的差异性。在这五个差异性里我们未来集中需要重点解决的一些问题和挑战在于，***，如何能够让我们的业务更快适应用户需求的变化，端上体验和交互形态更动态。如何能够利用更小的屏幕实现***的投放效率，例如基于不同地域的用户、不同场景的用户真正“千人千面”，能够更灵活地去实现UI到内容整体的动态和变化。第二是今天怎么样能够解决网络层本身的效率、稳定、复用等问题，包括到整个无线通讯协议层的更深度优化和体验提升。第三是在整个APP的开发框架层面上怎么样更好的支撑多端并行的模式，包括在业务团队层面，怎么样能够保障不同技术能力、不同经验背景的人员，能够基于同一个框架产出更统一、更标准的质量和用户体验。***，我们在质量体系里面怎么样更好更早的发现和预警线上的问题，更迅速地响应用户反馈的BUG或者问题等等。这些都是更深层次的挑战。
51CTO：您认为未来的移动生态架构是怎么样的?未来阿里无线有哪些什么计划?
徐昭：我相信未来的移动生态一定是更加开放的生态。今天，WEB和Native技术在不断地融合演进中，新技术产生也不断推动业务和体验层面的循环创新。对阿里来说，在电商的业务和技术形态上我们希望能够进一步开放，包括我们很多在“云管端”架构体系下所做的工作，希望能够进一步开源、进一步分享给同行去复用。同时，我们也希望在整个移动技术演进的过程中，综合思考今天和未来的移动研发模式如何去演进，什么样的机制、框架、技术手段是最合理、最有价值的，我们相信未来一定是云管端架构体系下APP生态的繁荣。
