前端【免费下载链接】beakerAn experimental peer-to-peer Web browser项目地址https://gitcode.com/gh_mirrors/be/beaker点击查看免费下载本文以仓库根目录 app/README.md 为骨架结合app目录下实际源码系统梳理 Beaker Browser实验性点对点 Web 浏览器的应用源码布局从 Electron 主进程入口main.js出发拆解bg后台、fg前台 UI、userland用户态应用三大代码域的分工与协作方式并给出从源码构建、调试到环境变量调优的完整实战方案。读完本文你将掌握 Beaker 的进程模型与模块组织原则能够定位任意功能模块所在的源码目录并能在本地环境从零构建运行这个项目。项目背景一个已归档的实验性 P2P 浏览器Beaker Browser 是一个实验性的点对点peer-to-peerWeb 浏览器其核心目标是在保持与 Web 其余部分兼容的前提下为构建无主机hostless应用提供新的 API。项目根目录 README.md 中明确标注了项目现已归档见 archive-notice.md当前仓库即其最终源码快照版本号为1.1.0见 app/package.json。这意味着本文描述的构建、运行与调试方式均基于该归档版本的真实代码可直接对照验证项目采用 MIT 许可证版权归属于 Blue Link LabsCopyright (c) 2018 Blue Link Labs作为归档项目社区已停止活跃维护遇到问题时应优先参考代码本身而非寻求在线支持。从 app/package.json 的依赖清单可以看到 Beaker 的技术底座electron由 scripts/package.json 固定为11.0.0-beta.18、hyperdrive-daemon-client、hyperspace、dat-dns、discovery-swarm、knexsqlite3本地数据库、winston日志等。这套依赖组合决定了app目录必然被拆分成“主进程 / 渲染进程 / 用户态沙箱”三个层次来组织。App 目录总览一份五行的架构地图仓库根目录 app/README.md 用 5 个条目精确概括了整个应用源码的布局路径职责/main.jsElectron 入口点entrypoint/assets静态资源如图片、字体等/bgElectron 主进程代码background后台/fgBeaker 的前端/UI 代码foreground前台/userland在用户态userland环境中运行的前端代码下面的章节会逐一展开这五个部分并补充 bg/README.md、fg/README.md、userland/README.md 三个子 README 中的细节让这张地图从“文件名列表”升级为“可导航的架构图”。assets静态资源目录assets下集中存放了应用运行所需的静态文件app/README.md 指出它包含 images、fonts 等资源。具体包括css/fa-all.min.cssFont Awesome 图标字体、syntax-highlight.css代码高亮样式favicons/数十种.ico站点图标如book.ico、terminal.ico、cloud.ico、home-house.ico等用于在地址栏/标签页展示不同类型站点的图标fonts/fa-*Font Awesome 字体族与source-sans-pro字体img/各类图片素材如drive-types/不同 drive 类型的图标、favicons/、frontends/前端应用截图、search-engines/搜索引擎图标、onboarding/首次启动引导插画、default-cover.jpg、logo.png等。该目录本身不包含任何业务逻辑是纯静态资源层。main.jsElectron 主进程入口如何运转main.js是整个应用的启动原点。app/README.md 称其为 “Electron entrypoint”而源码注释进一步说明它是 Electron 的主进程脚本“在应用启动时最先被执行并在整个应用生命周期内持续运行不拥有任何可见窗口但可以从这里打开窗口”。结合 app/main.js 的完整代码主进程的初始化流程可以归纳为以下顺序环境变量预处理读取BEAKER_USER_DATA_PATH覆盖用户数据目录见下文“环境变量”章节读取BEAKER_TEST_DRIVER启动测试驱动关闭 Electron 安全警告。安全与性能开关app.enableSandbox()启用渲染进程沙箱allowRendererProcessReuse true开启渲染进程复用以加速导航追加disable-featuresOutOfBlinkCors修复自定义协议下的 CORS 问题。注册特权协议通过protocol.registerSchemesAsPrivileged将dat、hyper、beaker三个自定义 scheme 注册为standard secure并开启 Service Worker、Fetch API、CORS 支持hyper额外开启stream——这是 Beaker 能承载 P2P 网页的基础设施。处理操作系统事件监听open-url与open-file将系统级 URL/文件打开请求转发给bg/open-url.js处理非 macOS 平台则在 argv 中查找带://的参数作为 URL 打开。ready事件后的子系统启动顺序即依赖顺序初始化日志写入userData/beaker.log→ 注册beaker协议 → 初始化 Web APIs → 打开初始化窗口 → 启动 NAT 端口转发 → 初始化全部 SQLite 数据库bg/dbs/*→ 启动 hyperdrivebg/hyper→ 初始化 hyperdrive 文件系统bg/filesystem→ 初始化浏览器核心bg/browser→ 启动广告拦截与统计 → 初始化书签/固定项 → 注册asset、hyper、dat协议 → 运行首次启动引导流程setup flow→ 初始化窗口菜单、右键菜单、托盘图标、浏览器窗口、下载管理与权限管理器。单实例锁app.requestSingleInstanceLock()保证只运行一个实例第二个实例启动时会把 argv 转发给已有实例并聚焦窗口。优雅退出will-quit时若 hyperdrive daemon 需要关闭则先shutdown()再退出quit时关闭 NAT 端口转发。从源码结构看main.js扮演的是“编排者”角色——它本身不实现业务逻辑而是把 bg 下的各个模块按依赖顺序装配起来。这也解释了为什么bg是整份代码中最大的目录。bgElectron 主进程的后台代码域bg/README.md 开宗明义本目录包含驱动 Beaker Electron 主进程的后端代码。其 Notable folders 给出了 7 个功能分区子目录职责摘自 bg/README.mdlib后端专用的可复用代码dat管理 dat daemon 及 dat 专属行为dbs全部 SQLite 数据库及持久化数据管理filesystem管理用户主 hyperdrive 及其持久化数据含 dats 库与用户protocols自定义 URL scheme 处理器rpc-manifests供/app/fg组件调用的内部 RPC 清单ui管理窗口、标签页、子窗口及一切 UI 相关逻辑web-apis通过 RPC 暴露给 userland 环境的所有接口同时包含 fg 与 bg 代码下面选取其中最能体现 Beaker 技术特色的几个模块做源码级展开。dbs版本化迁移的 SQLite 数据库层dbs是 Beaker 的本地数据层全部基于 SQLite目录内最引人注目的是schemas/下从profile-data.v1.sql.js到profile-data.v52.sql.js共 52 个版本化 schema 文件。这种“每版本一个 SQL 文件”的组织方式配合 bg/dbs 下的profile-data-db.js、settings.js、history.js、sitedata.js、watchlist.js等数据访问模块让数据库迁移清晰可追踪从 v1 到 v52 的演进史几乎就是 Beaker 功能演进的缩影。在 app/main.js 的启动流程中所有dbs模块会被统一遍历并调用各自的setup(commonOpts)完成建库/迁移其中commonOpts携带了userDataPath与homePath。日志系统则把运行日志写入userData/beaker.log见 bg/logger.js。protocols四个自定义 URL schemebg/protocols下存放着 Beaker 全部的自定义协议处理器asset.jsasset:协议用于加载打包资源beaker.jsbeaker:协议承载beaker://内部页面与用户态应用见下文userlandhyper.jshyper:协议对应新式 hyperdrive 地址dat.jsdat:协议对应旧式 dat 地址。这些处理器在 app/main.js 的ready流程中被逐一register(protocol)注册并与启动早期registerSchemesAsPrivileged声明的特权相匹配。与之呼应scripts/package.json 的build.protocols配置还声明了http、https、hyper、dat四类系统级 URL scheme 处理器使 Beaker 可以被操作系统注册为这些链接的默认打开程序。web-apis暴露给网页的 RPC 接口层web-apis是 Beaker“无主机应用”理念的核心载体。目录结构分为bg/后台实现与fg/前台封装两块其中bg/下包含beaker-filesystem.js、capabilities.js、contacts.js、drives.js、history.js、hyperdrive.js、peersockets.js、shell.js、watchlist.js等模块——这些正是网页通过beaker://或超驱页面可调用的浏览器能力 API 的后台实现。bg/README.md对此有一个意味深长的注释“它目前同时包含 fg 和 bg 代码这或许应该改变”暗示该模块的职责边界在项目演进中仍在调整。ui窗口与界面管理bg/ui负责所有窗口级 UI 状态与fg中的界面组件一一对应。fg/README.md 明确指出“许多文件夹与/app/bg/ui/subwindows/*中的文件存在 1:1 关联如perm-prompt、prompts、shell-menus”。bg/ui下还包含tabs/标签页管理器、窗格布局、窗格、缩放、windows.js、context-menu.js、downloads.js、permissions.js、tray-icon.js、window-menu.js、keybindings.js、setup-flow.js等。fg前台 UI 代码域fg/README.md 说明本目录包含驱动 Beaker UI 的前端代码每个文件夹都是一个自包含的 UI 组件许多组件与bg/ui/subwindows/*中的文件 1:1 对应。两个 Notable 条目lib前端专用的可复用代码shell-windowBeaker 的主 shell UI。fg目录实际包含的组件与子 README 相互印证location-bar/地址栏、modals/各类模态框add-drive、create-drive、drive-properties、prompt、user-editor 等、perm-prompt/权限询问弹窗、prompts/提示框、shell-menus/shell 菜单bookmark、share、peers、site、create 等、shell-window/主窗口与 navbar、tab-switcher/、webview-preload/webview 预加载脚本、json-renderer/与syntax-highlighter/。RPC 约定bg-process-rpc.js模式fg/README.md特别强调了一个关键约束Beaker 的 Web API 在这些组件中不可用因此与 Electron 进程的所有 RPC 都需要手动建立这就是bg-process-rpc.js模式。这意味着fg组件不能像userland应用那样直接使用beaker.*Web API而是要通过pauls-electron-rpc等机制显式连接主进程。每个fg组件目录下都能看到bg-process-rpc.js如modals/、perm-prompt/、prompts/、shell-menus/、shell-window/目录内均存在这正是“1:1 组件 手动 RPC”架构的直接证据。userland运行在网页环境中的用户态应用userland/README.md 对第三层代码域做了最详细的阐述它是理解 Beaker 应用模型的关键文档核心内容如下定义userland包含在“与任何 userland 页面相同的环境”中执行的 fg 代码。与fg中的代码不同这里标准 Web API 可用原因是webview-preload.js被注入了即 fg/webview-preload 下的预加载脚本内含index.js、execute-javascript.js、prompt.js等。应用模型/app/userland下的每个文件夹都托管在自己的beaker://域名下可以视为一个独立的应用其中 “viewer” 应用包含多个子应用。beaker://app-stdlib提供了一批跨应用复用的组件。构建策略userland 应用尽可能不做构建仅当需要与 Beaker 内部代码共享代码时才引入构建步骤典型案例是 “library” 和 “site-info”。演进方向userland中的每个应用都应被视为“可迁入 hyperdrive”的候选者如果一个应用没有可能迁入 hyperdrive它就应当被放进fg。仓库中userland下实际包含app-stdlib标准组件库、cmd-pkg命令行工具包、desktop、diff、drive-view、editor、explorer、history、hypercore-tools、init、library、settings、setup、site-info、webterm——它们分别对应 Beaker 内置的桌面模式、文件浏览器、编辑器、历史、设置、站点信息、WebTerm 等应用全部运行在beaker://域名之下。从源码构建与运行仓库根目录 README.md 提供了完整的构建指南本节结合 scripts 目录下的构建脚本做展开说明。环境依赖源码构建要求Node.js 12 或更高版本。不同平台还需安装原生模块编译工具链Linux部分 macOS 场景同样需要sudo apt-get install libtool m4 make g autoconf # debian/ubuntu sudo dnf install libtool m4 make gcc-c libXScrnSaver # fedora brew install libtool autoconf automake # macosWindows需要 Python 2.7、Visual Studio 2015 或 2017 与 Git可尝试 windows-build-tools随后配置 node-gypnpm config set python c:/python27 npm config set msvs_version 2017 npm install -g node-gyp npm install -g gulp构建步骤与脚本化工作流git clone https://github.com/beakerbrowser/beaker.git cd beaker/scripts npm install # 不必担心构建原生模块时的 v8 api 报错rebuild 会修复 npm run rebuild # 每次 install 之后都需要执行参见 electron/electron#5851 npm startscripts目录中的任务脚本由 scripts/package.json 定义把上述步骤自动化了npm run rebuild→ scripts/tasks/rebuild.js通过 gulp 对需要重建的原生模块执行 Electron 环境的npm rebuild。从源码看MODULES_NEEDING_REBUILD [sqlite3]即本项目需要针对 Electron runtime 重新编译的模块是sqlite3命令为npm rebuild sqlite3 --runtimeelectron --target11.0.0-beta.18 --disturlhttps://electronjs.org/headers --build-from-source随后自动执行npm run build。这就是 README 中“rebuild 会修复原生模块错误”的实现依据。npm start→ scripts/tasks/start.js 与 scripts/tasks/start-cli.js启动应用。npm run watch→gulp start-watch开发模式下监听文件变更、自动重建资源构建管线见 scripts/gulpfile.js。疑难杂症处理npm run burnthemallREADME 中有一个颇具 Beaker 风格的“终极清理”命令npm run burnthemall其背后的实现是 scripts/tasks/burnthemall.js。从源码可以看到它依次完成删除scripts/与app/下的node_modules源码注释戏称这是“the mad king”在焚烧依赖目录删除两处的package-lock.json依次执行npm install→npm run rebuild→npm run build。README 对该命令的定位是当你从仓库拉取最新代码后遇到诡异的模块错误时使用执行完npm start应当恢复工作。对于这个已归档的项目它同样适合在本地环境混乱时一键重建干净的依赖树。打包发布scripts/package.json 的scripts.release为electron-builder -p never gulp postbuildbuild配置块appId: com.bluelinklabs.beaker-browser、asar: false、macOShardenedRuntime与 entitlements、Linux AppImage 分类等完整描述了如何用 electron-builder 产出各平台安装包发布流程细节可参考 scripts/how-to-make-a-release.md。普通用户更推荐直接使用 Releases Page 的现成安装包见根 README.md。环境变量调试与测试的开关面板根 README.md 的 “Env Vars” 一节集中列出了 Beaker 支持的环境变量这是本地调试和自动化测试最实用的入口。结合源码逐条展开如下。DEBUG需要输出哪些日志系统逗号分隔的字符串。可选值beaker、dat、bittorrent-dht、dns-discovery、hypercore-protocol。指定*表示全部。从 bg/logger.js 的实现看Beaker 的日志基于 winston日志同时写入userData/beaker.log文件JSON 格式含 timestamp并会对 64 位 hash 做4..2形式的截断显示与控制台bg/dat/dns.js等模块通过logger.child({category: dat, subcategory: dns})建立按分类的日志通道因此DEBUGdat即可过滤出 dat 域名解析等子系统的输出。例如DEBUGbeaker npm start # 只看 Beaker 自身日志 DEBUG* npm start # 输出全部日志系统BEAKER_OPEN_URL启动时打开指定的 URL而非恢复上一次会话或默认标签页。其实现位于 bg/ui/windows.js源码第 68 行通过getEnvVar(BEAKER_OPEN_URL)判断该变量是否设置第 170 行在构造初始页面时把opts.pages [getEnvVar(BEAKER_OPEN_URL)]传入。使用示例BEAKER_OPEN_URLhyper://example.com npm start注意环境变量读取是大小写不敏感的——bg/lib/env.js 中的getEnvVar会先查process.env[name.toUpperCase()]再查小写形式所以beaker_open_url同样有效。BEAKER_USER_DATA_PATH覆盖 user-data 路径从而改变数据读写位置。对测试很有用。默认值参见 Electron 文档中app.getPath(userData)的定义。源码实现同样在 app/main.js启动最早期执行if (getEnvVar(BEAKER_USER_DATA_PATH)) { console.log(User data path set by environment variables) console.log(userData:, getEnvVar(BEAKER_USER_DATA_PATH)) app.setPath(userData, getEnvVar(BEAKER_USER_DATA_PATH)) }即通过app.setPath(userData, ...)重定向 Electron 的用户数据目录。由于 SQLite 数据库、日志、hyperdrive 元数据都落在这个目录下切换该路径即可获得一套完全隔离的浏览器环境非常适合并行测试多个配置BEAKER_USER_DATA_PATH/tmp/beaker-test-1 npm startBEAKER_DAT_QUOTA_DEFAULT_BYTES_ALLOWED覆盖 dat 站点允许写入字节数的默认最大配额。对测试很有用。默认值为500mb。可以是 Number 或 String支持的单位与缩写见bytes.parse。这是与 dat 协议磁盘配额相关的高级测试开关。默认500mb意味着普通 dat 站点默认最多可向本机写入 500MB 数据调大/调小该值可以分别模拟“海量站点写入”与“配额耗尽”场景BEAKER_DAT_QUOTA_DEFAULT_BYTES_ALLOWED10gb npm start # 字符串形式 BEAKER_DAT_QUOTA_DEFAULT_BYTES_ALLOWED10485760 npm start # 数字形式字节其他调试辅助除 README 列出的四个变量外源码中还有两个实用的隐藏开关BEAKER_TEST_DRIVERapp/main.js 在启动早期检测该变量并调用testDriver.setup()实现见 bg/test-driver.js用于启用测试驱动接口供自动化测试套件驱动浏览器行为ELECTRON_DISABLE_SECURITY_WARNINGS被强制置为1用于静默 Electron 的安全警告输出源码注释自嘲 “we know, we know”。已知问题与安全说明tmux 启动挂起问题根 README.md 记录了一个已知问题在 macOS 上从 tmux 启动会导致 GUI 应用出问题Beaker 可能因此启动时挂起。如果你在 tmux 会话中运行 Beaker 且无窗口响应应考虑在 tmux 外直接启动或换用其他终端复用工具。漏洞披露涉及安全漏洞的发现与上报请遵循 SECURITY.md 中的流程处理社区贡献规范见 CONTRIBUTING.md。结语如何用好这份源码地图把本文的各个部分串起来app目录的三层结构可以归结为一句话bg决定浏览器“能做到什么”主进程能力fg决定界面“长什么样”内嵌 UI 组件userland决定网页“能调用什么”beaker://应用与 Web API 沙箱。上手实践的建议路径先用环境变量BEAKER_OPEN_URL与BEAKER_USER_DATA_PATH做隔离式冒烟测试理解各协议dat:、hyper:、beaker:的页面行为想改 UI进 app/fg 找对应组件目录并留意其bg-process-rpc.js与 app/bg/ui 的 1:1 对应关系想研究 P2P 数据能力读 app/bg/web-apis 与 app/bg/dbs 的 52 个版本化 schema想理解“无主机应用”模型重点研读 app/userland/README.md 与beaker://app-stdlib的复用机制。这份目录结构文档虽然只有五行但它准确反映了 Beaker 将“Electron 主进程、内嵌 UI、用户态 Web 应用”三者物理隔离的架构选择——而上述所有细节都对应着仓库中可逐行阅读的真实源码。赞分享前端【免费下载链接】beakerAn experimental peer-to-peer Web browser项目地址https://gitcode.com/gh_mirrors/be/beaker点击查看免费下载相关推荐3分钟掌握大麦自动抢票Python脚本终极解决方案3分钟掌握大麦自动抢票Python脚本终极解决方案 还在为抢不到演唱会门票而烦恼吗大麦自动抢票工具是一款基于Python开发的智能脚本能够实现全自动化抢票GUI 自动化RPAelectron-vue 应用调试指南主进程远程调试与生产构建调试electron vue 应用调试指南主进程远程调试与生产构建调试 导读 本篇指南基于 electron vue 官方文档 docs/ko/debugging前端桌面应用electron-vue 项目结构深度解析单一 package.json、主进程入口与生产构建electron vue 项目结构深度解析单一 package.json、主进程入口与生产构建 本篇技术指南以 electron vue 样板工程boile前端桌面应用上一篇Unity WebGL中RTSP视频流播放终极指南零插件实现实时监控下一篇终极指南如何快速掌握Vue可视化打印解决方案vue-plugin-hiprint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考