北京
我没有电脑。对于大多数安卓开发来说，这听起来像是一个相当不便的起点。但我仍然想开发安卓软件，所以我没有等待更好的硬件，而是开始琢磨能把多少工作流程搬到手机上。
这件事最终超出了实验的范畴。我开始用这种方式构建真正的安卓项目，包括 AppBlur，同时把源代码和项目证据公开放在 GitHub 上。这篇文章记录了这个工作流程是如何成形的、我从中学会了什么，以及这套方法在哪些地方开始触及极限。
一部手机当开发工作站
我的主要开发设备是一部硬件有限的安卓手机。这意味着我不能直接打开 Android Studio、启动模拟器、跑一个大型构建然后忘掉底层的机器。我必须换一种思路来对待整个开发流程。
手机成了我做这些事情的地方：编写和编辑代码、管理项目文件、在可行的情况下运行本地工具、测试应用、检查结果、管理开发过程。GitHub 则成了我公开源代码、维护项目历史、在需要时使用远程基础设施的地方。
关键不在于让手机神奇地表现得像一台电脑。我在弄清楚的是：开发的哪些部分真正需要在手机上完成，哪些部分可以放到别处处理。
从手机到 GitHub 再到设备
从高层次看，这个流程变成了：手机 → 源代码 → GitHub → 构建/发布 → 安卓设备。手机仍然是主要的开发环境。GitHub 并没有取代开发过程，它给了我一个可靠的地方来保存源代码，并处理那些在本地很难完成的工作流环节。
最重要的结果是：一个真正的应用，我可以把它安装并运行在与我用来构建它的同一种设备上。
真正的问题不是打字
在触屏上写代码显然和坐在桌面键盘前不是同一种体验。但打字并不是最难的部分。更难的问题是管理一个真正的项目。一旦安卓项目增长到超过几个文件，你就会面对清单文件、资源、Gradle 配置、依赖、资产以及其他需要协同工作的部分。
所以我开始把手机更多地当作一个小型开发工作站，而不仅仅是一个代码编辑器。工作流程变成了：编辑项目、检查文件、在本地运行能运行的东西、在设备上测试、提交更改、把 GitHub 当作公开的事实来源。这不是最常规的设置，但它确实有效。
AppBlur 成了真正的考验
AppBlur 是这套方法必须从实验变成现实的项目之一。它的想法很简单：一个安卓隐私工具，可以在设备闲置后模糊显示内容。但实现它意味着要处理真实的安卓行为，而不仅仅是创建一个界面。这里涉及服务、悬浮窗、生命周期行为、计时等等。
这个项目让我把手机上的工作流推到了更接近真实开发场景的程度。源代码和项目证据都公开在 GitHub 上，任何人都可以看到这套流程实际产出了什么。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
