安卓上的小组件，跟 Windows 上的桌面小组件一样，一直是个鸡肋。我这么说倒不是针对开发者，而是针对用户。从这么多年的使用上来看，这些小组件如果是使用更基础的开发方式实现的话，就能达到一些很酷奇的效果，一旦被官方所规范化之后，几乎就都成了花瓶，实用性一败涂地。Windows 从 Vista 开始，甚至可以远追 Active Desktop 时代，在这一块都铩羽而归，据说目前在 Windows 11 上又蠢蠢欲动了。

安卓下的情况稍微好一点，但也没好到哪儿去，尽管听说有团队运营小组件年入千万量级，尽管连高冷的苹果都被安卓给拐带到了这一条不归路上。鸿蒙的生态以安卓打底，故而在这块也没落下，甚至于很看重，在小组件的基础上推出了功能更强劲的服务卡片，用以为 app 更好地向用户提供服务入口，特别是在不需完整打开整个 app 的前提下。但对于一整个操作系统来说，这个领域毕竟还是属于一个边缘地带，因此上出现一些奇奇怪怪的问题也就不足为奇了。

安卓在古早的版本上，要创建桌面小组件的话，必须从桌面上进入（例如执行长按操作，或者，华为系将操作改为捏合手势），甚至直到现在，Vivo 系还一直坚持以这种方式作为创建桌面小组件的唯一途径。其实这种创建方式非常蠢笨。由于大部分 app 都会出于要占领桌面部分区域的考虑出发而决定加入对桌面小组件的支持（姑且不论支持得好不好以及是否确实必要），你要创建某个 app 的小组件的话，但就创建动作一开始，就要在一大堆的列表项中寻找目标。也必然是基于此痛苦，安卓在中期就添加了新的 API 给到 app，允许 app 主动向系统发起请求，向桌面添加一个小组件。这样做的好处还有，可以先设计、调整小组件的外观和行为，把创建动作留在最后一步，而不是倒过来。

在 app 向系统申请往桌面上添加小组件的时候，有一个参数可以供 app 向用户即时提供小组件的预览。而在这个参数的支持上，鸿蒙系统不知出于什么原因，竟然阉割掉了，只能使用 app 内预制布局作为预览，这个特性和其他绝大部分的安卓派生变种都不一样，也为适配带来了额外的繁琐。

纵观国内的手机厂商，在对安卓系统进行定制时，华为显得势大力沉，经常过度设计（并实现）；小米则显得鸡贼无处不在，能省事就省事，能偷懒就偷懒，前有直接使用工作资料机制来凑合用于提供给用户双开/分身功能，后有在实现小组件创建成功后的回调里不返回组件 ID 的对开发者的小暗器。而且，在安卓 13 的移植过程中，更是把之前允许桌面更新请求不限速的国产优势给遗漏了，可见萝卜快了不洗泥。

除此外，前几天还发现了个怪现象：京东竟然可以在鸿蒙系统的桌面上创建出服务卡片来。这个发现一开始差点把我下巴惊掉。如果说京东为了鸿蒙，把整个安卓 app 全部都重新实现了一遍，那是打死我也不信的。好在一番搜索之后发现了端倪，具体请参看《京东APP鸿蒙版上架实践》。在这篇文章里，说明了至少几点：1. 京东 app 确实为鸿蒙做了适配，并按照华为应用市场的规范提交了上架应用包；2. 京东最大程度地利用了安卓 app，对于鸿蒙桌面的服务卡片的支持属于在原有基础上的锦上添花；3. 鸿蒙系统无论有意还是无意，为安卓应用套壳后再增加鸿蒙特性提供了支持。

在这些认知下，其实俺觉得鸿蒙要是直接支持传统的 apk 里通过导入一些桥梁库来增加对鸿蒙特性的支持那就更好了。跟京东 app 目前的实现相比，开发过程基本相同，主要不同在于最终的形态。当前京东 app（其实还有优酷和知乎两家）的封包肯定是 hap 格式的，而我希望的设想则是能够保持 apk 形态，且能一包两用，在非鸿蒙系统上安装的话，开发者把鸿蒙相关特性屏蔽掉即可。有利于开发者提升效率，最终也会有利于鸿蒙自身。

所谓的安卓和鸿蒙混合开发，还有一篇简略的操作指南，《Harmony 鸿蒙 Android 安卓混合开发》。