这次基于 RustDesk 1.5.0 定制 iOS 客户端，重点解决两件事：让应用自身访问私有 API，同时让 iPhone、iPad 上的设备选择、画面方向和触摸操作更顺手。

这套部署将账号管理、连接协调和会话数据传输分开处理：

• Rustk API Server：提供账号登录、设备管理和地址簿同步，服务端口为 21114，仅通过 Tailnet 私网访问。
• hbbs：提供设备注册、ID 查询和连接协调，主入口为公网 21116；当前部署使用支持 TCP KeyExchange 的补丁版本。
• hbbr：使用官方 RustDesk OSS 中继服务，主入口为公网 21117，负责需要中继时的会话数据转发。
• Headscale：自建的 Tailscale 控制服务，负责节点注册、授权及网络信息分发。它与 Rustk API Server 是两个独立服务，不承担远程桌面流量中继。

下图展示定制后的 iOS 客户端如何接入现有部署。按服务职责划分逻辑链路，不表示这些组件必须部署在不同物理主机上；图中省略了域名、节点地址及其他辅助端口。

对于这套部署，客户端只需要让 API 请求走内嵌 Tailnet，ID 和中继继续走原有网络。远程画面并不经过 Rustk API Server；图中画的是中继连接，具备直连条件时仍由原有 RustDesk 连接机制处理。

原客户端访问私有 API 时，需要设备先具备到该私网的连通性。定制的目标是将这部分网络能力收进 RustDesk 应用，让它以独立节点加入 Headscale 管理的网络，不再要求用户先切换到另一个 App 建立系统 VPN。

定制内容与实现思路

1. 按服务分流，保留原来的协议与认证​

内嵌网络基于官方 Go tsnet。Flutter 管理设置和状态，Swift 通过 MethodChannel 负责节点生命周期与 Keychain，Go 编译为 iOS 静态库提供网络能力，Rust 则继续处理现有 HTTP 和 TCP 协议。

对于 Rustk API Server，请求沿着以下路径进入私网：

登录 / 设备 / 地址簿
    → 原有 Flutter / Rust HTTP 入口
    → 受限的本机转发端口
    → 内嵌 tsnet 节点
    → Tailnet 内的 Rustk API Server

转发器只接受明确配置的目标，原有账号认证、Server Key 和 secure TCP / KeyExchange 流程继续保留；HTTPS 的证书校验也仍由 Rust 客户端完成。不能为了让第三方 API 或补丁版 hbbs 连通，就跳过已有的校验。

API、ID、Relay 分别提供分流开关。内嵌 Tailscale 总开关默认关闭；在本文部署中，开启后只需启用 API 分流。这样账号和地址簿可访问私有服务，而其他平台和未启用分流的连接继续沿用原来的路径。

如果以后把 hbbs/hbbr 也迁入 Tailnet，可以再开启对应开关。不过当前内嵌 ID 分流只覆盖 TCP 信令和在线查询，启用后会要求会话走中继路径，尚未接入原生 UDP、P2P 等完整能力。

2. 明确 Headscale 配置和节点状态​

设置页增加独立的控制服务器地址，用于填写自建 Headscale 的 URL。它决定节点向哪里注册；Rustk API、ID 和中继地址仍在原有“ID/中继服务器”中配置，两类设置各管各的职责。

授权通过控制服务器生成的链接完成，支持打开浏览器，也提供复制链接入口。Headscale 可以按部署配置采用管理员注册或 OIDC 登录，客户端沿用其注册流程。更换控制服务器时，会提示清除本应用原来的节点身份后重新授权，避免跨网络复用身份。

首页同时增加 Tailnet 状态条：连接中、已连接、需要授权、等待设备批准和连接失败都能直接看到；已连接时展示节点 IP，点击可进入设置。这样 API 不可用时，首先能区分网络尚未接通和业务服务异常。

3. 围绕移动端的使用顺序调整界面​

首页以地址簿和设备列表为中心，保留手动输入 ID，同时提供收藏、最近连接、在线设备等入口。iPhone 使用紧凑的分段入口，较宽的 iPad 窗口使用侧栏，继续复用现有设备模型和地址簿同步逻辑。

进入远程会话时，iPhone 按配置请求横屏，退出后恢复首页方向；iPad 默认保留系统方向。悬浮工具栏集中放置键盘、鼠标模式、显示、旋转和更多操作，空闲时收起，减少对远程画面的遮挡。

