简介：面向安卓初学者的简易安卓项目完整源码包，依托安卓开发工具构建，涵盖用户登录与注册、数据存储、选项卡切换、信息表注册及圆形头像处理等核心功能。登录注册功能涉及输入控件、按钮事件与网络请求，可帮助理解前后端交互流程；数据存储部分引导学习轻量级存储或数据库的用法；选项卡切换采用标签布局与滑动页面的组合，适合掌握页面适配器机制；信息表注册包含日期选择、单选多选和表单验证，同时用圆形头像提升界面美观，覆盖了常见应用开发场景。压缩包为zip格式，大小12.12MB，体积轻便，便于快速下载导入。已有1129人学习，项目代码结构清晰，适合正在学习安卓组件的初学者参考调试，也可作为课程设计或期末项目的起步模板。
1. 简易安卓项目是什么：一个最小 App 骨架要花多久跑通
用 Android Studio 写一个简易安卓项目，是绝大多数人接触安卓开发的第一步，也是我做内部小工具时最常回退到的起点。它要解决的不是“学会一门语言”，而是用最小代码量把一个能安装、能交互、能出安装包的 App 跑通：通常只有一两个页面，一个输入框加一个按钮，数据写死在代码里或存进本地缓存。它适合刚入门的初学者，也适合想给团队快速做临时工具、又不想上完整架构的工程师。顺利的话，从新建工程到真机跑通，一个下午足够。真正拦人的不是代码，而是版本、资源和环境这些黑匣子，也是后面几章想帮你提前踩掉的。
2. 新建工程的每一步怎么选：Android Studio 向导里的语言、SDK 与 Gradle
2.1 Java 还是 Kotlin、API 26 还是 34：开工前的三个关键选项
新建项目时，向导里最让人犹豫的选择有三个：开发语言、最低版本和页面模板。
先说语言。从 2019 年起，Google 官方主推 Kotlin，Android Studio 新项目的默认语言就是它，官方模板、代码补全和大部分文档都以 Kotlin 优先。完全没有基础的人，直接选 Kotlin，别因为“Java 资料多”往回走。反过来，如果团队存量代码全是 Java，或者你自己更熟 Java，那沿用 Java 也完全没问题——简易项目这个体量，两种语言写出来的结构几乎一样，差距没到需要翻车的程度。
最低支持版本（Minimum SDK）我一般选 API 26 或 28，对应 Android 8.0 和 9.0。选高一点，能少处理很多兼容分支：运行时权限在 API 23 之后变简单了，后台限制在 API 26 之后规则清晰，这些对你一个只有一两个页面的项目来说，都是可以不用管的边界。做内部工具或者自己练手，没必要为了覆盖老设备把 minSdk 一路压到 21。而 compileSdk 和 targetSdk，就用当前 Android Studio 推荐的值，通常是 34 或更高，这两个值不要手动往下压，否则不少依赖库会直接拒绝编译。
页面模板选 Empty Views Activity（老版本里叫 Empty Activity）。不要选带 Compose 的入口——Compose 是另一套界面技术栈，对简易项目来说，经典 View 体系的代码更直白，网上的旧教程、现成代码、第三方控件几乎都能直接套。等你界面复杂到需要声明式 UI 时再回来学 Compose，那时候踩坑也有基础了。三个选项里，语言和模板随时能换，minSdk 一旦定下来、并且你的代码开始用高版本 API，回头压低版本就得改代码，所以它是最需要一次想清楚的。
| 选型点 | 推荐 | 理由 |
|---|---|---|
| 语言 | Kotlin（存量 Java 项目除外） | 官方默认，模板代码更少 |
| minSdk | 26 或 28 | 兼容分支少，自用足够 |
| 页面模板 | Empty Views Activity | View 体系资料多、易复现 |
提示：minSdk 定在 26，意味着 Android 8.0 以下设备装不了这个应用。团队内部工具这么做基本没影响，但如果有对外发布计划，先确认目标用户的机型分布。
2.2 Empty Views Activity 与 Gradle 同步：从点 Next 到出现可用页面
模板选好后，Android Studio 会生成一个最小工程，结构是固定的：
SimpleApp/ ├── app/ │ ├── build.gradle.kts │ └── src/main/ │ ├── java/com/example/simpleapp/ │ │ ├── MainActivity.kt │ │ └── （后续新增页面都放这里） │ ├── res/ │ │ ├── layout/activity_main.xml │ │ ├── values/strings.xml │ │ └── values/themes.xml │ └── AndroidManifest.xml ├── build.gradle.kts └── settings.gradle.kts第一次打开工程，Android Studio 会自动做 Gradle 同步。同步的本质是：按 build.gradle.kts 里声明的依赖，把需要的库和构建工具下载到本地。这个动作头几次会持续几分钟，进度条看起来像卡住，其实是在下载。别关窗口、别反复点 Sync，等它一次跑完。app 模块下的 build.gradle.kts 是后续最常打交道的文件：
plugins { id("com.android.application") // 声明这是一个 Android 应用模块 } android { namespace = "com.example.simpleapp" // 代码包名，改了要同步改目录 compileSdk = 34 // 编译用的 SDK 版本 defaultConfig { applicationId = "com.example.simpleapp" // 应用唯一标识，发布后别改 minSdk = 26 // 最低支持 Android 8.0 targetSdk = 34 // 目标版本，决定系统行为 versionCode = 1 versionName = "1.0" } buildTypes { release { isMinifyEnabled = false // 正式版先关混淆，以后再说 } } } dependencies { implementation("androidx.appcompat:appcompat:1.6.1") implementation("com.google.android.material:material:1.9.0") }几个参数说清楚：applicationId 是应用在系统里的唯一身份，上架后改它会变成另一个应用，之前装过的用户就收不到更新了；versionCode 是给系统判断版本的整数，每次更新必须递增；versionName 是给人看的版本号，可以叫 1.1 也可以叫 2.0-beta。dependencies 里那两行是基础库和 Material 设计库的常见入门组合，具体版本号以你新建工程时生成的文件为准，不需要背。
同步通过后，点工具栏的绿色运行按钮，选模拟器或真机，一个写着 Hello World 的页面就能跑起来。至此你已经完成了简易安卓项目的最小闭环：建工程、编译、运行。接下来所有功能，都是在这个骨架里加代码。
2.3 把 Android Studio 设置成中文界面：适合新手的一步到位的配法
英文菜单不习惯的话，可以把 Android Studio 界面切成中文。路径是 File > Settings（macOS 是 Android Studio > Settings）里的 Plugins，搜索 Chinese Language Pack 安装，重启后生效。这只是界面翻译，不影响代码，也不会改变构建行为。
顺手把两件事一起做了：在 Settings > Editor > General 里把字号调大一点；在 Settings > Editor > File Encodings 里确认 Project Encoding 是 UTF-8。中文乱码的问题，往往在项目还没写第一行代码时就已经埋下了，这里定好，后面省事。
下载安装包这件事多说一句：尽量从官网下载，别用搜索引擎前排的第三方打包站，那些站点经常捆旧版本和多余软件，装完反而多出几个你不需要的东西。机器上如果之前装过别的 JDK，不用管它，Android Studio 自带 JDK 足够用；Project Structure 里把 SDK 路径指向自带 JBR 即可。
3. 把首页做成能点的界面：布局、控件与事件绑定的最小套路
3.1 LinearLayout 还是 ConstraintLayout：两种写法的取舍
打开 activity_main.xml，你会看到一个布局根节点。新手第一个选择题就是：用 LinearLayout 还是 ConstraintLayout。
LinearLayout 的规则最简单：子控件按垂直或水平方向依次排队。垂直排布的输入框和按钮，每个设好间距，界面就成了。问题也明显：布局复杂时需要嵌套，一层套一层，层级深了渲染和测量都要多花时间，页面卡顿的隐患就是这个阶段埋下的。
ConstraintLayout 用约束关系定位——一个控件的左边对齐谁的右边、和谁同一条基线，全凭约束。它层级浅、灵活，是官方推荐的现代方案。但它的学习门槛也真实存在：不先理解“约束”这个概念，拖拽出来的界面时常莫名其妙跳动。
我的建议很直白：简易项目一律 LinearLayout，把精力留给 Activity 和事件逻辑；等出现“一个控件要同时参照两个方向定位”的需求，再换 ConstraintLayout。判断标准是：当你为了对齐一个按钮写了六个约束，这页面已经复杂到该换 ConstraintLayout 了。
3.2 按钮点击、输入读取、Toast 反馈：MainActivity 里的核心代码
一个简易安卓项目最典型的交互，就是输入框写东西、点按钮、有反馈。用 LinearLayout 把两个控件放进去：
<?xml version="1.0" encoding="utf-8"?> <!-- 外层垂直布局：子控件按纵向排队 --> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:padding="16dp"> <EditText android:id="@+id/input_text" android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入内容" android:inputType="text" /> <!-- 按钮文字用 string 资源，不要硬编码 --> <Button android:id="@+id/btn_submit" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_marginTop="16dp" android:text="@string/submit" /> </LinearLayout>这段布局里每个属性都有实际作用。match_parent 让输入框撑满宽度，wrap_content 让按钮只占自己的内容大小；hint 是输入框的灰色占位提示，inputType="text" 告诉系统这是普通文本。按钮文字我用了 @string/submit 而不是直接写“提交”——先把所有显示文字放进 res/values/strings.xml，以后统一改措辞或者做多语言，只改一处。这是简易项目阶段最值得养成的习惯之一。
接着写 MainActivity：
class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) // 先用 findViewById 拿到布局里的两个控件，id 和 XML 里的保持一致 val inputText = findViewById<EditText>(R.id.input_text) val btnSubmit = findViewById<Button>(R.id.btn_submit) btnSubmit.setOnClickListener { val content = inputText.text.toString().trim() if (content.isEmpty()) { Toast.makeText(this, "内容不能为空", Toast.LENGTH_SHORT).show() } else { Toast.makeText(this, "你输入了：$content", Toast.LENGTH_SHORT).show() } } } }findViewById 把布局控件和代码变量连起来，id 必须和 XML 里一致，这是初学者打错最多的点。setOnClickListener 注册点击回调，按钮按下时执行里面的代码。text.toString().trim() 顺手把首尾空格去掉，避免用户只敲空格就提交。Toast 是系统级的轻提示，显示几秒自动消失，适合这种一次性反馈。
如果界面要跳转到第二个页面，用 Intent：
val intent = Intent(this, DetailActivity::class.java) intent.putExtra("content", content) startActivity(intent)传出去的字符串在 DetailActivity 里用 intent.getStringExtra("content") 取回。这里有个高频错误：putExtra 和 getStringExtra 的 key 不一致时，取到的是 null，而 Kotlin 对 String? 类型的 null 处理会直接让编译报错——报错位置又往往不在你写 Intent 的地方，看起来特别像玄学。第二个页面记得在 AndroidManifest.xml 里注册，现在向导只自动注册了 MainActivity。没注册的 Activity 一启动就崩溃，Logcat 里会有一个明显的 ActivityNotFoundException。
3.3 控件再多也不乱：id 命名规范与 string 资源代替硬编码
页面上控件一多，代码就容易乱。我习惯的规则是：id 用“控件类型_含义”，比如 input_text、btn_submit、tv_result，一眼能看出是什么；字符串资源名用“页面_含义”，比如 submit 而不是 button_submit。这不是什么强制规范，但半年后重新打开自己的项目，省下的时间是实打实的。
另外两件小事一起说：命名规范直接让 Android Studio 的布局预览和代码补全更友好；当标准控件满足不了界面时，才需要写自定义组件（自定义 View），那是界面复杂到一定程度之后的话题，简易项目阶段不用碰，也别觉得非用不可。先把标准控件用熟，比急着自定义重要得多。
4. 数据不丢、列表能刷：状态保存与列表页的常用做法
4.1 旋转屏幕输入框内容还在：EditText 自动保存与 onSaveInstanceState 的边界
简易项目最容易翻车的场景之一是：界面填了一半，手机转个方向，内容全没了。原因在于转屏时系统默认销毁并重建 Activity。
第一道防线很朴素：EditText、CheckBox 这类带 id 的控件，系统会自动保存并恢复状态。条件是它必须有 android:id。所以别省 id——很多从别人项目里拷过来的控件没 id，转屏后就丢内容，加个 id 就好了。
第二道防线是 onSaveInstanceState，保存那些控件不自动管的数据：
override fun onSaveInstanceState(outState: Bundle) { super.onSaveInstanceState(outState) // 把输入框内容存进 Bundle，系统会在重建前保管它 outState.putString("saved_input", inputText.text.toString()) }恢复写在 onCreate 里：
if (savedInstanceState != null) { val restored = savedInstanceState.getString("saved_input") if (restored != null) { inputText.setText(restored) } }这里要强调边界：onSaveInstanceState 适合轻量数据，进程被系统回收时不保证生效，也不适合塞大对象。等数据一多、页面一复杂，就该上 ViewModel——它是官方推荐的转屏保持数据方案，把数据放在一个不随 Activity 重建的容器里。简易项目阶段先知道有这个方案、能说清它和 onSaveInstanceState 的区别就够了，不要为了一两个输入框提前上 ViewModel。
注意：转屏只是 Activity 生命周期问题的一种，onCreate 每次重建都会重新走。写代码时不要假设普通变量能跨重建存活，需要跨页面、跨重建的数据，一开始就放到可视作用域之外。
4.2 一个列表页要多长时间：RecyclerView 的 Adapter 与 ViewHolder
简易项目里，“列表”迟早会出现：记录清单、任务列表、缓存条目。RecyclerView 加 Adapter 是标准做法。Adapter 的角色是数据到控件的翻译官：给它一个 List，它负责为每一条数据创建视图并填充内容。
class ItemAdapter(private val items: List<String>) : RecyclerView.Adapter<ItemAdapter.ViewHolder>() { // ViewHolder 缓存一行里的控件引用，避免重复 findViewById class ViewHolder(view: View) : RecyclerView.ViewHolder(view) { val tvItem: TextView = view.findViewById(R.id.tv_item) } override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder { val view = LayoutInflater.from(parent.context) .inflate(R.layout.item_text, parent, false) return ViewHolder(view) } override fun onBindViewHolder(holder: ViewHolder, position: Int) { holder.tvItem.text = items[position] } override fun getItemCount(): Int = items.size }配套的 item_text.xml 只是一个带 id 的 TextView。使用的时候两行代码：
recyclerView.layoutManager = LinearLayoutManager(this) recyclerView.adapter = ItemAdapter(taskList)三个方法的分工要记牢：onCreateViewHolder 负责造一行，onBindViewHolder 负责填一行，getItemCount 告诉 RecyclerView 一共几行。layoutManager 决定列表形态，LinearLayoutManager 是垂直列表，最常用。这里有个高频错：忘了设 layoutManager，界面一片空白，很多人以为是 Adapter 写错了，折腾半天。出现空白列表时，先确认 layoutManager 设了没有。
4.3 SharedPreferences 能做什么：轻量缓存的适用边界
简易项目通常没有后端，数据落在本地。最轻量的缓存方案是 SharedPreferences，本质是一个 XML 文件，适合存键值对。
// 写入：getSharedPreferences 的第一个参数是文件名，MODE_PRIVATE 表示只有本应用可读 val prefs = getSharedPreferences("app_cache", MODE_PRIVATE) prefs.edit().putString("last_input", content).apply() // 读取：第二个参数是取不到时的默认值 val lastInput = prefs.getString("last_input", "")apply() 是异步写，速度很快，同一进程内立即能读到内存里的新值；commit() 是同步落盘，会阻塞调用线程，简易场景里两者差别不大。SharedPreferences 的边界要清楚：存临时状态、小配置、上次的输入，都可以；存大量结构化数据、二进制文件，就超出它能力了。数据量上来以后，常见做法是换 Room 或者直接读写文件。简易项目阶段 SharedPreferences 够用——但要知道它够用在哪、不够用在哪，项目边长边补，比长到一半再重构舒服得多。
5. 跑起来之前的避坑清单：资源重复、adb 与 Gradle 的四个典型踩坑
5.1 资源重复错误：从别人工程拷贝代码后最常见的报错
现象：编译或同步时提示 android studio 资源重复错误（Resource ... is duplicated）之类，报错指向 res 目录，而且往往不在你自己写的代码里。
原因：八成是从别的工程拷贝了 res 文件，或者合并时把两个同名布局、同名 drawable 塞进了同一个 res 目录。Android 的资源系统要求全局唯一：两个同名 layout 算重复，values 里两个同名 string 也算重复。还有个隐蔽来源：复制文件时把整个子目录一起带进来，产生嵌套的 res 文件夹。
解决：按报错里的资源名，去 res 目录逐层找同名文件，删掉多余的那个；内容都想保留就改名，而不是改内容。改完做一次 Build > Clean Project，把中间产物清干净再重新编译。还要留意：资源文件名用全小写字母加数字、下划线，混入大写或非法字符时，报错常常伪装成资源重复，先检查文件名再动代码。
5.2 adb 看不到设备：数据线、驱动与调试开关的排查顺序
现象：点运行按钮，设备列表是空的；命令行敲 adb devices 也看不到手机。
排查顺序固定下来能省大量时间：一，确认手机开发者选项里的 USB 调试开了没有。很多新手机默认隐藏开发者选项，要连点版本号七次才出现，这一步是最常被跳过的。二，确认用的数据线支持数据传输——随手抓的充电线没有数据通道，换根原装线往往立刻解决。三，看手机上有没有弹出“允许 USB 调试”的授权框，不小心点了拒绝的话，去开发者选项里撤销授权重连。
按顺序走完还不行，Windows 用户优先怀疑驱动：设备管理器里有没有带感叹号的设备。macOS 和 Linux 很少遇到。这套顺序本身就是技巧，别一开始就怀疑代码、怀疑电脑配置，那种玄学式排查到最后发现是线的问题的情况，我见过太多次。
5.3 模拟器黑屏、启动慢：AVD 配置与冷启动的正确姿势
现象：安卓模拟器第一次启动要好几分钟，启动完黑屏，或者一直停在“正在启动”。
原因：第一次冷启动要做完整系统引导，慢是正常的；持久黑屏通常是 AVD 配置和本机硬件不匹配——分辨率设得比屏幕还高、没开硬件加速、选了过老的系统镜像。
解决：创建 AVD 时选 x86_64 架构的镜像，别选 arm 版；分辨率选 1080p 以下；Device Manager 里把启动方式设为 Cold Boot；Windows 上确认 Hyper-V 或 Intel HAXM 加速组件在 SDK Manager 里装好了。小技巧：模拟器窗口尽量保持打开，别反复冷启动，能省掉大量无谓等待。
5.4 Gradle 同步失败：版本对不上与网络超时的两套处理
现象：Gradle 同步失败，报 Could not resolve 或 Failed to sync，或者停在某个依赖上下载超时。
原因分两类，处理方式完全不同。第一类是版本对不上：从网上拷来的项目，它的 Android Gradle Plugin 要求 Gradle 8.x，而你用的是新版本 Studio 自带的 Gradle 9.x。这类报错信息通常写得很明确。解决是按 Android Studio 的提示升级 AGP，或者把版本调到和本机兼容，一次只动一个变量，别同时改 AGP 和 Gradle。
第二类是网络超时。首次同步要下载几百 MB 依赖，网络抖动时失败很正常，原样重试即可。如果反复在同一个位置超时，检查本机有没有占用常用端口的软件，退掉再同步。这里最忌讳从网上随手抄一段仓库地址改来改去——改错了，比不改还难排查，因为报错会从网络问题变成配置问题。
6. 把简易项目收成 APK：签名、安装验证与一个值钱的编码习惯
简易项目写到能用了，就该变成能发给别人的安装包。直接用 run 按钮打出来的 debug 包能安装，但换个环境就会暴露出安装失败、被安全软件拦截、后续更新装不上等问题，根源是签名不一致。
正确做法是生成正式签名。在 Android Studio 里通过 Build > Generate Signed Bundle or APK，按向导创建 jks 密钥库，记好密码和别名，选 release 变体。更工程化的做法是把签名配置写进 build.gradle.kts：
signingConfigs { create("release") { storeFile = file("release.jks") storePassword = "your-password" keyAlias = "release-key" keyPassword = "your-password" } } buildTypes { getByName("release") { signingConfig = signingConfigs.getByName("release") } }密码别明文提交到代码仓库，常见做法是放到项目根目录的 keystore.properties 里，由 build.gradle.kts 读取。也不要图省事去网页上“在线生成 jks”——密钥走了一遍别人的服务，等于把应用的更新权交出去了，这算是安卓开发的兜底线。密钥库文件单独备份，一旦丢失，已装应用永远签不上新包，这是个没有后悔药的坑。
打包后的验证分两步：先装到自己的手机，再找一台从没接过这个项目的手机装一次。装完立刻打开，把每个入口都点一遍，盯着有没有秒退。命令行验证用 adb install -r app-release.apk，-r 表示覆盖安装。这一步能拦住 90% 的发布事故。
最后一个习惯，价值比签名还高：当 MainActivity 里的点击监听越来越长时，用抽取方法快捷键（Windows 是 Ctrl+Alt+M，macOS 是 Cmd+Option+M），选中一段代码抽成带名字的方法。这个动作看着小，但它逼着你给逻辑命名——想清楚“这段在干什么”，项目的边界就清晰了。简易项目通向复杂项目，靠的不是架构书，而是每次改代码前先想清楚行为边界。这是我最受益的习惯，希望帮到你。
本文还有配套的精品资源，点击获取
