FerryVip's Blog

技术分享

1. Copixel 工具基本介绍和安装

Copixel 是一个 UI 还原走查的工具,目前只支持 Chrome 浏览器使用,需要去 Chrome 商店下载使用 下载地址;

2. Copixel 工具的使用

1. 点击插件使用

UPvroX-14-22-OwH3tV

2. 从 Figma 导出设计图,并添加到图片中;

wps_doc_1-14-24-AUlp6E

3. 打开页面,调整窗口宽度,使用校稿工具比对

wps_doc_2-14-24-UAjIpC

4. 通过截图软件记录问题的地方

wps_doc_3-14-24-zJDraz

3. 浏览器屏幕宽度快捷设置

wps_doc_4-14-24-dWN0vY

4. 其他相关

官方的指南: Copixel走查验收插件使用指南-对外版

1. 常用的文件类型规范

  • 客户端基本上都是ES的开发规范;
  • nodejs服务端项目基本上都是CJS的开发规范;
  • 近两年的nestjs框架才让服务端出现了ES的文件类型;

2. 介绍

1. CJS

CJS 是 CommonJS的缩写,通过 module|require 来导入导出:

1
2
3
4
5
6
7
// importing 
const doSomething = require('./doSomething.js');

// exporting
module.exports = function doSomething(n) {
// do something
}
  • CJS通常是在Node中、Node服务端框架中。
  • CJS是同步导入模块
  • 你可以从node-modules中引入一个库或者从本地目录引入一个文件
  • CJS不能在浏览器中工作,它必须经过转换和打包
  • CJS的输出是运行时加载,输出的内容是值的拷贝而不是值的引用。

2. AMD

AMD代表异步模块定义

1
2
3
4
define(['dep1', 'dep2'], function (dep1, dep2) { 
//Define the module value by returning a value.
return function () {};
});
  • AMD 是异步(asynchronously)导入模块的(因此得名)
  • 一开始被提议的时候,AMD 是为前端而做的(而 CJS 是后端)
  • AMD 的语法不如 CJS 直观。

3. UMD

UMD 代表通用模块定义(Universal Module Definition)

1
2
3
4
5
6
7
8
9
10
11
(function (root, factory) { 
if (typeof define === "function" && define.amd) {
define(["jquery", "underscore"], factory);
} else if (typeof exports === "object") {
module.exports = factory(require("jquery"), require("underscore"));
} else {
root.Requester = factory(root.$, root._);
}
}(this, function ($, _) {
// this is where I defined my module implementation var Requester = { // ... }; return Requester;
}));
  • 在前端和后端都适用(“通用”因此得名)
  • 与 CJS 或 AMD 不同,UMD 更像是一种配置多个模块系统的模式。这里可以找到更多的模式
  • 当使用 Rollup/Webpack 之类的打包器时,UMD 通常用作备用模块
  • UMD先判断支持Node.js的模块(exports)是否存在,存在则使用Node.js模块模式。再判断是否支持AMD(define是否存在),存在则使用AMD方式加载模块。都不行就挂载到 window 全局对象上面去

4. ESM

ESM 代表 ES 模块。这是 Javascript 提出的实现一个标准模块系统的方案。
我相信你们很多人都看到过这个:

1
2
3
4
5
6
7
8
9
10
11
12
import React from 'react'

//or

import {useState,useEffect} from 'react';

//or

const demo=()=> 1;
export default demo;
//or
export {demo};
  • 在很多现代浏览器可以使用
  • 它兼具两方面的优点:具有 CJS 的简单语法和 AMD 的异步
  • ESM是编译时输出接口,输出的是值得引用。
  • ES6 模块不是对象,而是通过 export命令显式指定输出的代码,import时采用静态命令的形式。JS 引擎对脚本静态分析的时候,遇到模块加载命令import,就会生成一个只读引用。等到脚本真正执行时,再根据这个只读引用,到被加载的那个模块里面去取值。模块内部引用的变化,会反应在外部。
  • 在import时可以指定加载某个输出值,而不是加载整个模块,这种加载称为“编译时加载”。在编译时就引入模块代码,而不是在代码运行时加载,所以无法实现条件加载。也正因为这个,使得静态分析成为可能。
  • 得益于 ES6 的静态模块结构,可以进行 Tree Shaking
  • ESM 允许像 Rollup 这样的打包器,删除不必要的代码,减少代码包可以获得更快的加载
  • 可以在 HTML 中调用,只要如下