“显示”菜单新增“双指缩放和拖动画布”选项，复用现有的画布锁定能力。关闭后，普通双指手势不会再缩放、平移本地画布，远端鼠标点击和拖拽仍沿用原有处理。这里不重写手势识别或坐标换算，减少横屏、键盘和触摸模式之间的相互影响。

4. 配置与身份独立于安装包保存​

服务器地址、Headscale 地址和界面开关保存在应用用户数据区。画布手势选项也会持久化，下一次会话和重启应用后恢复上次选择。

节点身份加密存放在 Library/Application Support/embedded-tailnet，解密密钥保存在 Keychain。普通断开和禁用会保留身份，清除本地身份、授权新节点或更换控制服务器才会主动重置。

正常覆盖更新应保留这些数据。使用 LiveContainer 时，要继续使用同一个应用标识、数据容器和 Keychain；新建容器、清除数据或更换设备不能按普通更新处理。节点身份目录不参与设备备份，密钥也绑定设备，因此复制普通配置文件不等于迁移了授权。

构建与使用中需要注意的坑

控制服务器必须在加入网络之前可达​

Headscale 地址负责建立节点身份，不能只在“加入这个 Tailnet 后”才能访问，否则注册流程会形成循环依赖。配置时也要区分节点名称、控制服务器地址和业务 API 地址：早期状态里出现的 localhost 是授权前 SDK 返回的系统主机名，并不是要连接的服务器；现在授权前显示配置的节点名，获得网络信息后再显示实际名称和 IP。

节点启动完成也不代表授权链接已经生成。授权入口需要等待状态变化，并在超时或浏览器打开失败时给出反馈；只在点击瞬间检查一次链接，会表现为按钮没有反应。当前实现有等待窗口和复制链接入口，但不会假设浏览器一定能自动跳回应用。

Rust 与 Go 要在最终应用阶段一起链接​

新增 Go 静态库后，如果 Cargo 先尝试生成独立的 Rust 动态库，Go 提供的 _rd_tailnet_port 等符号此时还没有参与链接，会出现未定义符号错误。

iOS 构建因此明确生成 Rust 静态库：

cargo rustc --locked --features flutter,hwcodec --release \
  --target aarch64-apple-ios --lib --crate-type staticlib

随后由 Xcode 把 liblibrustdesk.a 和 libEmbeddedTailnet.a 一起链接进应用。这个调整只涉及 iOS 构建，不需要改变其他平台的产物类型。

缓存中的 Flutter SDK 可能已经打过补丁​

缓存整个 Flutter SDK 时，修改过的源码也可能被缓存。恢复缓存后再次无条件执行 git apply，会报 patch does not apply，即使补丁本身兼容该 Flutter 版本。

处理方式是在应用前用 git apply --reverse --check 判断是否已经包含补丁：已应用则跳过，否则正常应用。不完整或确实不兼容的补丁仍然报错，避免用忽略退出码的方式隐藏问题。

构建环境也需要统一。CI 固定 Flutter 3.24.5、Rust 1.75、Go 1.26.5 和 Xcode 16.4；开发机使用更高版本 Flutter 时，可能先撞上现有依赖的 API 兼容问题，不能直接当作新功能本身的错误。

Xcode 归档和可导入的 IPA 是两种产物​

.xcarchive.zip 是构建归档，不能直接作为 LiveContainer 的 IPA 使用。unsigned 模式需要把归档里的 Runner.app 按 Payload/Runner.app 结构重新打包，并检查 ZIP 完整性。

最终 iOS artifact 只上传 .ipa，不附带体积更大的 Xcode 归档；许可证和第三方声明保留在应用资源中。未签名 IPA 可供 LiveContainer 导入或后续重签名使用，但不等于能够通过 iOS 普通安装流程直接安装。

另外，Fork 需要启用 Actions，workflow_dispatch 工作流也需要先存在于默认分支，Actions 页面才有相应的手动运行入口，再选择要构建的分支。具体规则见 GitHub 手动运行工作流说明。

当前范围

这轮改动集中在 iOS：按现有部署接入私有 API，保留原来的远控协议，再补齐移动端界面和配置持久化。增强逻辑主要放在独立模块，共享入口只增加必要的条件判断，方便后续同步上游。

