简介面向安卓学习者与毕业设计学生提供一款基于安卓的天气预报应用完整源码实现了城市列表选择、实时天气、温度星期展示以及未来六天预报等核心功能。项目界面左侧提供中国城市列表点击城市即可联动刷新对应区域的天气卡片交互逻辑完整。资源共二十四个文件压缩包大小五点零二兆字节包含界面布局文件、依赖库文件、图标图片、应用安装包及说明文档目录结构清晰便于直接导入开发环境进行编译与二次开发。当前已有一千五百九十七人学习下载适合作为本科毕业设计参考或安卓入门实战项目。通过研读源码可以快速掌握网络请求、数据解析、列表绑定、界面刷新等关键模块的实现思路配合可运行安装包与说明文档能够显著降低环境搭建和调试门槛帮助读者快速复现并改造出属于自己的天气应用。1. 打开这个zip你大概率正在做Android本科毕业设计或者接手一份别人已经写好的天气预报APP系统源码。天气预报项目在移动开发里之所以被反复拿出来当题目是因为它数据源公开、交互链路短、UI能做出很直观的展示效果一个天气主界面、一个多日列表、一个城市搜索框就能把Activity、网络请求、JSON解析、列表渲染、权限适配这些核心知识点全部覆盖。本文不做论文层面的格式讲评直接按工程实现顺序走先看整体架构和数据流再处理Gradle环境接着拆核心功能实现然后适配新设备上的定位权限与存储限制最后用Lint和打包验证代码质量。按这条路走完这份“系统源码.zip”就不再是解压后躺着的静态文件而是一套你能讲清楚、能改得动、敢拿上演示台的可用App。2. 天气APP源码的分层框架与数据流先看懂骨架再动手2.1 传统写法、MVP与MVVM毕业设计源码里最常见的三种结构拿到zip后第一件事不是急着点运行而是先浏览整个项目的包结构。多数本科毕设的Android工程会呈现三种组织方式传统写法把所有逻辑塞进ActivityMVP用接口把网络请求和界面回调拆开MVVM依赖ViewModel和LiveData做响应式驱动。怎么判断你手里的源码属于哪一种看根目录下是否存在model、presenter、viewmodel这些包名就行。结构风格目录特征回调方式调试难度答辩讲解价值传统写法只有activity和adapter匿名线程加HandlerUI与网络逻辑耦合查日志费劲较低MVP出现presenter/view/model三层接口回调每个页面需要维护两个以上接口高结构清晰MVVM出现viewmodel/repositoryLiveData、Flow链路长但可单元测试高贴近企业项目多数课程设计和毕设源码实际位于“MVP的简化版”网络层放在model里MainActivity实现View接口Presenter负责把两者接起来。以天气预报这份代码为例你会在model包里看到WeatherBean、WeatherRequest在ui包里看到MainActivity和ForecastAdapter。看到这种结构别急着改造成MVVM答辩时讲清楚MVP的单向数据流就够了用户点击刷新View把事件交给PresenterPresenter调用Model发起网络请求Model拿到数据回调PresenterPresenter最终刷新View。这个链路里最值得跟导师强调的一句话是“View不直接碰网络”。很多新手会把OkHttp写进Activity的onCreate里看似代码少但一旦页面旋转导致Activity重建请求就会被重复调用。MVP把网络层下沉以后Activity的职责只剩下渲染和转交用户事件这正是源码里分层的意义。2.2 从HTTP请求到UI刷新一次天气数据的完整链路天气预报应用的数据源通常分两类一类是免费天气API比如和风天气的devapi.qweather.com另一类是直接抓取公开网页再解析。毕业设计源码大多走免费API路线因为接口稳定、返回JSON结构清晰、文档齐全。拿到源码后先确认baseUrl指向哪个域名很多老项目写的是旧版和风天气地址free-api.heweather.net现在已经被新版接口替代不改就等着HTTP 401。典型请求代码是OkHttp发异步请求Gson解析JSON到实体类再通过RecyclerView的Adapter刷新列表OkHttpClient client new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(10, TimeUnit.SECONDS) .build(); Request request new Request.Builder() .url(https://devapi.qweather.com/v7/weather/now?location101010100key API_KEY) .get() .build(); client.newCall(request).enqueue(new Callback() { Override public void onFailure(Call call, IOException e) { // 注意这个回调在子线程不能在这里直接弹Toast } Override public void onResponse(Call call, Response response) throws IOException { if (response.isSuccessful()) { String body response.body().string(); WeatherNowBean bean new Gson().fromJson(body, WeatherNowBean.class); runOnUiThread(() - mTvTemperature.setText(bean.getNow().getTemp())); } } });这里面有两个参数值得记住connectTimeout和readTimeout都设置成10秒是为了避免弱网环境下界面长时间无响应enqueue是异步执行但onResponse并不保证回到主线程所以更新TextView前要包一层runOnUiThread否则新版本SDK会直接抛CalledFromWrongThreadException导致闪退。这个闪退也是老源码跑在今天的模拟器上最常见的崩溃点之一排查时先看日志有没有“Cant create handler inside thread”。顺便说一句如果源码里用的是HttpURLConnection而不是OkHttp不要觉得落后。对于单个天气接口来说原生方案足够演示等做到多接口、需要统一日志拦截时再替换成OkHttp也不迟别在答辩前夜做这种无意义的框架替换。2.3 城市切换与页面状态源码里最容易空指针的地方见过不少毕设源码在切换城市时崩溃根因不是网络而是异步回调还在路上、Activity已经销毁。典型场景是用户在主界面点击城市A马上又切到城市B第一次请求的响应返回后在onResponse里调用了finish后不再存在的控件于是空指针。更稳的做法是把当前城市ID存进SharedPreferences每次启动直接读存储值再配合onSaveInstanceState保存一份临时状态。源码里如果出现“切换城市后按返回就崩”第一步检查回调方法里有没有对View做空判断第二步检查Activity销毁时有没有把未完成的Call通过cancel()取消掉。记住一个原则网络请求要跟随页面生命周期。如果Timer轮询天气没有在onPause里停掉页面退到后台还在持续发请求内存、电量、流量三方面都会被导师点名。源码城堡里最耐看的不是功能花哨而是每个生命周期对应的资源回收很干净。3. 从zip到Android Studio导入工程与Gradle环境配置3.1 解压前先校验zip完整性别让文件损坏浪费一晚上很多同学拿到压缩包直接双击解压等到Android Studio报“Could not read signature”这类错误时才开始怀疑压缩包是否损坏浪费至少半小时。我通常先执行一次测试解压命令确认文件头和数据块都能正常读取再解压。# 在zip所在目录执行测试不实际解压 unzip -t weather_forecast_src.zip # 确认输出包含 No errors detected in compressed data 后再解压到指定目录 unzip weather_forecast_src.zip -d /Workspace/android/weather_project-t参数的作用是逐文件校验CRC校验值能在几秒内发现哪个文件数据损坏。解压目录也要讲究不要解压到桌面或带中文的路径比如“桌面/project/天气”Gradle的NDK与CMake插件对带空格和中文的路径支持一直不好路径解析错乱时会报一串难以理解的“task not found”。解压完成后立即检查根目录是否有settings.gradle、build.gradle和app子目录如果只是一堆散落的.java文件说明这个zip是手工导出的源码片段而非完整工程需要自己重建Android项目结构。3.2 compileSdk、targetSdk与Gradle版本老工程开箱必改的配置用当前版本Android Studio打开几年前写的工程最常见提示是“Minimum supported Gradle version is 8.4”或者“Android Gradle plugin requires Java 17”。这不是源码坏了而是构建工具链版本代沟。应对方式不是降级Android Studio而是把工程的Gradle插件和依赖版本提到当前环境兼容的档位。打开app/build.gradle重点关注这一块android { namespace com.example.weather compileSdk 34 defaultConfig { applicationId com.example.weather minSdk 21 targetSdk 33 } }namespace是Android Studio 4.2之后新增的配置老工程里通常只有applicationId没有namespace这一行。如果不补上新版AGP会报“Namespace not specified”。compileSdk 34要求本机安装了API 34平台Android Studio会在提示后帮你下载targetSdk低于23时Android 6.0以上真机默认拒绝所有危险权限所以演示定位功能前一定要把targetSdk调到30以上否则权限对话框根本不会出现。我见过另一种诡异情况源码里gradle/wrapper/gradle-wrapper.properties指向Gradle 6.5而Android Studio自带的JDK是17一运行就报“Unsupported class file major version 61”。解决方式是打开File → Project Structure → SDK Location把JDK设为Android Studio内置的jbr版本或者单独安装JDK 17并指定给Gradle JVM两条路选一条就行。3.3 jcenter仓库失效与依赖拉不下来2024年必踩的毒坑2021年以后jcenter进入只读状态很多老项目的依赖同步会卡在“Could not resolve com.android.support:appcompat-v7:28.0.0”。打开根目录的build.gradle把repositories里的jcenter()整体替换buildscript { repositories { google() mavenCentral() } } allprojects { repositories { google() mavenCentral() } }替换后再次Sync基本都能正常拉包。顺带讲一个判断经验老依赖一般写成com.android.support开头的包名新工程统一用androidx。如果源码是support库且没有androidx迁移可以维持现状跑通演示因为迁移会改动大量import语句如果后续要新增功能建议先用Refactor → Migrate to AndroidX做一次自动迁移再继续写代码。报错现象真正原因最快解法Could not resolve com.android.supportjcenter仓库不可用换google与mavenCentralUnsupported class file major versionJDK版本与AGP不匹配使用Android Studio内置JDKNamespace not specifiedAGP 8.0要求显式声明在build.gradle补namespaceSDK location not found本机未配置SDK路径SDK Manager安装对应平台4. 核心功能实现与常见坑天气展示、JSON解析与刷新机制4.1 主界面布局CoordinatorLayout、NestedScrollView与RecyclerView的组合天气预报App的主界面通常是一屏多段结构顶部当前温度、中间逐小时预报、底部多日列表。源码里普遍用CoordinatorLayout作根布局AppBarLayout放标题栏内容区用NestedScrollView包裹一个纵向RecyclerView还会嵌一个横向滚动RecyclerView展示24小时温度变化。典型布局骨架如下androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto android:layout_widthmatch_parent android:layout_heightmatch_parent androidx.core.widget.NestedScrollView android:layout_widthmatch_parent android:layout_heightmatch_parent app:layout_behaviorstring/appbar_scrolling_view_behavior LinearLayout android:idid/container android:layout_widthmatch_parent android:layout_heightwrap_content android:orientationvertical androidx.recyclerview.widget.RecyclerView android:idid/rvHourly android:layout_widthmatch_parent android:layout_heightwrap_content android:orientationhorizontal / /LinearLayout /androidx.core.widget.NestedScrollView /androidx.coordinatorlayout.widget.CoordinatorLayoutCoordinatorLayout真正的价值在于behavior机制让AppBarLayout与NestedScrollView联动实现“向上滑动收起头部露出更多列表空间”的交互。NestedScrollView里的LinearLayout高度是wrap_content如果RecyclerView占满整个屏幕会导致滑动事件全部被NestedScrollView吞掉。这是源码里常见的“列表划不动”问题的根源。4.2 JSON字段映射与Adapter绑定不要照抄网上那种每帧findViewById接口返回的daily数组要解析成实体列表再交给ForecastAdapter显示。一个判断Adapter质量好坏的方法ViewHolder里findViewById是否只执行了一次。好的Adapter在onCreateViewHolder里创建Holder并完成控件查找onBindViewHolder只负责设置数据。public void onBindViewHolder(NonNull ViewHolder holder, int position) { DailyForecast item dataList.get(position); holder.mTvDate.setText(item.getDate()); holder.mTvTemp.setText(item.getTempMin() °C / item.getTempMax() °C); holder.mTvInfo.setText(item.getTextDay()); holder.mIvIcon.setImageResource( getResources().getIdentifier( ic_ item.getIconDay(), drawable, getPackageName())); }上面代码有个隐藏问题getIdentifier()每调用一次就做一次字符串匹配列表滑动时会反复执行轻微掉帧是常事。演示数据只有7天时感受不明显但被追问“这个还能怎么优化”时可以回答“把图标名映射到int资源ID的Map查询”得分能力立刻不一样。逐小时项也是同样的绑定套路不需要在bind里new对象频繁创建实例是GC触发卡顿的源头。和风天气新版接口返回的JSON字段名称比如temp、textDay、iconDay直接对应实体类的字段名Gson自动映射只要字段名一致即可。字段缺失时Gson不会抛异常而是把缺失字段置为null所以列表项里显示可能出现空字符串。JSON字段实体类字段页面展示fxDatefxDate日期tempMintempMin最低温度tempMaxtempMax最高温度textDaytextDay白天天气描述iconDayiconDay天气图标4.3 SwipeRefreshLayout与进度条刷新动画什么时候关、什么时候置灰下拉刷新逻辑写得粗糙的源码典型症状是断网后拉一下白色刷新圈转个不停。原因是没有在回调失败分支里调用setRefreshing(false)。正确姿势是请求开始时置true无论成功还是失败回到主线程后即刻置falsemSwipeRefreshLayout.setRefreshing(true); weatherModel.requestDaily(cityId, new CallbackDailyBean() { Override public void onSuccess(DailyBean data) { adapter.setData(data.getDaily()); mSwipeRefreshLayout.setRefreshing(false); } Override public void onError(Throwable t) { Toast.makeText(mContext, 更新失败请检查网络, Toast.LENGTH_SHORT).show(); mSwipeRefreshLayout.setRefreshing(false); } });还有一个细节刷新指示器出现在顶部如果外层根布局是LinearLayoutSwipeRefreshLayout应该成为第一个且唯一的子View。很多源码把RecyclerView写在SwipeRefreshLayout外面导致下拉动画根本不显示。另一个检查点不要在onRefresh里请求完之后立刻刷新整个Activity的onCreate流程直接调用adapter.notifyDataSetChanged()就好全量重建页面会让进度条动画和列表闪烁一起出现。5. 适配与避坑定位权限、FileProvider与新版本Android的硬性约束5.1 运行时定位权限不再只在Manifest里声明一句就够了老源码只在AndroidManifest里写一句ACCESS_FINE_LOCATION拿到Android 10以上真机运行时点击“定位”按钮毫无反应。原因是Android 6.0引入了运行时权限模型危险权限必须在运行时弹窗申请Android 11进一步把单次授权和精确位置剥离开来用户可选择“仅这一次”授权因此代码里要同时兼容两种返回状态。if (Build.VERSION.SDK_INT Build.VERSION_CODES.M) { if (checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) ! PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[]{ Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); return; } // 已授权直接继续初始化定位 startLocationUpdate(); }requestPermissions的第二个参数是请求码在onRequestPermissionsResult里判断时要用同一个常量。关键陷阱有两个一是用户第一次点拒绝后第二次弹窗不再出现只能在回调里检测shouldShowRequestPermissionRationale然后引导用户去系统设置里手动打开二是targetSdk低于23时权限弹窗不会出现导致某些老项目在旧模拟器上能定位、新手机上完全失效。答辩前一定要在真机上过一遍“首次启动→弹窗→拒绝→再次申请”的全过程。Android版本权限行为变化对天气App的影响6.0-9.0危险权限运行时弹窗定位必须动态申请10分区存储启动后台定位受限读写缓存路径变化11单次授权、应用可见性限制请求权限及打开系统设置方式变化12-13大致位置与精确位置分离用户可拒绝精确位置只给模糊定位5.2 FileProvider与content://分享天气卡片时绕不过的机制Android日志里出现的content://com.tencent.wework.fileprovider/...本质上都是Android 7.0后App通过FileProvider对外分享文件时生成的授权URI。毕设里的常见场景是做一个“分享今日天气”的功能把天气信息写入一张图片或文本再调用系统分享面板交给微信。如果继续用file://UriAndroid 7.0以上会立刻抛FileUriExposedException。配置FileProvider需要两步第一步在AndroidManifest.xml注册Providerprovider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /provider第二步在res/xml/file_paths.xml中限定可分享的路径范围。对天气App来说只暴露cache-path就足够不需要把整个外部存储开放出去。把authorities写成${applicationId}.fileprovider这种可替换变量比写死包名更稳妥因为多渠道打包时applicationId会变化。5.3 屏幕适配与状态栏写死的dp在刘海屏上会不会顶到摄像头老项目常见做法是给头部容器写死400dp高度放到刘海屏与长宽比更大的新机上温度文字被状态栏或挖孔区域遮挡。适配手段有两件状态栏文字颜色要跟随页面主题切换深色壁纸下状态栏时间电量都是白色时完全看不清底部预留导航条高度不然手势横条会压住多日列表的最后一个item。fitsSystemWindowstrue是一种快速方案让根布局自动避开系统栏但要注意它跟CoordinatorLayout同时使用时会产生inset消费冲突表现为顶部多出一块透明区域。更可控的做法是用ViewCompat.setOnApplyWindowInsetsListener手动读取SystemBars再往容器加padding。这段代码不复杂但能让工程的屏幕适配段落在答辩时显得明显更专业因为绝大多数同类毕设还在盯着dp改数值。6. 答辩前夜的快速验证Lint检查、签名打包与真机内存观察毕业设计真正拉开差距的不是功能数量而是“当着导师的面能不能顺利跑通三分钟”。把以下三个动作当作答辩前夜的固定流程每一步都能暴露源码里的隐藏问题。第一运行Android Studio自带代码分析。Build → Analyze → Inspect Code会扫描整个工程的隐患毕业论文关注两个条目Hardcoded Text提示所有界面文案是否写死在布局或代码里顺手把这些文字抽到strings.xmlUnused Resources删除没有引用的drawable和layoutAPK体积会小一圈。不用追求零警告但要能做到“打开的每一处提示都能说出为什么”。第二构建一次Release包尽管演示通常用Debug包Release包能提前暴露混淆和最小化问题./gradlew assembleRelease --no-daemon如果构建时报MissingTranslation在app/build.gradle的lintOptions里禁用即可android { lintOptions { disable MissingTranslation } }Release包生成后把APK安装到手机上试一遍确认proguard规则没有把Gson需要的字段混淆掉。遇到反序列化后字段全为null就在proguard-rules.pro里加一行-keep class com.example.weather.model.**{*;}。第三真机定位测试一定要到室外或窗边。GPS在室内无信号Home键默认城市会失去意义。当着导师的面点“定位”系统弹出位置授权接着温度在十秒内出现这个场景把运行时权限、HTTP请求、JSON解析和UI刷新四个核心能力一次性串演完毕。比对一下系统天气应用显示的温度值偏差只要在正常范围内就能淡化对数据来源准确性的追问。如果等待期间转圈超过十秒再回头查OkHttp的readTimeout和API Key是否过期这样技术弱点在答辩前就已经补掉。本文还有配套的精品资源点击获取 Android天气预报APP源码解析与改造指南
简介面向安卓学习者与毕业设计学生提供一款基于安卓的天气预报应用完整源码实现了城市列表选择、实时天气、温度星期展示以及未来六天预报等核心功能。项目界面左侧提供中国城市列表点击城市即可联动刷新对应区域的天气卡片交互逻辑完整。资源共二十四个文件压缩包大小五点零二兆字节包含界面布局文件、依赖库文件、图标图片、应用安装包及说明文档目录结构清晰便于直接导入开发环境进行编译与二次开发。当前已有一千五百九十七人学习下载适合作为本科毕业设计参考或安卓入门实战项目。通过研读源码可以快速掌握网络请求、数据解析、列表绑定、界面刷新等关键模块的实现思路配合可运行安装包与说明文档能够显著降低环境搭建和调试门槛帮助读者快速复现并改造出属于自己的天气应用。1. 打开这个zip你大概率正在做Android本科毕业设计或者接手一份别人已经写好的天气预报APP系统源码。天气预报项目在移动开发里之所以被反复拿出来当题目是因为它数据源公开、交互链路短、UI能做出很直观的展示效果一个天气主界面、一个多日列表、一个城市搜索框就能把Activity、网络请求、JSON解析、列表渲染、权限适配这些核心知识点全部覆盖。本文不做论文层面的格式讲评直接按工程实现顺序走先看整体架构和数据流再处理Gradle环境接着拆核心功能实现然后适配新设备上的定位权限与存储限制最后用Lint和打包验证代码质量。按这条路走完这份“系统源码.zip”就不再是解压后躺着的静态文件而是一套你能讲清楚、能改得动、敢拿上演示台的可用App。2. 天气APP源码的分层框架与数据流先看懂骨架再动手2.1 传统写法、MVP与MVVM毕业设计源码里最常见的三种结构拿到zip后第一件事不是急着点运行而是先浏览整个项目的包结构。多数本科毕设的Android工程会呈现三种组织方式传统写法把所有逻辑塞进ActivityMVP用接口把网络请求和界面回调拆开MVVM依赖ViewModel和LiveData做响应式驱动。怎么判断你手里的源码属于哪一种看根目录下是否存在model、presenter、viewmodel这些包名就行。结构风格目录特征回调方式调试难度答辩讲解价值传统写法只有activity和adapter匿名线程加HandlerUI与网络逻辑耦合查日志费劲较低MVP出现presenter/view/model三层接口回调每个页面需要维护两个以上接口高结构清晰MVVM出现viewmodel/repositoryLiveData、Flow链路长但可单元测试高贴近企业项目多数课程设计和毕设源码实际位于“MVP的简化版”网络层放在model里MainActivity实现View接口Presenter负责把两者接起来。以天气预报这份代码为例你会在model包里看到WeatherBean、WeatherRequest在ui包里看到MainActivity和ForecastAdapter。看到这种结构别急着改造成MVVM答辩时讲清楚MVP的单向数据流就够了用户点击刷新View把事件交给PresenterPresenter调用Model发起网络请求Model拿到数据回调PresenterPresenter最终刷新View。这个链路里最值得跟导师强调的一句话是“View不直接碰网络”。很多新手会把OkHttp写进Activity的onCreate里看似代码少但一旦页面旋转导致Activity重建请求就会被重复调用。MVP把网络层下沉以后Activity的职责只剩下渲染和转交用户事件这正是源码里分层的意义。2.2 从HTTP请求到UI刷新一次天气数据的完整链路天气预报应用的数据源通常分两类一类是免费天气API比如和风天气的devapi.qweather.com另一类是直接抓取公开网页再解析。毕业设计源码大多走免费API路线因为接口稳定、返回JSON结构清晰、文档齐全。拿到源码后先确认baseUrl指向哪个域名很多老项目写的是旧版和风天气地址free-api.heweather.net现在已经被新版接口替代不改就等着HTTP 401。典型请求代码是OkHttp发异步请求Gson解析JSON到实体类再通过RecyclerView的Adapter刷新列表OkHttpClient client new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(10, TimeUnit.SECONDS) .build(); Request request new Request.Builder() .url(https://devapi.qweather.com/v7/weather/now?location101010100key API_KEY) .get() .build(); client.newCall(request).enqueue(new Callback() { Override public void onFailure(Call call, IOException e) { // 注意这个回调在子线程不能在这里直接弹Toast } Override public void onResponse(Call call, Response response) throws IOException { if (response.isSuccessful()) { String body response.body().string(); WeatherNowBean bean new Gson().fromJson(body, WeatherNowBean.class); runOnUiThread(() - mTvTemperature.setText(bean.getNow().getTemp())); } } });这里面有两个参数值得记住connectTimeout和readTimeout都设置成10秒是为了避免弱网环境下界面长时间无响应enqueue是异步执行但onResponse并不保证回到主线程所以更新TextView前要包一层runOnUiThread否则新版本SDK会直接抛CalledFromWrongThreadException导致闪退。这个闪退也是老源码跑在今天的模拟器上最常见的崩溃点之一排查时先看日志有没有“Cant create handler inside thread”。顺便说一句如果源码里用的是HttpURLConnection而不是OkHttp不要觉得落后。对于单个天气接口来说原生方案足够演示等做到多接口、需要统一日志拦截时再替换成OkHttp也不迟别在答辩前夜做这种无意义的框架替换。2.3 城市切换与页面状态源码里最容易空指针的地方见过不少毕设源码在切换城市时崩溃根因不是网络而是异步回调还在路上、Activity已经销毁。典型场景是用户在主界面点击城市A马上又切到城市B第一次请求的响应返回后在onResponse里调用了finish后不再存在的控件于是空指针。更稳的做法是把当前城市ID存进SharedPreferences每次启动直接读存储值再配合onSaveInstanceState保存一份临时状态。源码里如果出现“切换城市后按返回就崩”第一步检查回调方法里有没有对View做空判断第二步检查Activity销毁时有没有把未完成的Call通过cancel()取消掉。记住一个原则网络请求要跟随页面生命周期。如果Timer轮询天气没有在onPause里停掉页面退到后台还在持续发请求内存、电量、流量三方面都会被导师点名。源码城堡里最耐看的不是功能花哨而是每个生命周期对应的资源回收很干净。3. 从zip到Android Studio导入工程与Gradle环境配置3.1 解压前先校验zip完整性别让文件损坏浪费一晚上很多同学拿到压缩包直接双击解压等到Android Studio报“Could not read signature”这类错误时才开始怀疑压缩包是否损坏浪费至少半小时。我通常先执行一次测试解压命令确认文件头和数据块都能正常读取再解压。# 在zip所在目录执行测试不实际解压 unzip -t weather_forecast_src.zip # 确认输出包含 No errors detected in compressed data 后再解压到指定目录 unzip weather_forecast_src.zip -d /Workspace/android/weather_project-t参数的作用是逐文件校验CRC校验值能在几秒内发现哪个文件数据损坏。解压目录也要讲究不要解压到桌面或带中文的路径比如“桌面/project/天气”Gradle的NDK与CMake插件对带空格和中文的路径支持一直不好路径解析错乱时会报一串难以理解的“task not found”。解压完成后立即检查根目录是否有settings.gradle、build.gradle和app子目录如果只是一堆散落的.java文件说明这个zip是手工导出的源码片段而非完整工程需要自己重建Android项目结构。3.2 compileSdk、targetSdk与Gradle版本老工程开箱必改的配置用当前版本Android Studio打开几年前写的工程最常见提示是“Minimum supported Gradle version is 8.4”或者“Android Gradle plugin requires Java 17”。这不是源码坏了而是构建工具链版本代沟。应对方式不是降级Android Studio而是把工程的Gradle插件和依赖版本提到当前环境兼容的档位。打开app/build.gradle重点关注这一块android { namespace com.example.weather compileSdk 34 defaultConfig { applicationId com.example.weather minSdk 21 targetSdk 33 } }namespace是Android Studio 4.2之后新增的配置老工程里通常只有applicationId没有namespace这一行。如果不补上新版AGP会报“Namespace not specified”。compileSdk 34要求本机安装了API 34平台Android Studio会在提示后帮你下载targetSdk低于23时Android 6.0以上真机默认拒绝所有危险权限所以演示定位功能前一定要把targetSdk调到30以上否则权限对话框根本不会出现。我见过另一种诡异情况源码里gradle/wrapper/gradle-wrapper.properties指向Gradle 6.5而Android Studio自带的JDK是17一运行就报“Unsupported class file major version 61”。解决方式是打开File → Project Structure → SDK Location把JDK设为Android Studio内置的jbr版本或者单独安装JDK 17并指定给Gradle JVM两条路选一条就行。3.3 jcenter仓库失效与依赖拉不下来2024年必踩的毒坑2021年以后jcenter进入只读状态很多老项目的依赖同步会卡在“Could not resolve com.android.support:appcompat-v7:28.0.0”。打开根目录的build.gradle把repositories里的jcenter()整体替换buildscript { repositories { google() mavenCentral() } } allprojects { repositories { google() mavenCentral() } }替换后再次Sync基本都能正常拉包。顺带讲一个判断经验老依赖一般写成com.android.support开头的包名新工程统一用androidx。如果源码是support库且没有androidx迁移可以维持现状跑通演示因为迁移会改动大量import语句如果后续要新增功能建议先用Refactor → Migrate to AndroidX做一次自动迁移再继续写代码。报错现象真正原因最快解法Could not resolve com.android.supportjcenter仓库不可用换google与mavenCentralUnsupported class file major versionJDK版本与AGP不匹配使用Android Studio内置JDKNamespace not specifiedAGP 8.0要求显式声明在build.gradle补namespaceSDK location not found本机未配置SDK路径SDK Manager安装对应平台4. 核心功能实现与常见坑天气展示、JSON解析与刷新机制4.1 主界面布局CoordinatorLayout、NestedScrollView与RecyclerView的组合天气预报App的主界面通常是一屏多段结构顶部当前温度、中间逐小时预报、底部多日列表。源码里普遍用CoordinatorLayout作根布局AppBarLayout放标题栏内容区用NestedScrollView包裹一个纵向RecyclerView还会嵌一个横向滚动RecyclerView展示24小时温度变化。典型布局骨架如下androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto android:layout_widthmatch_parent android:layout_heightmatch_parent androidx.core.widget.NestedScrollView android:layout_widthmatch_parent android:layout_heightmatch_parent app:layout_behaviorstring/appbar_scrolling_view_behavior LinearLayout android:idid/container android:layout_widthmatch_parent android:layout_heightwrap_content android:orientationvertical androidx.recyclerview.widget.RecyclerView android:idid/rvHourly android:layout_widthmatch_parent android:layout_heightwrap_content android:orientationhorizontal / /LinearLayout /androidx.core.widget.NestedScrollView /androidx.coordinatorlayout.widget.CoordinatorLayoutCoordinatorLayout真正的价值在于behavior机制让AppBarLayout与NestedScrollView联动实现“向上滑动收起头部露出更多列表空间”的交互。NestedScrollView里的LinearLayout高度是wrap_content如果RecyclerView占满整个屏幕会导致滑动事件全部被NestedScrollView吞掉。这是源码里常见的“列表划不动”问题的根源。4.2 JSON字段映射与Adapter绑定不要照抄网上那种每帧findViewById接口返回的daily数组要解析成实体列表再交给ForecastAdapter显示。一个判断Adapter质量好坏的方法ViewHolder里findViewById是否只执行了一次。好的Adapter在onCreateViewHolder里创建Holder并完成控件查找onBindViewHolder只负责设置数据。public void onBindViewHolder(NonNull ViewHolder holder, int position) { DailyForecast item dataList.get(position); holder.mTvDate.setText(item.getDate()); holder.mTvTemp.setText(item.getTempMin() °C / item.getTempMax() °C); holder.mTvInfo.setText(item.getTextDay()); holder.mIvIcon.setImageResource( getResources().getIdentifier( ic_ item.getIconDay(), drawable, getPackageName())); }上面代码有个隐藏问题getIdentifier()每调用一次就做一次字符串匹配列表滑动时会反复执行轻微掉帧是常事。演示数据只有7天时感受不明显但被追问“这个还能怎么优化”时可以回答“把图标名映射到int资源ID的Map查询”得分能力立刻不一样。逐小时项也是同样的绑定套路不需要在bind里new对象频繁创建实例是GC触发卡顿的源头。和风天气新版接口返回的JSON字段名称比如temp、textDay、iconDay直接对应实体类的字段名Gson自动映射只要字段名一致即可。字段缺失时Gson不会抛异常而是把缺失字段置为null所以列表项里显示可能出现空字符串。JSON字段实体类字段页面展示fxDatefxDate日期tempMintempMin最低温度tempMaxtempMax最高温度textDaytextDay白天天气描述iconDayiconDay天气图标4.3 SwipeRefreshLayout与进度条刷新动画什么时候关、什么时候置灰下拉刷新逻辑写得粗糙的源码典型症状是断网后拉一下白色刷新圈转个不停。原因是没有在回调失败分支里调用setRefreshing(false)。正确姿势是请求开始时置true无论成功还是失败回到主线程后即刻置falsemSwipeRefreshLayout.setRefreshing(true); weatherModel.requestDaily(cityId, new CallbackDailyBean() { Override public void onSuccess(DailyBean data) { adapter.setData(data.getDaily()); mSwipeRefreshLayout.setRefreshing(false); } Override public void onError(Throwable t) { Toast.makeText(mContext, 更新失败请检查网络, Toast.LENGTH_SHORT).show(); mSwipeRefreshLayout.setRefreshing(false); } });还有一个细节刷新指示器出现在顶部如果外层根布局是LinearLayoutSwipeRefreshLayout应该成为第一个且唯一的子View。很多源码把RecyclerView写在SwipeRefreshLayout外面导致下拉动画根本不显示。另一个检查点不要在onRefresh里请求完之后立刻刷新整个Activity的onCreate流程直接调用adapter.notifyDataSetChanged()就好全量重建页面会让进度条动画和列表闪烁一起出现。5. 适配与避坑定位权限、FileProvider与新版本Android的硬性约束5.1 运行时定位权限不再只在Manifest里声明一句就够了老源码只在AndroidManifest里写一句ACCESS_FINE_LOCATION拿到Android 10以上真机运行时点击“定位”按钮毫无反应。原因是Android 6.0引入了运行时权限模型危险权限必须在运行时弹窗申请Android 11进一步把单次授权和精确位置剥离开来用户可选择“仅这一次”授权因此代码里要同时兼容两种返回状态。if (Build.VERSION.SDK_INT Build.VERSION_CODES.M) { if (checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) ! PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[]{ Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); return; } // 已授权直接继续初始化定位 startLocationUpdate(); }requestPermissions的第二个参数是请求码在onRequestPermissionsResult里判断时要用同一个常量。关键陷阱有两个一是用户第一次点拒绝后第二次弹窗不再出现只能在回调里检测shouldShowRequestPermissionRationale然后引导用户去系统设置里手动打开二是targetSdk低于23时权限弹窗不会出现导致某些老项目在旧模拟器上能定位、新手机上完全失效。答辩前一定要在真机上过一遍“首次启动→弹窗→拒绝→再次申请”的全过程。Android版本权限行为变化对天气App的影响6.0-9.0危险权限运行时弹窗定位必须动态申请10分区存储启动后台定位受限读写缓存路径变化11单次授权、应用可见性限制请求权限及打开系统设置方式变化12-13大致位置与精确位置分离用户可拒绝精确位置只给模糊定位5.2 FileProvider与content://分享天气卡片时绕不过的机制Android日志里出现的content://com.tencent.wework.fileprovider/...本质上都是Android 7.0后App通过FileProvider对外分享文件时生成的授权URI。毕设里的常见场景是做一个“分享今日天气”的功能把天气信息写入一张图片或文本再调用系统分享面板交给微信。如果继续用file://UriAndroid 7.0以上会立刻抛FileUriExposedException。配置FileProvider需要两步第一步在AndroidManifest.xml注册Providerprovider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /provider第二步在res/xml/file_paths.xml中限定可分享的路径范围。对天气App来说只暴露cache-path就足够不需要把整个外部存储开放出去。把authorities写成${applicationId}.fileprovider这种可替换变量比写死包名更稳妥因为多渠道打包时applicationId会变化。5.3 屏幕适配与状态栏写死的dp在刘海屏上会不会顶到摄像头老项目常见做法是给头部容器写死400dp高度放到刘海屏与长宽比更大的新机上温度文字被状态栏或挖孔区域遮挡。适配手段有两件状态栏文字颜色要跟随页面主题切换深色壁纸下状态栏时间电量都是白色时完全看不清底部预留导航条高度不然手势横条会压住多日列表的最后一个item。fitsSystemWindowstrue是一种快速方案让根布局自动避开系统栏但要注意它跟CoordinatorLayout同时使用时会产生inset消费冲突表现为顶部多出一块透明区域。更可控的做法是用ViewCompat.setOnApplyWindowInsetsListener手动读取SystemBars再往容器加padding。这段代码不复杂但能让工程的屏幕适配段落在答辩时显得明显更专业因为绝大多数同类毕设还在盯着dp改数值。6. 答辩前夜的快速验证Lint检查、签名打包与真机内存观察毕业设计真正拉开差距的不是功能数量而是“当着导师的面能不能顺利跑通三分钟”。把以下三个动作当作答辩前夜的固定流程每一步都能暴露源码里的隐藏问题。第一运行Android Studio自带代码分析。Build → Analyze → Inspect Code会扫描整个工程的隐患毕业论文关注两个条目Hardcoded Text提示所有界面文案是否写死在布局或代码里顺手把这些文字抽到strings.xmlUnused Resources删除没有引用的drawable和layoutAPK体积会小一圈。不用追求零警告但要能做到“打开的每一处提示都能说出为什么”。第二构建一次Release包尽管演示通常用Debug包Release包能提前暴露混淆和最小化问题./gradlew assembleRelease --no-daemon如果构建时报MissingTranslation在app/build.gradle的lintOptions里禁用即可android { lintOptions { disable MissingTranslation } }Release包生成后把APK安装到手机上试一遍确认proguard规则没有把Gson需要的字段混淆掉。遇到反序列化后字段全为null就在proguard-rules.pro里加一行-keep class com.example.weather.model.**{*;}。第三真机定位测试一定要到室外或窗边。GPS在室内无信号Home键默认城市会失去意义。当着导师的面点“定位”系统弹出位置授权接着温度在十秒内出现这个场景把运行时权限、HTTP请求、JSON解析和UI刷新四个核心能力一次性串演完毕。比对一下系统天气应用显示的温度值偏差只要在正常范围内就能淡化对数据来源准确性的追问。如果等待期间转圈超过十秒再回头查OkHttp的readTimeout和API Key是否过期这样技术弱点在答辩前就已经补掉。本文还有配套的精品资源点击获取