第一行代码
第一行代码
如何学习四大组件
理解四大组件
- Activity: 了解Activity的生命周期,学习如何在不同的状态下处理用户交互。
- Service: 学习Service的使用场景,了解如何在后台执行长时间运行的操作。
- BroadcastReceiver: 理解如何接收和处理系统或应用程序发送的广播消息。
- ContentProvider: 学习如何使用ContentProvider来共享应用的数据。
常见问题及解决方案
- 理解生命周期: 初学者常常对Activity和Service的生命周期感到困惑。可以通过绘制生命周期图表来帮助记忆,并在代码中添加日志输出,观察状态变化。
- 数据传递问题: 在使用Intent传递数据时,可能会遇到数据丢失或类型不匹配的问题。确保在Intent中使用正确的键值对,并在接收端进行类型检查。
- 调试困难: 初学者在调试时可能不知从何入手。学会使用Android Studio的调试工具,设置断点,逐步跟踪代码执行,帮助定位问题。
- 权限管理: 使用BroadcastReceiver和ContentProvider时,可能会遇到权限问题。确保在AndroidManifest.xml中正确声明权限,并在运行时请求必要的权限。
如何管理四大组件的生命周期
1. Activity
生命周期方法:
- onCreate(): 创建Activity时调用,通常在此方法中初始化UI组件和数据。
- onStart(): Activity即将对用户可见时调用。
- onResume(): Activity对用户可见并可以交互时调用。
- onPause(): 当前Activity被其他Activity覆盖时调用,通常在此方法中保存数据或停止动画。
- onStop(): Activity不再对用户可见时调用。
- onDestroy(): Activity被销毁时调用,清理资源。
管理建议:
- 在
onCreate()
中加载布局和初始化资源,避免在onResume()
中执行耗时操作。 - 在
onPause()
中保存用户数据,确保在Activity被覆盖时不会丢失数据。 - 使用
onStop()
释放不再需要的资源,防止内存泄漏。
2. Service
生命周期方法:
- onCreate(): 创建Service时调用,通常用于初始化。
- onStartCommand(): Service被启动时调用,处理启动请求。
- onBind(): 当其他组件绑定到Service时调用。
- onUnbind(): 当所有客户端都解除绑定时调用。
- onDestroy(): Service被销毁时调用,清理资源。
管理建议:
- 在
onStartCommand()
中处理后台任务,确保Service在后台运行时不阻塞主线程。 - 在
onDestroy()
中停止任何正在运行的任务,释放资源,避免内存泄漏。
3. BroadcastReceiver
生命周期方法:
- onReceive(): 当接收到广播时调用。
管理建议:
- BroadcastReceiver的生命周期较短,通常在
onReceive()
中执行轻量级任务。 - 在
onReceive()
中避免执行耗时操作,建议使用Service或AsyncTask来处理复杂任务。
4. ContentProvider
生命周期方法:
- onCreate(): 创建ContentProvider时调用,通常用于初始化数据库或其他资源。
管理建议:
- 在
onCreate()
中初始化数据库连接,确保在访问数据时能够快速响应。 - 确保在ContentProvider中处理数据的安全性和隐私,避免未授权访问。
Activity
Activity的生命周期及其各个状态。
1 |
|
Intent的使用
学会使用Intent在Activity之间传递数据。
1 | // 从当前Activity启动另一个Activity |
特征 | 显式 Intent | 隐式 Intent |
---|---|---|
定义 | 明确指定目标组件的 Intent | 不明确指定目标组件的 Intent |
使用场景 | 一般用于应用内部组件之间的通信 | 用于跨应用程序的组件交互 |
组件指定方式 | 通过组件名或类名直接指定 | 通过 Action、Data 和 Category 来匹配 |
示例代码 | Intent intent = new Intent(this, SecondActivity.class); |
Intent intent = new Intent(Intent.ACTION_VIEW); |
适用性 | 适用于已知目标组件的情况 | 适用于不确定目标组件的情况 |
过滤器 | 不需要 Intent 过滤器 | 需要 Intent 过滤器来匹配组件 |
显式 Intent 直接指定了要启动的组件,适合于应用内部的操作,而隐式 Intent 则依赖于系统根据 Intent 的内容查找合适的组件,适合于跨应用的功能调用
例子: 比如说你的应用程序中需要展示一个网页,这时你没有必要自己去实现一个浏览器(事实上也不太可能),而是只需要调用系统的浏览器来打开这个网页就行了。
1 | button1.setOnClickListener(new View.OnClickListener() { |
数据保存与恢复
1 |
|
Activity启动模式
1. Standard模式(默认)
每次启动Activity时,都会创建一个新的实例,并将其压入启动它的Activity所在的任务栈中。
一个任务栈中可以有多个相同的Activity实例。
不同的任务栈中也可以有相同的Activity实例。
应用场景: 大多数Activity都使用这种模式,每次启动都会创建新实例,适用于没有特殊需求的普通Activity。
示例: 电子邮件应用中的收件箱和邮件详情页面。
2. SingleTop模式
如果新Activity已经位于任务栈的栈顶,就不再创建新实例,而是复用栈顶的实例。
如果不在栈顶,则创建新实例并压入栈中。
应用场景: 当Activity已经位于任务栈栈顶时,不需要重复创建,可以复用栈顶实例。适用于不需要在任务栈中存在多个实例的Activity。
示例: 浏览器应用中的新标签页,如果已经存在就不需要重复创建。
3. SingleTask模式
系统会先查看任务栈中是否已经存在该Activity的实例。
如果存在,就将该实例之上的所有Activity出栈,并调用该实例的onNewIntent()方法。
如果不存在,则创建新实例并压入栈中。
应用场景: 应用中的主要入口Activity,每次启动都会将目标Activity之上的所有Activity出栈,确保任务栈中只有一个该Activity实例。适用于作为应用入口的Activity。
示例: 地图应用的主界面Activity,每次打开地图都会回到这个Activity。
4. SingleInstance模式
每次启动该Activity时,系统都会为其创建一个新的任务栈。
以后任何应用程序启动该Activity,都会在这个独立的任务栈中运行。
这个任务栈只有这一个Activity实例。
应用场景: 需要独立于应用单独存在的Activity,会启动一个新的任务栈。适用于需要独立运行的Activity。
示例: 电话应用的拨号盘Activity,需要独立于应用单独存在。
任务栈
任务栈(Task)是一组存放Activity实例的容器,它采用后进先出的栈结构。
- 当启动一个应用时,系统会为其创建一个默认的任务栈。
- 每次启动一个新的Activity,都会将其压入当前任务栈的栈顶。
- 按返回键时,会将栈顶的Activity出栈,显示下一个Activity。
- 当任务栈中所有Activity都出栈后,任务栈也就被销毁了。
Intent Flag
Intent中还有一些Flag可以用来控制Activity的启动行为:
- FLAG_ACTIVITY_NEW_TASK: 相当于singleTask模式,会创建新任务栈。
- FLAG_ACTIVITY_CLEAR_TOP: 会将目标Activity之上的Activity全部出栈。
- FLAG_ACTIVITY_SINGLE_TOP: 相当于singleTop模式,如果目标Activity在栈顶,就不创建新实例。
1 | <activity |
权限管理
在Activity中请求和管理权限。
1 | if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_EXTERNAL_STORAGE) |
Service
Service 基础知识
- 什么是Android Service?Service是Android中的一种组件,用于在后台执行长时间运行的操作。
- Service的生命周期是什么?Service的生命周期包括
onCreate()
、onStartCommand()
、onBind()
、onUnbind()
和onDestroy()
。 - Service与Activity的区别是什么?Activity是用户界面组件,而Service是用于后台处理的组件,不提供用户界面。
- 如何启动一个Service?使用
startService(Intent intent)
方法来启动Service。
Use thestartService(Intent intent)
method to start the Service. - Service的返回值是什么?
onStartCommand()
方法返回一个整数,指示系统如何处理Service的重启。
Service 类型
- 什么是前台Service?前台Service在运行时会显示一个通知,表示它正在执行重要任务,系统不会轻易终止它。
- 什么是后台Service?后台Service在用户不再与应用交互时运行,可能会被系统终止以释放资源。
- 什么是绑定Service?绑定Service允许组件(如Activity)与Service进行交互,使用
bindService()
方法。 - Service的IntentService是什么?IntentService是一个特殊类型的Service,处理异步请求并在完成后自动停止。
Service 进阶知识
- 如何在Service中执行耗时操作?使用子线程(如
HandlerThread
或AsyncTask
)来避免阻塞主线程。 - Service如何与BroadcastReceiver交互?Service可以通过广播接收器接收和发送广播消息。
- Service如何处理配置更改?Service不会被配置更改(如屏幕旋转)影响,但需要注意数据的持久化。
- 如何在Service中使用Handler?使用Handler在Service中处理消息和任务调度。
- 如何停止一个Service?使用
stopService(Intent intent)
或在onStartCommand()
中调用stopSelf()
。
Service 性能与优化
- 如何优化Service的性能?避免在Service中执行长时间的操作,使用前台Service来提高优先级。
- Service与JobScheduler的关系是什么?JobScheduler用于调度任务,而Service用于执行任务,JobScheduler可以在合适的条件下启动Service。
- 如何处理Service中的内存泄漏?确保在不需要时停止Service,避免持有Activity的引用。
Service 安全与权限
- Service如何处理多进程?使用
android:process
属性在Manifest中定义Service的进程。 - 如何保护Service不被外部访问?在Manifest中使用
android:permission
属性限制访问权限。 - 如何在Service中使用权限?在Service中检查和请求必要的权限,以确保安全性。
Service的使用场景有哪些?
后台音乐播放
Service可以用于音乐播放器应用,当用户切换到其他应用或锁屏时,音乐仍然可以继续播放。
网络请求
在进行网络请求时,可以将请求逻辑放在Service中执行,以避免阻塞主线程,确保用户界面的流畅性。
后台定位服务
应用需要持续获取用户位置信息时,可以使用Service来实现定位功能,即使应用在后台运行或被关闭。
文件下载
Service可以用来在后台下载文件,即使用户退出应用或锁屏,下载任务仍然可以继续进行。
数据同步
应用需要定期从服务器获取数据或上传数据时,可以通过Service实现数据的同步。
推送服务
Service可以处理推送消息,接收并处理来自服务器的通知或消息。
后台数据更新
应用如新闻、天气等需要在后台更新数据时,可以使用Service进行数据的定期更新。
定时任务
Service可以用于执行定时任务,例如定期检查更新或执行某些后台操作。
长时间运行的计算任务
在需要执行复杂计算或处理大量数据时,可以使用Service来进行这些耗时操作,而不会影响用户界面。
其他后台任务
任何需要在后台执行的长时间任务,如数据处理、文件处理等,都可以通过Service来实现。
使用Service时,开发者需要注意避免在主线程中执行耗时操作,以防止应用出现无响应(ANR)问题。可以通过使用子线程或其他异步处理方式来优化性能
Service的生命周期如何管理?
了解Service的生命周期方法
onCreate()
:Service被创建时调用,在这里进行初始化操作。onStartCommand()
:通过startService()
启动Service时调用。onBind()
:通过bindService()
绑定Service时调用。onUnbind()
:所有绑定都被取消时调用。onDestroy()
:Service被销毁时调用。
合理启动和停止Service
- 使用
startService()
启动长时间运行的任务。 - 在不需要时及时停止Service,避免资源泄露。可以在
onStartCommand()
中返回START_NOT_STICKY
或调用stopSelf()
。
处理绑定Service的生命周期
- 在
onBind()
返回一个Binder
对象,允许客户端与Service交互。 - 在
onUnbind()
中执行清理工作。 - 当所有绑定都取消时,Service可能会被销毁。
避免在主线程执行耗时操作
- 在Service中使用子线程执行耗时操作,如使用
HandlerThread
或AsyncTask
。 - 在子线程中执行完任务后,可以通过
NotificationManager
发送通知。
合理管理Service的优先级
- 使用前台Service可以提高优先级,避免被系统杀死。
- 在
onStartCommand()
中返回START_STICKY
可以让Service在被杀死后自动重启。
在Application中管理全局状态
- 将应用的全局状态保存在
Application
对象中,便于各组件访问。 - 在
Application
的生命周期方法中进行初始化和清理工作。
使用JobScheduler管理任务
JobScheduler
可以调度任务,并在合适的时机启动Service执行任务。- 使用
JobScheduler
可以更好地控制任务的执行时机和条件。
Service和Activtiy的通信方法又哪些?
Intent传递数据
使用startService(Intent intent)
或bindService(Intent intent, ServiceConnection conn, int flags)
时,可以通过Intent传递数据。可以使用putExtra()
方法将数据放入Intent中,Service可以通过getIntent().getExtras()
获取这些数据。
1 | java// 在Activity中 |
Messenger
使用Messenger进行双向通信。Activity可以通过Messenger发送Message对象到Service,Service可以通过Handler处理这些消息并回复。
1 | java// 在Activity中 |
BroadcastReceiver
Activity可以注册一个BroadcastReceiver来接收Service发送的广播。Service通过sendBroadcast(Intent intent)
发送广播,Activity通过onReceive()
方法接收。
1 | java// 在Service中 |
Bound Service
使用绑定Service时,Activity可以直接调用Service中的公共方法。通过onServiceConnected()
方法获取Service的Binder,Activity可以通过Binder调用Service的方法。
1 | java// 在Service中 |
EventBus
使用第三方库如EventBus,可以简化Activity与Service之间的通信。通过发布和订阅事件来实现数据传递。
如何分析ANR问题
分析 ANR(应用无响应)相关的堆栈轨迹是解决应用性能问题的重要步骤。以下是分析 ANR 堆栈轨迹的具体方法和步骤:
1. 理解 ANR 的基本概念
ANR 发生在应用的主线程被阻塞超过一定时间(通常是 5 秒),系统会弹出对话框提示用户。ANR 的类型包括输入事件超时、广播超时、服务超时等。
2. 收集 ANR 日志
在 ANR 发生时,系统会生成相关的日志信息,包括 traces.txt
文件和 logcat
日志。使用 adb bugreport
命令可以获取完整的错误报告,其中包含 ANR 的详细信息。
3. 分析 traces.txt
获取 traces.txt
ANR 发生时,系统会在 /data/anr/
目录下生成 traces.txt
文件。可以通过以下命令获取:
1 | adb pull /data/anr/traces.tx |
traces.txt
文件记录了发生 ANR 时各线程的状态。分析步骤如下:
- 查找时间戳和 PID:确保查看的堆栈轨迹与 ANR 发生时的时间戳和进程 ID 匹配。
- 检查主线程堆栈:主线程的堆栈可以告诉你在 ANR 发生时它正在执行什么操作。注意,主线程的堆栈可能并不总是导致 ANR 的真正原因,其他线程的状态也可能影响主线程的执行。
- 识别死锁:如果多个线程相互等待,可能导致死锁,从而引发 ANR。检查堆栈中是否有线程 A 等待线程 B 的资源,同时线程 B 也在等待线程 A 的资源。
4. 使用关键字过滤
在 logcat
日志中,搜索关键字如 ANR in
、Input event dispatching timed out
等,以快速定位 ANR 的类型和原因。
在分析 ANR 日志时,以下关键字尤为重要:
- ANR in:指示哪个应用发生了 ANR。
- Input dispatching timed out:表明输入事件未能及时处理。
- Broadcast:与广播相关的 ANR。
- Service:与服务相关的 ANR。
- **
Timeout executing service
**:表示某个操作超时导致的 ANR。
通过搜索这些关键字,可以快速定位 ANR 发生的原因和上下文
5. 检查 CPU 和内存使用情况
使用以下命令获取系统和应用的 CPU 使用情况:
1 | adb shell top |
通过观察 CPU 使用情况,可以判断 ANR 的原因是否与 CPU 资源紧张有关。关注以下几点:
- CPU 使用率:查看应用的 CPU 使用率是否异常高。
- IO Wait:如果 IO 等待时间过长,可能导致 ANR。
- 进程 CPU 分布:分析各个进程的 CPU 占比,找出占用资源过高的进程。
通过这些信息,可以进一步分析是应用本身的问题,还是由于系统资源不足导致的 ANR
6. 还原场景
通过分析日志和堆栈轨迹,尽量还原 ANR 发生时的场景,考虑用户操作、网络请求、数据库访问等因素,帮助找到问题的根源。
7. 代码审查
根据堆栈信息,查看相关代码,找出可能导致 ANR 的逻辑问题,如长时间的 IO 操作、未释放的锁等。
8. 使用工具
可以使用一些分析工具(如 Android Profiler、StrictMode)来监控应用的性能,帮助识别潜在的 ANR 问题。
9.使用 Logcat 分析 ANR 问题
获取 Logcat 日志
使用以下命令获取 Logcat 日志:
1 | adb logcat -b all -v time > anr_test.log |
-b all
:抓取所有类型的日志。-v time
:在日志中加入每条日志的时间戳。
在应用发生 ANR 后,使用 Ctrl+C
停止日志抓取。这条命令会抓取所有类型的日志,并将其输出到 anr_test.log
文件中。
过滤 ANR 相关日志
关键字过滤
在 anr_test.log
文件中,使用文本编辑器或命令行工具(如 grep
)搜索以下关键字:
am_anr:用于查找 ANR 事件的日志条目。
示例:
1
am_anr
ANR in:指示具体哪个应用发生了 ANR,后面通常会跟着应用包名和原因。
示例:
1
ANR in
Input dispatching timed out:表示输入事件处理超时。
示例:
1
Input dispatching timed out
Broadcast:与广播相关的 ANR。
示例:
1
Broadcast
Service:与服务相关的 ANR。
示例:
1
Service
通过这些关键字,可以快速定位 ANR 发生的具体时间、包名和原因。
分析 ANR 日志
解析 am_anr 日志
找到的 am_anr
日志条目通常包含以下信息:
- 时间戳:ANR 发生的具体时间。
- 进程 ID:发生 ANR 的进程 ID。
- 包名:发生 ANR 的应用包名。
- 原因:ANR 的具体原因描述。
例如:
1 | 11-02 11:32:16.915 I/am_anr ( 1753): [0,23694,com.example.app,820559686,Input dispatching timed out...] |
解析 ANR 原因
根据 ANR 原因的描述,可以进一步分析是由于主线程被阻塞、长时间的 IO 操作、死锁等引起的。
使用工具辅助分析
可以使用文本处理工具(如 grep
、awk
等)来快速筛选和分析日志。例如,使用 grep
命令:
1 | bash |
这将返回所有包含 “ANR in” 的日志条目,便于快速定位问题。通过以上步骤,可以有效地在 Logcat 中过滤和分析 ANR 相关日志,从而帮助开发者快速定位和解决应用无响应的问题。
10.如何在Logcat中过滤ANR事件的进程ID
启动 Logcat
首先,确保你的设备已连接并使用以下命令启动 Logcat:
1 | bash |
这条命令将所有日志输出到 anr_test.log
文件中。
过滤 ANR 相关日志
关键字过滤
在 anr_test.log
文件中,你可以使用以下关键字来查找 ANR 事件:
am_anr:用于查找 ANR 事件的日志条目。
示例:
1
2bash
grep "am_anr" anr_test.logANR in:指示具体哪个应用发生了 ANR,后面通常会跟着应用包名和进程 ID。
示例:
1
2bash
grep "ANR in" anr_test.log
解析 am_anr 日志
通过搜索 am_anr
关键字,你将看到类似以下格式的日志:
1 | 10-16 00:48:27 820 907 I am_anr: [0,29533,com.android.systemui,1082670605,Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50000114 (has extras) }] |
在这个日志中,关键字段如下:
- 29533:这是发生 ANR 的进程 ID。
- com.android.systemui:这是发生 ANR 的应用包名。
- Broadcast of Intent:这是导致 ANR 的原因描述。
分析进程 ID
一旦获取到 ANR 事件的进程 ID,你可以进一步分析该进程在 ANR 发生时的状态。可以使用以下命令查看该进程的详细信息:
1 | adb shell dumpsys activity | grep 29533 |
将 29533
替换为你从 ANR 日志中获取的进程 ID。这将帮助你了解该进程的状态和资源使用情况。
11.Logcat和bugreport两者之间有什么区别和关联吗
Logcat和bugreport之间确实存在一些区别和关联:
区别
- Logcat是一个实时的日志系统,用于在设备上捕获各种系统和应用程序的日志信息。它提供了一个持续的日志流,开发者可以实时查看和分析。
- Bugreport是一个包含设备状态快照的压缩文件,其中包括Logcat日志、系统服务转储、电池统计信息等。它是在特定时间点捕获的一次性诊断数据。
关联
- Bugreport内部包含了Logcat日志的转储。当你生成一个bugreport时,它会包括从系统的main、events、radio、system等Logcat缓冲区导出的日志内容。
- Logcat日志是分析bugreport的重要组成部分。当你收到一个bugreport时,可以搜索Logcat日志中的关键字,比如”ANR”、”crash”等,来定位问题。
- Bugreport通常在应用崩溃或设备出现问题时生成,用于帮助开发者分析问题。而Logcat日志则是持续记录设备状态的重要工具,可以用于实时监控和调试。
- Bugreport包含的信息比Logcat更加全面和详细,包括了电池使用情况、进程信息、网络统计等。但Logcat提供了更实时的日志流,便于开发者在问题发生时快速定位。
综上所述,Logcat和bugreport是Android调试中密切相关的两个工具。Logcat提供了实时的日志流,而bugreport则在特定时间点捕获了设备的全面诊断信息,两者相辅相成,共同帮助开发者分析和解决问题。
学习过程中的问题及解决
方法论
主动学习: 靠内驱力不是总是会有的,有的时候需要push一下自己
心态: 不畏惧困难
询问同事:自己可以先思考一下,然后去询问同事
Google:搜索技巧(Jpg pdf)
AI(Kimi, XiaoMi插件,Perplextiy.ai):给出解决问题的思路和方案,节省时间,开拓新思路
如何解bug, 查看报错日志:
主动寻找资源,学会站在巨人的肩膀上,平总写的ANR问题就非常的好
为什么要解决问题?
创造个人价值最直接的方式
理解不透彻,代码无法运行
仔细对比书中代码,检查是否有遗漏或错误
查看报错信息,根据提示定位问题所在,可以Debug断点看看数据流转
网上搜索相关问题,看看有没有类似的解决方案
利用AI给出解决问题的方法
学习进度缓慢,动力不足
制定一个合理的学习计划, 每天坚持一点点
给自己设置一些小目标,完成后给自己一些奖励(比如要开分享会了,明白了具体要做的是哪些事情,此时就有了行动力)
和同事或朋友交流,互相鼓励
Android开发中哪些技术是必须掌握的
在Android开发中,有一些核心技术是每个开发者必须掌握的。以下是这些技术的概述:
- Java/Kotlin: Android应用主要使用Java和Kotlin语言进行开发,掌握这两种语言的基本语法、面向对象编程思想和常用库是基础。
- Android SDK: Android软件开发工具包(SDK)是开发Android应用所必需的工具集,包含了开发、调试和测试应用的工具。
- Android Studio: 作为官方推荐的开发环境,熟悉Android Studio的使用,包括项目管理、调试和构建工具,是开发高效应用的关键。
- XML: XML用于定义应用的用户界面(UI)和布局,开发者需要掌握XML的基本语法和结构。
- Android组件: 理解Android的四大组件:Activity、Service、BroadcastReceiver和ContentProvider,以及它们的生命周期和交互方式。
- 布局管理: 掌握不同的布局方式(如LinearLayout、RelativeLayout、ConstraintLayout等),以适应不同屏幕尺寸和分辨率。
- SQLite数据库: Android内置SQLite数据库,开发者需要了解如何使用SQL进行数据存储和管理。
- 多线程和异步处理: 理解如何使用Handler、AsyncTask、Executor等处理多线程和异步任务,以提高应用的响应性。
- 网络请求: 掌握如何使用Retrofit、OkHttp等库进行网络请求和数据解析。
- 依赖注入: 学习使用Dagger或Hilt等依赖注入框架,以提高代码的可维护性和可测试性。
- UI设计和自定义View: 理解Material Design原则,能够创建美观且用户友好的界面,掌握自定义View的实现。
- 性能优化: 学习如何优化应用性能,包括内存管理、布局优化和线程管理,以提升用户体验。
- 测试: 掌握单元测试和UI测试的基本知识,使用JUnit和Espresso等工具进行测试。
- 版本控制: 熟悉Git等版本控制工具,以便于团队协作和代码管理。
- Gradle构建系统: 理解Gradle的构建流程和配置,以便于管理项目依赖和构建过程。
- 安全性: 学习Android应用的安全性最佳实践,包括数据加密和安全存储。
- 应用发布: 理解如何将应用打包并发布到Google Play商店,包括签名和版本管理。
- 跨平台开发: 了解Flutter或React Native等跨平台开发框架,以扩展开发技能。
- 开源库的使用: 熟悉常用的开源库,如Glide、Picasso(图片加载)、RxJava(响应式编程)等,以提高开发效率。
- 持续集成/持续部署(CI/CD): 学习如何使用Jenkins、GitHub Actions等工具实现自动化构建和部署流程。
分享
Activity的四种启动模式对比
启动模式 | 特点 | 适用场景 |
---|---|---|
standard | 每次启动都会创建新的实例 | 独立的、无状态的Activity |
singleTop | 如果任务栈栈顶已经是该Activity,不会创建新实例 | 需要频繁启动的Activity |
singleTask | 如果任务栈已经存在该Activity实例,会把它上面的全部出栈 | 独立的、可重用的根Activity |
singleInstance | 会单独启动一个新的任务栈,且只有该Activity实例 | 需要与其他应用共享的Activity |
Service的启动方式对比
启动方式 | 特点 | 适用场景 |
---|---|---|
startService | 通过组件名启动Service,Service的生命周期独立于启动它的组件。即使启动的Activity被销毁,Service仍然在后台运行。 | 适用于需要长时间运行的任务,例如下载或上传文件。 |
bindService | 通过接口绑定Service,Service的生命周期依赖于绑定它的组件。当所有绑定的组件都解除绑定时,Service会被销毁。 | 适用于需要与Service交互的组件,例如音乐播放控制。 |
ContentProvider的数据访问方式对比
访问方式 | 特点 | 适用场景 |
---|---|---|
query | 查询数据,返回Cursor对象,可以遍历结果集。适用于需要读取数据的组件。 | 适用于获取联系人、媒体文件等数据。 |
insert | 插入数据,返回新插入行的URI。适用于需要写入数据的组件。 | 适用于添加新联系人或记录。 |
update | 更新数据,返回受影响的行数。适用于需要修改数据的组件。 | 适用于更新现有记录的信息。 |
delete | 删除数据,返回受影响的行数。适用于需要删除数据的组件。 | 适用于删除不再需要的记录。 |
BroadcastReceiver的注册方式对比
注册方式 | 特点 | 适用场景 |
---|---|---|
静态注册 | 在Manifest文件中声明,系统会在合适的时机调用BroadcastReceiver。适用于系统级广播。 | 适用于需要接收系统级广播的组件,例如网络状态变化。 |
动态注册 | 在代码中注册,通常在Activity或Service的生命周期内有效,适用于应用内广播。 | 适用于需要接收应用内广播的组件,例如自定义事件通知。 |
问题:
- 《第三行代码》Kotlin
问题 | 解决方法 | 结论 |
---|---|---|
Kotlin 语言的可读性不足 | 切换回《第一行代码》第二版,使用 Java 语言学习 | Java 的语法更适合团队合作和项目需求 |
学习成本高,时间不足 | 选择更熟悉的 Java 语言进行学习 | 熟悉的语言可以提高学习效率 |
Kotlin 代码简洁导致理解困难 | 通过 Java 的详细语法增强理解 | 适当的代码冗长有助于代码的可读性 |
团队使用 Java,个人学习 Kotlin | 适应团队的技术栈,回归 Java 学习 | 团队一致性有助于项目的顺利进行 |