郭霖的专栏

本文介绍了如何在Jetpack Compose中适配不同尺寸的Android设备，特别是大屏设备。随着Android 16系统将不再支持限制应用的横竖屏旋转，开发者需要更好地适配大屏设备。文章首先建议使用Android Studio中的可调整尺寸模拟器来测试不同设备类型的界面效果。接着，介绍了如何使用WindowSizeClass来获取设备的屏幕尺寸类型，并根据不同尺寸调整界面布局。最后，通过一个简单的Feed流界面示例，展示了如何利用LazyVerticalGrid在大屏设备上实现一行显示多条内容，从而提

即使你想说你们的App并不打算支持在除手机以外的Android设备上运行，但是别忘了，现在的折叠屏设备是可以瞬间从手机模式切换成平板模式的。首先，只有targetSdk指定到了36及以上的App，运行在Android 16的大屏设备上时，才会出现限制屏幕方向和比例的API失效的情况。只是Android大屏设备的保有量并不高，许多中小型App开发者的适配积极性不足，这也导致直到今天仍然还有许多App在大屏设备上的运行体验是比较差的。再具体一点，就是在最小宽度大于等于600dp的设备上，上述API才会失效。

首先要解决的第一个问题就是，什么是预测性返回手势？简单来说，就是在你想要触发返回操作时，让你能够提前预知即将返回到哪个界面。在Android系统中，用户是可以通过点击返回键，或使用返回手势来回到上一个界面的。但上一个界面具体是什么？我们可能并不知道，通常得等点完了返回键之后才能知道具体会返回到哪个界面。那么预测性返回手势是怎么优化这部分体验的呢？貌似我们也基本没怎么见过这种能提前预知即将返回到哪个界面的效果吧。

发现了这个现象之后，可能细心的朋友立马就察觉到了，那如果我手机底部的导航栏模式不是这种手势导航栏，而是传统的Back、Home、Task 3按键导航栏，edge-to-edge全面屏体验会变成什么样呢？绝大部分的App其实都只使用了绿色这部分的空间，屏幕上方的状态栏以及屏幕下方的导航栏这两个白色部分的空间都是没有利用起来的，想想你写的App是不是也是这样？适配的代码其实还是比较简单的，主要就是借助Compose提供的一些内置函数，来对某些指定的控件进行偏移，保证其不会被系统的状态栏或导航栏遮挡住就可以了。

那么由于我们不希望聊天内容进入状态栏区域，因此这里调用了WindowInsetsCompat.Type.statusBars()来获取状态栏的Insets，比如说这里获取到状态栏的高度是50，那么我们通过对chatRecyclerView设置一个50的padding就可以保证聊天内容不进入状态栏区域了。发现了这个现象之后，可能细心的朋友立马就察觉到了，那如果我手机底部的导航栏模式不是这种手势导航栏，而是传统的Back、Home、Task 3按键导航栏，edge-to-edge全面屏体验会变成什么样呢？

在得到所有子布局测量好的尺寸之后，我们选择其中最宽的子布局的宽度来作为我们自定义布局MyColumn的宽度，选择所有子布局高度的总和来作为MyColumn的高度。有了这两个参数之后，我们就可以遍历measurables中的所有可测量子布局，每别调用它们的measure函数来测量它们的尺寸，并将测量的结果赋值给placeables这个集合变量。编写自定义布局需要用到的最重要的一个函数就是Compose提供的Layout函数，事实上，几乎所有的Compose控件都是基于Layout函数打造出来的。

这里将shouldShowAddButton变量用derivedStateOf包裹了进来，那么根据derivedStateOf的特性，只有当这个表达式中的条件发生变化了，才算是State的值发生了变化，这时才会触发重组。不同的是，derivedStateOf接收的一个表达式，只有当这个表达式中的条件发生变化了，那么才算是State的值发生了变化，这时才会触发重组。在这篇文章中，我很细致地讲解了Lazy Layout的用法，但同时也埋下了一个坑，这个坑会严重影响Lazy Layout的性能。

今天这篇文章给大家介绍一下Android 14系统中的一个新特性，对部分照片和视频进行访问授权，也可以称之为选择性照片和视频访问授权。这是Android系统在隐私和安全性方面的又一次调整升级，目的是为了能够更好地保护用户隐私。但是这个新特性对于开发者而言，真的是让我们苦上加苦，因此我会边吐槽边来讲解这个最新的特性。

