HarmonyOS 开发现在是个不小的热度。但是这个玩意目前有坑，很容易就掉坑里，导致项目后期的维护成本陡然升高。
目前就总结下我的经验吧，也是一个避坑指南吧，后续遇到了其他问题再补充。
网络库
HarmonyOS系统有两套网络库（这个锅，华为必须背）：
- @ohos.net.http(不推荐，包括所有基于此的三方库，例如 axios)
- rcp（推荐）
这个坑掉进去了，后期切换网络库的成本是很高的
理由：
@ohos.net.http已经不会再演进了！，请看官方说明🤧@ohos.net.http不支持 HTTP3/QUIC 协议，rcp支持rcp使用方式简单，已经进行很好的封装了，各位只需针对业务自己包装下就行了@ohos.net.http功能不完善，rcp支持的网络功能更完善
| 功能分类 | 功能名称 | 功能描述 | HTTP | RCP |
|---|---|---|---|---|
| 基础功能 | 发送PATCH类型请求 | 以PATCH的方式请求 | 不支持 | 支持 |
| 基础功能 | 设置会话中URL的基地址 | 会话中URL的基地址将自动加在URL前面，除非URL是一个绝对的URL | 不支持 | 支持 |
| 基础功能 | 取消自动重定向 | HTTP请求不会自动重定向 | 不支持 | 支持 |
| 基础功能 | 拦截请求和响应 | 在请求后或响应前进行拦截 | 不支持 | 支持 |
| 基础功能 | 取消请求 | 发送请求前取消、发送请求过程中取消、请求接收后取消 | 不支持 | 支持 |
| 基础功能 | 响应缓存 | 是否使用缓存，请求时优先读取缓存。缓存跟随当前进程生效，新缓存会替换旧缓存 | 不支持 | 支持 |
| 基础功能 | 设置响应数据的类型 | 设置数据以何种方式返回，将要响应的数据类型可设置为string、object、arraybuffer等类型 | 支持 | 不支持 |
| 基础功能 | 定义允许的HTTP响应内容的最大字节数 | 服务器成功响应时，在获取数据前校验响应内容的最大字节数 | 支持 | 不支持 |
| 证书验证 | 自定义证书校验 | 自定义逻辑校验客户端和服务端的证书，判断是否可以连接 | 不支持 | 支持 |
| 证书验证 | 忽略SSL校验 | 在建立SSL连接时不验证服务器端的SSL证书 | 不支持 | 支持 |
| DNS | 自定义DNS解析 | 包括自定义DNS服务器或静态DNS规则 | 不支持 | 支持 |
| rcp特有 | 捕获详细的跟踪信息 | 在会话中的HTTP请求期间捕获详细的跟踪信息。跟踪有助于调试、性能分析和深入了解通信过程中的数据流 | 不支持 | 支持 |
| rcp特有 | 数据打点，获取HTTP请求的具体数据 | HTTP请求各阶段的定时信息 | 不支持 | 支持 |
图片加载库
由于社区生态问题，没有比较好的网络加载库，京东家的JDImage又不开源，目前只有官方的@ohos/imageknife可用，但是这个库bug多，性能差，代码质量差！仅仅只是能用！
这不，为了性能，官方直接出了个 C 的版本……哈哈哈哈哈，来，请瞻仰@ohos/imageknifec
所以避坑的点来了： 一定要对这个组件二次封装，方便以后替换，华为自己搞了太多的三方库，一个公司要写完以前整个社区的开源库，还都不烂尾，你信么？还不如信我是秦始皇
路由框架
这个的选择要慎重，不管是官方的@hadss/hmrouter，还是其他第三方的，都是侵入性很强的东西，大家自己慎重做好选型就行了。我们考虑了很多，最后是自己实现的动态路由方式。
复杂逻辑
这里指的的业务上复杂的逻辑，例如庞大的CPU密集型计算、上万代码的计算量，对多线程性能有高要求的。建议直接仓颉语言写，完了再用ArkTS调用。千万不要对ArkTS抱有幻想。群里已经有好几兄弟深陷其中，无法解决，用C++或者仓颉重写工作量实在太大了。
(来，文档在这，仓颉和 ArkTs 互调的恶心程度🤢)
小声的吐槽
这个问题，华为更是要背锅，一个还没release的系统，搞出两套完全不兼容的语言体系。666
iOS的OC和swift，Android的Java和Kotlin，都是由于历史演化，平滑过渡到更现代化的语言上，同时保证了生态的稳定过渡，语言之间的互操作性。
而这一切，在ArkTS和仓颉上来说，就是个梦（我就看华为怎么圆这个梦）。
结尾
宣传下自己的开源库吧，图片裁剪：
