前言
我想问一下,有多少同学知道钉钉也有小程序?有多少同学参与过钉钉小程序的开发?参与程度有多深?有多深,至少50页吧!经过一轮筛选,应该剩下的勇士不多了,顾明应该也算是勇士之一。
两年前我们决定all in钉钉小程序,因为h5的一些体验问题,以及业务快速迭代的需要,小程序是首选;公司所有用户、组织等数据也都绑定在钉钉上,所以最终决定做钉钉小程序。目前tob业务的6个应用都托管在钉钉小程序上,500多个页面。除了小程序,h5应用也运行在钉钉容器里。支撑的基础设施如表单引擎、组件库、OSS、F2、工具库等也都是围绕钉钉小程序搭建的。客观的说,我们真的是靠钉钉小程序吃饭的!
然而在用钉钉小程序做py交易的这两年里,总感觉钉钉小程序承接业务的能力天花板很低,稍加努力就能实现业务,给产品留下了“不好印象”(前端不太好~)。所以我们一直积极和钉钉小程序团队沟通,几乎每周都会反馈问题和建议。但悲催的是,大部分问题都要自己解决,直到前几天的一张工单让我按耐不住。
批评
准备好,开始喷涂。
奇怪的数字键盘
是什么原因让我想站出来“点赞”呢?原来是因为iOS版钉钉小程序无法正确弹出数字键盘,让我彻底按捺不住了。冷静一下,我还是个前端er,回归技术
我们都知道手机浏览器会根据手机类型调出对应类型的键盘,手机直接点击即可查看
小程序也提供了相应的配置,但你知道吗,钉钉小程序的这些配置都是摆设?
于是我们在钉钉社区里提问,得到了如下的回复,不知道回复的人是不是官方的技术人员,我很震惊。
一直没有结果,就向官网提交了工单,得到的答复是iOS有bug,需要等待修复,我们当时就愣住了。
我天真的以为这个问题一定很严重,于是就去查看了微信,结果发现微信是没问题的,如图。
不是,可能微信小程序有更先进的同层渲染,钉钉小程序暂时做不到。
然后我们看看抖音小程序,原来抖音也可以啊~这……
然后我们来看看支付宝的半个app,虽然显示有些奇怪,但是至少数字键盘可以弹出来满足需求。
果然,想要弹出iOS原生的数字键盘,似乎确实有些困难。
于是我联系了钉钉官方,希望他们能照搬支付宝的方案,至少能安排一下,结果回复说不处理,你自己写个数字键盘吧,我好无奈啊……
有bug很正常,谁也不能保证程序是完美的,但是对待bug的态度要端正,这种态度确实不好。
尤其是作为一个开放平台,这么明显的bug他们能放过吗?而且修复起来真的很难吗?真的是他们的错吗?第一张图的demo是用钉钉容器打开的,为什么能正确弹出?
我也在这里问问题,希望有知道的可以帮忙解答一下
小程序开发工具2.0,KPI IDE?
忍不住说出来然后夸赞
微信和支付宝都有相应的开发工具,我们开发钉钉小程序其实也是用支付宝IDE,不过前段时间无意间发现钉钉官方出了一款专门针对钉钉小程序的开发工具,当然好奇心大增想试试看有什么体验升级,于是就下载安装了。
果然钉钉从不让我失望,爽了三秒就好了。dd。反正请求失败了,这个接口是钉钉授权的,最高级的API,拿不到就没办法了。
怎么办?我照常去官网,结果回复笑死我了,别用这个了,推荐用支付宝IDE开发,你用这个干啥?2.0的
其实我在 5 月 15 号就针对这个问题提交了工单,发帖当天就打开验证了,到现在还没修复,效率太惊人了,难道只有我一个人用吗?
票务群已经关闭,没有图片也没有证据,就当这个回复是我瞎编的,纯属个人不当使用,OK?反正我不会再用了。
谨慎使用
大概半年前,朋友的电脑在 后一直报错,前端报错is not,但是CI平台搭建的测试环境却正常,这种问题对我来说是最烦人的了,不过好在能稳定复现。
我先自己模拟复现了一下,一步步来。因为中间夹了一层Taro,所以重点排查了Taro的构建逻辑。排查到最后,我又想到了钉钉的构建环节。排查的结果着实让人震惊,原来是钉钉在构建的时候替换了逻辑。不管你的逻辑是什么,只要名字一样,就直接替换。
钉钉小程序在编译的时候会内置一些变量,比如应该还有其他的,我猜支付宝小程序也是这样(没验证过)
我理解它和常用的环境变量 .env.xxx 是一样的,在构建过程中会被替换。问题就出在这里,在特殊场景下,Taro 会将函数转换为如下形式
// 部分代码只为了展示
...
regeneratorRuntime = webpack_required(20)
regeneratorRuntime_default = wepack_required.n(regeneratorRuntime)
...
命名发生冲突,数据结构发生变化,页面崩溃。
我们查看了官方文档,但没有提到这一点!!!~他们不应该解释一下这个重要的黑匣子吗?
又想吐槽一下,文档质量实在太差,找不到我想要的,垃圾一大堆,有时候直接看支付宝文档就完事了。别跟微信小程序开发文档比了,就跟竞争对手飞书开放平台比吧。别的不说,单单跟小程序开发文档比,真的被打脸了。
更重要的是,我们当时也跟钉钉官方建议可以增加类似的使用说明,他们也说会加,是会加,但是几个月过去了好像还没加,今年会不会加?
这种编译时变量能不能定义得“抽象”一点?别这么轻易就中招了,中招了你就得在钉钉小程序上花半天时间,你以为钉钉小程序在给你白吃大餐吗?
我想上传一段超过一分钟的视频
这个看似简单的要求,已经和钉钉小程序官方讨论了将近两个月,仍然没有结论。
我们这边上传下载的场景非常多,比如拍摄一个拔罐过程视频,一般时长三分钟左右。门店本来就很忙,没太多时间处理总部管理事务,现在一个视频要分几部分拍摄,真的是每天都有人抱怨。
有人会问,难道不能先拍后上传吗?答案是不行,钉钉会崩溃,大部分内存处理不好的APP都会崩溃;首先钉钉小程序不提供分段上传,只能在小程序端直接推送,会占用很大的内存;而且大部分门店工作机器配置都不太好,会大大降低上传成功率
我们也想到了几种解决方案:
增加拍摄时间
降低分辨率并延长拍摄时间
分段上传
首先拍照 -> 在商店解压 -> 通过钉钉应用上传
钉钉小程序不会处理上传
123钉钉暂时还不支持,45也因为操作环节被拒绝。
恳请钉钉小程序团队考虑一下,至少给我们一条出路。工单早就下达了,能不能安排到下个合适的时间段?隔壁飞书在这方面比你们快多了~
除了上传视频之外,钉钉的API在文件处理方面也存在一些不足,例如, (无法处理文件)。
缺了还好,但有些API还是不稳定,比如蓝牙相关的API,特定场景需要断线重连,稳定复现,最后只能用提示作为备用。
永远无法升级的版本
说实话,钉钉小程序的版本升级真的很不稳定,我们刚迁移到钉钉小程序的时候,在线上环境等待验证的时候,就是升级不了,真的等了一个多小时,是真的!各种清除缓存都没用,当时我们还太小,后来长大了,直接卸载钉钉重新安装,这样每次打开小程序都能同步获取到最新版本。
别告诉我为什么不用试用版?有些场景只有版本发布后才能在正式环境中验证,比如一些消息场景。
几乎团队里所有人都问过我一个问题:这个版本的钉钉小程序怎么用?怎么还是老版本?怎么还没升级?
我们就此向钉钉官方进行了询问,得到的回复如下:
说实话,拿到版本升级攻略之后,我看了三遍,突然发现有点头疼~(开个玩笑)
无论如何,根据回复策略,我们验证的结论是:不要相信一切
此外,还有一些疑点:
新版本发布48小时后,旧版本日志还在(可能一直没注销)
策略3什么时候触发离线包下载?
48 小时对于紧急释放来说太长了
小程序的更新机制我就不多说了,如果需要复习可以点击小程序的更新机制和小程序更新策略介绍进行了解。
无法检测冷启动
钉钉小程序在版本管理上还有一个问题,没有启动页,无法检测到冷启动。

