m0_62494390的博客

有很多想法，都想借着这个应用来实践下，最优先的可能还是云后台那一套，毕竟微信小程序也可以借鉴。元服务的开发本周基本按照预定完成了初版。还行，虽然比起预计的500条规模少了很多，但时间花销不大，即便扩充到500条规模也不需要多久。在ios平台已经有很多类似的应用，下载比较大的有西窗烛，西江诗词，句读，所以初版的逻辑，UI开发都是拿来主义---应用"缝合怪"的本质注定是以实践鸿蒙开发基础为主，其他的怎么简单怎么来。既然第一版做的内容是诗词，对应用的名字也调整了下，取"言出法随"中的前两字，图标也是豆包生成的。

是想做这个顺便学下swift的，ios只会用oc开发------后来做起了RN开发鸿蒙Next，再后来又看到了鸿蒙除了开发应用，还有元服务的说法。RN不大想写，写得太多已经公式化了，微信小程序，或者taro都是不错的选择---接近RN，又可以去接触多个平台，旧瓶装新酒。之前脑图规划的时候也想到了很多想去了解的技术点---小到灵动岛，小组件，大到swift/kotlin等新的不曾尝试的开发语言。为此也调整了作息，地铁RN的后续开发缓一缓，在没有明确后续商务的情况下优先这个元服务的开发。

其中有个浏览帖子图片并下载保存到手机相册的功能，在当初开发的时候是先借助react-native-fs把网络图片下载到临时文件夹后，再利用rn自带的CameraRoll另存到相册。所以就打算直接用react-native-camera-roll直接下载网络图片到相册的方式来实现。camera-roll有鸿蒙化版本@react-native-oh-tpl/camera-roll。处理方式很干脆------删掉createTurboModule中RNCCameraRollPermission的创建即可。

某次鸿蒙Next版本更新后，现在HarmonyRN下的ScrollView会自动去处理键盘遮挡组件了。RN里的Keyboard组件依然无法收到各种监听，但可以执行dismiss。应用第一版开发的时候提到过RN下键盘不响应的问题：react-native-keyboard-aware-scroll-view无法处理键盘遮挡。无话可说，可以用下面的代码测试下，基于react-native-keyboard-aware-scroll-view的demo。有问题可在微信公众号或者掘金社区私信留言。

开始以为是公开性质的面向大众，内容就整了个空心汤团，后来才知道是讲给同行听的（好像还得是有点道行的？事后看了下HDE的介绍，自己这是小程序猿向大佬交流经验，倒反天罡了），临时加了点技术上的交流。虽然线上的会议比较冷清，互动较少，但事后也收到一些反馈，像帮忙看看RN项目的问题什么的，有交流总是好的，多看多参与也能逼自己向前走。三十人不到的在线会议，一个是我这边的经验交流，一个是通知与实况窗的介绍。周二做了个试讲，十五分钟左右就结束了，然后周三赶紧改PPT，周四正式讲，讲了半个钟头不到点。

原因： 审核时出现闪退的原因:在ArkTS工程的entry/obfuscation-rules.txt中添加了代码混淆相关规则导致release包出现问题。将相关混淆语句注释到后通过了云测试。

最近应用被鸿蒙测试团队提了几个问题，主要集中在图片上传上面。这几天在修改，过程中对于之前提到的蓝牙和图片上传两块有了点新的认识，记录以供参考。

ArkTS下加载RNbundle，大致分为以下三个步骤创建并持有RN实例对象(RNInstance)创建RN三方组件上下文(RNComponentContext)创建UI(RNAPP/RNSurface)

项目中用到了ble蓝牙，应用启动后开始定时轮询周边蓝牙设备，根据读取到的数据判断是否是后台绑定的蓝牙设备，并返回给RN端做业务处理。

又到了瞎编点技术帖的时候，很难。题目是上周立的，正文是现在开始写的。早上十点，今天起晚了刚买菜回来，把排骨放水池里泡着，坐下来开始瞎编。

RN中对app权限的获取判断涉及到原生与js的交互，比起原生app的直接请求需要考虑交互过程中的异常处理。利用RN开发HarmonyOS Next应用同样，下面结合项目看看如何在原生(ArkTS)与RN(js)间进行权限请求交互。

由于阿里云OSS没有HarmonyOS NEXT版本的SDK，只能使用web直传方式来实现RN端的图片上传，事实上阿里云对于HarmonyOS NEXT的最佳实践也是基于web直传来实现的。

