您好，我是ID: 熊猫钓鱼！
十余年深耕技术一线，我始终相信：优秀的开发如同垂钓——既要对技术生态的「水域」有深邃理解，也要对问题本质的「鱼汛」保持敏锐直觉。从架构设计到性能调优，从技术选型到团队协作，我专注在恰当的时机，用最合适的技术钓起最优雅的解决方案。关注我，我带你一起研究最新又好玩的热点技术~！

上个月我妈给我打电话，说楼下公交卡充值点撤了，她不会在手机上交钱，急着出门坐公交。我远程指导她：“你把手机背面贴一下充值机上那个鸿蒙标就行。”她半信半疑贴上去，锁屏界面直接弹出来公交卡充值的卡片，输了50块钱，指纹一按就付完了，前后没花10秒。

她后来跟我说：“这个比你上次给我装的那个公交APP好用，不用点进去找半天。”

我当时就在想，这可能就是我做了半年鸿蒙元服务，最想给别人解释清楚的事——很多人觉得鸿蒙Next就是“换了皮的安卓”，元服务就是“鸿蒙版小程序”，真不是。这半年踩的坑、改的需求、被审核打回来的次数、上线后看到的用户数据，让我慢慢摸清楚了这个新生态最根本的不同：它不是换了一套开发语言、换了一套UI组件那么简单，它是把整个“人找服务”的逻辑反过来了。

---

一开始我也以为元服务就是小程序，直到审核打了我三次

我最早接元服务需求的时候，心里是不屑的：这不就是快应用、小程序的老套路吗？把APP拆成小模块，免安装，加个卡片入口，换汤不换药。我就按照做小程序的思路，把原来APP里的充值功能抽出来，打包成一个2MB的包，首页放了个轮播广告，下面几个功能按钮，点“充值”跳转到充值页面，选金额、输密码、支付，链路和小程序一模一样。

结果提交审核，第一次10分钟就被打回来了，理由写得很直白：“未体现元服务直达特性，存在不必要的中间页面。”

我当时没当回事，把轮播广告删了，又提交。第二次打回来，理由：“功能入口层级过深，用户无法在两步内完成核心操作。”

我有点懵，两步？小程序三步跳转不都是很正常的吗？我把首页多余的按钮全删了，就留一个大的“立即充值”按钮，点进去直接选金额支付，整个链路就两步。第三次提交，终于过了，但审核员给我留了一句备注：“元服务不是把APP装小，是让用户不用找就能用。”

这句话我直到上线一周后看数据才真正懂。一开始我还在卡片上放了个小logo，想让用户点进主界面看看我们别的功能，结果数据出来：卡片点击率90%以上都集中在“直接充值”那个按钮上，点进主界面的人不到5%。后来我干脆把logo去掉，2×4的卡片上直接放三个常用金额按钮（20/50/100），用户点一下金额直接跳支付，连元服务主界面都不用进。改完第二天，充值成功率直接涨了40%，后台用户评论里最多的一句话是“太方便了，不用点进去瞎找”。

那时候我才反应过来我之前的思路有多错：做APP、做小程序的时候，我们的惯性思维是“怎么把用户拉到我的应用里来，多看看我的功能，多停留一会”；但做元服务，逻辑完全反过来了——你要想办法让用户不用进你的应用，在卡片上、在锁屏上、在负一屏，点一下就把事办完了。用户停留时间短不是坏事，说明他办事快，他下次还会用。你要是想尽办法把他往里拉，加开屏、加跳转、加广告，他转头就走了。

这不是设计规范要求，是用户用脚投票选出来的。

---

卡片不是广告位，是服务本身

我见过太多开发者把万能卡片做成了广告位：一张图、一个logo、一个“点击打开”按钮，点进去就跳APP主界面。我一开始也是这么干的，后来数据教我做人。

最早我做快递查询的元服务，2×2卡片就放个快递图标，下面写“您有X个快递”，点进去进列表页。那时候卡片点击率只有2.7%，我还觉得挺正常——不就是个通知入口吗。后来我改了一次版：2×4的卡片上直接把最近一个快递的取件码用36号大字打出来，下面加个“一键导航去驿站”的按钮，根本不需要点进APP。

改完上线第一天，点击率直接涨到27%。后台有个用户评论我印象特别深：“我以前取快递要开APP、点我的快递、找取件码，站在驿站门口举着手机找半天，现在锁屏一亮直接就能看到码，我把手机上其他三个快递APP全卸了。”

