Cross-Platform on Time Friend

使用Taro开发各端的顺序建议

Wed, 16 Dec 2020 22:17:36 +0000

以最小成本开发Taro各端

现在公司里面的所有小程序,快应用,rn等等都在使用Taro在开发.

如果只兼容一端的话,使用Taro开发,没有任何问题.

但是又想一次开发,各端正常运行的话,在很多的细节上是要花一点心思的.

每一端有每一端的难.

开发难度排序

华为快应用 > 快应用 > React Native > Swan小程序 > 微信小程序 > H5

关于快应用

在开发过程中,如果有涉及到快应用的业务,建议优先开发快应用.

快应用的布局标准跟js容器环境跟其他的小程序或者是H5有一定的差异.

并且华为快应用与其他快应用有很多莫名其妙的差异.

如果涉及到快应用,请谨慎对待开发时间.

目前看来,快应用的对UI布局的支持与小程序有一定的差异.虽然使用Taro的样式区分,快应用与小程序确实可以使用一套同样的代码同时跑在两端上.

但是在开发过程中,他们之间的差异有太多意想不到(快应用不符合W3C规范)的差异,建议UI布局相关的代码,各端单独布局.业务相关的可以使用一套代码. 就是布局样式独立,行为保持一致.

不然会花掉太多的布局差异抹平的工作.

关于React Native

React Native在UI布局上也只是部分支持W3C标准.虽然布局上不能跟小程序H5一样灵活,

对比起快应用来,并不会多出一个要额外兼容的华为快应用.

目前Taro封装的React Native的特性与小程序是非常接近的, 如果不过多调用太多冷门的API,基本上还是可以独立开发完成大部分UI编程.

如果RN想要调用原生APP的组件,在目前开来会带来相当大的沟通成本.

在开发中本身ios与安卓就有一定的特性差异,放到RN里实现后又会带来其他的差异.

并且开发人员从一个人变成了三个人.

如果桥接的组件太过于复杂,开发人员可能会有一种还不如自己独立开发的抱怨.

这个时候多端一起开发,时间不一定会比独立开发要快.

关于 Swan小程序

Swan小程序与微信小程序已经非常接近了.

就我们现有业务来说除了wifi不能实现以外,其他的基本上都跟微信小程序保持了一致.

目前开发中,IDE的卡顿是Swan小程序最不好的开发体验.

迭代中,swan小程序的基础库兼容方面也做得不是很好,

好几次遇到莫名其妙的问题,都是因为基础库兼容不好导致的.

使用Taro开发的快应用如何优化体积

Tue, 15 Dec 2020 22:17:36 +0000

快应用重复打包问题

使用Taro开发快应用,有一个问题绝对不能忽视,那就是体积问题.

因为快应用打包的特性(1080以下)多个页面里,如果重复应用了一个第三方库,那么这个库的代码会一起打到这个页面中,导致一样的代码会存在多个页面中.

因为目前1080版本的快应用没有全面铺开.如果你贸然升级自己快应用的最低平台版本号为1080. 你将会失去大量低版本的用户.

官方给出的解决方案 (1080以下版本)

当然快应用官方也意识到了这个问题,给出了最早期的解决方案.

那就是将多个页面会依赖到的代码,全部在快应用初始化的时候挂载到全局变量上面.

其他页面使用的时候,直接引用全局变量就可以了.

// 入口文件
import day from 'day';

const globalRef = Object.getPrototypeOf(global) || global;
globalRef.day = day;

// 页面使用
const globalRef = Object.getPrototypeOf(global) || global
const day = globalRef.day

day()

分析项目使用了哪些公共代码

重复打包的内容,npm依赖会占大头,也有可能是自己写的公共代码.

我们的项目用到了哪些npm依赖?

Taro打包之后,dist/quickapp 下的构建产物会单独把所有项目能用到的npm包放到 src/npm/ 目录下.

公共代码分析

只要一个js被多个page引用,就必须会造成重复打包的问题.

使用Taro的 alias 特性解决重复打包的问题

alias 是应用路径别名的特性,他的实现原理很简单,在config文件中制定好路径替换规则.

在taro打包的时候,直接替换应用路径成为正确的应用路径就可以了.

{ 
 '@src': 'src',
 '@plugin': 'src/plugin',
 '@components': 'src/components',
}

如何使用alias解决我们的打包问题

既然 alias有替换应用路径的问题,再加上我们的第三方库只要挂载到全局变量中就可以让所有页面都可以使用到.

