写了一篇文章,总结做小程序兼容的详细技术方案( PS:小程序太坑了)
1
FEDT 2021-07-16 23:57:44 +08:00 via iPhone
网页版也挺不错的,打算开源吗
|
2
linhongye 2021-07-17 02:31:55 +08:00 via Android 1
不是抬杠哈。
想问下,大概项目的代码量是多大呢?是不是除了 4 天上线之外,还有更多的考量? 我试了一下小程序端,也对比了下网页端。 一是网页端功能没有完全移植过来。 二是初略看来,就是以现在这个小程序的功能丰富程度,大概是一个人 3 ~ 5 天能够实现的… (当然,对内部细节不清楚,还请指教。) 而文章中说了团队协作流程的重要性,那我想程序员应该数量达到 3 人或以上,所以我猜想即使没有代码复用,大概完成时间也在 4 天之内… 我自己也写过小程序,用过 react 、用过 taro 、用过原生,也写过 ios 、安卓和网页。因为我开发过很多个平台,也试过不同的跨平台方案。 所以,我想的一个问题就是,有多少时候追求代码复用是伪需求呢? 有些时候,追求复用是能大幅提高效率的,比如 vs code 在 mac 和 win 上跨平台。 然而,ios 、安卓、微信小程序 这些都在极力创建自己封闭生态的地方,而且前端工作量不大的情况下。就我自己的体验来说,前端放弃直接的代码复用,而选择环境生态下本身优秀的开发思路,其实更快更省人力,后期可维护性也更强。 |
3
daimaosix 2021-07-17 03:13:27 +08:00 via Android
PPT
|
4
qiayue 2021-07-17 09:24:35 +08:00
我花了 1 小时上线了一个小程序,因为用的 webview 嵌入已经做好的网页版,并且网页版做了微信公众号授权登录,所以小程序真的就是一个浏览器。
写代码加审核发布时间加起来 1 个小时。 |
6
zengqz OP @linhongye 是的 就现在看到的功能来说重新写一个也不麻烦,这是第一个版本,原因是很多代码没有迁移过来,目前实现的是一个简化版本,文章是介绍一些兼容的手段,小程序端向 web 兼容,而不是类似 taro 那种相反的做法,代码复用真的很重要,因为就 UI 来说可以直接迁移而不需要重新根据小程序端重新设计(当然有很多精细排版后续需要手动优化)
|
7
zengqz OP @linhongye 这个项目前端工程量不大,4 万行代码左右,但是想象一下,如果按文章的做法操作,这些代码可以直接迁移使用,不是极好的吗?而且这种做法不受规模影响,上线新特性的时候总是先完成 web 版本,连数据、UI 逻辑直接迁移小程序而无需改动,这样开发效率是最高的。你提到的另一个问题是封闭生态上的开发,这个我很赞同你,直接在这些生态上开发无论体验还是性能都是杠杠的!比 react-native 和 flutter 之类的方案好太多,但是从商业角度来说,复用能够明显降低开发成本,加速上线
|
8
linhongye 2021-07-17 12:04:15 +08:00
@zengqz #7 我的也是商业项目... 踩坑以后发现... 每个端始终得做单独优化...
也就是说, iOS 的人不能少、网页的人不能少、小程序的人不能少... 还得有个高手来做底层优化... 看看美团他们, 多大的团队专门在优化 flutter, 性能还是那个样子... 小公司更不可能了... 代码复用能不能降低成本、提高速度, 是一个不等式, 需要考虑的东西很多... 有时候, 追求尽量多的代码复用, 反而让总体效率下降. 我现在是后端用 graphQL, 所以向后端请求数据的部分代码复用. 剩下的全部原生撸. 在我的项目上, 这种方案效率比, 开发一个复用率高的版本, 再去做各端优化来的高.... 毕竟现在前端撸起来还是快且容易的.... swiftUI 撸起来又滑又优雅; 微信小程序自己那么多坑, 自己去解决起来也比 copy 其他端的代码来的容易解决... 如果只有网页版和小程序需要适配, webView 其实是一个非常简单明了的办法... ps. 小程序的 navigateTo 不能用超过 10 次, 你们的小程序里现在这个事件没有处理. |
13
wq2016 2021-07-19 11:15:11 +08:00
用微搭
|