1
2
3
4
<script type="module"> 
import {func1} from 'my-lib';
func1();
</script>

但是不是所有的浏览器都支持

3.结论

  • UMD 随处可见,通常在 ESM 不起作用的情况下用作备用
  • ESM 是异步的,适合前端,ESM输出是静态的,在编译时就能完成输出,输出的是值的引用,ESM(ESModule)是ECMAScript自己的模块化体系,具有简单的语法,异步特性和可摇树性,因此它是最好的模块化方案
  • CJS 是同步的,适合后端,CJS输出是一个对象,所以输出是在脚本运行完成后才执行,输出的是值的拷贝
  • AMD 是异步的,适合前端

1. 断点

在 Chrome 的 dev tools 里面断点是有多种方式的,但是最简单的断点方式对于调试一些 race condition 的代码是有负面影响的,特别是多重断点对于调试流程阻碍性很强。
那么就需要一些新的方式来组合使用保证调试到目标逻辑代码。

2. 代码断点

右键对应的行数,有相关菜单功能出来

wps_doc_0-16-18-3jQF7Z

1.Add breakpoint

最简单的基础断点功能

2. Add conditional breakpoint

具备条件执行断点功能的断点方式,允许通过调用执行代码环境的变量判断是否需要断点。
wps_doc_1-16-18-b8OiKv

表达式的执行允许修改变量的值

1
a = 5 && false

3. Add logpoint

日志断点,类似条件断点的 console.log({expression}) && false, 始终不会断点,但是可以不断输出环境里面的变量和计算的值。

3. 断点工具栏

断点控制栏,除了常见的暂停、return 等功能,我们可以看到还有最右边两个功能
wps_doc_2-16-18-iEx6tF

1. Deactivated breakpoint

禁止所有的断点

2. Pause on exceptions

当发生 uncaught exceptions 时,将会直接断点。
如果勾选了 Pause on caught exceptions 时,只要碰到 throw 关键字,会自动断点。

4. 网络断点与事件断点

1. 网络断点

网络断点将在发起网络请求的时候直接断点住对应代码,目前最大的作用是断点后修改其参数来实现一些目的。

2. 事件断点

目前来说事件断点在 react fiber 的实现下功能并没有特别大的用处,但是对于一些原生调试还是有用的。
wps_doc_3-16-18-ruYm6N

5. Dom 断点

Deactivated breakpoints 对 dom 断点无效
Dom 断点是一个特殊的功能,对于一些实现奇葩的情况下是可以直接找到修改 dom 代码的源头进行追踪代码的。
使用方式
wps_doc_4-16-18-ItHN05
1.Subtree modifications
当 children 发生变化的时候,将会断点到对应的代码
2.Attribute modifications
当 dom 属性发生变化的时候,将会断点到对应的代码
3.Node removal
当被选择的 dom 被删除的时候(如果是父级 dom 删除不算),将会断点到对应代码调用栈
wps_doc_5-16-18-VcZpIa

之前写文章用的图床是在微博,后面发现微博把这个给封了,这就让人很尴尬,最主要问题就是图片没了,之前的文章图片也没有备份,只能找寻新的图床,后面找到了 uPic 软件,开源的用着也还不错,主要是可以上传图片到 git 仓库,还有外链,图片还能备份,满足了我基本使用,今天的文章就是 uPicgitee 配合的基本配置;

1. uPic 软件下载

https://github.com/gee1k/uPic/releases GitHub 去下载最新版本的文件,解压缩托进应用程序文件夹,双击打开就可使用

2. gitee 配置

  1. 新建仓库

16-19-zNF3dd-gitee仓库创建

  1. Token 创建
      1. 进入码云 Token 创建页面
      1. 勾选 repo 访问权限。然后滚动页面到底部,点击Generate token按钮来生成 token

        16-19-J68X4y-Token生成1

      1. 复制生成好的 Token 值到 uPic token 输入框
        16-19-hkrtd9-Token生成2
        注意:此 Token 只会显示一次!请务必保存好,否则之后丢失了,就得重新创建