自动横屏受 iOS 窗口策略限制，后台连接受系统生命周期限制；内嵌网络也不提供通用系统 VPN 的全部能力。完整体验仍应结合实际 Headscale、Rustk API Server、hbbs/hbbr 和设备验证，尤其是账号登录、地址簿同步、连接协商及覆盖更新后的身份复用。

相关实现保存在 suhli/rustdesk，配置和实现细节可参考对应提交的 iOS 增强文档。

2026-10-12 更新：自定义键盘宏与移动端细节修正

1. 将常用远端操作保存为键盘宏​

在手机上操作远程 Windows 时，一些本来很短的键盘操作，需要反复打开软键盘、切换修饰键、等待菜单展开。例如让远端电脑进入睡眠，可以先按 Win+X，再依次按 U、S。这类固定流程适合保存为宏，在需要时一次触发。

因此新增“自定义宏”功能：在“设置 → 远程控制 → iOS 增强功能”中管理宏，也可以从远程会话的悬浮工具栏或“更多”菜单进入。每个宏包含名称和有序步骤，每一步填写一个按键或组合键，并设置执行后的等待时间，支持添加、编辑、删除和调整顺序。

以 Windows 睡眠为例，应用提供了可以直接编辑的预设：

Win+X → 等待 300 ms → U → 等待 200 ms → S

组合键使用 + 分隔，例如 Ctrl+Shift+Esc；每步延迟可设为 0–60000 毫秒。延迟用于等待菜单或窗口响应，快捷字母则取决于远端系统语言，使用时仍要按实际界面调整。添加预设只会进入编辑页，保存后需要在会话中主动点击“运行宏”。

实现上继续复用 RustDesk 已有的键盘消息：每一步完成按下和释放，再等待后续步骤，不改动原有的远端输入协议。运行中可以停止，关闭宏页面或应用进入后台会取消剩余步骤；发送前也会检查连接状态、键盘权限和只读模式。“宏已发送”表示按键发送完成，并不代表远端菜单一定执行成功。

宏定义保存在本机用户配置中，重启和保留同一数据容器的覆盖更新后仍可使用。它与节点身份一样，需要沿用原来的应用数据，但不会上传到 Rustk API Server，也不要求 Windows 被控端增加宏功能。

2. 全屏页面和保存入口需要单独检查​

宏编辑页最初使用全屏弹窗承载。在 iPhone 上，弹窗仍会受到安全区和键盘留白影响，底部可能露出上一层设置页的开关；“全屏弹窗”并不等于拥有完整页面的布局行为。

这次将宏列表和编辑页改为独立页面，由页面背景覆盖整个屏幕，再在内容区保留安全间距。步骤输入仍使用普通对话框，保持短输入操作的交互方式。

保存入口也暴露了主题适配问题：文字按钮沿用蓝色文字，放到蓝色标题栏后几乎不可见。现在改用右上角的保存图标，跟随标题栏的图标颜色，并保留“保存宏”提示。修正集中在宏页面的展示与入口，不改变已有宏的存储格式和执行逻辑。

3. 图标检查延伸到最终 IPA​

应用图标需要同时检查生成过程和最终产物。早期图标绘制使用的位图格式不适合 Quartz 绘制，导出的图片虽然存在，却是纯黑；改为支持的 32 位 RGBX 绘制格式后，再导出不透明 PNG，才得到正常图案。

只检查构建前的源图仍然不够。现在除了校验各尺寸源图，还在上传 artifact 前解开最终 IPA，读取 iPhone、iPad 的主图标声明，检查对应文件是否存在、是否不透明，以及是否有可见图案。Xcode 会把 PNG 转换为 iOS 优化格式，检查时先通过 SDK 的 pngcrush -revert-iphone-optimizations 解码；普通图片查看器打不开这类文件，并不能直接说明文件损坏。

另一个容易混淆的点是版本与缓存。列表中的 1.5.0 不能区分不同构建，应结合构建编号确认实际安装的包。如果 IPA 内图标正常，LiveContainer 中仍显示黑图，还要检查它保留的图标缓存。处理时优先覆盖更新原应用并重启 LiveContainer，必要时只清理图标缓存，保留原数据容器和节点身份，避免为了刷新图标重新配置整套连接环境。

