好久没时间写了，被业务推着走是多么可怕的事情，没有时间静下来沉淀。最喜欢过年前后这段时间，终于有时间安安静静地写代码、做自己想做的事情。
近2年被大前端的浪潮冲击中，原生app开发何去何从呢？这就要从app发展至今的一个发展史说起了。
技术上：原生->嵌入h5->Hybrid->(Lua、RN、Weex)->小程序
形式上：简单应用->复杂应用（服务分布式、app：模块化、组件化）->平台型app->生态型app
构架上
简单型app：MVC->MVCS->MVCS+基础工具库（一个git仓库）
复杂型app：pod+模块化方案+中间件等(n个git仓库，私有库，业务库等等)不细展开，细说又是长篇大论了。
平台型app：在复杂型app的基础上扩展，开发一系列的工具来支撑，如管理业务组件工具，打包工具等让其平台化，适合多团队并行开发。业务模块边境约束等。
生态型app：是未来的趋势，未来会有更多超大型app的诞生。也是我们现在需要探索之路。现在流行的载体是小程序，也许后面会有更多的解决方案，但是这只是技术上的解决方案。不影响app的趋势。
对从微信小程序火起来后各大公司都开发自己的小程序，让自己的app成为小程序平台，连接更多外部应用。在我看来小程序平台不止是连接外部应用，如果用在大型app设计也是个不错的选择。设想公司有多条垂直业务线，每个业务线的迭代互不影响，如果每个子业务线都是一个个独立的小程序，那在公司平台app上加一个入口就完美解决了。为此我还特意破解了几大平台app，发现支付宝和淘宝都有用小程序来开发子业务。
这些子业务有些是h5有些是小程序，整体来说小程序的体验要比h5要好。生态型app是趋势，一个app发展到最后不可能还是单一功能，所以要想构架好一个大型app已经不在是模块化组件化就能够解决的事情。小程序平台开发是原生app开发的最终去向，让自己的app像微信一样承载各种各样的小程序在上面运行。每个业务线的miniapp要长成什么样各个业务线自己决定，他们的迭代周期发布周期自己控制，互不影响。
生态型app还有一个很明显的优势，子业务的发布不需要提交应用市场的审核，用户安装也是无感知。如果把它用于企业内部子业务的话，试想整个小程序的发布和规则都是企业内部自己制定的，那一个个子业务的动态发布岂不是都很顺利的进行着。生态型App区别与传统的App，除自身提供的功能外（比如微信的IM功能），更多的功能可以由三方的团队自行完成。除了ToC的超级应用外，也特别适合多团队、跨地域、多供应商的大中型企业使用。生态型App一般提供了一共生的生存环境（运行环境）以及相同的约束（规范和API等），允许不同的团队或个人，在允许的情况下，自行的研发或相同或者不同的移动相关的功能。相关功能运行在一个进程里，相互间独立，且与同在的环境有一定的交互。
关于如何设计和构架生态型app还在进一步研究中，这里分享一篇不错的文章，大家可以参考一些思路。生态型App的架构实践分享
