鸿蒙生态的机遇与挑战

鸿蒙生态的现状

从一个程序员的角度看，鸿蒙的崛起路还很长，主要是面临的问题很多。

鸿蒙首先分为OpenHarmony和HarmonyOS两种，前者为开源项目，在4.0版本开始已经不再支持安卓，HarmonyOS从5.0也就是Harmony Next版本开始不再支持安卓，HarmonyOS Next从某种意义上来说，算是OpenHarmony4.0的一个衍生产品吧。

鸿蒙生态下开发时遇到的挑战

机缘巧合，公司的一个客户点名要求我们的SDK支持OpenHarmony4.0，原以为可以直接上Android SDK省点事，可客户说版本是4.0.10，没办法了，Android已经跑不了了。公司根本没有人做过鸿蒙，外包公司也找了，鸿蒙方向的人才真的是少的可怜。

由于公司做的是硬件产品，设备的控制需要和C层接口打交道，但面试了很多人，基本都是只会ArkTs的，涉及napi的并不多，没办法，自己硬着头皮尝试着做一个最简单的demo给客户，但中间遇到的问题真的不少。

首先IDE的版本，5.0和4以前的版本，看上去就是两款工具，5.0以后，只有OpenHarmony SDK，不再把HarmonyOS SDK单列出来了，致使我误认为自己安装错了。

第二，从SDK来看，不管是native SDK还是arkUI都只有10-12的版本，不再支持9及以前了，基本可以确定，9以前是被废弃了，这就意味着之前适配过鸿蒙的应用全白做了，对于企业也是巨大的负担。

第三，从官方文档看，示例并不多，尤其是我想要找的示例，至少一半找不到。加上一些全新的涉及思路，比如worker和taskpool彻底代替thread的概念，使得自己一时难以适应。napi层对于线程的使用也是有很大风险存在的，同时，官方示例也不能完全信任，照着官方文档写出来，一运行就appcrash，真的有些头疼。我之前的博文里也有提到，主要还是使用者太少，慢慢来吧

第四，第三方库很多都会依赖一些系统底层的库，虽然架构都是armeabi-v7a，arm64-v8a，x86_64的，但其它环境的clang或gcc编译出来的动态库大概率会遇到依赖库问题而无法运行，虽然使用cmake编译时不报错，但运行时就会提示napi层接口不存在。解决这个问题的方法只能是把相关的库使用鸿蒙方式重新编译，工作量确实有些大。

第五，设备能力和权限问题，由于我用的是openHarmony的开发板，在HarmonyOS模拟器里可以运行的东西，到了openHarmnoy的开发板上就各种错误，甚至是syscap导致安装都是问题，对于开发者来说，要有一个适应的过程才行。

鸿蒙生态未来的发展趋势

最近，微信和鸿蒙之间的较量一直被人热议，从我的角度看，鸿蒙虽然被国家认可，但其实并没有被绝大多数普通用户认可，鸿蒙现有的APP数量不足2万，而安卓有150万，这个差距太大。而对于微信，依赖它的人太多，抛开社交工具属性不说，单支付市场，微信就占用70%，银联都头疼。有些人会说，我就不用微信支付，当然，你不用别人会用。微信给的理由是需要所有权限，但鸿蒙核心的思想之一是隐私保护。至于最终如何解决，我个人的看法是华为会偷偷妥协，先让用户愿意使用，市场占有率上去了，微信自然就只能乖乖的，就像适配安卓一样适配鸿蒙了。苹果不也妥协降低了支付费率吗？这并不丢人。

其它app，重量级的app目前还是测试版本，适配的路还长。

未来，鸿蒙会是一个热门赛道，但大厂从内部培养开发人员的可能性比较大，对于想转行的程序员来说，竞争可能会比现在的java还大，毕竟，岗位比较少。目前来说，鸿蒙的核心开发人员都在华为以及华为的外包公司，如果能接受外包，鸿蒙赛道还是比较宽的。未来5年，华为的生态能发展成什么样，可能会直接决定了华为的未来，毕竟，国内外的竞争还是很大的