setImageBitmap与setImageUri的区别？为何加载图片两种写法均可行？

这个问题问得好！我当初刚接触Android开发时也有过一模一样的疑惑，咱们来拆解这两种写法的核心差异，你就能明白教程的用意了～

1. 版本兼容性与底层逻辑的展示 #

ImageView.setImageUri()其实是Android API优化后的便捷封装方法，在Android 3.0（API 11）及之后的版本里，它内部已经自动帮你完成了内容解析、Bitmap加载、异常处理等一系列操作。但在更早的Android版本中，这个方法的实现并不完善，甚至存在兼容性问题。

很多教程会选择手动加载Bitmap的写法，一方面是为了兼容旧版本设备，更重要的是把图片加载的完整流程暴露给学习者——让你明白“从Uri到显示在ImageView上”到底经历了哪些步骤，而不是只调用一个黑盒方法。

2. 对Bitmap的自定义控制空间 #

用MediaStore.Images.Media.getBitmap()的写法，你能在图片显示前对Bitmap做各种自定义处理：

• 压缩图片尺寸（通过BitmapFactory.Options设置inSampleSize，避免大图片导致OOM）
• 修正图片旋转方向（解决某些拍照后图片自动旋转的问题）
• 添加滤镜、裁剪、圆角等自定义效果
• 手动管理Bitmap内存（比如在不需要时调用recycle()释放内存）

而setImageUri()是把所有逻辑交给系统处理，你没法在中间插入这些自定义操作。教程这么写，是为了让你掌握手动掌控Bitmap加载的能力，这在处理复杂图片场景时至关重要。

3. 异常处理的灵活性 #

教程里的代码用try-catch捕获了IOException，这意味着你可以在图片加载失败时做针对性处理：比如显示一张占位错误图、弹出提示告诉用户“图片加载失败”，甚至重试加载。

而setImageUri()内部虽然也会处理异常，但它的错误反馈是隐藏的——如果加载失败，ImageView可能只是显示空白，你很难排查问题，也没法给用户友好的交互提示。

4. 内存管理的主动性 #

直接手动加载Bitmap时，你可以通过BitmapFactory.Options来精准控制内存占用：比如设置inPreferredConfig为RGB_565（比默认的ARGB_8888节省一半内存），或者根据ImageView的尺寸对图片进行采样压缩，避免加载远超控件大小的Bitmap造成内存浪费。

setImageUri()虽然也会做一些内存优化，但都是系统自动完成的，你没法根据实际场景做针对性调整，遇到超大图片时更容易触发内存溢出。

总结一下：mImageView.setImageUri(mImageUri)确实是简洁高效的写法，适合快速实现基础的图片显示功能；但教程里的冗长代码是为了传授底层原理、自定义处理能力和健壮的异常处理逻辑，让你不仅“能用”，还能“用好”。实际开发中，根据场景选择合适的写法就好～

内容的提问来源于stack exchange，提问作者Florian Walther