大家好，写给初学者的Jetpack Compose教程第4篇更新了。今天我们要介绍的是Compose当中至关重要的一个组件，State。State不光非常的重要，同时可以让我们的Compose学习之旅变得更加有趣。为什么这么说呢？因为在之前的学习过程当中，我们所实现的都是静止的界面效果，而有了State之后，则可以让界面开始动起来了。

不久之前，Google公开了Android 14的首个Developer Preview版本。按照Google正常的节奏，每年年初会发布两个Developer Preview版本，然后在每年中上旬发布两到三个Beta版本。之后会进入平台稳定期，将版本打磨精细，然后在秋季左右发布当年最新的Android系统版本。其实之前我倒是基本没太写过这种新系统特性一览的文章。去年因为公司安排的原因，我去学习了一下Android 13 Developer Preview的新特性，并写了一篇比较全面的文章介绍，可以参

大家好，今天是Kotlin Flow响应式编程三部曲的最后一篇。其实回想一下我写这个Kotlin Flow三部曲的初衷，主要还是因为我自己想学这方面的知识。虽然Kotlin我已经学了很多年了，但是对于Flow我却一直没怎么接触过。可能是因为工作当中一直用不上吧，我现在工作的主语言依然还是Java。而我一直都是这个样子，写博客基本上不是为了谁而写的，大部分都只是因为我自己想学。

Kotlin在推出多年之后已经变得非常普及了。相信现在至少有80%的Android项目已经在使用Kotlin开发，或者有部分功能使用Kotlin开发。关于Kotlin方面的知识，我其实分享的文章并不算多，主要内容都是集中在《第一行代码 第3版》这本书当中。看完这本书，相信你一定可以很好地上手Kotlin这门语言。

要不了多久，Android 13正式版就要发布了。其实就在几个月前，我写了一篇关于Android 13首个开发者体验版的全面介绍，详情可以参考。那么相比于首个开发者体验版，目前Android 13已经进入了平台稳定期阶段，也就是说API基本已经固定，不会再有什么大的修改了。于是我又重新回顾了一遍Android 13的重要新特性和行为变更，发现有一处重大变化在首个开发者体验版中几乎没有提及，那就是Android 13的运行时权限变更。因此，今天我就再写一篇Android 13的运行时权限变更一览，带你全面..

说起来，在不知不觉中，我竟然凑成了这沉浸式状态栏三部曲。其实最开始的时候，我主要是因为工作上的原因想要在Android版的Edge浏览器上实现首页图片沉浸式的功能。那么为了实现这个功能，我提前去做了一些技术调研，并将调研的结果整理成了一篇文章，具体可参阅 再学一遍android:fitsSystemWindows属性 。做完技术调研之后，接下来就是功能实现了。对于Android版的Edge浏览器而言，首页图片的沉浸式一直是部分网友长久以来的呼声，经过我的各种攻坚和踩坑之后，终于将这个功能完成了。具体可参阅

掰手指数一数，我入职微软也已经有一年半的时间了。从入职以来，我一直在从事于开发Android版的Edge浏览器。这么长时间下来，我也慢慢从完全不知如何上手，提个PR都困难，到现在能够负责独立开发一个比较大的功能模块了。不得不说，Edge是我见过的最复杂的一个项目，我是真的很难想象一个浏览器工程可以庞大到如此地步。Chromium本身就已经是一个巨型工程了，而Edge又要在其基础之上加入许多微软定制的需求，那就肯定避免不了一通魔改，代码自然就变得更加复杂。记得当初刚加入微软不久时，有一些公众号上的小伙伴

不要吃惊。Android 12才刚刚正式推出没几个月时间呢，Android 13就已经来了。是的，Android 13 Developer Preview目前已经推出了两个版本迭代了，包含了众多的新特性和行为变更。本来按照往年的习惯，我是不会在如此早期的阶段就去研究每年新系统的新功能的。但是由于最近公司安排我去做一次内部的技术分享涉及到了这个主题，所以今年第一时间就对Android 13进行了还算比较全面的体验

相信二维码扫描现在大家都已经不稀奇了，几乎所有的App里都会支持这个功能。这里我要问大家一个问题，你们都是如何在自己的App中加入二维码扫描功能的呢？相信会有一大部分朋友说，使用的是ZXing或者ZBar这种开源库。但是不知道大家有没有思考过，二维码功能这么常见，为什么Google却没有提供一个官方的二维码扫描库呢？反正我是没思考过。有需求，找开源，这可能已经成了很多Android开发者的常态化思维。但令我没想到的是，官方的二维码扫描库，它真的要来了

