跳到主要内容

· 阅读需 10 分钟
JSZ
JJ

一、背景

鸿蒙作为华为自研开发的一款可以实现万物互联的操作系统,一经推出就受到了很大的关注,被国人寄予了厚望。而鸿蒙也没让人失望,今年 Harmony2.0 正式推出供用户进行升级之后,在短短的三个月内实现了 1.2 亿的装机量,并且在前不久的华为开发者大会上,华为宣布 Harmony2.0 的装机量已经突破了 1.5 亿。

众多应用厂商都逐步推出了适配的鸿蒙应用,Taro 作为一个开放式的 跨端跨框架 解决方案,不少开发者期待将小程序的能力移植到鸿蒙 OS 上,可以使用 Taro 开发鸿蒙 && OpenHarmony 应用。

鸿蒙的方舟开发框架提供类 Web 范式编程,支持使用 JS 开发 UI 层,其语法与小程序相接近。经过前期调研,可以沿用 Taro 现有的架构适配鸿蒙

今年 6 月份我们新建了支持鸿蒙的提案,希望能达成三大目标:

  • 开发者可以使用 Taro 开发鸿蒙应用。
  • 开发者可以把现有的 Taro 应用适配到鸿蒙平台。
  • 开发者可以使用 Taro 的反向转换工具,把原生开发的小程序转换为 Taro 应用,再适配到鸿蒙平台。

目前 Taro 和 OpenHarmony 建立了官方合作关系,受邀并成立了跨平台前端框架兴趣小组(SIG-CROSS-PLATFORM-UI),同时 Taro 与华为鸿蒙 && OpenHarmony 保持着内部沟通与分享,Taro 拥有的海量开发者和优秀案例,能有效补充华为鸿蒙 && OpenHarmony 生态。

二、实现细节

鸿蒙的 JS UI 语法与小程序类似,但毕竟两者底层原理不一样,不可避免地存在许多差异。接下来将简单介绍鸿蒙与小程序的主要差异,和 Taro 又是如何处理这些差异的。

1. 鸿蒙与小程序的异同

1.1 项目组织

鸿蒙的项目组织和小程序类似,有入口文件 app.js 、页面、自定义组件。

其中页面、自定义组件均由三类文件组成:

  • .hml 用来描述布局结构。与小程序的模板文件相比,语法、支持的能力有少许区别。
  • .css 用来描述页面样式。
  • .js 用于处理页面和用户的交互,默认支持 ES6 语法。

1.2 配置文件

和小程序规定的入口文件、页面文件、自定义组件各自对应一份配置文件不一样,鸿蒙 JS UI 的配置文件只有一份。

鸿蒙的路由和小程序一样是配置式的,需要在 JS UI 的配置文件中进行配置。

1.3 样式

CSS 方面,鸿蒙和 RN 一样有着诸多限制。例如不支持盒子模型、各组件只支持部分 CSS 属性等。

1.4 组件 & API

鸿蒙提供了一系列功能丰富的组件,与小程序的组件相比,命名、功能上略有差别。

API 也是一样的,两者的 API 集合有部分交集,用法、功能上有差别。

2. 兼容细节

2.1 Taro 可以解决什么?

Taro 适配鸿蒙致力于尽可能地抹平差异,但作为一个框架,注定有它能够解决和不能解决的问题。

语法差异可以通过编写运行时框架去处理;使用鸿蒙的组件、API 去尽可能地实现微信小程序规范的组件和 API,以抹平两者之间的使用差别。

而 CSS 的差异、组件和 API 能力上的差异等依赖着鸿蒙底层实现,Taro 是无法解决的。

适配方案

2.2 鸿蒙插件

Taro 在鸿蒙方面的兼容工作主要由 @tarojs/plugin-platform-harmony 插件来完成,开发者引入该插件即可编译为鸿蒙应用。它主要做了这些适配工作:

a) 模板

熟悉 Taro 的同学都应该清楚,Taro 在小程序端利用 <template> 标签的递归来渲染页面动态的 DOM 树。而鸿蒙中并没有 <template> ,因此我们使用自定义组件进行递归。

b) 运行时

运行时主要在鸿蒙端兼容了小程序的生命周期和数据更新方法 setData

c) 组件 & API

我们使用鸿蒙的原生语法封装了符合微信小程序规范的组件库和 API 库。在兼容微信小程序的属性的同时,也保留了鸿蒙独有的支持属性。

目前共适配了 29 个组件,16 类 API。组件示例库可参考:taro-components-sample

组件示例图

3. 架构图

架构图

三、使用方法

如您是新项目, 升级 Taro 选择鸿蒙模板即可;

旧项目需要按照如下方法进行手动配置:

1. 把 Taro 升级到 v3.5.0-canary.0 版本

首先需要安装 v3.5.0-canary.0 的 CLI 工具

npm i -g @tarojs/cli@canary

然后更新项目本地的 Taro 相关依赖:把  package.json  文件中 Taro 相关依赖的版本修改为  ~3.5.0-canary.0,再重新安装依赖。