这轮更新仍集中在 iOS 客户端及其构建流程。宏的保存恢复、按键顺序与延迟、停止或权限失效后的行为已通过本地逻辑测试，页面修正通过静态检查；实际菜单操作、修正后的界面和新增的 macOS IPA 校验步骤仍需结合新构建与真机确认。

然而clickhouse-jdbc却不支持

修改ClickHouseClientModule.java 在configure方法抄一行隔壁mysql module的调用

newSetBinder(binder, ConnectorTableFunction.class).addBinding().toProvider(Query.class).in(Scopes.SINGLETON);

然后开启调试发现报了个

Query not supported: ResultSetMetaData not available for query: ...

然后追查clickhouse plugin testcase的历史提交发现曾经有备注说为啥没有table function

// table function disabled for ClickHouse, because it doesn't provide ResultSetMetaData, so the result relation type cannot be determined

然后搜索一下,发现曾经有过issue提问怎么不执行查询拿到resultset metadata

然后简单粗暴,给clickhouse client加上一个override:

@Override
public JdbcTableHandle getTableHandle(ConnectorSession session, PreparedQuery preparedQuery) {
    ImmutableList.Builder<JdbcColumnHandle> columns = ImmutableList.builder();
    try (Connection connection = connectionFactory.openConnection(session);
          PreparedStatement statement = connection.prepareStatement(preparedQuery.getQuery() + " LIMIT 0")) {
        ResultSetMetaData metadata = statement.executeQuery().getMetaData();
        if (metadata == null) {
            throw new UnsupportedOperationException("Query not supported: ResultSetMetaData not available for query: " + preparedQuery.getQuery());
        }
        for (int column = 1; column <= metadata.getColumnCount(); column++) {
            String name = metadata.getColumnName(column);
            JdbcTypeHandle jdbcTypeHandle = new JdbcTypeHandle(
                metadata.getColumnType(column),
                Optional.ofNullable(metadata.getColumnTypeName(column)),
                Optional.of(metadata.getPrecision(column)),
                Optional.of(metadata.getScale(column)),
                Optional.empty(), // TODO support arrays
                Optional.of(metadata.isCaseSensitive(column) ? CASE_SENSITIVE : CASE_INSENSITIVE));
            Type type = toColumnMapping(session, connection, jdbcTypeHandle)
                .orElseThrow(() -> new UnsupportedOperationException(format("Unsupported type: %s of column: %s", jdbcTypeHandle, name)))
                .getType();
            columns.add(new JdbcColumnHandle(name, jdbcTypeHandle, type));
        }
        return new JdbcTableHandle(
            new JdbcQueryRelationHandle(preparedQuery),
            TupleDomain.all(),
            ImmutableList.of(),
            Optional.empty(),
            OptionalLong.empty(),
            Optional.of(columns.build()),
            // The query is opaque, so we don't know referenced tables
            Optional.empty(),
            0);
    } catch (SQLException e) {
        return super.getTableHandle(session, preparedQuery);
    }
}

提交,build镜像,然后就可以使用clickhouse的table function了

Trino是一个分布式大数据分析查询引擎,支持多种连接器

PrestoSQL是Persto主要贡献者Dain, David离开facebook后基于Presto创建的项目,在2020年PrestoSQL改名成Trino

阿里云云原生数据仓库AnalyticDB

云原生数据仓库AnalyticDB MySQL版是融合数据库、大数据技术于一体的云原生企业级数据仓库服务。AnalyticDB MySQL版支持高吞吐的数据实时增删改、低延时的实时分析和复杂ETL，兼容上下游生态工具，可用于构建企业级报表系统、数据仓库和数据服务引擎。

adb这个是之前公司就在使用了,目前仅仅把polardb的数据通过免费的dts同步到abd用作部分统计,trino定位跟adb是有部分重合的地方,在trino成功落地之后会再考虑adb的应用场景

起因

因为不想直接影响主数据库polardb,所以目前尝试方案为metabase -> trino -> adb/mongodb,虽然adb支持jdbc mysql,但是因为部分系统表与mysql有出入,会导致trino mysql connector无法查询adb的数据

复现

使用trino mysql connector连接adb,select数据返回错误column size not present

调试

1. 克隆trino仓库并切到最新release(现在是402)
2. 编辑依赖仓库配置,添加profile:

<profile>
    <id>p</id>
    <repositories>
        <repository>
            <id>apache_snapshot</id>
            <name>apache_snapshot</name>
            <url>https://repository.apache.org/content/groups/snapshots</url>
        </repository>
        <repository>
            <id>public</id>
            <name>public</name>
            <url>https://repo.maven.apache.org/maven2</url>
        </repository>
        <repository>
            <id>ossrh</id>
            <name>ossrh</name>
            <url>https://oss.sonatype.org/service/local/repositories/releases/content</url>
        </repository>
        <repository>
            <id>confluent</id>
            <name>confluent</name>
            <url>https://packages.confluent.io/maven/</url>
        </repository>
    </repositories>
</profile>

3. mvn clean install trino根项目
4. 启动DevelopmentServer,添加vm参数

-ea
-Dnode.id={节点id}
-Dnode.environment=docker
-Dconfig={/path/to/config.properties}
-Dcatalog.config-dir={/path/to/catalogs}
-Djdk.attach.allowAttachSelf=true
-Dlogging.level=debug
-Dplugin.bundles={/path/to/trino/plugin/trino-mysql/pom.xml}
-Dstatistics.enabled=false

5. 启动cli

{/path/to/trino/client/trino-cli/target/trino-cli-402-executable.jar}

排查问题

经过搜索,发现在io.trino.plugin.jdbc.JdbcTypeHandle::getRequiredColumnSize内有该错误抛出
打断点发现是在获取varchar长度时调用到该方法,且adb的varchar等数据类型是没有长度限制的,因此触发了错误 修复方法很简单,只需要orElse一个长度然后重新package一下trino-base-jdbc即可

其他问题

getRequiredColumnSize内的错误修复完毕后查询虽然正常返回,但是trino会打印一些错误信息由io.trino.plugin.mysql.MySqlClient:getColumnHistograms抛出
经过排查,发现adb没有INFORMATION_SCHEMA.COLUMN_STATISTICS表,仅有INFORMATION_SCHEMA.COLUMNS,把这方法改成以下内容即可修复

Map<String, String> getColumnHistograms(JdbcTableHandle table)
    {
        try {
            handle.execute("SELECT 1 FROM INFORMATION_SCHEMA.COLUMNS WHERE 0=1");
        }
        catch (UnableToExecuteStatementException e) {
            if (e.getCause() instanceof SQLSyntaxErrorException && ((SQLSyntaxErrorException) e.getCause()).getErrorCode() == ER_UNKNOWN_TABLE) {
                // The table is available since MySQL 8
                log.debug("INFORMATION_SCHEMA.COLUMNS table is not available: %s", e);
                return ImmutableMap.of();
            }
        }

        RemoteTableName remoteTableName = table.getRequiredNamedRelation().getRemoteTableName();
        return handle.createQuery("" +
                        "SELECT COLUMN_NAME, 0 FROM INFORMATION_SCHEMA.COLUMNS " +
                        "WHERE SCHEMA_NAME = :schema AND TABLE_NAME = :table_name")
                .bind("schema", remoteTableName.getCatalogName().orElse(null))
                .bind("table_name", remoteTableName.getTableName())
                .map((rs, ctx) -> new SimpleEntry<>(rs.getString("COLUMN_NAME"), rs.getString("HISTOGRAM")))
                .collect(toImmutableMap(Map.Entry::getKey, Map.Entry::getValue));
}

替换插件

因为使用容器化部署,因为重新打个镜像就好了
镜像目录:

.
├── Dockerfile
├── trino-base-jdbc-402.jar
├── trino-mysql-402-services.jar
└── trino-mysql-402.jar

Dockerfile:

FROM trinodb/trino:402
COPY --chown=trino:trino $PWD/trino-base-jdbc-402.jar /usr/lib/trino/plugin/mysql/
COPY --chown=trino:trino $PWD/trino-mysql-402.jar /usr/lib/trino/plugin/mysql/
COPY --chown=trino:trino $PWD/trino-mysql-402-services.jar /usr/lib/trino/plugin/mysql/

1. create react app

npx create-next-app@latest --example with-turbopack

nextjs 13 app目录

• layout: 布局文件,子目录会使用上级的layout
• page: 路由入口,默认是server component,可以使用 'use client' 标记为客户端渲染,可以使用fetch获取数据
• error: 错误页
• loading: loading组件,react的Suspense的fallback组件,也可以手动使用Suspense

坑