这件事给我触动特别大。以前我们做APP的通知栏推送，总怕打扰用户，发多了被关权限，发少了用户想不起来打开。但卡片不一样——它就安安静静待在用户桌面上、负一屏上，用户不需要的时候它不响不震不弹通知，需要的时候抬眼就能看到核心信息。它不是用来引流的广告位，它就是服务本身。

后来我做所有卡片都定了个规矩：任何卡片，最多点一下，必须能完成用户最常用的那个操作，绝对不许做“点卡片进APP再点按钮”这种脱裤子放屁的事。

• 查公交的卡片，直接显示最近一班车还有几分钟到，不要点进去才看；
• 门禁卡的卡片，直接弹二维码，不要点进去选哪个门；
• 外卖的卡片，直接显示还有几分钟送达，不要点进去看骑手位置。

很多人说鸿蒙卡片没什么技术含量，不就是个远程View吗？技术上确实不难，难的是思路转过来——你得真的站在用户的角度想：他掏出手机想看这个信息的时候，最想第一眼看到什么？他懒得点进去的那个步骤是什么？你替他省一步，他就会用你的东西。

---

分布式不是炫技，是真能少写一半代码

刚开始看到分布式软总线、跨端流转这些概念的时候，我觉得这就是发布会炫技用的，普通人谁会天天把手机上的东西投到平板上？直到我做社区门禁那个元服务的时候，才发现这东西是真的能省工作量。

一开始需求是：手机能开门禁，手表能开门禁，车机上也要能开门禁——毕竟很多人开车进小区，总不能停下车掏手机扫二维码吧？我当时估算了一下工作量：手机端做一个，手表端因为屏幕小、性能弱，得单独做一个版本，车机端又要做一个横屏版本，三端加起来怎么也得写小一个月。

后来我抱着试试的心态用了分布式能力，结果三天就做完了。逻辑特别简单：手机上的元服务正常生成门禁二维码，车机连接到手机的分布式软总线之后，直接把二维码的渲染指令推送到车机屏幕上，车机根本不需要装这个元服务，只要和手机在同一个华为账号信任环里，就能直接显示。手表端更简单，直接把手机上的2×2卡片推过去，手表抬腕就显示二维码，连单独打包都不用。

上线之后有个车主给我发反馈，说他以前进小区，要么掏手机扫，要么把门禁卡贴车玻璃上，现在车开到门口，车机屏幕自动就弹出二维码，抬杆就走，连手都不用抬。他说“我以为这功能得等车机版更个半年才能用上，没想到这么快就有了”。

他不知道的是，这功能我三天就写完了。

当然坑也不是没有：一开始直接把手机上的二维码推到手表上，因为手表屏幕只有1.6英寸，二维码太大，扫不上；车机横屏的时候，卡片竖过来显示，占了半个屏幕挡导航。这些适配工作花了点时间，但比我重新写两个完整应用简单太多了。以前说“一次开发多端部署”我总觉得是口号，这次真用上了才发现，分布式不是给你用来炫“碰一下传文件”这种炫酷功能的，最大的用处是帮开发者省力气——你不用给每个设备都做一套独立APP，核心逻辑写一遍，哪个设备需要就把服务推过去就行。

用户才不管你是怎么实现的，他只知道自己在车机上看到了门禁码，不用掏手机，他就觉得好用。

---

这半年踩过的最实在的几个坑，都是文档上没写的

做这半年，踩的坑能写满满一笔记本，很多都是官方文档没写明白、示例代码里没提，自己熬了好几个夜debug出来的：

第一个坑：元服务主包4MB的限制，真的不是闹着玩的。一开始我往包里塞了三张引导页的高清图、两个动画特效文件、一套全量icon，打包出来6MB，根本传不上去。一开始我还想找办法拆分包、做动态加载，后来干脆把引导页全删了——用户点进来就是充值、查快递、开门禁的，办完就走，谁看你三页引导教他怎么用啊？删完之后包大小1.8MB，冷启动速度从1.2秒变成了300毫秒，点一下就出来，反而体验更好。后来我才想明白，4MB的限制不是故意卡开发者，是逼你把没用的东西全删掉，只留核心功能。

第二个坑：别做超过两步的操作链路。我一开始做查公积金的服务，流程是“选城市→选缴存银行→输身份证号后四位→看结果”，四步，转化率只有18%。后来我做了个本地缓存：用户第一次查完，下次进来直接显示结果，只有一个“刷新”按钮，一步到位。改完转化率直接涨到62%。真的，别觉得用户有耐心一步步点，超过两步，一半人就退出去了。

