本文是基于HarmonyOS API 24的进行的ReactNative 鸿蒙跨平台开发依托适配鸿蒙的 RN 运行层使用 React 与 JS 编写一套业务代码无需大量 ArkTS 原生开发通用业务实现代码复用支持按需扩展原生桥调用鸿蒙特有能力有效降低多平台开发维护成本。ReactNative 鸿蒙跨平台开发简单来说就是基于 ReactNative 技术栈依托鸿蒙平台适配层使用 JavaScript 与 React 语法编写一套业务代码经过编译适配后同时支撑鸿蒙应用、安卓、iOS 等多端运行的开发方案。开发者沿用前端熟悉的组件化、状态管理等 React 开发范式不用分别针对鸿蒙原生 ArkTS、安卓原生、iOS 原生独立实现相同业务逻辑依靠桥接层完成 JS 逻辑与鸿蒙原生能力的通信调用鸿蒙的窗口、媒体、设备硬件等系统接口最终打包生成鸿蒙应用安装包兼顾开发效率与多端复用能力同时也存在部分鸿蒙特有系统能力需要编写原生桥模块进行扩展适配复杂交互、高性能场景下要权衡跨平台通用方案与原生开发的取舍。ReactNative 鸿蒙跨平台开发优势1.前端开发者直接复用已有的 React 开发经验与存量业务代码一套代码可同时产出鸿蒙、安卓、iOS 多端应用大幅降低多平台分别开发、维护的人力与时间成本迭代更新时多数业务改动只需修改一处代码就能同步生效2.借助 JS 热更新机制还能绕过应用商店快速推送功能修复与轻度版本变更3.依托成熟的 React 生态海量第三方组件、工具库可以直接接入不用从零适配鸿蒙原生开发体系上手门槛更低4.熟悉网页与 React 技术的开发人员可以快速转型参与鸿蒙应用建设5.框架内置 JS 与原生的通信桥基础 UI、网络、存储等通用设备能力开箱可用大部分常规业务场景无需编写原生扩展模块同时支持按需开发鸿蒙原生桥接模块调用系统独有能力在跨端复用和平台特性之间保留灵活平衡相比纯原生多端开发团队可以更快完成产品落地适合业务频繁迭代、需要同时覆盖多终端的中小型应用场景。–Python 装饰器的作用是使函数包装与方法包装一个函数接受函数并返回其增强函数变得更容易阅读和理解。最初的使用场景是在方法定义的开头能够将其定义为类方法或静态方法。如果不用装饰器语法的话定义可能会非常稀疏并且不断重复class WithoutDecorators:def some_static_method():print(“this is static method”)some_static_method staticmethod(some_static_method)def some_class_method(cls):print(“this is class method”)some_class_method classmethod(some_class_method)如果用装饰器语法重写的话代码会更简短也更容易理解class WithDecorators:staticmethoddef some_static_method():print(“this is static method”)classmethoddef some_class_method(cls):print(“this is class method”)一般语法和可能的实现装饰器通常是一个命名的对象不允许使用lambda 表达式在被装饰函数调用时接受单一参数并返回另一个可调用对象。这里用的是“可调用callable”。而不是之前以为的“函数”。装饰器通常在方法和函数的范围内进行讨论但它的适用范围并不局限于此。事实上任何可调用对象任何实现了__call__方法的对象都是可调用的都可以用作装饰器它们返回的对象往往也不是简单的函数而是实现了自己的__call__方法的更复杂的类的实例。装饰器语法只是语法糖而已。看下面这种装饰器用法some_decoratordef decorated_function():pass这种写法总是可以替换为显式的装饰器调用和函数的重新赋值def decorated_function():passdecorated_function some_decorator(decorated_function)但是如果在一个函数上使用多个装饰器的话后一种写法的可读性更差也非常难以理解。作为一个函数编写自定义装饰器有许多方法但最简单的方法就是编写一个函数返回包装原始函数调用的一个子函数。通用模式如下def mydecorator(function):def wrapped(*args, **kwargs):在调用原始函数之前做点什么result function(*args, **kwargs)在函数调用之后做点什么并返回结果return result返回 wrapper 作为装饰函数return wrapped作为一个类虽然装饰器几乎总是可以用函数实现但在某些情况下使用用户自定义类可能更好。如果装饰器需要复杂的参数化或者依赖于特定状态那么这种说法往往是对的。非参数化装饰器用作类的通用模式如下class DecoratorAsClass:definit(self, function):self.function functiondefcall(self, *args, **kwargs):在调用原始函数之前做点什么result self.function(*args, **kwargs)在调用函数之后做点什么并返回结果安装DevEco Studio程序选择目标安装目录设置环境变量但是需要重启一下新建一个空白模板设置API为24的模板项目初始化项目自动下载相关依赖return result参数化装饰器在实际代码中通常需要使用参数化的装饰器。如果用函数作为装饰器的话那么解决方法很简单需要用到第二层包装。下面一个简单的装饰器示例给定重复次数每次被调用时都会重复执行一个装饰函数def repeat(number3):“”“多次重复执行装饰函数。返回最后一次原始函数调用的值作为结果:param number: 重复次数默认值是 3“””def actual_decorator(function):def wrapper(*args, **kwargs):result Nonefor _ in range(number):result function(*args, **kwargs)return resultreturn wrapperreturn actual_decorator这样定义的装饰器可以接受参数repeat(2)… def foo():… print(“foo”)…foo()foofoo注意即使参数化装饰器的参数有默认值但名字后面也必须加括号。带默认参数的装饰器的正确用法如下repeat()… def bar():… print(“bar”)…bar()barbarbar没加括号的话在调用装饰函数时会出现以下错误repeat… def bar():… pass…bar()Traceback (most recent call last):File “”, line 1, inTypeError: actual_decorator() missing 1 required positionalargument: ‘function’保存内省的装饰器使用装饰器的常见错误是在使用装饰器时不保存函数元数据主要是文档字符串和原始函数名。前面所有示例都存在这个问题。装饰器组合创建了一个新函数并返回一个新对象但却完全没有考虑原始函数的标识。这将会使得调试这样装饰过的函数更加困难也会破坏可能用到的大多数自动生成文档的工具因为无法访问原始的文档字符串和函数签名。但我们来看一下细节。假设我们有一个虚设的dummy装饰器仅有装饰作用还有其他一些被装饰的函数def dummy_decorator(function):def wrapped(*args, **kwargs):“”“包装函数内部文档。”“”return function(*args, **kwargs)return wrappeddummy_decoratordef function_with_important_docstring():“”“这是我们想要保存的重要文档字符串。”“”如果我们在 Python 交互式会话中查看 function_with_important_docstring()会注意到它已经失去了原始名称和文档字符串functionwithimportant_docstring. _name __‘wrapped’functionwithimportant_docstring. _doc __‘包装函数内部文档。’解决这个问题的正确方法就是使用 functools 模块内置的 wraps()装饰器from functools import wrapsdef preserving_decorator(function):wraps(function)def wrapped(*args, **kwargs):“”“包装函数内部文档。”“”return function(*args, **kwargs)return wrappedpreserving_decoratordef function_with_important_docstring():“”“这是我们想要保存的重要文档字符串。”“”这样定义的装饰器可以保存重要的函数元数据functionwithimportant_docstring. _name __functionwithimportantdocstring.’functionwithimportant_docstring. __doc __‘这是我们想要保存的重要文档字符串。’