随着小程序应用越来越广,我们需要更深度的了解这项技术,分享的第一篇,就从科普小程序容器开始吧!
“容器”一词来源于英文单词 Container ,翻译过来也是“集装箱”,那为什么要把容器比作集装箱呢?
首先,单从外形上来看,整整齐齐的集装箱不管是尺寸还是材质都是一样的(连我的强迫症都被治愈了),就像是工厂有一台大型机器,只需放入制造集装箱的原材料就能快速的批量生产完全一致的集装箱。
其次,集装箱的作用是对商家的货物进行打包隔离,一般会将不同商家的货物打包装到不同的集装箱内,这样不管是装载还是卸货都不容易混淆。
另外,集装箱还有一个更重要的功能:保护箱内的货物。不管海运过程中遇到强风暴雨还是烈日暴晒,我们对箱内的货物都能放心。
其实我们也希望容器能达到同样的效果,只要我们提供的原材料(镜像)一样,得到的结果(运行实例)都是一样的,并且还能实现打包隔离和轻松运输。
如果把容器类比成集装箱的话,可以很清晰的汇总容器的优势:“提供的原材料(镜像)一样,得到的结果(运行实例)一样”、“打包隔离”、“轻松运输” 等。
容器内运行的服务或服务对应的多个进程就应该是集装箱里对应的货物了,可以很自然地想到,容器的目的就是为进程集合提供一个独立的运行环境。
那我们具体应该怎么实现 “独立的运行环境” 呢?
2.1 文件系统隔离
2.2资源隔离
所以容器的本质就是一个视图隔离、资源可限制、独立文件系统的进程集合,它将系统的其他资源隔离开来,具有自己独立的资源视图。“视图隔离”,指的是能够看到部分进程、有独立的主机名,“资源可限制”,指的是可以限制内存大小、CPU 使用个数等。
在国内,时代的搅局者非小程序莫属。
随着微信、支付宝、百度、抖音等小程序平台的推出,小程序生态获得空前的成功,那有没有一种可能,小程序生态和容器相结合,形成小程序容器呢?
小程序容器顾名思义,是一个承载小程序的运行环境,可主动干预并进行功能扩展,达到丰富能力、优化性能、提升体验的目的。
可能大家也会想,H5也能实现为啥非要搞小程序,如果用小程序和我们更常接触和使用的“H5 移动应用”与“移动原生应用”作比较,我们会发现小程序的又具有非常明显的几大优势。
总而言之小程序容器可以帮助开发者快速优化发布包大小,节省流量和存储。同时,App 服务迭代不再受发版限制,快速发布,快速迭代。甚至,基于统一的开发标准,小程序仅需开发一次,便可快速投放至多端。
因为语法的规范性和兼容性,在开发工作中只需要开发一次小程序,就能在不同的应用打开,天然解决跨端痛点。同时,通过IDE工具调试适配后可将小程序投放至例如微信、阿里、百度、字节等开放平台,连接各大流量平台,触及海量用户,满足多端引流的需求。
对于例如金融、社交、电商等复杂的业务本身会有频繁迭代的需求,其实较好的方式是将这部分业务剥离改造为小程序,继而通过上下架的形式到 App 中,可以做到热更新,不再需要等待主版发版和频繁的提交App Store审核,满足复杂业务多变的场景。
对于有生态建设的企业来说,同样可以通过小程序上下架形式引入第三方商户,在 App 内打造一个自有轻应用集散中心(应用商店),快速覆盖衣食住行、办公协同等各类高频小程序场景,像微信、支付宝一样形成自己的开放生态平台。
小程序容器很好,很多公司也都是内部在自研,不过仅限于有实力的公司,研发出来也是自己内部在用。例如,腾讯、阿里、字节、百度等大厂都有自己的小程序平台,但他们几乎也都是仅限于内部使用。
更普遍的现实是更多的公司想用但没这个实力搞,如果确实需要一个小程序容器该用怎样的正确姿势获得呢?做商用的比较好的小程序容器其实目前市场上就3家。
个人推荐 FinClip ,也是我司在用的方案。只需要在你的 App 里面,引入它的 SDK,就能加载运行外部小程序了。除了 SDK,它还提供一个后台管理系统,统一管理小程序的上架和下架,以及收集和分析小程序数据。
使用下来,想谈下对 FinClip的体验:
也就是说,现有的微信小程序可以不改一行代码,直接放进你的 App 里面,运行效果保持不变,不必额外二次开发和改造,大大节省了人力成本。
除了移动端的 iOS 与 Android,看到还支持了包括 Linux、Windows、MacOS、麒麟等操作系统。相当于PC 端、车载设备、智能电视都能使用小程序了,看得出来做产品确实很用心。
提供小程序 IDE 开发工具,界面与微信小程序的开发工具类似,自带调试和真机预览,简单易上手。可以在这个 IDE 里面,对现有项目进行二次开发,扩展功能和接口,或者从零开始写出一个小程序。
总体来说搭建成本比较低,寄生型的容器,对自有的app和已经研发好的小程序不需要太多改动,直接就能用,感兴趣的也可以去试试,目前社区版是免费的。