3. uPic 软件配置

打开 uPic 的偏好设置,选择图床,添加 Gitee 图床,输入我们刚才创建的仓库资料和 Token,配置完成可以点击验证,看是否能够成功;

保存路径我是设置为 uPic/{year}-{month}-{day}/{filename}-{hour}-{minute}-{random}{.suffix}

16-19-z3yzaa-uPic设置


16-19-4fmCAf-uPic上传设置


4. uPic 软件使用

一般使用的话我是选择文件上传

16-19-q8z5tJ-uPic选取文件


还有一个是拖拽文件直接上传

16-19-8WcCLu-uPic拖拽文件上传

使用 GitLab-CI 和 GitLab Runner 打包 iOS 应用

折腾由来

来源于一篇国外的博客 iOS Continuous Integration with GitLab CI, Fastlane & OTA Installation,看到其使用 GitLab-CI 和 GitLab Runner 来打包 iOS 应用做持续集成,看着还不错,自己之前也做了一些持续集成的例子;

1. 安装 runner

  • 手动安装(推荐)
    1. 下载 binary sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
    2. 设置权限 sudo chmod +x /usr/local/bin/gitlab-runner
  • brew 安装(发现会有权限问题)
    1. 安装 brew install gitlab-runner
    2. 启动 brew services start gitlab-runner

2. 注册 Runners

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1. 注册 runner
sudo gitlab-runner register
2. 填写 gitlab-ci 地址,这边以官方的为主
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
3. 输入获取的 token ,下面会介绍如何获取
Please enter the gitlab-ci token for this runner
xxx
4. 输入描述,后面可以修改
Please enter the gitlab-ci description for this runner
mac description
5. 输入机器的 tag,后面可以修改
Please enter the gitlab-ci tags for this runner (comma separated):
mymac
6. 输入执行类型,这边填入 shell
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker
shell

获取 token

3. 配置 .gitlab-ci.yml 文件

在 git 的根目录创建 .gitlab-ci.yml 文件,内容示例如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

before_script:
- echo "----------global---before_script--------------"

stages:
- build
- publish
# 构建 pipeline

build_job:
stage: build
tags:
- testmac
before_script:
- echo "------build-------before_script--------------"
script:
- sh ios.sh
# 打包 App 脚本
artifacts:
expire_in: 90 days
paths:
- build
# 构建产物打包保存服务器
only:
- master

pages:
stage: publish
script:
- ls build
index.html
artifacts:
expire_in: 90 days
paths:
- build
# 把 build 文件设置成 pages 静态托管
only:
- master

一些 gitlab-ci 配置文档, GitLab CI/CD Pipeline Configuration Reference

4. 自动构建

当代码推上去后, gitlab-ci 会触发构建,向 GitLab Runner(自己设置的机器) 发布任务,并执行构建

  • push 取消自动构建
1
2
git push --push-option=ci.skip    # using git 2.10+
git push -o ci.skip # using git 2.18+

构建面板

5. 定时自动构建

根据自己需要自己添加定时构建

使用 Storybook 开发管理组件(ReactNative 版本)

0. 介绍

Storybook 是 UI 组件的开发环境。它允许您浏览组件库,查看每个组件的不同状态,以及交互式开发和测试组件。

根据官网的介绍可以支持 React,React Native,Vue,Angular,Ember,HTML,Svelte,Mithril,Riot.

做了不少 ReactNative 的项目,每个项目的组件不少,开发到最后都不知道有多少个,如何使用,所以才会想着用啥管理起来,我这次讲的就是关于 React Native 的一些简单使用方法;

1. 安装(ReactNative 版本)

  • Automatic setup 自动安装,通过官方的 @storybook/cli 命令行创建

    npx -p @storybook/cli sb init --type react_native

    • 是否安装 web server 选取



安装完成,一些依赖,以及文件目录