如果安装失败或打开项目失败,可以删除  node_modulesyarn.lockpackage-lock.json  后重新安装依赖再尝试。

2. 安装 taro 适配鸿蒙插件

(1)Taro 项目中安装鸿蒙插件 @tarojs/plugin-platform-harmony

$ yarn add --dev @tarojs/plugin-platform-harmony

(2)在 config/index.js 中增加编译配置

config/index.js
config = {
// 配置使用插件
plugins: ['@tarojs/plugin-platform-harmony'],
mini: {
// 如果使用开发者工具的预览器(previewer)进行预览的话,需要使用 development 版本的 react-reconciler。
// 因为 previewer 对长串的压缩文本解析有问题。(真机/远程真机没有此问题)
debugReact: true,
// 如果需要真机断点调试,需要关闭 sourcemap 的生成
enableSourceMap: false,
},
// harmony 相关配置
harmony: {
// 【必填】鸿蒙应用的绝对路径
projectPath: path.resolve(process.cwd(), '../MyApplication'),
// 【可选】HAP 的名称,默认为 'entry'
hapName: 'entry',
// 【可选】JS FA 的名称,默认为 'default'
jsFAName: 'default',
},
}

3. 准备鸿蒙运行环境

开发鸿蒙软件需要用到 HUAWEI DevEco Studio,它提供了模板创建、开发、编译、调试、发布等服务。

主要包括以下内容:

(1)注册开发者账号

(2)下载 DevEco Studio 安装包

(3)启动 DevEco Studio,根据工具引导下载 HarmonyOS SDK

(4)新建 MyApplication JS 项目

(5)使用预览器或真机查看应用效果

《初窥鸿蒙》 《华为开发者工具》《鸿蒙开发文档》

4. 项目运行

运行命令

$ taro build —-type harmony —-watch

若您在步骤 2(2) 设置好了打包输出到鸿蒙项目的路径,即可查看 Taro 适配鸿蒙的应用效果。

testHarmony 为您通过 DevEco Studio 创建的 JS 项目。

运行效果图

四、最后

接下来我们会继续完善对鸿蒙的适配工作,预计会在 2022 年 Q1 发布 v3.5 正式版。

同时也希望社区有更多的开发者参与共建,无论是提出 Issues、在论坛发帖、提交 PR 还是帮助建设周边生态等,对我们来说都是宝贵的财富,让我们一起把 Taro 建设的更强。

Taro 团队衷心感谢一路走来大家对我们的支持,正是因为大家的期待、信赖敦促我们走向更好。

最后,该版本鸿蒙的适配由京东内鸿蒙共建小组共同完成,感谢以下同学:@AdvancedCat@jiaozitang@huozhongyi123@troy-sxj@JSZabc@crazyonebyone@evernoteHW@soulhat@xueshuai@LuMeiling

标签:

· 阅读需 7 分钟
JJ

项目体积是困扰小程序开发者的一大问题,如果开发者使用 Taro React 进行开发,更是不得不引入接近 100K 的 React 相关依赖,这让项目体积变得更加捉襟见肘。因此,Taro v3.4 的主要方向,是探索对于 Preact 的支持。

Preact 是一款体积超小的类 React 框架,提供和 React 几乎一致的 API,而体积只有 5k 左右。

支持使用 Preact

Taro v3.4 正式实现了对 Preact 的支持,下文将简单介绍适配思路及用法。

适配思路

1. 运行时改造

Taro 在小程序环境模拟实现了类浏览器环境,因此理论上任意的前端框架都可以在 Taro 中使用。

对于 Preact,它与 React 最大的不同在于没有实现合成事件系统,而是直接使用浏览器的事件方法,此外还使用了少量和 React 不一样的 DOM API。

对于事件的适配,Taro 已经提供了浏览器规范的事件方法,因此只需要再处理 Preact 的事件名与小程序事件名的差异。而对于 DOM 方法,则需要额外实现 Preact 使用到的 DOM API。

2. 兼容 React 生态

Preact 使用了 preact/compat 去磨平与 React 的 API 差异,让 React 的各种生态库可以直接运行在 Preact 上。得益于此,开发时我们可以使用任意的 React 生态库,甚至对 React、ReactDOM 的 API 引用也不需要修改,只需要简单地配置 alias 即可:

// Webpack config
const config = {
resolve: {
alias: {
react: 'preact/compat',
'react-dom/test-utils': 'preact/test-utils',
'react-dom': 'preact/compat',
'react/jsx-runtime': 'preact/jsx-runtime',
},
},
}

用法介绍

文档地址

新项目

运行 taro init 时,框架选择 Preact 即可创建基于 Preact 的项目。

现有的 React 项目

  1. 将 CLI、项目中 Taro 相关的依赖更新到 v3.4.0-beta 版本。

  2. 安装依赖:

yarn add preact @tarojs/plugin-framework-react
  1. 修改 Taro 编译配置:
config/index.js
const config = {
// ...
framework: 'preact',
}
  1. 修改 Babel 配置:
babel.config.js
module.exports = {
presets: [
[
'taro',
{
framework: 'preact',
},
],
],
}
  1. 如果项目使用了 TypeScript,请打开 skipLibCheck 配置,以避免和其它 React 生态库配合使用时报类型错误:
tsconfig.json
{
...
"skipLibCheck": true,
}

Vue 3 支持 Composition API 版本的小程序生命周期钩子

文档地址

Vue3 提供了 Composition API(组合式 API) 特性,和传统的 Options API 不同,Composition API 提供了全新的编码方式 ,可以让我们更好地去组织和复用代码逻辑。

过去 Taro 只提供了 Options API 版本的小程序生命周期钩子,开发者往往对于这些钩子和 setup 函数内部该如何通讯、如何共享数据等问题感到困惑,更是不能很好地兼容 script setup 语法。

因此 Taro v3.4 提供了 Composition API 版本的小程序生命周期钩子,让开发者更方便地使用 setup 语法,例子:

<script setup>
import { useDidShow } from '@tarojs/taro'

useDidShow(() => console.log('onShow'))
</script>

运行时体积优化

目前 Taro 对于前端框架的适配层代码都放在了运行时库 @tarojs/runtime 里,意思即当开发者使用 React 时,还是会包含 Vue2、Vue3 的适配层代码。(Tree Shaking 失败的原因是使用了 Webpack Provider Plugin 导出 @tarojs/runtime 里的 BOM API)

因此,Taro v3.4 以 Taro 插件的形式去实现对于各前端框架的适配,其中一个好处是可以把上述运行时适配层的代码拆分到各个插件内。加上对运行时代码的写法优化,3.4 版本的运行时减少了约 30k 的空间。

另一个好处是现在开发者可以通过编写 Taro 插件去支持任意的前端框架,而几乎不需要改动 Taro 的核心代码。

升级指南

1. 安装 v3.4.0-beta 的 CLI 工具:

npm i -g @tarojs/cli@beta

2. 更新项目依赖

如果安装失败或打开项目失败,可以删除 node_modulesyarn.lockpackage-lock.json 后重新安装依赖再尝试。

修改 package.json 文件中 Taro 相关依赖的版本修改为 ~3.4.0-beta.0,再重新安装依赖。

3.【Breaking Changes】安装对应的框架适配插件

因为 Taro v3.4 把各前端框架的适配逻辑拆分到对应的插件中,因此旧项目升级时需要安装对应框架的适配插件:

  • 使用 React,请安装 @tarojs/plugin-framework-react
  • 使用 Vue2,请安装 @tarojs/plugin-framework-vue2
  • 使用 Vue3,请安装 @tarojs/plugin-framework-vue3

其他

Breaking Changes

  • 百度小程序使用 onInit 代替 onLoad 生命周期,以优化首次启动时间。

最后

接下来 Taro 的重心将会放在编译系统升级(如升级 Webpack5)和优化 H5 能力(如输出 SSR 方案、优化路由系统等)上。

鸿蒙应用 && OpenHarmony

Taro 迭代的另一条主线是对鸿蒙应用 && OpenHarmony 的适配,Taro 与 OpenHarmony 团队成立了跨平台 UI 兴趣组(SIG-CROSS-PLATFORM-UI),联合社区共同展开适配工作。目前第一阶段的开发工作即将完成,12 月初会发布首个可用的体验版本。

相关咨询:

鸿蒙 & OpenHarmony 交流群:

标签:

· 阅读需 18 分钟
zhiqingchen

Taro React Native 重大更新来了,全方位降低上手成本,提升开发体验。全流程自动化,让开发者摆脱原生环境配置,专注前端开发。

背景

Taro 3.2.0 正式版本发布至今,已过去半年。在此期间,有不少社区开发者已经使用上 Taro 来开发 APP 了。看到社区的使用量越来越多,开发团队也是收获满满。

同时我们也收到了很多来自开发者的反馈, 主要集中于开发环境配置复杂、组件和 API 的完善度不够及使用上的 BUG 等。对于组件和 API 的完善度及使用上的 BUG,我们都是尽可能地及时地处理并发布新版本。然而,对于开发者反馈的开发环境配置的问题,却很难复现及解决。

首先 Android + iOS + React Native + Taro,4 个技术的各种环境配置,会让很多开发者望而却步。其次开发者面对的环境问题千奇百怪,很多问题难以通过远程协助解决。不少开发者在调研阶段,因为无法顺利运行,便放弃了使用。对于一个跨平台框架来说,主要目的是提效,而非给开发者带来更多困难。开发环境配置问题的解决,显得尤为重要。

这次我们从以下三个方向去优化整个开发流程,全面降低上手成本,让 Taro 开发 APP,变得无比轻松。

  1. 为 Taro 提供 react-native 模板,项目的初始化,只需要几个命令。
  2. 与 GitHub Actions 进行集成,不再需要本地安装原生开发环境,打包及发布交给 CI 去做。
  3. 提供 Taro Playground APP,可以通过应用商店或者 GitHub 下载安装,进行项目调试。

react-native 开发模板