两个特性结合起来的解决方案就是这样的.

第一步,修改npm的alias

为什么要这样做,看到第二步你就会明白.

classnames.ex 文件为classnames的映射文件.

{
 'classnames': 'src/replacement/classnames.ex',
 'prop-types': 'src/replacement/prop-types.ex',
 'mobx': 'src/replacement/mobx.ex',
}

第二步, 制作替身依赖

拷贝 dist/quickapp/src/npm 中的内容到src/replacement/npm中.
在src/replacement下新建一个index.js文件,大致内容如下

import crypt from './npm/crypt/crypt'
import classnames from './npm/classnames'


const globalRef = Object.getPrototypeOf(global) || global

globalRef.classnames = classnames;
globalRef.crypt = crypt;

制作npm依赖映射的文件

看到这一步,你应该就会明白为什么alias为什么会将正常的npm依赖路径替换到一个映射文件.

Taro跨端开发之让Taro UI支持React Native

Thu, 27 Aug 2020 22:17:36 +0000

Taro UI 不支持RN的窘境

Taro UI 文档上很早就说明会有可能支持rn了,但是快一年多了,因为taro ui团队人力的问题一直没有兼容到rn.

业务紧迫,我们等不到那一天了.自己动手丰衣足食.

Taro 传统组件打包在RN上的问题

一般来说,组件库打完包之后 dist/index.js文件会是这样的.

根据运行时的环境变量区分是否要引入哪一个组件库.

if (process.env.TARO_ENV === 'weapp') {
 module.exports = require('./weapp/ui')
 module.exports.default = module.exports
 } else if (process.env.TARO_ENV === 'h5') {
 module.exports = require('./h5/ui')
 module.exports.default = module.exports
 } else {
 module.exports = require('./weapp/ui')
 module.exports.default = module.exports
 }

理想模式下,只要加入一个rn的环境判断,就可以做到rn组件库的引入了.

if (process.env.TARO_ENV === 'weapp') {
 module.exports = require('./weapp/ui')
 module.exports.default = module.exports
 } else if (process.env.TARO_ENV === 'h5') {
 module.exports = require('./h5/ui')
 module.exports.default = module.exports
 } else if (process.env.TARO_ENV === 'rn') {
 // 理想模式,只需要加这一段
 module.exports = require('./rn/ui')
 module.exports.default = module.exports
 } else {
 module.exports = require('./weapp/ui')
 module.exports.default = module.exports
 }

可是现实不是这样的,rn如果引入组件库的索引文件,是dist/index.js,他会提前把所有端的代码全部预执行一遍.

代码还没有真正运行,就因为其他端的代码不兼容,直接报错了. 所以这样硬核的引入方法是不可行的.

rn组件库代码与其他端代码完全隔离

ui.js文件的改动

在src下边有一个ui.js文件,大致内容是这样的:

import Taro from '@tarojs/taro'
import './style/index.scss'
export { default as AActionSheet } from './components/action-sheet'
export { default as AActionSheetItem } from './components/action-sheet/body/item'
export { default as AText } from './components/text'
export { default as AToast } from './components/toast'
export { default as AButton } from './components/button'

// 其他组件...

为了更好的在原来组件库上做rn的兼容,利用taro可以根据文件后缀名区分端的特性就排上用场了. 需要新建一个ui.rn.js

Taro跨端开发之多业务模块管理 React Native篇(终篇)

Tue, 25 Aug 2020 22:17:36 +0000

React Native 热更新方案

rn的业务越来越庞大,同时协同的团队越来越多. rn的动态化就必须提上日程了. 对于rn热更新,首当其冲的问题就是分包.

rn的基础库很大,再加上我们依赖了很多的三方库.这些代码就必须在分包的时候单独剥离出来. 业务包让他比较纯粹的只有业务代码. 这样就可以保证业务包的体积比较小,保证热更新时候的速度.

使用metro分包

React Native 提供的 metro 自带分包功能。metro我们本来就一直在用,只要在metro打包的时候,提供相应的打包规则. 就可以实现rn的分包了.

示例: ios打包

node ./node_modules/react-native/local-cli/cli.js bundle --platform ios --dev false --entry-file rn入口文件.js --bundle-output ./xxx/ --assets-dest ./xxx/ --config /{你的绝对路径}/你的metro配置文件.js

metro 关键api介绍

我们分包需要用的选项主要是两个：

createModuleIdFactory：这个函数传入要打包的 module 文件的绝对路径，返回这个 module 在打包的时候生成的 id。
processModuleFilter：这个函数传入 module 信息，返回一个 boolean 值，false 则表示这个文件不打入当前的包。

