write once, run everywhere
Android应用程序使用Java或Kotlin,iOS应用程序使用Objective-C或Swift,网页界面使用HTML/CSS/JavaScript。需要开发支持多个终端的应用程序时,每个目标必须独立地进行研究和测试,直到上线。
为了解决多域独立开发的问题, 优先采用跨域技术.
现在在前端需要处理的场景太多了,android、ios、pc、智能手表、车载、智能电视等，当一些场景非常相似时,我们希望能够以最低的发展成本取得最佳效果,相反,每个端需要一个单独的人来维护它。
因此,今天的交织节目充满了鲜花,比如现在最为人们所熟知的react native、flutter、electron、weex、小程序等，他们之间没有什么共同之处,如果我们能找到它的本质,这就是今天这篇文章的主题。
一, 主流 的 跨 部门 执行 计划
1、以 Web 为基础的 H5 Hybrid 方案
其实，浏览器书是一个跨部门的实现程序,因为你只需要输入URL,您可以在浏览器的任何端打开您的网页。那么，如果我们将浏览器嵌入到应用程序中,然后隐藏内容,例如地址栏,是否可以将我们的网页嵌入到本地应用程序中?这个嵌入式应用程序浏览器,我们称它为网页视图,只要一个端支持网页视图,所以它可以使用这个程序截面。
同时,它也是一个低成本的程序,因为它实际上是写 front-end 接口,与我们正常的Web开发没有太大的区别。
2.框架层+原始渲染方案
典型的表现是反应原生,它的开发语言选择js,使用语法和反应完全一致,事实上,也可以说这是一种反应,这是我们的框架层。与一般反应应用不同,它需要利用原始人的能力来渲染,组件最终将被渲染成原始组件,这可以给用户带来更好的体验。
3.框架层+自渲染引擎方案
这个方案与上述方案之间的区别是,它不直接借用原始的能力来渲染组件,相反,它使用更深的渲染能力,自己去渲染组件。这样显然,链将比上述方案更短。那么成绩也会更好。同时,它在确保多端渲染的一致性方面也比以前的方案更加可靠。这种框架的典型例子是浮动。
小程序跨端程序
众所周知，近年来,一个东西变得非常爆炸性:小程序,现在许多大工厂开始进行小程序进入办公室,但现在软件技术不再局限于 BAT,小型工艺容器技术解决方案在市场早期被引入。集成小程序容器SDK后,不论是 iPhone, Android, Flutter,React Native, 电脑、电视、车载或物联网设备，这些都可以使不同的应用程序或终端设备快速运行小程序,同样的小程序场景可以分配到不同的终端上运行,不需要为不同的终端编写不同的代码,这类小程序容器技术可以借鉴一下 FinClip （https://www.finclip.com/product）。
什么是共同的跨端场景
- 跨 PC 端。例如跨 Windows Linux Macos
- 跨多 Native 平台：例如跨 Android 和 iOS
- 跨应用程序:随着越来越多的超级应用程序,许多企业需要在多个应用程序中配置相同的业务场景。
- 跨 Web、小程序、QuickApp 等：其实本来类似跨 APP，但是奈何小程序本身是各家控制的封闭生态，故而有了开发一次适配到多种封闭生态的诉求。
选择跨端技术方案
跨端技术方案，所关注无外乎如下这4个方面：研发效率、动态性、多端一致性、性能体验。
研发效率:最大化代码重用,减少多端的适应性工作量,降低开发成本,即使操作启动后,也可以维持低成本,加快新功能的迭代速度,这是持续的效率提升。
动态化：可实现业务快速迭代，这一点不只是跨平台技术的诉求，也是Native技术必备的杀手锏，这也是评估跨端技术的一个重要考核点。
多端一致性:多端UI设计的良好产品,每一个都是统一的整体风格,因此业务方采用原生各自独立开发完成后，修改UI也需要大量的额外时间,以确保多端一致性;参见,开发方法在各个方面都独立实施,带来的效率滞后，开发代码不仅仅是Android和iOS的工作量,还有关于双端UI的兼容性的工作。
性能体验：通常地，跨部门技术方案具有上述多项优势,但性能比原来的流程要差。牺牲部分经验以提高效率,这同样在精神上,试想一下，跨平台技术方案也同时实现了这些四个点。因此,我担心原始技术已经过时了,在跨平台技术的早期,因此,每个跨平台技术的性能成为核心指标。
四、结尾
对企业技术团队来说,跨部门的实质是杠杆。 一方面,重要的是为新变化提出新的方案,另一方面,更重要的是确保有效性真正持久,这样有效性不会变成从一个方案到另一个方案的跳跃。
跨端的诉求和与之对应的方案仍然会处于频繁的变化中，也不会出现一个解决所有跨端问题的方案。而其中相对不变的部分是值得我们为了长治久安必须要投入的。