目前使用 Taro 开发 React Native APP 时,我们需要一个原生壳工程,在另外一个仓库[1]。对于新手来说,通常会造成一些困惑:

  1. 没有接触过 React Native 开发的开发者首先需要理解 React Native 的开发流程,然后完成两个仓库的初始化。
  2. 两个仓库都需要安装依赖,并且需要保持某些依赖版本的一致性。当有依赖更新时,需要在两个仓库中进行操作,非常容易遗漏。
  3. 项目依赖原生的运行环境。开发者经常遇到安装过程报错,无法运行的场景。一些依赖包的下载需要切换源或依赖特定网络环境。

这些问题对新手入门很不友好,为此我们提供了一个初始化模板[2]。初始化项目使用 taro init [project] 选择 react-native 模板。

初始化完成后,便可使用进入开发。以下为一些常用命令:

# 更新相关依赖。在初始化完成后或 Taro 版本更新后执行,用于同步 peerDependencies。
$ yarn upgradePeerdeps

# 打包 js bundle 及静态资源。在初始化完成后执行,用于打包默认使用的 bundle。
$ yarn build:rn --platform ios

# 启动 bundle server
$ yarn start

# 启动 iOS
$ yarn ios

# 启动安卓
$ yarn android

具体操作可以查看录屏:

通过模板方式进行初始化的项目,有几个优势:

  1. Taro 仓库与壳工程仓库进行整合,不再需要管理双仓库。当然习惯双仓库模式的开发者,仍然可以正常使用。
  2. 当 Taro 进行升级时,可以通过执行 yarn upgradePeerdeps进行依赖同步。这里我们将 Taro 依赖的 React Native 相关库写入了 peerDependencies 中,然后通过 install-peerdeps 去完成依赖的同步。
  3. 集成了 GitHub Actions,可通过 workflow 完成 APP 的打包。

GitHub Actions

要解决开发环境的各种问题,通常的做法就是提供一个稳定的环境用于打包发布,在企业里是各种 CI/CD 平台。但对于开源项目来讲,就需要一个公开的平台,每个人都能使用,当然最好是免费的。于是我们想到了 GitHub Actions。

GitHub Actions 是 GitHub 提供的持续集成服务,于 2018 年 10 月推出。功能非常强大,并且免费(每月有限额),同时私有仓库也能够使用,非常契合我们的需求。

通过模板初始化的项目,可在 .github/workflows 目录中看到 4 个文件。分别为 iOS 和 Android 的 release 包和 debug 包的打包工作流。模板为了简化过程,设置为通过 git push 即可触发打包,可根据自身情况,配置合适自身业务场景的工作流。打包生成的产物可以在 Artifacts 中找到,也可以使用 softprops/action-gh-release@v1 action,将产物发布到项目的 Release 中。

这样一来新手便可以不需要关注原生环境以及 APP 打包的问题。开发时,可以安装 debug 包加载本地的 jsbundle,进行调试。发布时,交给 CI 进行打包,产物再提交到应用市场,整个过程完全不需要 AS 与 XCode。当然这里还有一些必要配置需要做,比如 APP 的签名等,将在后面的章节讲解。

GitHub Actions 功能非常强大,Taro 就用它来做打包发布等工作,可参考文档[3]或查看资料做进一步探索,做点有趣的事情。

GitHub Actions 配置

在 Taro 项目模板里面我们提供了一个 CI 脚本模板,开发者仍然需要进行一些配置,才能够开始打包。下面是打包 Android APP 的基础配置说明,iOS 同理:

  • 配置打包的环境变量

    env:
    APP_ID: com.taro.demo # 应用 ID
    APP_NAME: Taro Demo # 应用名称
    VERSION_NAME: 1.0.0 # 应用版本号
    VERSION_CODE: 10 # 用于应用市场、程序内部识别版本,判断新旧版本,一般递增处理
    KEYSTORE_FILE: debug.keystore # 签名文件
    KEYSTORE_PASSWORD: android # 密码
    KEYSTORE_KEY_ALIAS: androiddebugkey # 别名
    KEYSTORE_KEY_PASSWORD: android # 别名的密码
  • 通过 github secrets 管理秘钥配置

    通常我们不应该把密钥等敏感信息直接写在配置文件中,而是置于加密信息中。在 GitHub Actions 中,可以使用加密机制进行处理[4]。如图,在 setting -> secret 配上 CI 需要的 secret。然后在 workflow 中通过相应变量进行使用,如 ${{secrets.DEBUG_KEYSTORE_PASSWORD}}

壳工程 GitHub Actions 方案