主工程分包

之前我们有提到过我们有一个项目是主工程,里面没有任何的业务代码.只有一些代码运行需要的所有依赖.

我们需要将所有的依赖全部收集起来,当业务模块打包的时候,发现本地有这个依赖就可以使用 processModuleFilter方法排除掉.

因为我们的主工程与业务项目的依赖版本都是高度统一的. 所以我们node_modules下面的依赖包路径都是完全一致的.

Taro跨端开发之依赖管理

主工程的metro配置文件示例:

function createModuleIdFactory() {
 return path => {
 // 在这里我们拿到依赖的文件路径,
 // 我们需要在这个函数块中,将路径以收集并且将这些数据生成文件
 // 部署到我们内网的服务器中
 // 当业务模块需要打包的时候,是否要将代码打进包中,将以这个文件为依据
 return path;
 };
}

module.exports = {
 serializer: {
 createModuleIdFactory:createModuleIdFactory
 }
};

主工程入口文件示例:

Taro跨端开发之多业务模块管理 React Native篇(中)

Sun, 23 Aug 2020 22:17:36 +0000

实现一个简单的模块管理工具,解决npm拉取业务模块慢的问题

使用npm拉取git仓库,速度其实还是可以接受的. 主要慢的地方在于 postinstall的时候需要在npm拉取git仓库的时候,需要重新构建项目代码.还有一点就是业务模块也有依赖,npm install的时候也需要重新拉取相同的依赖.

这两个步骤其实是可以省略的,解决的办法就是可以实现一个简单的模块管理工具来替代npm加载业务模块的处理.

创建一个配置文件

module.exports = {
 "Module1": {
 "url": "http://xxx1.git",
 "moduleName": [
 "模块名称"
 ],
 "branch": "develop",
 "type": "taro"
 },
 "Module2": {
 "url": "http://xxx2.git",
 "moduleName": [
 "模块名称"
 ],
 "branch": "develop",
 "type": "taro"
 }
}

因为每一个项目都会用到这一个文件,把这个文件放到服务器上. 在业务模块初始化的时候,自动拉取解析这个文件.再使用nodejs拉取相应的git仓库.

拉取git仓库

使用download-git-repo拉取git仓库的代码放到node_modules目录下. 这样在项目中,我就可以引用普通npm一样引入这个仓库的代码了.

这是download-git-repo的地址与使用方法 https://www.npmjs.com/package/download-git-repo

模拟npm生命周期

代码拉下来之后,还需要用postinstall来构建业务代码, 所以需要使用nodejs遍历以下业务模块的目录,读取目录下的每一个packages.json.

如果有npm钩子的,就执行一下里面的script.

大致示例代码如下:

// 示例代码,仅供参考
const spawn = require('cross-spawn');
const fse = require('fs-extra');


const packageData = fse.readJsonSync('./packages.json');

if (packageData.scripts.preinstall) {
 spawn.sync('npm',['run','preinstall']);
}

if (packageData.scripts.postinstall) {
 spawn.sync('npm',['run','postinstall']);
}

并发执行业务模块的npm钩子

在npm执行postinstall的时候,并不是全部一股脑的全部执行.

使用 yarn 安装依赖的时候,同时最多可以4个模块执行(npm install 没有具体研究). 所以构建业务模块的时候,总是会出现一个一个等的情况.

Taro跨端开发之多业务模块管理 React Native篇(上)

Fri, 21 Aug 2020 22:17:36 +0000

原生RN项目与Taro如何共存?

我们团队一开始就有实践原生React Native的项目,很长一段时间,

所有的业务模块都是在一个项目里面开发维护,时间久了这个项目就变成了一个巨无霸项目.

再加上后来引进了基于Taro开发的rn项目,为了保证原生与Taro的RN共存,

不管是原生rn项目还是taro项目的package.json文件的main对外导出的索引文件格式都是一致的.

我们使用以下方案来维护我们的代码.

使用npm来管理我们的业务模块

RN业务的主工程

这是我最初实践的方案,首先我们创建一个项目为RN的主工程.

里面没有任何的业务代码,只有在根目录下有一个index.js的业务索引文件.

它大概是这样的:


import { AppRegistry} from 'react-native';
import Module1 from 'Module1';
import Module2 from 'Module2';
import Module3 from 'Module3';
AppRegistry.registerComponent('Module1', () => Module1);
AppRegistry.registerComponent('Module2', () => Module2);
AppRegistry.registerComponent('Module3', () => Module3);