对于android:fitsSystemWindows这个属性你是否感觉又熟悉又陌生呢？熟悉是因为大概知道它可以用来实现沉浸式状态栏的效果，陌生是因为对它好像又不够了解，这个属性经常时灵时不灵的。其实对于android:fitsSystemWindows属性我也是一知半解，包括我在写《第一行代码》的时候对这部分知识的讲解也算不上精准。但是由于当时的理解对于我来说已经够用了，所以也就没再花时间继续深入研究。而最近因为工作的原因，我又碰上了android:fitsSystemWindows这个属性，

如果你将项目中的appcompat库升级到1.3.0或更高的版本，你会发现startActivityForResult()方法已经被废弃了。这个方法相信所有做过Android的开发者都用过，它主要是用于在两个Activity之间交换数据的。那么为什么这个如此常用的方法会被废弃呢？官方给出的说法是，现在更加建议使用Activity Result API来实现在两个Activity之间交换数据的功能。我个人的观点是，startActivityForResult()方法并没有什么致命的问题，只是

Android 12正式版即将发布。这次的Android系统变化当中，UI的变化无疑是巨大的。Google在Android 12中采取了一种叫作Material You的界面设计，一切以你为中心，以你的喜好为风格。相信大家一旦上手Android 12之后应该能立刻察觉到这些视觉方面的变化。另外还有一个非常显著的视觉变化就是，Android 12强制给所有的App都增加了SplashScreen的功能。是的，即使你什么都不做，只要你的App安装到了Android 12手机上，都会自动拥有这个新功能

不知道你有没有好奇过，像Microsoft Edge这种巨型项目是如何进行版本管理的？当然关于这个问题我就需要先解释一下，因为Edge是多么巨型的一个项目很多人可能并没有概念。事实上，其实我也没有概念，因为我知道自己接触的只是冰山一角，可能绝大多数人看这个项目的代码都像是在管中窥豹一样。Edge是微软研发的一款基于Chromium内核的浏览器，而Chromium则是由Google推出的一个开源浏览器项目。那么Chromium有多么庞大呢？很可惜，我没有找到最新的数据，但是根据2019年的数据

前段时间跟QQ群里的群友聊天时无意聊到了抓包的话题。抓包可以说是程序员日常开发调试问题的一个重要手段，可以帮助我们理清客户端与服务器之间的数据传输问题，以便于甩锅。在过去，网络请求基本都是靠的http协议，那个时候的抓包是一件非常简单的事情。然而这几年，http协议在逐渐被淘汰，几乎所有的网络请求都变成了https协议，这就使事情变得复杂了。群里一位朋友说，https是不可能被抓包的，不然怎么保证https传输的安全性，毕竟那么多大公司都在用这个协议来传输重要的数据。这其实是一个比较有意思的话题

Paging是Google推出的一个应用于Android平台的分页加载库。事实上，Paging并不是现在才刚刚推出的，而是之前就已经推出过两个版本了。但Paging 3和前面两个版本的变化非常大，甚至可以说是完全不同的东西了。所以即使你之前没有学习过Paging的用法也没有关系，把Paging 3当成是一个全新的库去学习就可以了。我相信一定会有很多朋友在学习Paging 3的时候会产生和我相同的想法：本身Android上的分页功能并不难实现，即使没有Paging库我们也完全做得出来，但为什么Pa

相信不少关注谷歌开发者官方公众号的小伙伴们最近应该都知道了一个消息。随着Jetpack Compose首个Beta版的发布，Google在上周四的时候发起了一个Android开发挑战赛的活动。在接下来的四周时间里，Google每周都将发起一个挑战项目，以帮助开发者能够更加熟练地使用Jetpack Compose来构建出色的应用。参与挑战还有机会赢取包括Pixel 5在内的1000多份奖品

kotlin-android-extensions插件可能算得上是我最喜欢的一个Kotlin在Android上的特性了。这么说并不夸张，因为以前在使用Java开发Android程序时，我们总是要写一大堆的findViewById，枯燥又没什么意义。虽然也有一些诸如ButterKnife之类的第三方库，专门用于对findViewById的用法进行简化，但是ButterKnife还是要通过注解来让控件与资源id之间进行绑定，并不算是非常方便。而kotlin-android-extensions插件的