对于壳工程与项目工程分开的场景,利用 CI 命令将两个项目进行合并也可以实现打包自动化。具体流程如下:

  1. 壳工程和业务项目合并

    因为 GitHub Actions 只能在当前项目下进行操作,所以需要将壳工程(taro-native-shell)合并到项目工程下。

  2. 合并项目和壳工程的 package.json

    在有原生依赖的情况下,必须保证壳工程和业务项目的原生依赖版本一致,不然打包可能会报错。

  3. 安装依赖

    在业务项目工程下安装合并后的 package.json 依赖。

  4. 软链依赖

    将安装到业务项目下的依赖软链至壳工程项目 node_module 下。

    ln -s ./node_modules ./taro-native-shell/node_modules
  5. 业务项目编译

    执行 taro/cli build:rn 编译命令,打包生成 jsbundle 与静态资源。

  6. 将编译产物移动到原生壳工程

    rn: {
    appName: 'taroDemo',
    output: {
    ios: './ios/main.jsbundle',
    iosAssetsDest: './ios',
    android: './android/app/src/main/assets/index.android.bundle',
    androidAssetsDest: './android/app/src/main/res',
    iosSourcemapOutput: './ios/main.map',
    androidSourcemapOutput: './android/app/src/main/assets/index.android.map',
    },
    }

    taro 编译 rn 输出静态资源,需要将资源移到原生项目中。

  7. 编译原生 APP

    到 ios 和 android 目录里分别执行对应的打包命令。

  8. 上传 APP

    将打包后的 APP 进行上传,提供下载链接。

    # iOS
    - name: Upload iOS Products
    uses: actions/upload-artifact@v2
    with:
    name: app-${{ env.BUILD_TYPE }}
    path: |
    ${{ github.workspace }}/ios/taroDemo.ipa
    ${{ github.workspace }}/ios/taroDemo.app.dSYM.zip
    # Android
    - name: Upload Android Products
    uses: actions/upload-artifact@v2
    with:
    name: app-${{ env.BUILD_TYPE }}
    path: ${{ github.workspace }}/android/app/build/outputs/apk/${{ env.BUILD_TYPE }}/app-${{ env.BUILD_TYPE }}.apk

    在 iOS 侧,release workflow 还集成了上传至 APP Store 命令:

    - name: Upload app to App Store Connect
    env:
    APP_STORE_CONNECT_USERNAME: ${{ env.APP_STORE_CONNECT_USERNAME }}
    APP_STORE_CONNECT_PASSWORD: ${{ env.APP_STORE_CONNECT_PASSWORD }}
    run: |
    cd ios
    xcrun altool --upload-app -t ios -f "taroDemo.ipa" -u "$APP_STORE_CONNECT_USERNAME" -p "$APP_STORE_CONNECT_PASSWORD"

上面整个流程对于开发者来说理解成本太高,配置过于繁琐,所以我们将前 6 个步骤封装成一个 GitHub action[5],开发者只需要添加一些配置项就能完成上面的流程。

- name: taro-native-publish
uses: shinken008/taro-native-publish@0.4.0
with:
REPO: ${{ env.SHELL_REPO }}
REPO_REF: ${{ env.SHELL_REPO_REF }}
REPO_PATH: taro-native-shell
BUILD_CMD: yarn build:rn
IOS_BUNDLE: ios/main.jsbundle
IOS_ASSETS: ios
ANDROID_BUNDLE: android/index.android.bundle
ANDROID_ASSETS: android
PLATFORM: android

对应的需要拉取的另一个仓库的配置:

env:
# 壳工程
SHELL_REPO: NervJS/taro-native-shell
# 壳工程ref
SHELL_REPO_REF: 0.63.2
# 壳工程目录
SHELL_REPO_PATH: taro-native-shell

配置介绍:

  • REPO: 壳工程地址
  • REPO_REF: 壳工程分支
  • SHELL_REPO_PATH: 壳工程目录
  • IOS_BUNDLE: 编译 iOS 后的 js bundle 地址
  • IOS_ASSETS: 编译 iOS 后的其他静态文件(图片等)地址
  • ANDROID_BUNDLE: 编译 Android 后的 js bundle 地址
  • ANDROID_ASSETS: 编译 Android 后的其他静态文件(图片等)地址
  • PLATFORM:编译的目标平台 ios/android

模板提供的 iOS 打包方案

iOS APP 的打包过程相对繁琐,这里我们直接使用了一个优秀的工具 fastlane[6]。fastlane 是一个为 iOS 和 Android 开发者提供的工具,可以自动执行繁琐的任务,如生成屏幕截图、处理配置文件和发布应用程序。

打包过程中的 info plist 文件修改、版本号修改、签名设置都可以交给 fastlane 去处理,经过 fastlane 的封装,开发者处理这些繁琐的任务,只需要添加几行配置即可。

但是要让 fastlane 在 GitHub Actions 使用,还需要几步操作。因为证书(Certificate)与描述文件(Provisioning Profiles)并不存储在项目仓库中,而每次工作流都是发生在随机的主机上的,这就需要我们在打包前,先将证书与描述文件导入到当前主机中。

Release 证书的导入过程如下:

  1. 将证书的 p12 文件转成 base64 字符串。

    cat Certificates.p12 | base64 | pbcopy
  2. 将第一步内容保存在项目的 secret 中,keyRELEASE_SIGNING_CERTIFICATE_P12_DATA

  3. p12 文件的密码保存在项目的 secret 中,keyRELEASE_SIGNING_CERTIFICATE_PASSWORD

  4. secret 内配置的相关信息导入到主机中。

    security import <(echo $SIGNING_CERTIFICATE_P12_DATA | base64 --decode) \
    -f pkcs12 \
    -k build.keychain \
    -P $SIGNING_CERTIFICATE_PASSWORD \
    -T /usr/bin/codesign