1. 对其他react框架支持不好(如antd,react-syntax-highlighter等)
2. 无法使用css的import url
3. 开发时在客户端组件里使用fetch会导致重复渲染
4. 开发时会有奇怪的卡顿

体验

尝试过不使用app目录而是使用pages的写法,开发时的速度感觉还是比不上vite,而且加上了其他react框架的时候会引起chrome devtools卡顿(macbook pro 14' m1max),因此体验并不好,建议观望

hex to binary string(javascript)​

因为接触的不多,所以在线笔试的时候我并没有能写完,只写到16进制转10进制,后面的位操作是睡觉前才突然想起来能这样写的.
我的实现:

export function hexToBinary(input: string) {
    let num = hexToNumber(input);
    if(num === 0){
        return '0';
    }
    if(!num){
        return NaN;
    }
    let strList = [];
    while (num !== 0){
        strList.push(num & 0b1);
        num = num >> 1;
    }
    return '0b' + strList.reverse().join('');
}


function hexToNumber(input: string) {
    if (!input.trim()) {
        return NaN;
    }
    let index = 0;
    let total = 0;
    for (let char of input.split("").reverse()) {
        if (!/[0-9a-fA-F]/.test(char)) {
            return NaN;
        }
        total += Math.pow(16, index) * singleHexToBinary(char);
        index ++;
    }
    return total;
}

function singleHexToBinary(input: string): number {
    if (/\d/.test(input)) {
        return parseInt(input);
    }
    return input.toLocaleLowerCase().charCodeAt(0) - 'a'.charCodeAt(0) + 10;
}

2题,字符串中心对称判断和字符串压缩​

字符串中心对称判断​

实现1:

    public static void main(String[] args) {
        System.out.println(isPalindrome(""));//false
        System.out.println(isPalindrome("a"));//true
        System.out.println(isPalindrome("aba"));//true
        System.out.println(isPalindrome("abccba"));//true
        System.out.println(isPalindrome("abcdcba"));//true
        System.out.println(isPalindrome("abcdcba"));//true
    }
    public static boolean isPalindrome(String s) {
        if(s == null || s.trim().isEmpty()){
            return false;
        }
        if(s.length() == 1){
            return true;
        }
        String sub1,sub2;
        int mid = s.length() / 2;
        if(s.length() % 2 == 0){
            sub1 = s.substring(0,mid);
            sub2 = reverse(s.substring(mid));
        }else{
            sub1 = s.substring(0, mid);
            sub2 = reverse(s.substring(mid + 1));
        }
        return sub1.equals(sub2);
    }

    public static String reverse(String s){
        Stack<String> stack = new Stack<String>();
        for(char c : s.toCharArray()){
            stack.push(c + "");
        }
        StringBuilder str = new StringBuilder();
        while(!stack.empty()){
            str.append(stack.pop());
        }
        return str.toString();
    }

实现2:

    public static void main(String[] args) {
        System.out.println(isPalindrome(""));//false
        System.out.println(isPalindrome("a"));//true
        System.out.println(isPalindrome("aba"));//true
        System.out.println(isPalindrome("abccba"));//true
        System.out.println(isPalindrome("abcdcba"));//true
        System.out.println(isPalindrome("abcdcba"));//true
    }
    public static boolean isPalindrome(String s) {
        char[] chars = s.toCharArray();
        List<String> matching = new ArrayList<String>();
        for (int i = 0; i < s.length(); i ++){
            if(chars[s.length() - 1 - i] == chars[i]){
                matching.add(chars[i] + "");
            }else{
                break;
            }
        }
        return !matching.isEmpty() && (s.length() - matching.size() * 2 ) <= 1;
    }

字符串压缩​

    public static void main(String[] args) {
        System.out.println(compressString("aabcccccaaa"));//输出：a2b1c5a3
        System.out.println(compressString("abbccd")); //输出：abbccd。 abbccd"压缩后为"a1b2c2d1"，比原字符串长度更长
    }

    /**
     * 实现这个函数
     */
    public static String compressString(String str){
        //实现1
        if(str.trim().length() <= 2){
            return str;
        }
        StringBuilder builder = new StringBuilder();
        char matching = '#';
        int count = 1;
        for(char c : str.toCharArray()){
            if(matching == '#'){
                matching = c;
            }else{
                if(matching != c){
                    builder.append(matching).append(count);
                    matching = c;
                    count = 1;
                }else{
                    count ++;
                }
            }
        }
        builder.append(matching).append(count);
        return builder.length() >= str.length() ? str : builder.toString();
    }

面试

公司1​

提了几个问题,答的都不是很好,这里记录下

nodejs和java的区别​

这区别大了去了,唯一沾点边的就是jit?还是java?

但是我回答的是nodejs单线程时间循环,java则是有对线程的掌控能力.
略显肤浅的回答.

现在来整理下我对这2种语言的异同.

• 语法上 js有部分类似java的语法,但是越新的版本差别越大,套上ts以后与其说是像java不如说像c#;
• 编译上 js基本是通过babel和插件转换,混淆,但是实际递交虚拟机执行的还是js; java编译出来,实际递交虚拟机执行的是字节码(.class);
• 运行时 js的运行时是v8等js引擎; java的运行时是各种jvm/dvm实现;
• 语言上 js是一种弱类型语言(所以才有了ts); java是一种强类型语言(有了var也改变不了);

nodejs单线程的理解​

我的回答是:单线程的是事件循环,实际执行时还是有多线程的能力的;

回答太过粗糙.

首先,nodejs是有多线程能力的,在N-API中也能找到对应的描述:

底层是有thread safe multiple threads的能力的,上层js也有worker threads提供多线程能力.

按照文档的描述,worker threads

They do so by transferring ArrayBuffer instances or sharing SharedArrayBuffer instances

When implementing a worker pool, use the AsyncResource API to inform diagnostic tools (e.g. to provide asynchronous stack traces) about the correlation between tasks and their outcomes. See "Using AsyncResource for a Worker thread pool" in the async_hooks documentation for an example implementation.

Worker threads inherit non-process-specific options by default. Refer to Worker constructor options to know how to customize worker thread options, specifically argv and execArgv options.

刚才提到了nodejs native addon,能描述下怎么写插件吗?​

这里我只给了一个自己写的napi的demo的仓库地址
并简单地说了下,写binding.gyp和在cpp中描述对应的方法即可

实际可以参考native addon文档或N-API文档

公司2​

线上面试交流的东西主要是工作经历/公司状况之类的,并无太多技术上的东西
技术方面主要还是在线下面试

mysql 如何调优​

我的回答是explain SQL;然后看对应的描述,是否有用filesort,filesort是否过大;是否有添加索引等并做对应处理.

太那啥,主要这问题也有点泛,糙一点的explain,然后哪里有问题填哪里. 细一点就加各种软件,监控mysql的状态然后再找问题. 不过这方面经验的确不足,之前的公司mysql直接用的rds mysql,有很全的监控与自动化备份等功能. 出问题了小一点的复制索引优化建议,中型问题改业务逻辑,大问题提工单就能解决,实在没怎么认真了解过.

树的类型​

从mysql突然跳到树,我第一反应是数值的数,萌蠢的我说了什么int,big int之类的. 后面才反应到说的是tree. 遂回答:BTree,B+Tree,B*Tree,RBTree

RBTree跟BTree的区别​

我只简单回答了RBTree是BTree的子集,使用红黑颜色描述节点,通过变更颜色与左右旋来降低时间复杂度. 实际文章很多,也可以参考wiki

RBTree应用​

回答到java的hashmap,mysql(索引用的b树,这里是真的蠢).
虽然文档里有rbt,但是有哪里用到? 有空要翻翻

其他​

聊了下seata,还包括吹出去的贡献者,得知面试官是初期贡献成员之后爆了.
总的来说对方的意思是:基础不太扎实.

离职这件事我考虑了w很久,第一次出现离职的想法应该在2018年,那时候我还是个直面社会未满3年的小伙. 契机是啥现在已经忘了,突然间就感觉工作中的crud,浅尝即止的demo,写不下去的日志全无意义. 周围所有人都在随着时间的增长在快速地成长的时候,我却停在了自己的面前,像进入刺客信条的读取环节,周围的人渐渐消失,而我无论怎么奔跑都仍在原地.

于是离职的想法就那样自然地冒了出来.

思前想后​

离职可以,然后呢?
想了很久,没存款,没目标,没理想,于是又混混噩噩地过了近2年.

后来还是找了个理由离职了.

建模

blender​

yes!blender!

回头看,这学习建模的理由就是在欺骗自己.
3个月过去了,基础是有一点,可随着时间的流逝,热情也在消退. 恰好有几个朋友对我曾经在酒桌上提出的方案感兴趣.

于是开始创业.

创业

关于项目​

项目很简单,就是cbd写字楼下面卖早餐,我想要做的核心是快,成交快,出餐快;其次是不难吃;最后就是价格中上.

莽撞前期​

我一开始臆想的实现2个快速的核心就是机器,带加热功能的取餐柜;
拖沓着看了几家厂商,见我不愿承担选择机器的任务和带来的责任的伙伴去了趟青岛,拿回了5台既不符合我快的定义,也很难从这机器的外型吸引顾客的机器
于是开始定餐品,定包装,选点,测试机器等.
说实话,这些工作内容并不枯燥,只是在习惯了互联网开发的我的看来,这些工作能选择的方式都过于低效.
低效的方式让我变得有点像代码质量被人质疑的时候那样的急躁;现在看来开始的工作实在是过于草率.

选点​

• 某商住2用写字楼大堂
  这个点位初看非常好,既是写字楼出入口关键位置,也是早上电梯排队人流的不远处,租金也非常低. 可是到进去了之后,活动时与顾客交谈过后才知道,这位置原来有过一家OK便利店,可是已经做不下去搬走了. 这才知道甚至连点位背景都没调查就直接签约进场是有多么地愚蠢
  后面这个点位的日销量的事实也在提醒着这点

• 某写字楼入口旁,某团外卖取餐柜隔壁 这个点位位于一个十字路口旁的写字楼入口旁,物业给到我们的位置紧靠着某团外卖取餐柜. 比起上一个点位,这个点位位置竞争更加激烈,马路斜对面有一家麦当劳,麦当劳对面有OK便利店,麦当劳与OK便利店后面是一条食街,一直从这延伸到地铁口附近. 但是从后面的结果来看,这个点位的日销量却是非常的稳定,虽然扩大用户数量很困难,但它仍是所有点位最稳定,日销量最高的一个点位. 甚至就算流动早餐车就在写字楼入口另一侧的时候也能保持这种稳定的销量.

• 某商住2用小区入口必经之处 这点位与上一点位距离不远,但是相比起上一点位,这里附近不但连餐饮店没有,最近的便利店也在差不多1公里外. 但是这个点位的日销量并不理想,原因可能是目标人群(上班族)并不多.

• cbd内某写字楼 这点位在某地铁口旁,地铁口里联通着一座商城的地下食街,但是方向不一样. 这点位是定得最草率的一个,这点位的物业与前两个为同一个,据扩展的人员(找的中介)的人的意思是,如果我们3个点都拿下的话会有优惠和免电费. 但是这个点位非常不理想,因为给到的位置在地铁口与大堂的延伸线上,在上班这一场景中并不顺路 日销量也证明了这个位置并不理想

餐品与包装和测试机器​

定餐品与包装用了近2个月,却还是仓促上架. 这部分其实并非我主导,但是不可否认的是,我明知伙伴的拖延与低效却没起到监督的作用,像是事外人一样去看待这工作.

浑噩中期​

每个点位进场后我们都会开始为期3天的免费早餐活动,活动期间几乎没有损耗. 被这种热情刺激到的我们马上就被活动结束后惨淡的日销量给打肿了脸. 于是开始寻找问题.

餐品​

在活动中收集到的反馈基本都是挺好吃的,但是日销量的惨淡说明问题并不全在此. 剩下就是餐品过少的问题了.

机器​

我到目前为止还是坚持核心是要快,目前位置并不能做到,但是我们也没资源去改变这一点了 另外就是APP,二手售货机原生的APP像是停留在移动时代之前,无论是界面还是功能 于是我后面便将APP重写了

失败后期​

人心散了怎么聚回来? 春节假期过后,上了两期新品,结果不尽人意. 同时生产核心位置的伙伴突然说要在工作日出去玩2天. 知道这消息的时候我就开始准备简历,并在App上投递了. 机器停运的2天内经过了2场远程面试,1场在线笔试,1场线下面试(其实就2间公司,一共也就投了4份简历左右)

于是,我感觉我要回去工作了

总结

不仅仅是这2年,人生至此一直是这样草率莽撞,思前顾后的却并非重点,失败的创业后面多少要有些成长吧!