做了Android开发这么多年，一直以来都有一个我认为非常不人性化的地方，就是开发人员没有办法简单直接地查看当前应用程序中的数据库文件，这个问题导致Android数据库的开发与调试工作一直都比较困难。举个例子，我们编写了一段代码去查询数据库当中的某条数据，但是却没能查出来。那么到底是因为查询语句写错了？还是因为这条数据根本就不存在？要如何定位及解决这种问题是比较头疼的，因为我们无法直观地看到当前数据库中实际的数据。那么过去大家都是如何解决的呢？这个真的是八仙过海，各显神通了。像我个人比较习惯的方

没有人愿意编写处理Android运行时权限的代码，因为它真的太繁琐了。这是一项没有什么技术含量，但是你又不得不去处理的工作，因为不处理它程序就会崩溃。但如果处理起来比较简单也就算了，可事实上，Android提供给我们的运行时权限API并不友好。以一个拨打电话的功能为例，因为CALL_PHONE权限是危险权限，所以在我们除了要在AndroidManifest.xml中声明权限之外，还要在执行拨打电话操作之前进行运行时权限处理才行

在不久之前，我才发布了一篇Android 10适配的文章，讲的是作用域存储的相关内容。而除了作用域存储之外，深色主题也是Android 10中的一大亮点，并且是需要开发者进行适配的。因此本篇文章我们就来探讨关于深色主题的内容。另外说明一下，本篇文章主要摘自《第一行代码——Android 第3版》的第14章，在此基础之上，我又扩展了一些内容

大家好，今天给大家带来一个仿360手机卫士悬浮窗效果的教程，在开始之前请允许我说几句不相干的废话。不知不觉我发现自己接触Android已有近三个年头了，期间各种的成长少不了各位高手的帮助，总是有很多高手喜欢把自己的经验写在网上，供大家来学习，我也是从中受惠了很多，在此我深表感谢。可是我发现我却从来没有将自己平时的一些心得拿出来与大家分享，共同学习，太没有奉献精神了。于是我痛定思痛，决定从今天开始写博客，希望可以指点在我后面的开发者，更快地进入Android开发者的行列当中。好了，废话就说这么多，下面开始

我发现了一个比较怪的现象。在iPhone上使用十分普遍的指纹认证功能，在Android手机上却鲜有APP使用，我简单观察了一下，发现Android手机上基本上只有支付宝、微信和极少APP支持指纹认证功能，就连银行和金融类的应用都基本不支持，甚至很多开发者都不知道Android系统是有指纹认证的官方API的。事实上，Android从6.0系统开始就支持指纹认证功能了，但是指纹功能还需要有硬件支持才行，而Android手机的硬件都是由各厂商生产的，手机档次也参差不齐，因此不能像iPhone那样保证所有的手机都是

大家好，今天跟大家分享一个我编写的MVVM架构的开源小项目。话说这个小项目已经提前跟大家预热很久了，也是被不少朋友催了很多次。我之前在公众号里透漏过这个项目能够帮助大家更好地理解MVVM架构，当然我也希望确实如此。虽说这篇文章重点是向大家介绍这个开源小项目的，但是我并不希望就写得如此简单，我准备把它写成一篇干货文章。一切先从Jetpack说起

最近二维码真是越来越火了，随便电视上、网络上、商场里，到处都是二维码。而内嵌二维码扫描功能的软件也越来越多，QQ、微信、UC浏览器等等应用都可以对着二维码扫一扫，感觉我们自己的应用里不加上二维码扫描功能，都跟不上时代潮流了。所以今天我就将带着大家一起，在我们自己的程序里加入二维码扫描的功能。不过，二维码功能如果真要做起来还是非常复杂的，从零开始实现不太现实，比较好的做法就是借助现有的开源项目。目前在二维码这一领域名气最大的开源项目就是ZXing了(Zebra Crossing)，它提供了多个平台的二维码扫

大家好，感觉好像已经很久没更新博客了。前段时间主要是忙于新书的事情，时间比较紧张。而现在新书已经完稿，剩下的事情就都是出版社的工作了，那么我又可以抽出时间来写写博客了。记得之前有位朋友在我的公众号里问过我，像直播的那种弹幕功能该如何实现？如今直播行业确实是非常火爆啊，大大小小的公司都要涉足一下直播的领域，用斗鱼的话来讲，现在就是千播之战。而弹幕则无疑是直播功能当中最为重要的一个功能之一，那么今天，我就带着大

