geesehoward20000的博客

PC端回调是同步的，所以不会有任何问题，释放时不会有任何地方去使用这个地址，但harmony不行，回调是异步的，指针释放时，部分回调操作不能保正完成，而且，底层库和napi层也无法用锁或者其它方式同步。查了一下资料，官方的资料并不多，只是给了简单调用示例，后来从部分文字中看出，线程安全函数是把回调放入队列来执行，并发立即执行，这也是为什么回调在接口return之后才执行，因为接口是队列中正在执行的任务。没办法，改逻辑，把回调放到专用线程里，保正线程不会停止，原接口内的各个线程，都不在调用本线程内的回调。

接口定义可以看出，C#有2重定义，C#调用会比Java更复杂，由于C结构体中定义的char*并非真正的字符串，而是指针，C#的string与char*并不能直接转换，加上汉字乱码问题，所以，调用C层接口前，需要做如下封装处理。上一篇简单说了回调函数，其中回调函数包含更复杂的参数，结构体等，所以，本系列的第三篇先说一下结构体，由于内容会比较多，本篇先说Java(Jna调用、Jni比较复杂，如有需要，后面再单独来将)、C#两种比较常见的开发语言。接下来我们来看一下Java的Jna改如何调用。

先来看一下C接口的定义，这个回调比较简单，参数只有一个const char*#else#endif#endif//消息回调函数#endif这里是初始化SDK，并设置消息推送的回调函数，C语言的调用方式比较简单elseJava调用C接口有2种方式，Jni和Jna，Jni需要编写C层代码，运行的适应率更高，包括一些ZF、JF的SM机都可以正常运行，Jna由于运行时需要在临时目录下解压jar包，可能会有权限问题。

C变量类型Java变量类型C#变量类型python变量类型arkts变量类型备注intintintc_intnumberlonguintc_uintnumbershortshortshortc_shortnumberintushortc_ushortnumberlongintintc_longnumber32位系统中，C中的long型占4字节，可以当作int来使用longuintc_ulongnumber。

第三，从官方文档看，示例并不多，尤其是我想要找的示例，至少一半找不到。第五，设备能力和权限问题，由于我用的是openHarmony的开发板，在HarmonyOS模拟器里可以运行的东西，到了openHarmnoy的开发板上就各种错误，甚至是syscap导致安装都是问题，对于开发者来说，要有一个适应的过程才行。由于公司做的是硬件产品，设备的控制需要和C层接口打交道，但面试了很多人，基本都是只会ArkTs的，涉及napi的并不多，没办法，自己硬着头皮尝试着做一个最简单的demo给客户，但中间遇到的问题真的不少。

查看clang.cmake(位于Sdk的native/build-tools/cmake/share/cmake-3.16/Modules/Compiler/Clang.cmake)今天看了一下cmake相关的脚本，首先，在ohos.toolchain.cmake(位于SDK的native/build/cmake目录下)要让警告消失，可以把ohos.toolchain.cmake中262和263行注释掉，一般的C/C++库都可以正常编译通过。注意到257、262、263行的内容如图。

发出来的是个300多K的数据，传过来只有10K，查了官方资料并没有特殊说明，只能猜想是emitter最大只能传输10K的数据，毕竟这是个消息订阅机制，大数据还是postMessage比较好。本来是一个很简单的需求，异步采图在主界面上显示，用emitter来订阅并发送消息传数据，由于EventData是json格式，所以图像要先base64编码，界面显示的数据也恰好可以是base64，没有什么问题，于是动手。感觉自己要疯掉了，这么简单一个数据传递，居然不对！记录一下，避免以后再踩坑。

后来逐步接触高级语言对C接口的调用，毕竟，底层C开发要比高级语言性能好，这就涉及到一个无法回避的问题，C的很多类型对于高级语言并不友好，比如指针、结构体、函数指针、回调等等。至今用到过的语言也比较多，常见的Java、C#、python，不常见的Delphi，PB以及最近非常热门的鸿蒙等等。开这个坑就是想记录一下自己遇到过的各种花式调用情况，以及遇到的让人头大的问题，以及一些解决方法。当然也会有至今没遇到的情况，边写边看吧。坑先开着，啥时候填也不知道，内容太多，工作之余来写，时间不固定，能不能写完就随缘吧。

鸿蒙napi层也有一套USB的通信接口，官网看了一下，还是有点复杂，需要借助arkts获取deviceid后，传入napi层才可以通信，目前还没有尝试，以后有机会或许可以试一下。拿来嵌入式组的通信库代码，选则出连接设备的代码片段，编译成napi，调试运行，意外的顺利，打开成功了，剩下的问题就是通信了。拿来开发板，插上设备，lsusb看了一下，设备节点正常，shell用户可以正常看到，而且看到节点权限666，感觉有希望。拿来一段简单的通信代码，编译，调用，结果意外的顺利，通信完全正常。

SDK初始化接口中有一个推送的回调函数，会把SDK的中间状态等信息推送给调用者，以便和用户交互。那么问题来了，初始化接口不管是在主线程调用还是work线程调用，推送回调接口被调用的时机和线程都是不确定的，重要的问题就是要在任何线程调用回调时，界面都能有反应。主要提供线程间发送和处理事件的能力，包括对持续订阅事件或单次订阅事件的处理、取消订阅事件、发送事件到事件队列等。参考示例略作修改，加入到程序里，目前还没有测试，后面有了结果再更新，总感觉不会这么顺利。官方资料查询了一下，发现了。

底层C/C++库需要初始化时，设置回调函数，供其它接口回调时使用，其它接口为异步调用。其中，回调内用了消息订阅，将回调信息发送给主线程，这里是否需要消息订阅，还没测试。

熟悉IDE的会说，去build目录里复制出来就行了。没错，可以这样，但个人很不喜欢，so文件在build目录里真的太深了，不只目录深，隐藏的也深。可以看到，cmake编译时的命令就在这个文件里，这样就好办了，自己写一个批处理，已有动态库编译成鸿蒙版本就可以和其它CPU架构一样了。仔细观察编译生成的路径，在.cxx目录下，有一个metadata_generation_command.txt文件，打开文件，内容如图。至于Cmakelist.txt的编写，这里就不详细介绍了，其实并不难，而且大多数人也是会的。