绕过技术聊'跨端'......

开门见山，我知道有很多业界大佬或组织深耕在跨端开发领域中，小弟才疏学浅，就不在技术层面故作姿态了，今天跟大家绕过技术、仅从架构思想上聊跨端开发。

跨端的本质是复用

跨端开发很难吗？一点都不难，你财大气粗可以每个端都招一组人马开发就得了，多少端都不是事儿。所以我们在此聊的跨端其实是如何节省人力成本、时间成本而进行“跨端复用”。

这是一个开放的话题，不只是开发技术上可以聊，架构思想上可以聊，甚至团队管理、资源分配上也可以聊...

为什么不能跨端

我们回头想想应用为什么不能跨端呢？思维逻辑是无国界的，你可以借助任何一种语言来描述与表达，而Javascript运行时又被多种运行平台广泛支持，按理说跨端应当不难呀。

这个

魔障就是UI/UE

，这是一个感性的东西、它灵活多变、不但不存在标准反而还追求个性。各端都坚守自己用户习惯、设计风格、传统文化、个性表现、默认优化、方言约定等等，这已经不是技术范畴的事了，即便你强行抹平了，也只能顾此失彼...

为什么后端接口不需要跨端开发？(即便需要也仅仅是个BFF适配层)。因为后端是面向业务逻辑的开发，而前端是面向UI界面的开发。

所以最简单的跨端思路就是：

直面UI的个性化，把这层基于感性的、非标准的东西剥离出来，并尽可能削薄它。

从理想主义到现实主义

虽然

Write once run anywhere...

是很多人追求的梦想，但我不推崇它，因为即便是你做到了，你也可能失去平台优化、失去个性色彩、在平台生态中沦为二等公民。

那么退而求其次

Learn Once, Write Anywhere...

，不追求那么完美，能复用

业务逻辑

、

解题思路

、

应用骨架

、

核心代码

，也是知足常乐的。

从业务逻辑到领域模型

应用的核心是什么？是游戏规则，是

业务逻辑

，一个应用不管运行平台怎么变化，它的业务逻辑总是通行不变的。如果我们再进一步对业务逻辑进行领域建模，去掉那些花里胡哨的修饰、让业务模型变得抽象、纯粹、精炼，那么我们将得到一个最有价值的、最稳定坚固的、放之四海而皆可行的核心逻辑。

至于UI表现要个性化？要平台化？那就重新作件漂亮的外衣呗...

UI的职能

UI的职责只有2个：输入与输出，仅此而已。它是指令的收集者和结果的反馈者，而不应当成为指令的执行者。

当你秉承这个思路，那么UI层/UI框架就无足轻重了。我前几天发过一篇文章：

炮打司令部，别让一个UI框架把你毁了

，阐述了前端过度依赖UI框架，把UI框架当成应用的骨架，从而导致代码混乱，耦合紧密、更使你的应用失去通用性。

怎么落地

最关键的就是要分层架构，解耦UI逻辑和业务逻辑、写薄UI层：

• 首先，可以借助于一个跨平台的MVC框架分层而治。

• 其次，编写代码的时候注意不要再面向UI事件了，改为面向业务动作。

• 最后，将业务逻辑从UI层中彻底移出。

具体做法可以参考：

炮打司令部，别让一个UI框架把你毁了

，主要就是：

• 从 State 到 Model

• 从 Event 到 Action

实例演示

最后，为了证明这种思想并非纸上谈兵，可以看看我的开源框架：

Elux-基于“微模块”和“模型驱动”的跨平台、跨框架『同构方案』

，正是基于以上思想而设计。可以使用React/Vue/其它第三方框架，可以用来开发：Web(浏览器)、Micro(微前端)、SSR(服务器渲染)、MP(小程序)、APP(手机应用)。

安装方法：

npm create [email protected] 或 yarn create elux

小程序开发默认使用的TaroJS，原理是把TaroJS当成一个第三方UI框架，理论上uni-app或是其他也是可以接入的：

@elux/[email protected]
新建项目: /Users/hiisea/work/elux/aaa
totally [44P] templates are pulled from ...

? 请选择平台架构 
 CSR: 基于浏览器渲染的应用 [16P] 
 SSR: 基于服务器渲染 + 浏览器渲染的同构应用 [8P] 
 Micro: 基于Webpack5的微前端 + 微模块方案 [8P] 
* Taro: 基于Taro的跨平台应用（各类小程序） [8P] 
 RN: 基于ReactNative的原生APP（开发中...） [4P] 


抛砖引玉，你也许不会真的使用它，但它或许能给你带来新思路...