Android App开发全链路：环境搭建、Activity与数据存储上架实战

Android App 开发这件事，说难也难，说简单也简单。我带过几个刚入行的朋友，他们卡住的地方往往不是不会写 Java 或 Kotlin，而是打开 Android Studio 之后两眼一抹黑——SDK 装哪个、Gradle 报红怎么办、模拟器跑得比蜗牛还慢、写好的界面在真机上直接崩。这些问题的共同点是：官方文档都写了，但没人告诉你哪些是必须要懂的，哪些可以先放着不管。

这篇内容我想做的是把 Android App 开发的基础链路从头到尾捋一遍，从装工具、认目录、写界面、存数据，一直讲到打包上架和成本这笔账。适合两类人看：一是完全没碰过移动端、想从零起步的新手；二是做过一点前端或者后端、想快速把 Android 这块补起来的人。我不会只丢一堆名词，每一步都会说清楚为什么这么做、不做会出什么问题，以及我自己踩过的那些坑。

1. 环境搭建不是一路下一步，几个选择会决定后面顺不顺

很多人把装 Android Studio 当成装普通软件，点完下一步就以为完事了，结果第一个工程就卡在 Sync 上。环境这一关的核心不是"装没装上"，而是"工具链版本搭不搭"。

1.1 装 Android Studio 之前，先确认 JDK 这件事

Android Studio 现在自带了一个 JetBrains Runtime（简称 JBR），里面已经包含了 JDK，所以绝大多数情况下你不需要单独去装 JDK。但这里有个容易翻车的点：如果你电脑上早就装了别的 JDK，而且JAVA_HOME指向了它，Gradle 构建时可能会用错版本，报出类似Unsupported class file major version的错误。

我一般的做法是，先不去动系统里的环境变量，直接让 Android Studio 用它自带的 JBR。在设置里找到Build, Execution, Deployment > Build Tools > Gradle，把 Gradle JDK 明确指到 IDE 自带的那个版本。这样能避开八成的"明明装好了却编译不过"的问题。

如果你的项目确实需要指定某个 JDK 版本，比如团队要求用 17，那就统一在 Gradle JDK 这一栏设置，而不是去改系统的JAVA_HOME。系统级的改动会影响其他软件，而项目级的设置只影响这一个工程，出问题了也好回退。

1.2 SDK 管理器里，哪些组件是必装，哪些可以缓一缓

打开 SDK Manager，里面密密麻麻一堆组件，新手很容易全勾上，结果硬盘吃紧、下载半天。我的建议是按需装，下面这张表是我这几年总结下来的取舍：

重点说下 System Image。模拟器的镜像分 x86_64 和 arm64 两类，Intel 或 AMD 的电脑选 x86_64，跑起来会快得多；Apple 芯片的 Mac 就得选 arm64。选错了不是不能跑，而是慢到你怀疑人生——这一点后面还会细说。

1.3 模拟器和真机：什么时候必须插上数据线

模拟器方便，但有两个绕不开的短板。一是性能，尤其是图形渲染和一些底层硬件相关的功能，模拟器上表现和真机差得远；二是某些功能只有真机才有，比如打电话、发短信、传感器（加速度计、陀螺仪、光线传感器）、指纹、部分蓝牙协议。

做基础开发的时候，模拟器足够用了，界面布局、页面跳转、数据存储这些都没问题。但只要你碰摄像头、定位精度、性能优化，就老老实实上真机。

真机调试有个新手老忘的步骤：开启"开发者选项"。进设置找到"关于手机"，连续点七次"版本号"，开发者选项才会冒出来，然后在里面打开"USB 调试"。插上数据线之后，手机上会弹一个授权框，勾选"一律允许"再确定，不然 adb 是看不到设备的。

注意：如果插上电脑后 adb 一直显示device offline，八成是数据线只支持充电不支持数据传输。换一根原装线，或者换一个 USB 接口，问题往往就解决了。

2. 工程目录扫一遍，每个文件夹都不是随便放的

新建一个 Empty Activity 工程之后，左侧的项目面板展开，你会看到一大堆目录。很多人写了大半年代码，还是没搞清楚res和assets的区别，也不知道AndroidManifest.xml为什么这么重要。这一节把结构讲透。