描述文件的导入过程,与证书的导入过程类似,均已封装在 workflow 中。

要将生成的 ipa 文件上传至 testflight 或者 APP Store 上,还需要提供用户名(APP_STORE_CONNECT_USERNAME)与密码(APP_STORE_CONNECT_PASSWORD),可参考文档进行生成[7]

至于证书与描述文件的生成,可查阅 iOS 开发相关文章[8],这里不再赘述。fastlane 配置的更多细节可查看 ios/fastlane/Fastfile 文件。

模板提供的 Android 打包方案

Android 的打包过程相对简单,直接调用 gradlew 命令即可。除了配置 APP 的基础信息,还需要为应用进行签名。可参考 Android 应用签名相关文档[9],生成签名文件,置于 android/app 目录中。

签名文件也可通过命令行工具生成:

keytool -genkey -alias android -keyalg RSA -validity 99999 -keystore release.keystore

打包相关参数,通过 gradlew-P, --project-prop 参数进行传入,如 ./gradlew assembledebug -Papp_id=${{ env.APP_ID }},其默认值在 android/gradle.properties 文件中定义。

Taro Playground APP

基于 GitHub Actions 与 Taro 模板,我们完成了项目初始化与打包过程的自动化。但对于想要体验 Taro 开发 APP 的开发者来说,仍然太过繁琐。为此,我们开发了 Taro Playground APP,并完全开源[10]。一方面可以展示组件和 API 的使用示例,另一方面提供了动态加载 jsbundle 的功能,便于开发人员进行本地代码的调试。

本地调试

开发者可以在 Taro Playground 仓库的 Releases 页面进行安装包下载[11],也可扫描以下二维码安装 APP。

AndroidiOS

Taro 工程中通过 yarn dev:rn --qr 启动 bundler server,打印包含 IP 及端口信息的二维码。通过 Taro Playground APP 扫描该二维码,即可加载 jsbundle 进行调试,需要保证手机与电脑处于同一个局域网中。

具体操作可以查看录屏:

示列代码

Taro Playground 项目提供了较全面的示例代码,开发者可以参考,避免一些可能遇到的坑,如有问题,欢迎 pr。

总结

通过上述多方面的优化,极大地降低了使用 Taro 开发 APP 的成本。大部分场景下,只需要掌握 Taro 和 React Native,再加上一些配置,即可完成 APP 的开发与发布。

使用过程中,如遇任何问题,可添加 "58 技术小秘书" 或 "Taro 小助手" 为好友,备注 "Taro RN",加入官方交流群寻求帮助。

后续,我们还将带来支持 React Native 的 Taro UI 以及包含详细教程的技术小册,尽请期待。

同时我们也在征集社区优秀使用案例,欢迎开发者提交案例到案例仓库中[12]

相关链接

[1] 壳工程地址:https://github.com/NervJS/taro-native-shell

[2] 模板源码地址:https://github.com/NervJS/taro-project-templates/tree/v3.4/react-native

[3] GitHub Action 文档:https://docs.github.com/cn/actions

[4] GitHub Action 加密机制:https://docs.github.com/cn/actions/reference/encrypted-secrets

[5] Taro React Native Publish Action:https://github.com/shinken008/taro-native-publish

[6] fastlane 官网:https://docs.fastlane.tools

[7] AppleID 密码生成:https://support.apple.com/en-us/HT204397

[8] 使用 GitHub Action 发布 iOS 应用:https://betterprogramming.pub/deploy-an-ios-app-to-testflight-or-the-app-store-using-github-actions-c4d7082b1430

[9] 安卓签名文件生成:https://developer.android.com/studio/publish/app-signing#generate-key

[10] Taro Playground 源码:https://github.com/wuba/taro-playground

[11] Taro Playground APP 下载:https://github.com/wuba/taro-playground/releases

[12] Taro 案例提交:https://github.com/NervJS/taro-user-cases

标签:

· 阅读需 7 分钟
JJ

距离 Taro 3.3 第一个 alpha 版本的发布,已过去三个月的时间。期间我们不断地对 3.3 版本进行打磨,除了优化 H5 同构方案外,还引入了一些提升开发体验的新特性和修复了若干重要问题。

支持使用 H5 标签

Taro 3.3 最重要的特性就是支持使用 H5 标签进行开发,让开发者在小程序环境中复用部分的 Web 生态。

例如在 React 中可以这样使用:

function Index() {
return <div>Hello World!</div>
}

相关背景及实现思路在 《Taro 3.3 alpha 发布》 一文中有详细说明。

用法

首先需要安装插件 @tarojs/plugin-html

$ npm i @tarojs/plugin-html

然后配置使用即可:

// config/index.js
const config = {
// ...
plugins: ['@tarojs/plugin-html'],
}