人人客户端有一个特效还是挺吸引人的，在主界面手指向右滑动，就可以将菜单展示出来，而主界面会被隐藏大部分，但是仍有左侧的一小部分同菜单一起展示。据说人人客户端的这个特效是从facebook客户端模仿来的，至于facebook是不是又从其它地方模仿来的就不得而知了。好，今天我们就一起来实现这个效果，总之我第一次看到这个特效是在人人客户端看到的，我也就主观性地认为我是在模仿人人客户端的特效了。虽然现在网上类似这种效果的实现也非常多，可是我发现实现方案大都非常复杂，并不容易理解。但其实这种效果并不难实现，因此我

之前我向大家介绍了史上最简单的滑动菜单的实现方式，相信大家都还记得。如果忘记了其中的实现原理或者还没看过的朋友，请先去看一遍之前的文章 Android滑动菜单特效实现，仿人人客户端侧滑效果，史上最简单的侧滑实现 ，因为我们今天要实现的滑动菜单框架也是基于同样的原理的。之前的文章中在最后也提到了，如果是你的应用程序中有很多个Activity都需要加入滑动菜单的功能，那么每个Activity都要写上百行的代码才能实现效果，再简单的滑动菜单实现方案也没用。因此我们今天要实现一个滑动菜单的框架，然后在任何

之前有很多朋友都问过我，在Android系统中怎样才能实现静默安装呢？所谓的静默安装，就是不用弹出系统的安装界面，在不影响用户任何操作的情况下不知不觉地将程序装好。虽说这种方式看上去不打搅用户，但是却存在着一个问题，因为Android系统会在安装界面当中把程序所声明的权限展示给用户看，用户来评估一下这些权限然后决定是否要安装该程序，但如果使用了静默安装的方式，也就没有地方让用户看权限了，相当于用户被动接受了这些权限。在Android官方看来，这显示是一种非常危险的行为，因此静默安装这一行为系统是不会开放给开

经过前面两篇文章的学习，我们已经对ListView进行了非常深层次的剖析，不仅了解了ListView的源码和它的工作原理，同时也将ListView中常见的一些问题进行了归纳和总结。那么本篇文章是我们ListView系列三部曲的最后一篇，在这篇文章当中我们将对ListView进行功能扩展，让它能够以瀑布流的样式来显示数据。一直关注我博客的朋友们应该知道，其实在很早之前我就发布过一篇关于实现瀑布流布局的文章，Android瀑布流照片墙实现，体验不规则排列的美感。但是这篇文章中使用的实现算法比较简单，其实就是在

如果你是网购达人，你的手机上一定少不了淘宝客户端。关注特效的人一定都会发现，淘宝不管是网站还是手机客户端，主页上都会有一个图片滚动播放器，上面展示一些它推荐的商品。这个几乎可以用淘宝来冠名的功能，看起来还是挺炫的，我们今天就来实现一下。实现原理其实还是之前那篇文章Android滑动菜单特效实现，仿人人客户端侧滑效果，史上最简单的侧滑实现 ，算是以那个原理为基础的另外一个变种。正所谓一通百通，真正掌握一种方法之后，就可以使用这个方法变换出各种不通的效果

大家好，记得上次我带着大家一起实现了一个类似与淘宝客户端中带有的图片滚动播放器的效果，但是在做完了之后，发现忘了加入图片自动播放的功能(或许是我有意忘记加的.....)，结果图片只能通过手指滑动来播放。于是今天我将再次带领大家，添加上之前遗漏的功能，让我们的图片播放器更加完善。这次的程序开发将完全基于上一次的代码，如果有朋友还未看过上篇文章，请先阅读 Android实现图片滚动控件，含页签功能，让你的应用像淘宝一样炫起来 。既然是要加入自动播放的功能

记得我之前参与开发过一个华为的项目，要求程序可以支持好几种终端设备，其中就包括Android手机和Android Pad。然后为了节省人力，公司无节操地让Android手机和Android Pad都由我们团队开发。当时项目组定的方案是，制作两个版本的App，一个手机版，一个Pad版。由于当时手机版的主体功能已经做的差不多了，所以Pad版基本上就是把手机版的代码完全拷过来，然后再根据平板的特性部分稍作修改就好了。但是，从此以后我们就非常苦逼了。每次要添加什么新功能，同样的代码要写两遍。每次要修复任何bug