一、关于统一开发和模块开发
首先经过这几天的开发，其实你会发现它还是挺有自己的风格的。
但是它这个风格也让我比较困惑。首先就是即使是纯后台应用，它其实也是才用了前后混合开发的模式。当然，这是IDE自己搞的。如果你手动编译会不怎么收到这个的影响。
前店后厂的开发模式
鸿蒙的声明式UI和内包代码的风格，对一个纯程序员来说还是相当友好的。至少不用费太大的精力去搞一些界面的东西。而且IDE原生带有前段部分的ARKTS对于想要带界面的原生应用开发者还是折中友好一点。
对于几大硬件接口的天然缺失
首先我说一下，鸿蒙这里不是真没有，而是资料是少到可怜。
鸿蒙对与这部分IO的库支持也不咋地。
它默认有串口的设备代码，但是开发环境却默认不带。
二、第三方库及挂载使用
鸿蒙这方面做的很好。关于第三方库做了很多常见库，而且这些库都在一个统一的编译脚本下。非常统一，很多编译工作能简单非常非常多。
1、关于lycium
lycium是鸿蒙官方出品的关于编译第三方库的工具。它集成了大量常用第三方库，以及对应的编译命令。
OpenHarmony-TPC: https://gitee.com/openharmony-tpc
正常情况下，集成第三方库有两种方式，
hap方式和rom方式。
其实hap就是集成到你的app里，rom方式只有你做系统环境时候采用。如果只是要开发个应用，倒也没必要这么费劲。当然，如果需求太多有时候还是需要定制系统。
三、应用程序开发
1、原生应用的四要素
原生应用和askTs开发有区别。而且二者还需要进行交互。同时程序入口其实还是从arkTs中进入的。所以就必须搞懂接口的四个要素。arkTs如何识别到库，如何将原生接口转换为native环境的接口，native接口如何编写，如何隔离native接口与原生C++代码开发。即怎么使用，怎么转换，怎么编写，怎么隔离。
正常开发是统一执行环境不需要隔离。但是native形式就必须隔离。不然代码没法复用。
1.1、怎么识别库
首先要知道一个前提，那就是native接口其实最终还是被作为了arkTs的一个子模块加载进了环境。因此它导入的其实是.so文件作为一个库被整体导入。其中被宏导出的函数将通过nodejs的转换进入到环境中。只要符合native的吧先来那个类型，他会自动接管变量类型。
export const add: (a: number, b: number) => number;
这里是index.d.ts文件。也就是ts的定义文件。它定义了一个外部接口的基本信息。形参及返回值。
目前我还没找到这个文件是否能被拆分，怎么拆分的问题。毕竟函数多了它内容太多了
当然，你可以拆成多个so库文件
import entryInterface from 'libentry.so'
这里导入了库文件。当然这里import后面跟着的其实是from后面的别名，因此这个名称自己写就行（我一开始还以为要配置文件配，后来测试了才发现这只是个别名，自己喜欢怎么写就怎么写）
当然，这里其实还有个疑惑，那就是泽呢么切换，怎么创建子目录，怎么处理名字冲突。
1.2、怎么转换
其实这里和安卓的做法是一样的。不只是安卓，绝大多数基于容器或者类容器的这类开发都是这个套路。整个大环境以env的形式进行传递。而系统编译器将接口的原生变量通过宏的形式进行封包。从而只要知道native的宏列表就知道环境里本质上需要的是那种类型和格式的变量了。
看到简单且明了的接口转换，可能很多传统嵌入式开发者就跃跃欲试，希望原生开发应用，上层只负责呈现。毕竟这样最接近自己的知识范围。
但是上面那段我只是说为了给需要额外附加库中没有的功能而写的。
其实它的接口转换是基于底层C接口，除非你特别愿意写面向对象的C语言接口，否则，你在c++中的对象优势，在ts中灵活好入手的优势会被你通通丢掉。
当然，我下周再开发数据处理的时候会试试这里是不是可以直接传C++。毕竟它在接口部分又没写extern_c
1.3、怎么编写native接口
这里看似一大堆native的类型。但是其实这个函数大部分都是为了类型对接做准备的。这里并不用太纠结原生类型。甚至你可以按照json的形式为其传值。
它依然保留c++环境中的基本内容，当你写逻辑代码的时候依然要遵循传统的开发模式。
当然，这里我推荐将这个静态接口函数就只当做一个数据中转站，真正的业务逻辑继续下放。
1.4、怎么隔离native和传统c++的环境
我们想要搞一个易于代码复用，且功能宏大的原生应用时，那么隔离接口就成了必不可少的工作。要让真正的逻辑代码中不存在什么native_ ，就必须知道这二者的边界在哪。
其实吧，它没有真正意义上的环境边界。毕竟你在一个类似于ulibc的库环境下（注意，鸿蒙用的也不是gnu的glibc。所以代码模块和常规linux并不通用。这个更小更快，但功能更少）。但是在编写代码内容的时候是可以逻辑隔离的。毕竟很多代码你复制到别的编译器是没问题的。
从函数的角度来说，你的函数接口退出了就退出了。但是native这个大环境会随着你的.so文件一直存续。因为你的全局变量，管理对象等要直接放入你的native环境里。你的上层环境只是调用对象的接口，而你的后台任务对象其实还在native环境里运行。
比如说我获取一个mqtt的任务读取任务。此时这个任务始终在后台环境中自顾自忙碌。而我的上层接口不过是不断获取数据，或者被通知数据。
当然，极端一点的情况就是整个逻辑都在下层进行，顶层只负责进函数接口。
德赢Vwin官网
论坛
0
/6 
工商网监
湘ICP备2023018690号
1442
淘帖
感谢分享
赞
回复
显身卡