当初开发的时候列表是单独做的，没有用社区RN的组件。往往屎山就是这么造出来的。这次还是保留原样，后面的RN社区部分工作量感觉不小，就不再这上面花功夫了。虽说是列表，其实也把一整套处理富文本的逻辑都搬过去了，只是没用上多少，因为列表只是展示个文章的标题和缩略图，正文是不展示的。倒也不是白下力气，这部分后面去处理社区RN的改造是可以复用的。社区RN当年做的时候就是照着头条抄的，复杂点的地方在于富文本的排版处理。也许，把社区RN开发完，还这些吊儿郎当闲着就回过头来把这个富文本的组件好好改改，就当重新学习了。

有了第一个版本后面就好办多了。没有太多赶进度的压力，可以继续投入了。说来惭愧，9月就没投入多少时间。仲裁的事，后面是找工作还是试试自己干，预料之内，还好7/8月抓紧开发出了第一版。接下去开发就到社区这块了。今天把蓝牙优化了下，提高了点稳定性，RN里消息不会出现收到多次了。还有部分残留的小问题后面还需和鸿蒙那边一起处理下。商业转载请联系作者获得授权，非商业转载请注明出处。算来，这个RN开发鸿蒙的项目，是这段黑暗日子里唯一的光。项目第一个版本上架了。

早上六点多就赶去现场开会，虽然没我什么事就当个听众，但也了解到阿里负责开发的另一款App已经完成测试验证只待发布了。这里面都是国民哥的工作了，我要保证的是开发顺利。商城在做鸿蒙化之前的上一个迭代中已经完成了taro输出H5的改造，只是目前生产环境的配套后台没上。社区还得做大量的开发，这里面有实打实的大量工作，准备9月开始按需开发。图片上传的问题解决了，找了响哥看了现在的后台代码，拿到了目前PC端使用的上传接口调通了。周末还得整理下下周仲裁的材料，盘算下下周跑几个地方，执行法官约谈了，准备一天跑完。

兜兜转转，直到把以前的旧工程在另一台笔记本上跑起来，一对比参数没什么区别，这下终于怀疑是md5计算的第三方了。之前用的md5是鸿蒙三方库里的react-native-md5，问题就出在这个依赖的计算上。现在的办法比较粗暴，一方面把通知里面调用后台查询的逻辑去掉，放到root.tsx页面全局统一去做，另一方面靠global变量，做了防抖，尽量减小少触发次数，最终实现最多一秒触发一次。RN的开发也算是把功能基本做出来了，现在想着先收一收，把已知的几个问题解决下，8月能提个版本给遥遥领先。接着干呗，天快亮了。

App上下岗有点问题，线路车厢号如果开了自动上岗会显示不出，推断是state变量的问题，还没找到原因。还得补一补React的函数式编程才行，护行页面的变量使用有点乱，老毛病一直没梳理。所谓的大部分开发，也就是能凑合用的意思。把鸿蒙的ide更新到了5.0.3.600，跑起来也没什么问题。下周得弄被迫离职，强制执行这些了，时间又开始紧张起来，拉拉扯扯五月搞到8月，得亏八月都在家不然天天无薪上班又是亏到姥姥家。还有个图片上传的问题还没搞定，那个应该是接口问题或者调用方式，和鸿蒙跟RN都没关系。

可能下周还得去一趟，还得给其他领导汇报，不清楚，有些累人，X企开会有点绕，各种支线剧情。当初公司的二把手，最后也是在一起讨生活，各有各的难。老婆在教小孩作业，房间里正上演着鸡飞狗跳的剧情，很难集中精力，这段日子也就索性晚上不干活了，都白天猛干。晚上突然发现公众号上有哥们给我留了言，问了RN开发鸿蒙debug的事，回复交流了下，毕竟我也没搞定RN的debug，现在都是靠console勉强维持开发，效率比较低。用了七八年的咖啡机突然坏了，晚上倒腾了半天，怀疑是里面的电磁阀坏了导致没法上水。

A:到目前为止，对于用RN来开发所谓的纯血鸿蒙，可以看到在发布会是提到RN支持的(印象中还提到了Flutter)，但其中的技术资料，还没有公开。即便对于我这种基本不熟悉RN新架构的人来说，看看文档也就一步三摇上路了（文档不复杂，篇幅也不大，都是开发的基础，教你怎么直接上路，不整花活挺好）。算是有点心得体会了把。js->native利用RN新架构的turboModule，按照套路来，我没有用codegen生层代码的方式，而是基于demo的turboModule手动修改，这样开发阶段更加灵活便于随时修改。

React-Native开发鸿蒙NEXT