之前的一篇文章我已经提到,我们所有的模块依赖都是统一的,并且版本锁死.

有兴趣的可以点击查看:

Taro跨端开发之依赖管理

所以我的主工程的依赖与业务模块的依赖是保持一致的.

使用NPM管理业务模块

我们会把所有的业务模块当成npm来管理,因为npm有很多的生命周期钩子使用.

在统一了npm script 命令之后,很容易统一管理他们.

当然这些业务模块我们不会把他发布到npm服务器上,因为业务代码会频繁变动,如果每一次提交都要上传到npm服务器,自然会添加开发人员的代码管理成本(发布npm包很烦的)

所以我们使用 npm + git 地址来拉取我们的业务模块.

例如:

主工程的package.json


{
"name": "base",
"version": "0.0.6",
"scripts": {
"build":"构建rn的相关操作"
},
"dependencies": {
"公共依赖包": "1.0.0",
"Module1": "http://xxx.com/webfront/Module1.git",
"Module2": "http://xxx.com/webfront/Module2.git",
"Module3": "http://xxx.com/webfront/Module3.git",
}
}

业务模块的package.json

业务模块添加了postinstall,在使用npm拉取业务模块成功之后,业务模块会在 node_modules 中构建自己的项目,提供主工程的index.js使用

{
"name": "buz",
"version": "0.0.1",
"main": "main.js", // main字段要指向rn的索引文件
"scripts": {
"build":"构建rn的相关操作",
"postinstall":"npm run build"
},
"dependencies": {
"公共依赖包": "1.0.0"
}
}

统一对外输出的main.js文件


"use strict";

// 根据端的环境变量判断是否对外输出什么文件

if (process.env.TARO_ENV === 'weapp' || process.env.TARO_ENV === 'h5') {
module.exports = require('./dist/index');
module.exports.default = module.exports
} else {
// taro系工程,标准对外输出
Object.defineProperty(exports, "__esModule", {
value: true
});
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }
var _app = _interopRequireDefault(require("./rn_temp/app"));
exports.APP = _app.default;
}

业务模块之间相互调试

业务与业务之间肯定会有相互联调的情况,以上的方案业务模块只能独立运行自己的代码,当我们想要跳转到其他RN页面的时候,那就不行了.

Taro跨端开发之依赖管理问题

Thu, 20 Aug 2020 22:17:36 +0000

目前我们通过Taro触达的端已经有:

微信小程序
QQ小程序
百度小程序
React Native
H5
快应用

为了快速的让业务可以触达到各端,我们每一个业务模块都是独立的.

他们根据业务需要,分别兼容到不同的端,等到构建的时候再将其进行组装成为一个完整的项目.

为了满足以上需要,并且可以灵活开发.所以每一个业务模块都是可以独立开发,独立运行的,可以不依赖主工程.

目前来说项目之间的关系已经比较类似微前端了.

因为大部分端(除了React Native) 都不能做到热更新,所以相对微前端架构而言小程序们做不到独立部署.

关于Taro + React Native部分,后面会有专门的文章跟大家介绍我们是怎么玩的.

今天就跟大家介绍一下,多业务,多团队,多端的代码管理中我们遇到的第一个问题: 依赖管理问题

所有项目依赖统一管理

因为业务模块很多,我们项目工程的差异必须保持高度统一,其中包括依赖.

核心依赖集中管理

现在我们团队开发的跨端模块已经有几十个.为了方便管理,

我将所有的依赖封装成了一个npm包,里面没有任何的业务代码,只有稳定的依赖.

所有的项目都会引入这个核心的依赖,以保证所有项目可以稳定运行.

非核心依赖版本管理问题

如果是非核心依赖,我们将使用我们自研的cli工具强行修改package.json里面的版本号.

持续集成的过程中,所有的跨端项目都会通过这个cli工具在npm install执行之前修改我们的项目配置.其中就包括了我们的依赖.

我们修改过cli工具之后,所有的跨端项目都会更新到最新的依赖配置.

个别项目特殊处理办法

所有项目的依赖全部统一之后,总会有一些特殊原因个别项目的依赖会有一点区别.

这里就必须要提到package.json的 resolutions属性.

resolutions 字段用于解析选择性版本，可以通过此功能自定义依赖版本。

这样npm就会将多版本共存的版本,强行指定某一版本,满足个别项目的特定需求.

如果我要所有的 B 强行指定2.0