第三个坑：能不用自己做账号系统就别做。一开始我想做手机号验证码登录，还要做用户体系、做云同步，后来试了下华为账号一键授权，连授权弹窗都是系统级的，用户点一下“同意”就拿到openId了，不用输验证码，不用设密码，授权率能到92%以上。而且根本不用担心用户收不到验证码、手机号换了登录不上这些破事，系统都帮你处理了。我做的几个元服务，全用系统账号，自己一行账号相关的代码都没写，省了至少一周工作量，用户还觉得方便。

第四个坑：不要乱要权限。一开始我做笔记服务的时候，想顺便拿个位置权限，自动给笔记加位置标签，结果审核直接打回来，说“核心功能不需要位置权限，禁止申请”。我一开始还觉得委屈，加个位置标签不是更方便吗？后来做了用户调研，80%的用户看到弹位置权限请求，直接就点拒绝，还有人直接退出去不用了。我干脆把位置功能做成可选的，用户主动点“添加位置”的时候再申请权限，同意率反而涨了——人都不傻，你上来就一堆权限要，他第一反应就是你要偷他信息。

第五个坑：别想办法保活、别偷偷后台跑。以前做安卓APP，总想着怎么把服务保活，怎么收推送，怎么不被系统杀掉。在鸿蒙里，别动这个歪脑筋。元服务本来就是用完即走的，系统需要的时候把你拉起来，用完了就给你杀掉，你非要做后台保活，审核百分之百过不了，就算过了被系统检测到，直接给你下架。刚开始我还想做个后台常驻提醒快递更新，后来发现系统本身就能给你发推送，根本不需要你自己后台跑。系统的推送到达率比你自己保活高多了，还省电，省点力气不好吗？

---

所谓“新生态”，新的根本不是技术

跟很多做鸿蒙开发的朋友聊天，大家一开始都在抱怨：ArkTS不如TypeScript顺手，API改来改去，文档不全，调试工具难用，包体积限制多，权限管得严，这也不让做那也不让做。

我一开始也这么想，直到我做的第一个元服务上线一个月，用户量慢慢涨上来，有很多用户评论说“这才是APP该有的样子”，我才慢慢反应过来：这些“限制”，其实根本不是限制。

以前安卓和iOS的生态，本质是个大超市：开发者把自己的APP摆上货架，想尽办法打广告、搞推送、发优惠券，把用户拉进自己的店里，想尽办法让用户多待一会、多点几个按钮、多充点钱。用户想办一件事，得先记住这件事要找哪个APP，去应用商店下载，给一堆权限，然后在APP里找半天功能，还要忍受开屏广告、弹窗推送。我们这些开发者，一半的精力不是放在把核心功能做好上，是放在怎么搞流量、怎么保活、怎么提高日活、怎么让用户多打开几次上。

鸿蒙这个新生态，本质上根本不是又一个超市。它更像一个贴身助理：你到快递站了，他主动把取件码递到你面前；你到小区门口了，他主动把门禁码准备好；你手机快没电了，他主动告诉你附近哪有充电宝；你要坐公交，他主动把公交卡弹出来。你不需要记住“我要办这件事得打开哪个APP”，不需要下载，不需要找功能，系统直接把你需要的服务递到你手里。

一开始觉得处处是限制，是因为我们已经习惯了安卓那套玩法：想怎么收集数据就怎么收集，想怎么弹广告就怎么弹广告，想怎么保活就怎么保活。在鸿蒙这里，这些路都给你堵死了：你不能乱要权限，不能弹开屏广告，不能偷偷后台跑，不能把用户圈在你的APP里。你唯一能做的，就是把你那一件核心服务做好——用户充钱的时候10秒内能充完，取快递的时候能直接看到取件码，开门禁的时候点一下就能开。你把事办得越利索，系统越愿意把你的服务推给需要的用户，用户越愿意用。

说点实在的，现在鸿蒙生态确实还有很多不完善的地方：文档写得模棱两可，有些API说改就改，模拟器跑不起来分布式功能，有些审核标准也不明确，我上周为了调卡片刷新的bug，熬到三点多才睡，当时也骂过娘。但做了这半年，我是真觉得这是个不一样的东西——它不是要做一个更快的安卓、更流畅的iOS，它是想把用户从“找APP、下APP、在APP里找功能”这个破事里解放出来。

作为开发者，其实我们要做的事特别简单：别想着做大而全的超级APP，别想着圈用户搞流量，就把那一件小事做好——用户需要的时候，你1秒内出现，点一下就把事办完，别让他等，别让他找，别给他弹广告。就这么简单。

这可能就是我做了半年，最实在的一点心得。