插件的详细用法请见文档

示例项目

为了验证同构功能的可用性和效果,我们对 CSS 样式库 WEUI、React 组件库 Antd Design Mobile、Vue2 组件库 VantUI 的所有组件进行了测试。结果显示有相当一部分的组件能直接运行在小程序环境中。

示例项目仓库地址:

What's news

在开发 @tarojs/plugin-html 插件的时候,我们发现需要为 Taro 模拟的 DOM APIs 新增一些方法,如 getBoundingClientRect 等。但是对于不使用这个插件的开发者来说这些 API 是冗余的,会增大包体积。因此我们对 @tarojs/runtime 进行了重构,把 DOM APIs 做成可插拔式,让开发者可以选择在最终的编译结果里只存在哪些 DOM APIs。

本次对运行时的重构也是为了 Taro 3.4 版本作铺垫。React、Vue2 和 Vue3 这些框架运行时需要的 DOM APIs 是不尽相同的,但是目前假设开发者使用了 React,编译结果里仍然会存在着只有 Vue2 或 Vue3 依赖的 DOM APIs。Taro 3.4 将会把对各 Web 开发框架的支持逻辑抽离成为一个个插件,如:@tarojs/plugin-framework-react 等,目的是剔除掉冗余代码。

例如,假设开发者没有使用渲染 HTML 文本的 API(如 React 的 dangerouslySetInnerHTML)。这时可以修改 Taro 编译配置的 mini.runtime.enableInnerHTML 选项,令最终的打包结果剔除掉相关代码:

// config/index.js
config = {
// ...
mini: {
runtime: {
enableInnerHTML: false,
},
},
}

小程序支持使用框架的 DevTools

自 Taro 3.x 改造为运行时框架后,有不少同学抱怨小程序开发者工具的 AppData 面板看到的都是 Taro 虚拟 DOM 的序列化结果,而不是页面的 data 数据。为了缓解这个问题,并进一步地提升开发者的开发体验,Taro 对 React DevTools 和 Vue DevTools 进行了适配。只需要简单地配置,就能够和开发 Web 应用时一样使用框架的 DevTools。

React DevTools

安装并配置使用 @tarojs/plugin-react-devtools 即可,详细用法请见文档

效果图:

Vue DevTools

安装并配置使用 @tarojs/plugin-vue-devtools 即可,详细用法请见文档

效果图:

修复百度小程序 flex 布局的问题

在过去很长一段时间里,Taro 3 在百度小程序里是不支持使用 flex 布局的。原因是逻辑层的每个 Taro DOM 节点都在渲染层使用一个对应的 <template> 进行渲染,而百度小程序会把 <template> 渲染成一个真实节点。

非常感谢 @SyMind 的 PR,帮助 Taro 绕过了此问题。从 Taro 3.2 开始,部分组件在百度小程序中也能够使用 flex 布局。

相关的讨论和提交可以浏览 #6015 #9529

升级指南

从 v2.x 升级的同学需要先按 迁移指南 进行操作。

从 v3.x 升级的同学,首先需要安装 v3.3 的 CLI 工具:

npm i -g @tarojs/cli

然后手工修改 package.json 文件中 Taro 相关依赖的版本,再重新安装依赖;或者使用 taro update project 更新依赖。

如果安装失败或打开项目失败,可以删除 node_modulesyarn.lockpackage-lock.json 后重新安装依赖再尝试。

The End

Taro 3.4

下一个 minor 版本,我们会考虑把对各个 Web 开发框架的支持逻辑拆分为对应的插件。让开发者可以以插件的形式为 Taro 拓展支持一门新的开发框架,我们会运用此能力进行对 Preact 的支持,希望能进一步减少用户的包体积。

鸿蒙应用 && OpenHarmony

近期我们也一直在探索对鸿蒙应用 && OpenHarmony的适配,目前已有一系列的讨论和开发计划,也有可以运行的 Demo,详情请见 鸿蒙 && OpenHarmony 适配小组

RoadMap:

欢迎各位开发者参与讨论和共建~

快应用

此外,社区大佬 @bgfist 正在为 Taro 开发支持快应用的功能。也欢迎各位开发者参与讨论和共建,相关 PR

感恩

时光飞逝,1 年前 Taro 3 正式发布,Taro 逐渐成为被社区喜欢、信赖的开源项目。未来我们也将继续做好 Taro 的开源工作,同时也希望社区有更多的开发者参与进来,无论是提出 Issues、在论坛发帖、提交 PR 还是帮助建设周边生态等。让我们一起把 Taro 做好,做强。

最后,衷心感谢为 Taro 从 v3.2 走到 v3.3 贡献过代码的各位同学!

标签:

· 阅读需 10 分钟
JJ

小程序的设计并没有完全遵循 Web 规范,导致小程序生态和传统 Web 开发生态之间的割裂,海量优秀的 Web 物料并不能直接用于小程序开发。因而 Taro 在相当一段时间内生态都相对薄弱,UI 框架选择不多的问题更是深深困扰着开发者。