2.1 src/main 下的三兄弟：java、res、assets

src/main是主源码目录，里面最常打交道的是三块：

• java（或 kotlin）：放代码。你的 Activity、自定义 View、工具类都在这里。包名一般跟应用 ID 对应，倒过来写，比如com.example.myapp。
• res：放资源。资源的特点是它们会被编译，并且可以通过R.xxx在代码里引用。常见的子目录有layout（布局）、drawable（图片和图形）、values（字符串、颜色、尺寸、主题）、mipmap（应用图标）。
• assets：放原始文件。这里的文件不会被编译，也不会生成资源 ID，需要通过AssetManager以流的方式读取。适合放一些大文件、预置的数据库、HTML 页面等。

这里有个很实用的区别：如果一张图片需要在布局里通过@drawable/xxx引用，就放res/drawable；如果是一个需要整段读取进来的文本模板或者离线网页，就放assets。搞混了会导致"图片能找到但文字读不出来"这类莫名其妙的 bug。

2.2 AndroidManifest.xml：应用的身份证和门禁名单

AndroidManifest.xml是整个应用的清单文件，地位非常高。它主要管三件事：

第一，声明应用的基本信息，比如应用 ID、版本号、应用名称、图标。这些信息打包的时候会被写进 APK 里。

第二，注册四大组件。Activity、Service、BroadcastReceiver、ContentProvider 都必须在清单里登记，漏了就直接崩，报ActivityNotFoundException或者类似错误。新手最常见的崩溃之一就是新写了个 Activity 却忘了注册。

第三，声明权限。应用要访问网络、读写存储、使用摄像头，都得在这里申请权限。从 Android 6.0 开始，敏感权限除了在清单里声明，运行时还得动态申请一次，两个步骤缺一不可。

<manifest xmlns:android="http://schemas.android.com/apk/res/android"> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.CAMERA" /> <application android:label="我的应用" android:icon="@mipmap/ic_launcher"> <activity android:name=".MainActivity" android:exported="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest>

注意那个android:exported属性。从 Android 12 开始，凡是带intent-filter的组件，都必须显式声明这个属性，否则装不上。带LAUNCHER的那个 Activity 通常要设成true，因为它需要被桌面启动。

2.3 build.gradle 的两个层级和三个 SDK 版本号

现在新建工程默认用的是 Kotlin DSL，文件名叫build.gradle.kts，老一点的项目是build.gradle。不管哪种，都分两个层级：

• 项目级（根目录下）：配置整个项目共用的东西，比如插件版本、仓库地址。
• 模块级（app 目录下）：配置这个具体模块，比如依赖库、编译版本。

模块级里最关键的三个版本号，新手经常分不清：compileSdk、minSdk、targetSdk。我用一个比喻来解释：

• compileSdk是你写代码时用哪套 SDK 来编译，决定你能调用哪些新 API。
• minSdk是你的应用最低支持到哪个系统版本，决定有多少老设备能装你的应用。
• targetSdk是你针对哪个版本做过适配测试，系统会按这个版本的规则来对待你的应用。

举个实际例子：如果minSdk设成 24，就意味着 Android 7.0 以下的手机装不了。设得越低，覆盖用户越多，但你要处理的兼容问题也越多。我一般新项目设 24，做企业内部分发的可以设 26 甚至更高，因为设备是可控的。

提示：改targetSdk的时候要格外小心，因为它往往伴随行为变更。比如高版本对后台服务、通知权限、存储访问的限制越来越严，直接调高可能让原本正常的代码失效。

3. Activity 从点击图标到显示界面，这一路发生了什么

Activity 是 Android 里最核心的组件，一个 Activity 大致对应一个屏幕。理解它的生命周期，是理解 Android 应用运行机制的第一步。很多人写代码时在这里踩坑，是因为只记住了回调的名字，不知道每个回调的实际意义。

3.1 七个生命周期回调的真实执行顺序

当你在桌面上点开一个应用图标，代码层面发生的过程大致是：系统创建 Activity 实例，依次调用onCreate、onStart、onResume，界面显示出来并可以交互。

