好几天都没有去做文章内容的更新，并非归结于自身存在lazy的情况，而是由于最近这段时间正在着手进行关于方面多端适配的工作。
坦白说，我被折磨得够呛。
H5跑得好好的，一上小程序，页面直接裂了。
你经历过吗？
那种“明明代码都一样，偏偏就你不听话”的绝望。
我曾跟你交流过，然而你却难以清晰说明白，只是简单说了一句，“在自身电脑上常常是无法重现问题的，把问题推到线上就可以解决”。
可这特么不是Bug，是整段垮掉。
随后我才弄清楚，那些被传说的“一套代码在多个终端运行”，压根不是毫无思考地进行迁移，而是存在条件、有着代价的，我掉进去的坑你很有可能也踩过。
我花了两天两夜，手撸了一套多端适配源码。
这并非那种华而不实、徒有其表的UI框架，其底层全然是由“能够运行、具备兼容性、实现解耦”这三条底线所支撑起来的。
不是为了炫技才搞适配。
事情是这样的，那就是客户所要求的实在是太多了，具体表现为，先是要一套微信小程序，接着需要上线一套H5，而后呢还非得测试一套内测App，另外哦，就连鸿蒙也都处于即将到来的进程之中了。
每一端都有自己那些破规矩。
小程序不支持
那一套，你得上view、text这些灰扑扑的原生组件。
H5里的地址，手机App端压根访问不了。
就连*这种烂大街的全局选择器——非H5端理都不理你。
张小龙看了都得挠头。
更扎心的是那些被吹上天的第三方库，拉到小程序里直接卡死。
换哪个浏览器都没用，因为它跑的根本不是浏览器环境。
为什么一开始干不通？
一开始我想得太天真了。
以为就是万能胶，哪不行粘哪。
直到遇上了一个叫“原生组件层级”的鬼东西。
处于小程序里头，video、map这般原生组件，一直是居高临下的态势，普通的view试问想要在其之上添加一个按钮吗？
门都没有。
这还不是最气人的。
H5运行得好好的CSS动画，一旦到了App端低版本安卓机上，就直接呈现白屏状态，致使人们手忙脚乱，陷入一团糟糕的局面。
怎么拆这个局？
后来我去扒了很多源码，也翻了几十个开源项目。
其实底层用的是“编译器+运行时”双引擎。
简单来讲呢，就是在编译的这个阶段，会去进行“翻译”的操作，也就是把vue文件，拆解成为每一个平台所特有的那种东西。
最让我恍然大悟的是“条件编译”。
你知道吗？
ifdef MP-
wx.(…)
endif
并不是注释，它真的只在微信小程序端被编译进去。
我开始规范组件管理，按照平台拆分组件目录。
在pages///这里面，我曾目睹有的团队进行一层层的嵌套，随后借助props传参来做平台标识，最终才得以从中脱离出来。
可是更大的坑在于，的确省却了一堆以及声明的麻烦事儿，节约了50%的组件引入所需时间，条件是那些问题不太大的组件。
真正的核心实战
如果非得说这份源码里最核心的部分。
大概就是“UI组件层+平台适配层+业务逻辑层”三层解耦。
对外部调用者来说无感知。
除此之外，存在uni-kit的API二次封装情况，将路由领域、存储范畴、日期换算方面等痛点逐个覆盖，尽可能减少报错情况的发生，能少就报错就少报错。
奔跑起来之际，使用 uni.() 来开展设备环境检测。
根据系统版本来动态降级策略。
比方，iOS 13以下版本，当低于某一阈值时，便进行降级操作，以此来运用，进而避免连接莫名其妙地断开。
附一个让你少掉坑的“防坑脚本”
下述这几个对多个端口均适用的“防止掉入陷阱类脚本”，我差不多是将其复制至每一个页面的，其作用是帮你免去那些在毫无头绪的情况下陷入困境的夜晚。
1. 全局样式重置
在App.vue当中，引入reset.css，其专门用于解决小程序盒模型方面所出现的错乱情况，以及App端字体呈现不一致的那种毛病。
2. 统一路径别名配置（alias..js）
是不是远程协作开发使用的那种环境，不同系统之间路径分割符号不一样，容易出现错误，那就采用这个配置，再结合的.alias，使得@/在所有平台上都能够准确无误地找到文件，防止出现”模块不存在”这样的错误。
3. 条件编译分层uni-kit
以电商项目里 组件的思路作参照，将存在平台差异的代码，拆分至 -bar-h5.vue、-bar-mp.vue、-bar-app.vue 之中，仅挑选最为必要的予以暴露出来。
4. rpx 的响应式适应机制
屏幕宽度所对应的自适应尺寸，是rpx ，它不复杂 ，但别乱用 ，只在字号盒模型方向使用它 ，会稳一些。
5. 封装的跨端API封装好
在底层运用uni – kit进行封装之后，于上层开展微信分享的请求，进行App签名的操作，以及进行鸿蒙桥接，不会出现风格方面与内存方面两种不一样的错误竞态情况。
在此次所撰写的多端源码方面，最终实现了五个终端的运行情况，分别是小程序，H5，iOS，安卓，以及鸿蒙初代。
最开始的时候，我是照着官方所搭的-模板来弄的，那就是Vue3加上TS，再加上Vite以及Pinia，一次就运行成功了，根本连想都没去想。
是直到客户说出了”你这个App里请求为什么一直” 这样的话语，才察觉到.json里忘掉了配置小程序的合法域名以及App的网络访问权限。
对了，如果你有时间，还是得关注一下原生集成的调用时机。
在运用Plus API之际，务必要用if ( plus!== ”)进行包裹，不然的话，在iOS端一旦运行起来就会出现报错的情况。
极其令人感到不爽的是，pages.json当中的分包配置，以及线程配置，文档里是藏在第三方延伸版块之中的，非常难以翻找到。
周末时，我经过一番调试，才察觉到，原来，有关小程序的路径，出现了错误。
绝对路径和相对路径总混在一起！
返回来讲呢，终究仍旧是依照微信小程序组件的那一套来运行的，进行中包操作时最为头疼之处在于启动优化这方面，特别是首屏。
把预加载拆到二级页面，用户体感会好很多。
我搞IT这么多年才摸清楚一个道理。完美的代码不存在。
好用的代码只是踩过的坑比别人多罢了。
这套源码已经给了三个项目组在用，跨端跑起来兼容性都不错。
没有啥特别能引人注目的，不过起码每一种设备进入的时候不会出现错误提示。并非需要对百分百的设备做到兼容。
99%就够了。剩下那些低端国产机——就别折腾了。
要是你同样因为多端适配而被折腾得产生想砸电脑的念头，那就亲自去把源码拿过来跑上一回，如此你便会明白其中缘由了。
复制到里，点一下运行，选你要跑的端。
能跑起来你就赢了一大半。
许多时候并非是你自身能力欠缺，然而这是那些已然默认存在的环境差异，在与并未具备充足的预防方案作对抗，而就在当下这个时刻，我的文章正好就为你提供了一个方案，你拿去使用便是，无需客气。
