移动互联网时代的应用几乎面临着和桌面应用一样的问题，不跨平台、版本收敛慢、无法及时修复线上问题、需求迭代缓慢等。但移动应用还不能完全转成Web应用，当前的解决办法就是建设App动态化体系，本文就梳理了一下App动态化体系涉及的诸多系统。
背景
我们知道电脑应用经历了桌面应用到web应用的发展历程，摩尔定律的不断得到验证，让web的劣势逐渐被弥补，优势不断增强，大部分应用也从桌面应用转为了web应用。
桌面应用有哪些缺点呢？
- 不跨平台
- 版本收敛慢
- 缺陷修复不及时
- 需求迭代不敏捷
桌面应用又有哪些优点呢？
- 体验好
- 能力强
随着电脑性能提升，浏览器发展和网速提升，web应用已经能满足绝大部分人的需求了。web应用在保证体验的同时完美的弥补了桌面应用的缺点，因而得以在电脑端大放异彩。经历了1.0，2.0的发展，web已经走入寻常百姓家。
其中最重要的是，web的三大核心能力，html,css,javascript都是有完善的标准，只要实现了标准的平台都可以完美运行web应用。
现在互联网已经走进了移动互联网时代，可以发现，移动互联网时代的应用几乎面临着和桌面应用一样的问题，但移动应用还不能完全转成Web应用，解决的办法就是构建App动态化体系。当然这些体系不一定只用于动态化，但他们一定是动态化不可缺少的。
App动态化体系
现在绝大部分移动App都强依赖平台特性，大浪淘沙之后最主要的平台包括iOS和Android。可是这两个平台的差异性如此之大，甚至UED都需要针对两个平台做分别的设计。
移动App还没有发展到完全使用web应用的阶段，因此针对移动应用的劣势，需要建立一整套动态化体系来弥补这些缺陷。完整的动态化体系是一套多层次，全方位的动态化解决方案，搭建一个完整的动态化体系，也绝非一日之功。本文尝试梳理App中可能需要用到的动态化技术。
资源管理系统
动态化即意味着需要动态下发资源，各式各样的资源。将资源下发做成统一的系统，即可以方便管理，也可以节省资源。App动态化体系中的很多其他系统都需要依赖资源管理系统。
关键指标
- 更新率。影响更新率的因素比较多，比如资源大小、资源下发方式、更新策略等等。一般来说资源管理都需要有版本控制、增量下发能力等等。
- 安全性。资源下发后一般都需要验签通过之后才能使用，不能让资源动态下发成为黑客攻击App的手段。
- 可扩展性。资源的种类多种多样，通用资源管理在设计的时候需要尽可能的考虑资源的多样性，新资源接入的成本越低越好。
配置系统
App依赖很多配置信息来定制化功能，比如常见的开关、动态文案都是配置系统的一部分。App可以通过预埋需求实现，结合配置系统来实现App的动态变化。
关键指标
- 性能。几个版本迭代之后，配置系统中的配置项就会变得非常多，这个时候配置就可能会影响App的启动，内存占用等等，如何高效的更新配置、尽可能降低配置对App性能的影响是配置系统需要解决的。
- 及时性。如何保障配置的及时准确达到是衡量配置系统的重要指标。
- 可扩展性。配置除了简单的布尔值外，还可能有复杂的json串，如何更好的管理配置，提升配置的可扩展性也是非常重要的。
补丁系统
应用的稳定性对于用户是非常重要的，尤其是金融，服务类应用，关键时刻不能掉链子。能动态修复线上问题，是动态化体系最基本也是最重要的能力。针对移动App缺陷修复不及时的缺点，一般App都会搭建补丁系统来弥补。
业界开源的补丁方案很多，在iOS平台有wax，jspatch等，在Android平台有hotfix，tinker等，一般还需要搭建自己的补丁发布平台来实现补丁的下发。
关键指标
- 能力。能修复的线上问题越多越好，覆盖的系统版本越多越好，代码、资源都能修复才是王道。
- 修复率。影响修复率的因素很多，除了补丁大小、补丁生效时机以及补丁下发策略等等。
- 及时性。补丁当然是越快触达用户越好，这里主要是补丁发布系统最好能具备定向拉和推的能力，以备不时之需。
- 性能。补丁系统一般都会在一定程度上影响性能，如何降低对原有App的性能影响是补丁系统的重要考量。
- 易用性。线上问题没有不紧急的，自然是能越快修复越好。补丁系统的易用性主要体现在两个方面，一个是补丁代码的编写，出于系统的限制，iOS的补丁一般需要动态语言来编写，比如lua、js，相比于Android的Java编写，自然要麻烦很多，另外一个就是补丁发布平台是不是设计合理，如何以最快的速度打出正确的patch包并发布是补丁发布平台需要慎重考虑的。
灰度系统
动态化体系缺不了灰度能力 ，灰度能力是动态化体系的基础设施，不可或缺。灰度系统的几大重要能力包括：1.选择灰度范围的能力 2.扩大灰度范围的能力 3.回滚的能力。灰度范围简单的说就是一个白名单，如何决定白名单是需要根据业务调整的，这意味着灰度系统需要有足够的能力各种各样的白名单。灰度系统一般都不是单独存在的，可以将灰度系统拆成两部分，灰度能力和白名单系统。灰度能力需要嵌到各个系统中去，让各个系统根据自己的需要实现，而白名单系统一般是可以单独搭建的，让各个系统共用一个白名单系统有助于各个动态系统互相配合使用。
关键指标
- 能力。白名单、扩大灰度、回滚能力都最基本的要求，其他特殊能力依照不同的业务会有不一样。
AB系统
AB系统又称A/B Test系统，是敏捷开发的必备能力。使用线上数据对若干需求进行灰度测试，进而得出需求是否能满足用户需求结论，这对于需求迭代来说的确是最科学的方式，能有效防止拍脑袋导致的用户投诉。AB系统相比于灰度系统最大的不同在于，AB系统关注的指标和灰度系统不一样。灰度系统考虑更多的是系统的稳定性，新版本会不会导致线上问题，而AB系统一般要关注的都是业务指标，比如A需求和B需求相比较，哪个引导用户购买的效果更好此类的。因此AB系统的关键指标和灰度系统有所不同。
关键指标
- 公平性。因为是多个需求之间相互比较，如何创造公平公正的环境是AB系统首先要考虑的。这主要涉及的是如何方便快速的选择合理的灰度范围。
- 易用性。每次AB测试之前都要确定指标，而每个AB测试的指标一般都不会是一样的，如何能够方便的创建指标对比也是衡量一个AB系统是否优秀的重要标准。真正优秀的AB系统应该能做到全程都不需要开发的介入，PD能通过AB系统独自完成AB测试的创建、上线和数据对比。这可不是一个容易的事情。
运营系统
运营对于应用来说是非常重要的，如何快速花式的支持运营需求对于提升应用的日活很关键。构建这样一套平台也是不容易的，常用的运营方式有banner，弹窗，信息流等，完善的运营平台需要能够统计曝光，点击，乃至转化等，为运营活动提供数据支撑。运营系统可繁可简，简单如首页弹个广告，也有复杂如淘宝等重度依赖运营的App会有一整套非常复杂的运营系统。
关键指标
- 能力。一个合格的运营系统首先要具备能满足App运营需求的能力，比如是否能在特定的页面，或者特定的场景出现banner或者弹窗。这个能力重要的是未雨绸缪，在运营需要之前就具备这样的能力，因此设计运营系统的时候要尽量通用。
- 及时性。一般运营活动对时间都有严格的要求，什么时候开始，什么时候结束都需要非常精确。不准时的运营活动小则招致用户投诉，大则引起公关危机就不好了。
- 数据分析能力。运营是有拉新、提升日活等目的，如果没有数据分析能力，就无从衡量运营活动的效果了。
Hybrid架构
Web可以说是动态化的终极方案，Hybrid架构就是App基于系统自带的WebView增加了调用Native、离线包等能力。Hybrid的技术要点很多，并非一言两语能够覆盖完全的。业界对Hybrid的研究已经比较深入，有很多的技术文章可以参考。
从现在的App技术架构来看，Hybrid几乎是每一个App都不可或缺的，web的动态性对于App的动态化来说太重要了，而且相比于Native开发来说，web开发的效率要高不少。为App搭建一整套完善的Hybrid架构绝对是物有所值的。
关键指标
- 性能。h5相比于native最大的缺陷就是体验了，因此这方面是各大公司投入最大的部分，为了提升h5的性能都是不遗余力的。秒开率、帧率、内存占用、白屏时间等等都是非常重要的性能指标。
- 能力。h5因为收到虚拟机的限制，能调用的native能力基本没有，业界通过给h5提供jsapi来扩展h5的能力，jsapi越多，h5就越牛逼。
RN/Weex架构
现在ReactNative、Weex等因为能在保留web优秀能力的同时，还能弥补web在体验上的一些缺陷，在很多App中都得到了应用。虽然React Native/Weex想要替代Web还是不太可能的，但是在某些特定的场合充分发挥React Native/Weex的能力，能在保证体验的情况下，极大的提升App的动态性。举个例子来说，在App中列表无疑是最常用的组件，非常多的需求都会展现在列表中。纯Native的列表性能好，但是不灵活，每次需求迭代都需要发版，客户端和服务端都历史包袱沉重。纯Web的列表是够灵活，但是Web长列表性能实在是不敢恭维，尤其是在Android低端机，渣的不要不要的。这种场景下，ReactNative和Weex这类技术就能发挥它的长处，它能基于Native的列表搭建动态列表，既保证了动态性，又具备灵活性。例子中举的这个例子一般被叫做卡片系统。
RN/Weex架构和Hybrid架构的关键指标基本是一致的，一般来说也都还配有资源管理系统。也就是说Hybrid架构和RN/Weex架构可以共用很多基础设施。
关键指标
- 性能。既然对标的是web，当然秒开率、帧率、内存占用、白屏时间等等都是非常重要的性能指标，必须要能全面秒杀web，要不然有什么存在的意义呢？
- 能力。RN、Weex等因为技术的限制，很多时候没有web方便，而且兼容性也常常是个头疼的问题，而且也常常需要根据需求扩展native的能力，这都是衡量架构是否优秀的因素。
总结
没有一个App的动态化体系是一样的，都需要根据业务情况调整。上述整理的系统每一个想要做完善都是要下功夫的。当然动态化体系远远不止这些，抛砖引玉，欢迎大家各抒己见。
参考文献