我把它整理成一张对照表，左边是回调，右边是它被触发的时机和典型用途：

真正需要记牢的是成对关系：onCreate对应onDestroy，onStart对应onStop，onResume对应onPause。在这三对之间做资源的申请和释放，是最稳妥的写法。

3.2 onCreate 里别干重活，那是有原因的

新手很容易在onCreate里塞一堆耗时操作，比如读大文件、请求网络数据、初始化大型对象。结果就是点开应用之后黑屏或者白屏几秒，体验非常差。

原因在于，onCreate是在主线程（UI 线程）上执行的，而主线程负责渲染界面和处理输入事件。你在它里面做耗时操作，界面就没法及时绘制，用户看到的就是卡住不动。

正确的做法是：onCreate里只做"轻"的初始化，把布局设置好、控件找到、简单数据绑定完。网络请求和读数据库这类操作，交给子线程或者协程去处理，结果回来之后再更新界面。

override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val tvTitle = findViewById<TextView>(R.id.tv_title) // 耗时操作放到子线程，主线程负责更新 UI lifecycleScope.launch(Dispatchers.IO) { val data = loadDataFromDatabase() withContext(Dispatchers.Main) { tvTitle.text = data } } }

这段代码用到了lifecycleScope，它会把协程的生命周期跟 Activity 绑定在一起。Activity 销毁了，协程自动取消，不会造成内存泄漏。这是现在比较推荐的做法。

3.3 屏幕旋转和数据丢失，这个坑几乎人人都踩

把手机横过来，界面重新布局，看起来很正常。但你可能没注意到，屏幕旋转默认会销毁当前 Activity 再重新创建一遍。也就是说，onCreate又被执行了一次，你存在成员变量里的数据全没了。

假设你在一个输入框里填了字，然后旋转屏幕，字消失了，这就是这个机制导致的。解决办法有两个方向：

第一，用onSaveInstanceState保存状态。系统在销毁 Activity 之前会调用它，你往Bundle里塞数据，重建的时候在onCreate的参数里取出来：

override fun onSaveInstanceState(outState: Bundle) { super.onSaveInstanceState(outState) outState.putString("draft", editText.text.toString()) } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val draft = savedInstanceState?.getString("draft").orEmpty() editText.setText(draft) }

第二，用 ViewModel 来保存数据。ViewModel 的生命周期比 Activity 长，转屏重建的时候它不会被销毁，数据自然还在。这是目前最主流的方式，尤其是配合界面数据比较多的时候。

这两种方式不是互斥的。一般表单里临时输入的用onSaveInstanceState，界面展示的业务数据用 ViewModel。

4. 布局与列表，新手最容易写出卡顿界面的地方

界面写得好不好，直接决定用户对应用的第一印象。这一节讲三个点：布局用哪种、列表怎么写、耗时任务和进度条怎么配合。

4.1 ConstraintLayout 的约束思维和控件"不见了"的问题

现在新建工程默认的根布局是ConstraintLayout，为什么不用早年的LinearLayout或者RelativeLayout？

关键在于嵌套层级。LinearLayout和RelativeLayout想实现复杂布局，往往要一层套一层，层级一深，测量和绘制的时间就成倍增加。ConstraintLayout用约束关系来描述位置，绝大多数界面可以做到一层搞定，渲染效率高得多。

约束的核心就是四句话：控件要确定位置，必须至少有一条水平约束和一条垂直约束。只给水平约束，它会跑到顶上；只给垂直约束，它会跑到左边。新手画出来的控件"不见了"，九成是约束给少了或者给冲突了。

几个常用的约束属性：

<TextView android:id="@+id/tv_title" android:layout_width="0dp" android:layout_height="wrap_content" android:text="标题" app:layout_constraintStart_toStartOf="parent" app:layout_constraintEnd_toEndOf="parent" app:layout_constraintTop_toTopOf="parent" />

这里layout_width设成0dp配合左右两条约束，效果等同于"撑满父容器宽度减去边距"，也就是常说的 match_constraint。这是 ConstraintLayout 里非常常用的一个技巧，比写match_parent更灵活，因为它还能配合 bias 调整偏移比例。