另一方面,业界有着存量的 H5 应用,中短期内 H5 应用适配到小程序端的需要还会存在。我们希望能减少 H5 应用迁移到小程序端的成本,甚至能够直接运行在小程序端。

Taro 团队一直在思考如何最大限度地在小程序环境中复用 Web 生态,直到 Taro 3.0 诞生后,这种想法有了落地的可能。下文将介绍基于 Taro 3.0 实现 H5 同构的思路与问题,以及我们尝试适配了三大移动端 UI 框架 WEUIAnt Design MobileVantUI 的实验结果。

一、实现思路

Taro 3.0 是一款重运行时的跨端框架,它通过模拟实现浏览器的 BOM 和 DOM API 实现了对 React、Vue 等 Web 开发框架的兼容。

既然已经有了浏览器环境的 BOM 和 DOM API,Taro 应用和 Web 应用之间的鸿沟在于小程序组件和 HTML 标签之间的差异。

· 阅读需 12 分钟
yechunxi

Taro 是一个开放式 跨端跨框架 解决方案,支持使用 React/Vue/Nerv 等框架来开发 微信/京东/百度/支付宝/字节跳动/QQ小程序/H5/React Native 等应用。

自从 Taro 3 发布以来,不少开发者期待 Taro 3 可以支持 React Native。基于 58 团队在 React Native 方向的技术积累,我们与 Taro 团队达成战略合作伙伴关系。由 58 团队主导开发 Taro 3 React Native,共同推进 Taro 的发展。

去年 12 月开始,已经完成了 Taro 3 React Native 的支持,共发布了 9 个 canary 版本与 4 个 beta 版,经过较长时间的验证,如今终于迎来了 3.2 正式版。

· 阅读需 10 分钟
JJ

自 Taro 3.1 体验版推出后,我们不断地根据社区的反馈意见对 3.1 版本进行打磨。主要改进了开放式架构、引入了 CustomWrapper 组件以解决性能问题、提出了原生小程序渐进式混合使用 Taro 的解决方案。

经历了 12 个 beta 版本后,终于迎来了 3.1 正式版 🎉

· 阅读需 21 分钟
JJ

背景

2020 年是社区团购风起云涌的一年,互联网大厂纷纷抓紧一分一秒跑步进场。“京喜拼拼”是京东旗下的社区团购平台,依托京东供应链体系,精选低价好货,为社区用户提供次日达等优质服务。

​ 京喜拼拼团队技术选型使用 Taro 以便于实现多端需求,因此 Taro 团队有幸参与到 “京喜拼拼” 小程序的性能体验优化工作。

全面体验 - 梳理 Taro 写法最佳实践

我们全面体验后和熟悉业务代码后梳理出一系列 Taro3 写法的最佳实践:

· 阅读需 15 分钟
JJ

自 7 月初我们正式发布了 Taro 3,至今半年时间已然略去。期间我们不断地修复着问题,同时也在构想着下一个 minor 版本。

面对小程序平台越来越多的大环境,Taro 是选择偏安一隅,只支持部分的主流小程序,还是成为所有小程序平台  开发、多端转换的基础设施,我们在 v3.1 给出了答案:开放式架构

一、开放式架构

背景

近年来业界推出的小程序平台越来越多,但 Taro 核心维护的平台只有 6 个(微信、支付宝、百度、头条、QQ、京东小程序),因此常常有同学提出能不能支持某某平台的 Feature Request。

基于目前的架构,对于单一平台的兼容性代码分布于 Taro 核心库的各个角落,涉及编译时与运行时等部分。支持一个新的平台需要改动所有的这些地方,开发复杂度高,同时社区也难以参与贡献。

为此我们萌生了打造一个开放式框架的想法。目标是可以通过插件的形式扩展 Taro 的端平台支持能力:

  • 插件开发者无需修改 Taro 核心库代码,即可编写出一个端平台插件。
  • 插件使用者只需安装、配置端平台插件,即可把代码编译到指定平台。
  • 开发者可以继承现有的端平台插件,然后对平台的适配逻辑进行自定义。

· 阅读需 3 分钟
zhiqingchen

相关资料链接

  1. 版本内容对应的 RFC
  2. 3.2.0 canary 版本分支
  3. 壳工程分支
  4. 最新进展,可关注 58 开源

新版本特性一览

  1. 更快的编译速度
    1. 基于全新的编译体系,启动速度提升 1 倍
  2. 更便捷的开发调试体验
    1. 去掉了 webpack 后,source-map 的支持更加简单,这对于开发体验是一个巨大的提升
  3. 更全面的 API 和组件
    1. 新增 38 个 API
    2. 新增 7 个组件
  4. 更灵活的接入方式
    1. 支持 React Native 0.60 及以上版本,可自行定制,我们也将探索更多版本的支持
    2. API 和组件支持按需加载,未使用的原生依赖,无需安装
    3. 架构完全基于 React Native 生态,相关工具、组件等均可轻松接入
  5. 更稳定的源码
    1. 使用 TypeScript、ESlint、Jest,保证代码质量
    2. 欢迎社区贡献