爱吃胡萝卜

突然想对之前写的 JSBridge 用 TS 重构一下，顺便简化一下整体结构。TS 的强类型是有了，但是还是存在着不足，导致相比其他强类型语言，稍微显得有点蹩脚。 比如创建一个抽象类的匿名内部类对象，就没法像 Java 那样，幸好基于 JS 本身的一些特点还是达到这个效果，看代码； 1234abstract class SuperClazz { public constructor(readonly msg: string) { } public abstract hello(): void;} 在调用的地方我们通过 自执行函数 来创建子类对象： 1234567891011let msg = 'asd';((msgParam: string) => { return new class SubClazz extends SuperClazz { constructor(msg) { super(msg); } ...

如果不是一个从零开始的项目，那么更多情况下是需要把 React Native 作为一个功能模块嵌入到现有应用中，这篇文章简单记录一下怎么集成 RN 到现有 Android 项目中，以及一些坑点。 OS：macOS 10.13.4 node：v9.10.1 npm：5.8.0 AS：3.1.0 创建 npm 工程按照传统 React Native 的代码使用 npm 进行“构建”，并且 Android 项目中一些依赖也来自于这个工程。 找一个你喜欢的位置，执行一下命令初始化一个 npm 项目： 12$ mkdir rn && cd rn$ npm init -y 然后需要安装 react 和 react-native ： 1$ npm install --save react react-native 接着创建一个入口文件和一些必要目录： 12$ touch index.android.js$ mkdir app 完成以上操作后，会得到一个如下的目录结构： 12345├── app├── index.android.js├── node_modules├── ...

GitLab Flow 在 Git Flow 和 GitHub Flow 中进行了一个折衷，避免了 Git Flow 的复杂性，又使得 GitHub Flow 不便于发版审核的问题。 GitLab 比较鸡贼，提出好几种分支管理模式，还不能满足你需求？ 使用 production 分支 GitHub Flow 认为每一次的合并操作都会产生一个可发布的版本，但是这只适合诸如 SaaS 类应用；并且还无法处理无法精确控制发布时间或只能在规定时间里merge的问题。 这种情况下，可以开一个 production 分支来反应部署的代码。每次部署都要把 master 分支合并到 production，大概的部署时间能在 commit 记录中反映出来，如果使用脚本进行自动部署，那么时间会更加精确。 使用 environment 分支 在这种分支管理模式下，master 分支作为代码上游，通过将 master 合并到 pre-productiopn 部署 pre-production 环境，同理将 pre-production 合并到 production 部署 production 环境。这 ...

在 这篇 文章中，Git Flow 整体管理看起来非常规范，但是一个很明显的问题就是太复杂并需要长期维护两个分支，分支太多，导致需要频繁的进行分支切换，这些过程中难免不会出问题；特别是现在的大型工程都采用持续集成/交付进行管理，这样就需要有一个分支能够保证上面的代码都是随时都可以发布的。 GitHub Flow 就是对 Git Flow 的一种精简，并且非常适用于持续集成。 理解 GitHub Flow GitHub Flow 相对于 Git Flow，它只保留了一个 master 分支，任何功能的添加都需要创建一个新分支，并且这些新的分支在被其他成员审阅之前是不会被合并到 maste 分支上的。显然，master 分支总是处于一个可发布的状态，同时这种模式非常适合不断有新功能添加的项目。 如果有多个人（团队）进行开发，GitHub Flow 推荐使用 pull request 的方式来进行合作。 管理流程Git Flow 的管理流程也非常简单，大致的分为下面的几个步骤： 创建功能分支 提交功能分支 请求一个 pull request（GitLab 中叫做 merge ...

在这篇文章中，我将会向大家讲解我大约一年前引入一些项目（公司或者私有的）里并且被事实证明为非常成功的开发模式。我早就想写一些关于这方面的东西，但是直到现在才找到时间来完整地完成这些东西。这里我不会讨论任何项目细节方面的东西，仅仅讨论分支策略和发版管理。 为什么选择 Git网上有各种关于 Git 和其他版本控制系统的优缺点比较，当然也有很多意见不一致的地方。作为一名开发者，我更偏向于使用 Git。Git 确实改变了开发者对于分支管理的思考方式。在传统的 CVS/Subversio 的世界中，分支合并和创建通常被认为有一点吓人（通常是冲突）并且你一段时间内只会做一次。 但是使用 Git，这些操纵将会变得非常简单，并且它们会成为你日常工作流中核心的一部分。例如，在 CVS/Subversion 的文档中，分支的创建和合并被安排在最后三章作为高级功能；与此同时，所有的 Git 文档里面，这些都是在前三章中的基础部分进行讲解的。 由于 Git 的简便性和可复现性，分支创建与合并再也不令人望而生畏。版本控制系统本就应该只辅助完成分支的创建于合并。 关于工具的讨论就到这里， ...

平时做开发，关注得比较多的是具体的开发工作，等开发完成进行部署的时候，需要做一系列繁琐的工作，例如上传到测试平台等，这些事情的价值实在是没有多少，而且保不准哪时候就会出叉子；而且这次发版的一些信息也是相对闭塞的，基本上只有参与开发的人员可以得知。所以这些工作的自动化显得尤为必要，而 Jenkins 就是这样的一种工具，当然还有很多其他的，不过它比较流行且开源免费，非常适合团队自建。 这里以 Gitlab、Android 为例来讲解，宿主机为 CentOS，所以关于 GItLab 的安装也就不说明了。 准备工作为了避免在自己机器上配置不必要的环境，造成污染，这里使用 Docker 的来进行安装。关于 Docker 的使用，不是本文的重点。 选一个你喜欢的目录，创建一个 build_jenkins.sh： 12docker image rm jenkins:android -fdocker build -t jenkins:android . 接着创建一个 dockerfile： 123456789FROM jenkins/jenkins:2.107-alpineLABEL ma ...

现在学习 Android 不像早些年，会写个 App 就能找到饭碗，如今不看看 Framework 源码有种分分钟掉队的感觉。虽然现在有一些比较优秀的站点提供源码阅读，但是毕竟在浏览器里面阅读，还是会遇到很多限制，最好还是自己下载一份。说道下载问题就来了，AOSP 的仓库被墙了，所以直接不能直接下载，或者说直接下载网速会很慢，还好国内有一些镜像服务可以避免这一问题。 之前用 Ubuntu 直接挂个 SS 就能以 2M/s 速度同步源码，但是最近在 Mac 就死活没得办法了。这里我们使用 清华 的源，不过它给的帮助文档似乎并不能直接照搬。 准备工作准备一块至少 100G 空闲的磁盘作为下载盘（大一点准没错，强烈建议下载到移动硬盘里）。然后 AOSP 编译环境要求 大小写敏感（Case-Sensitive） ，所以先格式化： 然后在这个磁盘（分区）上执行： 12$ mkdir AOSP && cd AOSP$ mkdir android-9.0.0_r1 我们这次下载的是 Android 9.0.0 的源码，所以目录就命名成这样，你也可以选择你喜欢的名 ...

今天重装 CentOS 后发现按照之前的步骤来配置 SSH 后一直提示 Permission denied ，第一反应反应就是 /etc/ssh/sshd_config 配置出错，但是仔细检查一遍之后并没有发现什么错误。后来网上找到原因是权限问题，赶快记笔记，防止以后再遇上这个坑而不知道。 索性把配置 SSH 服务端的流程都过一遍，这里以 CentOS 为例，其它发行版只是包管理器的差别。 安装 openssh这一步一般情况下不需要，以为几乎全部的 Linux 发行版都自带的 SSH。当然，如果机器上没有安装，可以手动安装。 在服务器上执行以下命令： 1$ sudo yum install -y vim openssh net-tools 这里除了安装 openssh 之外还安装 vim 用来修改配置文件以及 net-tools 获取服务器的公网/内网 IP。 创建 SSH 密钥要实现免密登录，我们需要把自己机器（这里使用的是MacOS，其它平台一样）产生的 SSH 公钥部署到服务器上。回到客户端，执行命令： 1234567891011121314151617181 ...

之前一直用 Ubuntu 自带的 Bash，没有去配置什么插件，感觉用着也还行，现在换到 MacOS 的 Terminal 下，发现它默认配置真的没有 Ubuntu 的好看，为了能更加快乐的使用终端，还是决定去捣鼓一番。 MacOS 自带应用不像 Linux 那样，想删就能删除，又不喜欢安装两个功能相同的应用，就直接使用自带的 Terminal。 效果 ​ 安装 zshMacOS 自带了 zsh，可能不是最新版本，不过没影响，其它平台使用各自的包管理器进行安装就👌了。 先看看系统都提供哪些 shell： 1234567891011$ cat /etc/shells# List of acceptable shells for chpass(1).# Ftpd will not allow users to connect who are not using# one of these shells./bin/bash/bin/csh/bin/ksh/bin/sh/bin/tcsh/bin/zsh 这里看到 zsh 已经安装了，接着替换系统默认的 shell： 1$ chsh ...

一般情况下，我们都是通过 Android Studio 来进行 Android SDK 的管理的，更新啥的都是点点鼠标完成了，当然，我们知道 AS 只是做了一个封装。不过有时候，我们只是想安装更新，并不想启动 AS，那么这时候通过命令行就会轻量很多；在 CI 中，更加是没有 AS 的，那么这时候命令行操作成为了唯一的选择。 在 sdk 25.2.3 及以上，Android SDK 提供的了 android_home/tools/bin/sdkmanager 来代替原来的 android 。 概览先进入到 android_home/tools/bin/sdkmanager 来看看 sdkmanager 提供哪些操作选项： 1234567$ ./sdkmanager --helpUsage: sdkmanager [--uninstall] [<common args>] [--package_file=<file>] [<packages>...] sdkmanager --update [<common args>] sdkma ...