4.2 RecyclerView 的复用机制，和错位、闪烁的根源

列表是应用里最常见的界面形态，而RecyclerView是官方推荐的列表控件。它性能好的原因在于"复用"：屏幕上能显示 8 个条目，它可能只创建 10 个左右的 item 视图，滑动的时候把滑出屏幕的视图回收，再拿给新进入屏幕的条目用。

但这个机制带来了一个经典陷阱。因为视图是复用的，如果你在onBindViewHolder里只对某些条件设置了控件的状态，没在 else 分支里重置，那复用的旧状态就会残留下来。表现出来就是：明明这条数据不该显示红点，结果它显示了。

正确的写法是，每条数据绑定的时候，把所有可能变化的属性都显式设置一遍：

override fun onBindViewHolder(holder: MyHolder, position: Int) { val item = dataList[position] holder.tvName.text = item.name holder.ivIcon.visibility = if (item.hasNew) View.VISIBLE else View.GONE holder.itemView.setBackgroundColor( if (item.highlight) Color.YELLOW else Color.TRANSPARENT ) }

凡是if里面改了状态，else里面一定要还原。这几乎是我每次做列表都会提醒自己的事。

至于列表图片加载时闪烁，通常是图片还没加载完，占位图和应用的主题背景色不一致导致的。解决办法是给图片控件设置一个固定的占位颜色，或者用成熟的图片加载库来处理缓存和过渡动画。

4.3 进度条不动，多半是线程问题

进度条这个控件看着简单，出问题的时候却很让人抓狂：代码明明写了更新进度，界面上就是一根不动的横线。

根本原因还是回到主线程。子线程更新 UI 会抛异常或者被系统忽略。正确的方式是，计算进度的逻辑放在子线程，更新进度条的动作丢回主线程。

lifecycleScope.launch { withContext(Dispatchers.IO) { for (i in 1..100) { Thread.sleep(50) withContext(Dispatchers.Main) { progressBar.progress = i } } } }

还有一种情况：进度条显示的是不确定的状态（indeterminate设为 true），那它本来就是一格不停旋转的样式，不会显示具体百分比。要用确定进度，记得把这个属性关掉。

提示：如果用ProgressBar做加载提示，记得在数据加载成功后把它隐藏（visibility设为GONE），同时把真实内容显示出来。忘记切换状态，用户就会一直看到转圈。

5. 数据存哪里，从键值对到本地数据库的递进选择

应用不可能只展示静态内容，总得存点东西：用户设置、登录状态、缓存数据、业务记录。Android 提供的存储方案有好几种，选错会让代码越写越乱。

5.1 SharedPreferences 的边界在哪

SharedPreferences是最简单的存储方式，本质上是一个键值对文件，适合存少量简单的配置项，比如是否首次启动、用户选的主题、开关状态。

val sp = getSharedPreferences("settings", MODE_PRIVATE) sp.edit().putBoolean("dark_mode", true).apply() val isDark = sp.getBoolean("dark_mode", false)

它的优点是用起来快、简单。缺点是全量加载进内存，数据一多就吃内存；而且不支持复杂查询。我的经验是，条目数控制在几十条以内、结构简单的场景用它是合适的，一旦涉及列表数据、条件查询，就该换数据库了。

还有一点容易被忽略：apply()是异步写，commit()是同步写并返回结果。日常用apply()就行，只有在必须确认写入成功（比如关键配置）的时候才用commit()。

5.2 Room 的三层结构和一次完整读写

Room是官方在 SQLite 之上封装的一个数据库库，它让写数据库变得像写普通方法一样。核心是三个部分：

• Entity：一个实体类对应一张表。
• DAO：数据访问接口，定义增删改查方法。
• Database：数据库持有者，把实体和 DAO 关联起来。

看一个完整的例子：

@Entity data class Note( @PrimaryKey(autoGenerate = true) val id: Long = 0, val title: String, val content: String ) @Dao interface NoteDao { @Insert suspend fun insert(note: Note) @Query("SELECT * FROM note ORDER BY id DESC") suspend fun getAll(): List<Note> } @Database(entities = [Note::class], version = 1) abstract class AppDatabase : RoomDatabase() { abstract fun noteDao(): NoteDao }

