iOS动态部署方案

前言

 

这里讨论的动态部署方案，就是指经过不发版的方式，将新的内容、新的业务流程部署进已发布的App。由于苹果的审核周期比较长，并且苹果的限制比较多，业界在这里也没有特别多的手段来达到动态部署方案的目的。这篇文章主要的目的就是给你们列举一下目前业界作动态部署的手段，以及其对应的优缺点。而后给出一套我比较倾向于使用的方案。

其实单纯就动态部署方案来说，没什么太多花头能够说的，就是H五、Lua、JS、OC/Swift这几门基本技术的各类组合排列。写到后面以为，动态部署方案实际上是很是好的用于讲解某些架构模式的背景。通常咱们经验总结下来的架构模式包括但不限于：

 

1. Layered Architecture
2. Event-Driven Architecture
3. Microkernel Architecture
4. Microservices Architecture
5. Space-Based Architecture

 

我在开篇里面提到的MVC等方案跟这篇文章中要提到的架构模式并非属于同一个维度的。比较容易混淆的就是容易把MVC这些方案跟Layered Architecture混淆，这个我在开篇这篇文章里面也作过了区分：MVC等方案比较侧重于数据流动方向的控制和数据流的管理。Layered Architecture更加侧重于各分层之间的功能划分和模块协做。

另外，上述五种架构模式在Software Architecture Patterns这本书里有很是详细的介绍，整本书才45页，个把小时就看完了，很是值得看和思考。本文后半篇涉及的架构模式是以上架构模式的其中两种：Microkernel Architecture和Microservices Architecture。

最后，文末还给出了其余一些关于架构模式的我以为还不错的PPT和论文，里面对架构模式的分类和总结也比较多样，跟Software Architecture Patterns的总结也有些许不同的地方，能够博采众长。

Web App

 

实现方案

 

其实所谓的web app，就是经过手机上的浏览器进行访问的H5页面。这个H5页面是针对移动场景特别优化的，好比UI交互等。

优势

 

1. 无需走苹果流程，全部苹果流程带来的成本都能避免，包括审核周期、证书成本等。
2. 版本更新跟网页同样，随时生效。
3. 不须要Native App工程师的参与，并且市面上已经有不少针对这种场景的框架。

缺点

 

1. 因为每一页都须要从服务器下载，所以web app重度依赖网络环境。
2. 一样的UI效果使用web app来实现的话，流畅度不如Native，比较影响用户体验。
3. 本地持久化的部分很难作好，绕过本地持久化的部分的办法就是提供帐户体系，对应帐户的持久化数据所有存在服务端。
4. 即时响应方案、远程通知实现方案、移动端传感器的使用方案复杂，维护难度大。
5. 安全问题，H5页面等因而全部东西都暴露给了用户，若是对安全要求比较高的，不少额外的安全机制都须要在服务端实现。

总结

web app通常是创业初期会重点考虑的方案，由于迭代很是快，并且创业初期的主要目标是须要验证模式的正确性，并不在于提供很是好的用户体验，只须要完成闭环便可。早年facebook曾经尝试过这种方案，最后由于用户体验的问题而宣布放弃。因此这个方案只能做为过渡方案，或者当App不可用时，做为降级方案使用。

Hybrid App

 

经过市面上各类Hybrid框架，来作H5和Native的混合应用，或者经过JS Bridge来作到H5和Native之间的数据互通。

优势

 

1. 除了要承担苹果流程致使的成本之外，具有全部web app的优点
2. 可以访问本地数据、设备传感器等

缺点

 

1. 跟web app同样存在过分依赖网络环境的问题
2. 用户体验也很难作到很好
3. 安全性问题依旧存在
4. 大规模的数据交互很难实现，例如图片在本地处理后，将图片传递给H5

总结

Hybrid方案更加适合跟本地资源交互不是不少，而后主要之内容展现为主的App。在天猫App中，大量地采用了JS Bridge的方式来让H5跟Native作交互，由于天猫App是一个之内容展现为主的App，且营销活动多，周期短，比较适合Hybrid。

React-Native

 

严格来讲，React-Native应当放到Hybrid那一节去讲，单独拎出来的缘由是Facebook自从放出React-Native以后，业界讨论得很是激烈。天猫的鬼道也作了很是多的关于React-Native的分享。

React-Native这个框架比较特殊，它展现View的方式依然是Native的View，而后也是能够经过URL的方式来动态生成View。并且，React-Native也提供了一个Bridge通道来作Javascript和Objective-C之间的交流，仍是很贴心的。

然而研究了一下发现有一个比较坑的地方在于，解析JS要生成View时所须要的View，是要本地可以提供的。举个例子，好比你要有一个特定的Mapview，而且要响应对应的delegate方法，在React-Native的环境下，你须要先在Native提供这个Mapview，而且本身实现这些delegate方法，在实现完方法以后经过Bridge把数据回传给JS端，而后从新渲染。

在这种状况下咱们就能发现，其实React-Native在使用View的时候，这些View是要通过本地定制的，而且将相关方法经过RCT_EXPORT_METHOD暴露给js，js端才能正常使用。在我看来，这里在必定程度上限制了动态部署时的灵活性，好比咱们须要在某个点击事件中展现一个动画或者一个全新的view，因为本地没有实现这个事件或没有这个view，React-Native就显得捉襟见肘。

优势

 

1. 响应速度很快，只比Native慢一点，比webview快不少。
2. 可以作到必定程度上的动态部署

缺点

 

1. 组装页面的元素须要Native提供支持，必定程度上限制了动态部署的灵活性。

总结

 

因为React-Native框架中，由于View的展现和View的事件响应分属于不一样的端，展现部分的描述在JS端，响应事件的监听和描述都在Native端，经过Native转发给JS端。因此，从作动态部署的角度上讲，React-Native只能动态部署新View，不能动态部署新View对应的事件。固然，React-Native自己提供了不少基础组件，然而这个问题仍然仍是会限制动态部署的灵活性。由于咱们在动态部署的时候，大部分状况下是但愿View和事件响应一块儿改变的。

另一个问题就在于，View的原型须要从Native中取，这个问题相较于上面一个问题却是显得不那么严重，只是之后某个页面须要添加某个复杂的view的时候，须要从现有的组件中拼装罢了。

因此，React-Native事实上解决的是如何不使用Objc/Swift来写iOS App的View的问题，对于如何经过不发版来给已发版的App更新功能这样的问题，帮助有限。