* 启动项目

    > ![](https://ws1.sinaimg.cn/large/8bbf0afbly1g5byy5yakej20q81g0wq9.jpg)
发现会有依赖缺失,缺失的依赖安装(估计是当前版本缺失吧)
`yarn add -D emotion-theming @emotion/core`
![](https://ws1.sinaimg.cn/large/8bbf0afbly1g5byy5kfm6g208e0gkgu5.gif)运行成功

* `yarn storybook` 启动 web server 管理
    > ![](https://ws1.sinaimg.cn/large/8bbf0afbly1g5byy5k5paj22081d018u.jpg)
  • Manual setup 手动安装,自己添加依赖,以及配置文件位置(稍微麻烦点)

    yarn add -D @storybook/react-native @storybook/addons @storybook/addon-links @storybook/addon-actions emotion-theming @emotion/core babel-loader @storybook/react-native-server

    文件目录的就可以参照自动创建的,或者跟着官方教程

做,这边就不在展开,基本后面展示和上面一样

2. 插件 addon

刚才跑起来的项目点击到 ADDONS 里面显示没有配置加载,这里就说下插件已经配置
首先是一张官方 addon 插件支持表,可以看出 React 支持的最多, rn 的支持偏少而且支持配置比较复杂,接下来继续看

2.1 @storybook/addon-actions | @storybook/addon-ondevice-actions

Storybook Addon Actions可用于显示Storybook中事件处理程序接收的数据。

2.2 @storybook/addon-notes | @storybook/addon-ondevice-notes

Storybook Addon Notes允许您在Storybook中为故事编写注释(文本或HTML)。

Storybook Links addon 可用于创建在故事书中的故事之间导航的链接。在 ReactNative 中链接跳转这个版本好像有点问题,待跟进看下

2.4 @storybook/addon-backgrounds | @storybook/addon-ondevice-backgrounds

Storybook Background Addon 可用于更改故事书中预览中的背景颜色。

2.5 @storybook/addon-knobs | @storybook/addon-ondevice-knobs

Storybook Addon Knobs 允许您使用Storybook UI动态编辑React道具。您还可以使用旋钮作为Storybook中故事的动态变量。

2.6 @storybook/addon-options

  • NOTE: Options Addon is deprecated as of Storybook 5.0,直接内嵌
    • Global options: addParameters({ options: { … }}) and no addon is needed.
    • Story options: storiesOf(…).add(‘name’, storyFn, { options: { … }})

3.总结

  • Storybook 可以通过给每个组件写 story ,然后显示一些使用案例,同时可以根据一些 addon 插件,做到直接调试 UI,同时这样也能很好的管理组件;

  • 可以通过官方给的 addon API 自己写一些好用的插件,可以参考 官方教程

相关链接

  • GitHub 示例代码地址
  • Storybook GitHub
  • Storybook 官网

Jenkins 基本食用方法

0. 介绍

Jenkins是一个开源软件项目,是基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

Jenkins功能包括:

  1. 持续的软件版本发布/测试项目。
  2. 监控外部调用执行的工作。

1. 安装(Mac OS)

通过 brew 安装 Jenkins,其中可能还需要 Java 环境依赖,需要去官网下载 jdk,我这边用的是 jdk1.8

安装: brew install jenkins

  • 直接启动: jenkins 就可以启动,退出命令行就关闭服务

  • 通过 brew services

    启动: brew services start jenkins

    重启: brew services restart jenkins

    关闭: brew services stop jenkins

2. 初始配置

第一次安装后启动需要做初始配置

  • 解锁 Jenkins ,从命令行或者提示的路径找到密码

  • 自定义一些扩展插件,可选择安装推荐的或者自选,选择推荐安装,后续管理插件还能继续安装


  • 创建管理账户

  • 然后就进入 Jenkins 了

  • 插件的查找和安装


  • 简单的创建任务

创建任务,给任务起一个名

任务做配置,如 描述,Git,构建等;

任务构建,以及进度条

构建日志输出

3.一些好用的插件

  • 动态参数构建 Dynamic Extended Choice Parameter
  • Git 参数 Git Parameter

  • Build Name Setter
  • 设置构建后描述 Project Description Setter

  • 设置强制语言包 Locale

4. 一些问题解决

  • 有些时候 git 内容很大,pull 时会出现超时导致构建失败!

解决方式: Git 配置时添加一个 clone 的配置把超时改为 60 或者更多,把超时改大,一般就第一次的 pull 会请求比较久,后续都是增量的,会比较快了;

5. 等等

等待继续研究,估计是和 docker 相关的!

idea 使用一些配置

1. 创建文件自动添加注释

1
2
3
4
5
6
/**
* @Author: ferryvip
* @Description:
* @Date: Create in ${TIME} ${DATE}
*
*/

2.

App 打包构建系统

0. 由来

根据开发测试等实际应用需求设计了一套打包构建系统,系统包括以下主要功能:

  1. App 多环境打包;
  2. App 自动发布热更新;
  3. App 管理托管;

系统的基本组成:

  1. 通过 Jenkins 来做打包,热更新推包,自动测试服务;
  2. 应用打包完成上传到蒲公英,并把蒲公英上的下载地址等信息通过自建的 Node 服务做应用的托管,这样我们就可以在 Node 中对应用做相应的管理操作;
  3. 热更新推包后,我们记录相应的数据后,也记录到 Node 服务中,这样我们也可以在 Node 服务中对热更新做出查看或者撤回更新等操作;

打包对比

手动打包 VS 自动打包

手动打包 自动打包
耗时长,效率低; 自动化打包,解放双手;
重复性多,人工成本高; 配置好后,一键操作;
出错性概率大; 可配置一键远程打包;

1. 主要功能点





2. 主要实现点

利用 App Center 来打包你的应用

App Center 是巨硬(微软)家的一个应用开发管理平台服务,之前主要使用的是他的 CodePush 服务,后续平台升级了,把开发的崩溃收集,数据统计,推送服务,应用构建及测试,CodePush 等多个服务融合在一起,做出的 App Center 平台,基本功能也都是免费的,今天这篇文章主要是讲 iOS (原生和 ReactNative)应用通过 App Center 来打包;

0. 前期准备

  1. App Center 账号(可通过 GitHub 账号授权登录) https://appcenter.ms;
  2. GitHub 账号 https://github.com/;

1. 设置 Build 配置

1.1 仪表盘点击创建应用

1.2 填写应用信息

  1. 填写应用基础信息 –> 应用名称 –> Release type
  2. App Center 可以用来构建多种系统平台的应用,以及不同平台写的应用
  3. 这边我们 OS 选取 iOS , Platform 选 Objective-C / Swift

1.3 添加构建仓库

点击构建配置,连接仓库,选取 GitHub 仓库

通过关联的 GitHub 账号,选取相应的 iOS 仓库

1.4 分支构建配置

根据 GitHub 仓库获取仓库分支,点击分支对应的构建配置

1.5 构建配置

  1. App Center 会读取仓库的文件,让你选取你要构建的 Project/Workspace 和相应 Shared Scheme;
  2. Xcode 版本;
  3. Build scripts 自定义构建脚本,脚本是包含在 git 仓库文件里,具体配置见文档;(可选配置)
  4. 构建触发规则, push 触发构建/手动触发;
  5. 自动增加构建号,自动测试配置;(可选配置)
  6. 环境变量设置,见文档
  7. 签名证书设置,证书导出这边不做过多介绍,可参考链接;
  8. 真机测试,分发构建,构建状态图标;(可选配置)

1.6 分支构建历史

1.7 构建产物

构建完成后有 ipa 包等,可以通过 App Center 分发

但是个人发现访问和下载速度上不是很快,所以通过 Post-build 脚本自己上传到蒲公英托管平台;

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/usr/bin/env bash

if [ "$AGENT_JOBSTATUS" == "Succeeded" ]; then

ukey=蒲公英ukey
apikey=蒲公英apikey
desc=蒲公英上传描述

curl -F "file=@$APPCENTER_OUTPUT_DIRECTORY/$APPCENTER_XCODE_SCHEME.ipa" \
-F "uKey=$ukey" -F "_api_key=$apikey" \
-F "updateDescription=$desc" https://qiniu-storage.pgyer.com/apiv1/app/upload

fi

2. 总结

App Center 里面提供了一系列的关于应用开发的 SDK 和服务,产品做得很全面,还提供了一些云的概念操作(线上打包);

有时间可以多研究 App Center 的这一套东西,如果一个公司规模够大,产品丰富,也可以自己搭建一个自己像这样的一套系统;