DAO 方法加上suspend之后就可以直接在协程里调用，不用自己开线程。这一点非常重要：数据库操作是 IO 操作，绝对不能放在主线程，否则数据量一大界面就卡死。

用的时候一般做成单例，避免反复创建数据库连接：

val db = Room.databaseBuilder( applicationContext, AppDatabase::class.java, "app.db" ).build()

5.3 content:// 开头的 URI，跨应用数据共享的门道

有时候你会看到一个以content://开头的地址，长得像网址但不是网址。这是 Android 里 ContentProvider 暴露出来的数据地址，用来在应用之间共享数据。

一个典型的组成部分是这样的：content://作者标识/路径/具体ID。前面是协议，中间是提供方的唯一标识，后面是要访问的资源。

我们自己开发时最常打交道的场景是"把文件分享给别的应用"。出于安全考虑，从某个版本开始，应用之间不能直接传文件路径了，必须通过 FileProvider 生成一个content://的临时授权地址。配置流程大致是：

<provider android:name="androidx.core.content.FileProvider" android:authorities="com.example.myapp.fileprovider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/file_paths" /> </provider>

再配合一个res/xml/file_paths.xml声明可以暴露哪些目录。然后在代码里用FileProvider.getUriForFile()拿到 URI，通过 Intent 传出去。

这里最容易出错的是 authorities 写错、路径没配对，报IllegalArgumentException: Failed to find configured root。排查的时候先确认 authorities 跟代码里用的一致，再确认你要分享的文件确实在声明的目录范围内。

注意：FileProvider 暴露的目录要收窄，只开放确实需要分享的子目录，不要把整个存储根目录都放出去，那是明显的安全隐患。

6. 调试排错，日志、抓包和真机联调的实战方法

写代码的时间其实只占一半，另一半是在跟 bug 打交道。这一节讲三个最常用的排错手段。

6.1 Logcat 看得出来，问题就解决一半

Logcat是 Android 的日志面板，崩溃信息、系统提示、你自己打印的日志都在这里。新手常见的困惑是信息太多，刷屏刷到看不清。

几个实用技巧：一是按级别过滤，日志分 Verbose、Debug、Info、Warn、Error，平时看 Error 和 Warn 就够；二是按包名过滤，把 Logcat 顶部的进程选项切到你的应用，其他无关日志就没了；三是用关键字搜索，比如搜崩溃异常的类名。

打印日志的时候养成好习惯：用Log.d(TAG, message)，TAG用当前类名，并且不要在主线程里循环打印大量日志，那样会拖慢应用。

崩溃日志要重点看第一行和Caused by那一段。第一行说明异常类型，Caused by里往往藏着真正的根因，比如使用了空对象、数组越界、找不到资源。

6.2 抓包失败，通常卡在这几个地方

抓包是排查网络问题的利器，用来确认请求到底发出去没有、发了什么、服务端返回了什么。新手第一次抓包经常抓不到东西，原因集中在几个方面：

• 应用使用了加密协议：如果服务器用的是双向认证或者证书绑定，普通的抓包方式看不到明文。这是安全设计，不是 bug，遇到这种只能从日志或者服务端侧排查。
• 抓包工具的证书没装到系统信任区：普通应用装在用户区就行，但有些应用对证书来源有校验。
• 手机和电脑不在同一网络：代理方式抓包需要两者在同一网段，代理 IP 和端口设错连不上。
• 应用走了非 HTTP 通道：比如用了自定义的 Socket 协议，HTTP 抓包工具自然看不到。

我的建议是，先排查自己的应用。在代码里加一层日志，把请求的 URL、参数、响应码打出来，能解决大部分"到底请求成功没有"的疑问。抓包是辅助手段，不是唯一手段。

6.3 adb 高频命令，装进脑子里能省很多时间

adb是跟设备通信的命令行工具，藏了一大堆实用功能。下面这些是我日常用得最多的：

adb shell pm clear这个命令我特别推荐。测试首次启动流程、登录流程图省事，不用卸载重装，一条命令就回到干净状态。