为什么需要关心冷启动呢? 因为冷启动会触发版本,当有新版本时,会异步下载新版本的离线包,这个在钉钉的文档里也有说明。
相比传统SPA应用,小程序中间多了一个缓存层,小程序也制定了各种策略来管理缓存,好处不言而喻,坏处就是开发者相对难以精准把控版本,因此主动控制版本的选项之一就是依赖冷启动来下载新版本的离线包,但这个可感知的环节已经被阉割了。
然后我们来向微信致敬一下,微信有几次精准的销毁小程序的机会,销毁之后下次打开肯定是冷启动,错误可控。
小程序一旦被移至后台无法被看到,一般在5分钟内就会被微信客户端自动销毁。
如果你删除微信客户端中最近访问的小程序,它们也会从内存中销毁;
在iOS上,如果5秒内连续出现2次以上内存警告,应用程序将被销毁。
钉钉也有相应功能,比如下拉副屏可以管理小程序。
但我们也验证了1和2,结果表明它们无法准确触发新的离线包的下载。
微信小程序近期在版本管理方面发布重大更新,包括“优先本地版本设置”和“小程序最低可用版本设置”,这意味着小程序可以同步升级。钉钉什么时候能借鉴一下这个?这个配置是一次性解决的,B端应用需要这样的功能。
有一个陀香
还是在iOS上,钉钉小程序真可惜,iOS总是出问题。
自定义场景中,左边绿色部分无法点击,点击事件无法传递出去,被阻止冒泡,就像是把屎盖住了一样,实在是太恶心了。
真机左上角有头像,点击可以弹出操作侧边栏,iOS点击不了……只能用现有的占位符
幸好我们提交了工单之后,这么明显的bug我们没法忽视(为了面子),回复说会在8月版本修复。我们是6月底提交的工单,所以还可以接受。至少还有希望。
这是谁的菊花?
看看这是谁的菊花,我们查了半天,确认这是丁丁的菊花!
原因是有用户反映,访问钉钉小程序时,一直卡在这个页面,看来晚饭已经解决了。
于是我把项目里所有的菊花都检查了一下,没有一朵和它长得一模一样的,太紧了~最后我发现,这个根本就不是我们的,而且它根本就没有进过我们的小程序,所以我们根本没法控制它。
我气得在反馈群里打了“**叮叮”两声,最后还是忍住了怒气,一字一句地回复,最后说“很抱歉给您添麻烦了,请您尝试换4G,我们会继续跟进。”我猜客户心里也在想:“你就是天天知道道歉,你什么都不是。”
直到前几天,才有用户反映这个问题。如果我没记错的话,这个问题已经存在一年多了。我们束手无策,无能为力!
按照惯例,我们很早就已经联系过钉钉,但是钉钉小程序官方至今未就此原因给予我们回应。
我自己分析该现象是小程序容器初始化失败,在特定场景下,尤其网络状况较差的情况下,该现象可以稳定复现。
钉钉小程序的官方人员,请您花点时间看一下,至少给我们一个官方的措辞,让我们可以回复用户,谢谢。
失败的
这里有个关于iOS端的问题,呵呵,趁你还病的时候...
配置后,若有换行符+空格,则限制失效,允许无限制输入;可复现钉钉官网组件demo
向官方反馈后,回复很熟悉,是iOS系统问题,不会处理
无灰度控制
目前版本没有控制灰度的功能,所以只能自己处理了。我们有两种解决方案
耦合到代码中,通过配置圆圈范围进行灰度控制
新建灰度小程序,从外层分发流量
如果你支持我,我就给你100个赞,我估计你会不理我,就当我是YY吧。
长列表性能问题
这是我们讨论很久的话题了,同样的场景(平铺一个全年日历组件),有些低端设备已经很卡了,特别是结合一些动画效果之后,但是打开就毫无压力了
这不是钉钉小程序本身的问题,应该是所有小程序都存在的一个很头疼的场景,经过几层转换之后,性能肯定会有所损失。
不过说实话,对比过微信小程序,同样的模型,同样的代码,微信小程序确实流畅很多~
这里要澄清一下iOS的名头,渲染性能差别不大,主要是低端安卓手机很慢。
最终的解决方案是自己实现延迟加载
页面元数据
page-meta是小程序原生的一个组件,可以动态修改一些页面根节点的数据,有些需求我们需要用到这个组件,但是钉钉还是不支持。
同出一辙的支付宝小程序已经落地,我们是否应该在合适时机进行复制?
喜欢
钉钉小程序并不全是抱怨,它的一些功能非常开放,一些建议也得到非常积极的处理。
通讯
微信小程序之间想要通信,但只能在特定时刻进行通信(小程序退出、组件销毁、分享等);这个机制对于逐步迁移到小程序的 H5 应用来说非常痛苦。好在钉钉小程序的通信解决方案还是开放的。
钉钉小程序提供了一个方法,只要app内的应用调用它,小程序就能收到回调,其他的没有限制,这个机制能干的事情很多,就是小程序所有的h5应用api都可以用
基于此,我们做了以下几件事:
登录授权同步
数据缓存同步
常见的 DD API 映射
统一媒体资源上传
h5登陆页跳转至小程序
这种开放的沟通机制在我们逐步迁移小程序的过程中起到了很大的帮助,当然现在我们80%的业务都完成了小程序的重构,我们会越来越少用到它。
小程序版本管理
如果不想上传IDE构建的小程序版本怎么办?如果想自动发布体验版和正式版怎么办?内部小程序管理API钉钉小程序需要用到它。现在可以彻底关闭整个钉钉小程序自动化发布流程了,必须点赞!
大约半年前的发布过程
我们想把钉钉小程序的整个发布流程托管在内部的 CI/CD 平台上,但当时的 cli 只提供了简单的上传和预览,最终的发布版本还是需要在钉钉管理后台手动点击,也就是说最后一步还是需要人工干预。
想象一下,有两个版本排队等待同一天发布。
如果不出什么问题就好了。但是如果有人忘记点击正式版本发布怎么办?如果分支没有推送到最后怎么办?如果已经推送了,但是线上出现问题需要回滚怎么办?
因为小程序正式版还没有对应的hook回调,导致我们的CI/CD平台无法在合适的时间进行分支的合并,这个过程可能会出现很多变数。
于是我们向钉钉提出了需求,希望能够增加发布预览版、发布正式版、回滚版本等cli功能。幸运的是,半年后的6月份,该功能终于上线,并且与我们的
立即发布流程
剧透警告,我们的 CI/CD 同事也将以这种沉浸式的方式分享他们的经验。
结尾
关于钉钉的故事还有很多,毕竟团队三十多个人都在和钉钉打交道,就算没有bug,也迟早会被发现的。突然,我耳边响起了查查辉的声音:你知道我们这些年是怎么活的吗?如果要找bug,连耶稣都拦不住我们。
爱越深,责任越重。很感谢钉钉平台承载了我们这么多的业务。说了这么多,还是希望钉钉开放平台能做的更好,不能只看数据,更要注重开发体验和对待问题的态度。毕竟想要得到产品负责人的认可,还是要看钉钉小程序能给你多少。
希望有一天我可以说,钉钉小程序你给予我的太多了。
钉钉小程序的开发者可能不多,但遇到棘手复杂的问题确实很痛苦。相比微信小程序规模庞大、活跃度高的官方问答社区,钉钉在出现问题时只有一个选择,那就是向官方提交工作单。或许我们可以建一个钉钉小程序问答群?互相取暖?
最后来个小互动吧,如果微信小程序开发经验是10分的话,诚恳的请参与过钉钉小程序开发的勇士们在评论区给它的开发经验打分
终于