一、关于统一开发和模块开发

首先经过这几天的开发，其实你会发现它还是挺有自己的风格的。

但是它这个风格也让我比较困惑。首先就是即使是纯后台应用，它其实也是才用了前后混合开发的模式。当然，这是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的任务读取任务。此时这个任务始终在后台环境中自顾自忙碌。而我的上层接口不过是不断获取数据，或者被通知数据。

当然，极端一点的情况就是整个逻辑都在下层进行，顶层只负责进函数接口。