7. 打包上架，签名、混淆和成本这笔账

代码写完了，界面调好了，接下来就是打包发布。这一关没有什么技术难点，但流程细节多，漏一步就得重来。

7.1 签名和 release 构建，别拿 debug 包去发布

调试用的 debug 包用的是系统默认签名，不能用于正式发布。要发布必须生成自己的签名文件（keystore），并且在模块级的构建配置里配置 release 的签名信息。

生成签名可以在 Android Studio 的构建菜单里操作，也可以直接用命令行。关键是这个签名文件一定要保存好，并且记住密码。应用上架之后，后续所有版本更新必须用同一个签名文件签名，签名换了系统就不认为这是同一个应用，只能当新应用重新上架。

android { signingConfigs { create("release") { storeFile = file("my-release-key.jks") storePassword = "你的密码" keyAlias = "key0" keyPassword = "你的密码" } } buildTypes { release { isMinifyEnabled = true proguardFiles( getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro" ) signingConfig = signingConfigs.getByName("release") } } }

isMinifyEnabled打开之后会做代码压缩和混淆，包体会变小，代码也会被重命名增加逆向难度。代价是有些反射用到的类、跟后端约定的实体类可能被混淆掉导致崩溃，这时候要在proguard-rules.pro里把它们保留下来。我一般的做法是，反射、序列化相关的类统一加保留规则，第一次打包之后完整跑一遍主要功能，确认没崩再上传。

提示：签名文件和密码不要提交到代码仓库。放在本地，或者用构建环境变量注入，这是底线。

7.2 上架材料和审核退回的常见原因

国内的应用分发渠道和前几年相比，流程规范了很多。上架通常要准备的材料包括：应用名称和图标、应用截图、功能简介、隐私政策链接、软著或者相关资质（视渠道和品类而定）。

审核被退回的原因，我总结下来集中在三类：

• 权限说明不充分：申请了某个敏感权限，但功能说明里没解释为什么需要，会被质疑过度索取权限。原则是按需申请，用不到就别声明。
• 隐私政策缺失或不一致：应用实际收集的信息跟隐私政策里写的对不上。这个要认真核对，尤其是集成了第三方统计、推送服务之后，它们也会收集信息，要在政策里如实说明。
• 内容或功能不符合渠道规范：这个就不用多说了，功能要正当、内容要合规。

我的经验是，第一次上架预留一周左右的缓冲时间，因为来回修改和重新提审都需要时间。资料提前准备齐，能省掉不少来回沟通。

7.3 自己做一个应用到上架，大概要花多少钱

这是被问得最多的问题，但答案的跨度非常大，因为"做一个应用"的定义太模糊了。我把成本拆成几块说，这样估算起来有依据。

第一块是开发工具。Android Studio 和 SDK 都是免费的，这块基本是零成本。需要花的可能是电脑性能，如果做原生、跑模拟器，一台内存 16G 起步的电脑体验会好很多。

第二块是证书和资质。国内渠道上架一般会涉及软件著作权登记，这个有官方渠道和代办渠道，价格从几百到上千不等。签名证书本身不花钱，自己生成即可。

第三块是服务器和后端。如果应用需要账号、数据同步、云存储，就得有后端。轻量的可以用云服务商的入门配置，一年几百块也能跑起来；业务量上来了成本自然水涨船高。

第四块是人力。这才是真正的开销大头。一个功能完整、体验过得去的应用，从设计、开发、测试到上架，往往需要不止一个人、不止一个月。如果是外包，报价会按功能点、页面数、复杂度来算。

所以如果有人问"开发一个应用要多少钱"，我会反问：你要的是个能跑通流程的演示，还是一个能承载真实用户的产品？这两者的成本可能差十倍以上。想清楚定位，再谈预算，才有意义。

关于学习路径，我个人建议是，先用模拟器把第一个能交互的小应用跑通，别贪多。把这个过程中的每个报错都当成一次补课，会发现基础的东西其实翻来覆去就那些。等你能独立做出一个带列表、能存数据、能联网的小应用，再回头看那些框架和架构，就水到渠成了。