使用方法如下:

// package.json 
// 这样B这个依赖库,就被强行指定版本了
{
 "resolutions": {
 "B": "2.0.0"
 }
}

resolutions的解释,你可以在这里查看更多:

https://classic.yarnpkg.com/zh-Hans/docs/selective-version-resolutions

当然你也可以使用这个工具,将依赖强制指定版本:

https://www.npmjs.com/package/npm-force-resolutions

第三方依赖稳定性问题

我们在开发周期比较长的前端项目的时候,必然会遇到依赖管理的问题.

我们在开发项目的时候,我们用了大量的三方库.这些三方的依赖库时不时的会更新自己的代码.

第三方依赖库的代码更新会很容易造成代码运行的不稳定,

比如昨天还跑的好好的项目,另一位刚刚接手的同学重新安装依赖之后项目就完全跑不起来了.

或者自己机器跑的好好的代码,扔到打包机上重新打包之后就完全跑不起来.

因为三方依赖库用的太多,很多时候并不能很快速的定位到项目为什么跑不起来.

特别是开发RN项目的时候,一个依赖更新的问题可能会定位一个大半天才能找到罪魁祸首(曾经的我为了这种事情浪费了大量的青春).

Taro跨端开发之跨端开发新时代的思考与举措

Tue, 16 Jun 2020 22:17:36 +0000

新时代

跨端框架的出现,前端的浏览器兼容过渡到了客户端平台兼容的新时代.

对于初创公司而言,这种框架可以快速试错与降低人力与时间成本.

为什么选择Taro

并不是说Taro方案有多优秀,就当前时间节点看来目前的所有跨端框架都还处于完善阶段.最完善的端可能就是小程序与H5了.

但是对于有着对跨端开发有着强烈需求的公司来说,这些还远远不够.

只是第一眼看上去Taro比较适合我们的现有业务.后续各种端的数量增大,如何从容对待.

目前也还是未知数.就团队而言,前端输出突然猛增,其他配套设施没跟上等于随时翻车.目前我们面临的最大问题就是测试资源的问题.

对于跨端技术而言,目前相对完善且符合公司业务的技术框架可以选择

Taro
uni-app

一个类React, 一个类Vue.

在框架层面,两种技术框架提供着非常接近的多端兼容方案.

最大的不同是React 与 Vue的区别.当然,uni-app 提供了小程序容器方案.

taro这边目前还没有.

就目前对Taro来看,直接实现Taro to uni小程序理论上是可以实现的.

在Taro next版本中,已经支持对vue语法, 那这样后续是否会出现多端框架to多端框架的局面呢?

回到问题本身,为什么我们选择Taro呢,

团队组建之初使用React技术栈
我们在RN端有了一定的探索
Taro支持快应用

就历史包袱来看,选择Taro过渡成本是相对较小的.

目标

一处代码,多端运行.
减少维护成本
多端快速上线

如果就快速上线来看,人力成本在短期内看,是非常可观的.但是一旦项目变大,团队变得也越大的时候.

自动化测试,而项目工程化没有跟上,那就直接天堂变地狱.

处境与心态

目前使用taro开发单端,基本上没有太大的问题.目前遇到的问题,都有办法可以解决的.

唯一占用开发工作量的是,如何处理代码在多端中的兼容问题.

所以处理兼容问题的方法与技巧还有多端开发的意识就尤为重要了.

还有一个就是开发者的心态问题,因为要开发多端,多端差异还是会有的.

在开发多端的同时,也要学习多端的开发方式.一来二去的,很容易形态奔溃.

但是如果跨越了这一时期,了解了各端的特点,后续面对一些问题都会游刃有余了~

适配最佳路径

经过各种实践,我们认为一下开发的兼容路径是相对简单的.

在适配的过程中,主要还是样式的问题比较多.如果反向适配,会极其痛苦,

因为你之前写的任意一行代码,都可能是后面的bug.

可能在后续的发展中,这种类似短板问题会越来越不明显.

但是就现在来看,合适的适配路径,是你必须要关注的重要问题.

RN –> 快应用 –> 小程序 –> 其他小程序 –> H5

脑洞 & 展望

就目前跨端框架发展趋势的话会不会发生以下事件?

一款跨端框架直接兼容另一款框架,直接吃掉所有端?
开源一款类小程序的容器,直接替代react Native 与 weex?
多端测试框架(一套测试用例,测试所有端)会不会应运而生?

尾巴

后续的这段时间,我会把以下问题与团队实践整理出文章供大家思考.