1.AndroidUtilCodeKTX ！是时候提升你的开发效率了 ！（更新啦 ！）
2.聊聊获取屏幕高度这件事
3.Andriod文件选择器 支持Android/data和Android/obb目录访问 支持安卓4.4 ~ 13

AndroidUtilCodeKTX ！是时候提升你的开发效率了 ！（更新啦 ！游戏源码修改）

       AndroidUtilCodeKTX的最新版本0.0.6已上线，收获了个star和次fork。经过一个月的更新，我们添加了更多功能并修复了用户反馈的问题。在最新版本中，一系列空判断的优化使得代码更简洁、易读。通过使用高阶函数和lambda表达式，我们可以优雅地处理非空或空的对象，简化代码逻辑。

       另一个亮点是支持返回值，例如在TextView中处理文字为空的场景，我们通过定义扩展函数来实现。如果你发现更多的使用场景，欢迎提出issue，我们期待与你一同探索更多可能。

       执行shell命令的功能也得以实现，源于我们的Box项目需求，尽管最终未能成功读取内核版本，但这一功能为用户提供了解决方案。此外，网课平台搭建源码对BaseActivity进行异常处理的改进，使得在BaseVMActivity和BaseVMFragment中可以直接通过onError回调获取异常信息，提高了代码的健壮性。

       无障碍服务判断的实现解决了实际工作中的小需求，而RecyclerView.itemPadding的添加让布局调整更加便捷。发送邮件功能简化了IntentExt模块，使操作更加直接。文件相关部分，我们整合了Kotlin标准库的功能，满足了大部分文件操作需求，并且添加了简单的文件管理功能，使得文件管理更加高效。

       在CoroutineScope的实现中，BaseActivity和BaseFragment中可以直接使用主线程的协程作用域，简化了协程的使用流程。此外，自动感知生命周期的KtxHandler，以及Activity统一管理/应用前后台监听功能，通过自动完成生命周期的注册监听，使得应用管理更加智能。

       KtxSpan工具类的加入，提供了一个简洁且功能丰富的文本渲染工具，覆盖了大部分使用场景。通过三个方法：text、image和blockLine，我们可以轻松实现文字效果、建站之星源码下载显示和段落间距的调整。最后，我们期待用户对AndroidUtilCodeKTX的持续关注，欢迎反馈和建议，共同推动其发展。

聊聊获取屏幕高度这件事

       说起获取屏幕高度，或许你有所理解，但这个高度范围究竟指的是应用显示区域的高度，还是手机屏幕的高度呢？我们先来回顾一下平时使用获取高度的方法：

       以上三种方法的效果一致，只是写法略有不同。

       或许你使用的是这种方法：

       这个方法在系统版本大于等于Android 4.2时，会使用getRealMetrics（getRealSize）来获取屏幕高度。那么这里发生了什么？为什么会这样呢？

       其实在Android 4.0时，引入了虚拟导航键。如果你继续使用getMetrics之类的方式获取高度，获取的高度会去除导航栏的高度。

       由于在4.0和4.2之间并没有getRealMetrics这个方法，所以当时甚至需要添加适配代码：

       现在应该没有人还在适配4.4甚至5.0以下的机型了吧？所以历史的包袱可以放下了。

       上面方法名都是getScreenHeight，但这个高度范围到底和你需要的是否一致呢？这需要开发时注意。我的习惯是ScreenHeight指应用显示的高度，不包括导航栏（非全屏下），RealHeight指包含导航栏和状态栏的高度（getRealMetrics）。

       PS：以前也使用过AndroidUtilCode这个工具库，里面将前者方法名定义为getAppScreenHeight，后者为getScreenHeight。卡盟源码带sup也是很直观的方法。

       下文中我会以自己的习惯，使用ScreenHeight和RealHeight来代表两者。

       我印象中华为手机很早就使用了虚拟导航键，如下图（来源）：

       比较特别的是，当时华为的导航栏还可以显示和隐藏，注意图中左下角的箭头。点击可以隐藏，上滑可以显示。即使这样，使用getScreenHeight也可以准确获取高度，隐藏了ScreenHeight就等于RealHeight。

       上述的这一切在“全面屏”时代到来之前，没有什么问题。

       小米MIX的发布开启了全面屏时代（年底），以前的手机都是:9的，记得雷布斯在发布会上说过，他们费了很大的力气说服了谷歌去除了:9的限制（从Android 7.0开始）。

       全面屏手机是真的香，不过随之也带来适配问题。首当其冲的就是刘海屏，各家有各自的获取刘海区域大小的方法。主要原因还是国内竞争的激烈，各家为了抢占市场，先于谷歌定制了自己的方案。这一点让人想起了万恶的app下载页面 源码动态权限适配。

       其实在刘海屏之下，还隐藏一个导航栏的显示问题，也就是本篇的重点。全面屏追求更多的显示区域，随之带来了手势操作。在手势操作模式下，导航栏是隐藏状态。

       本想着可以和上面提到的华为一样，隐藏获取的就是RealHeight，显示就是减去导航栏高度的ScreenHeight。然而现实并不是这样，下表是我收集的一些全面屏手机各高度的数据。

       ScreenHeight一栏中括号内表示显示导航栏时获取的屏幕高度。

       大致的规律总结如下：

       其中vivo手机，屏幕高度加状态栏高度大于真实高度（ + > ）。本以为差值是刘海高度，但查看vivo文档后发现，vivo刘海固定dp（px），也还是对不上。

       一加6最奇怪，三种设置模式。使用侧边全屏手势时底部有一个小条，NavigationBar高度变为。（ + = + = ）也就是说这种模式也属于有导航栏的情况。

       这时如果你需要获取准确的ScreenHeight，只有通过RealHeight - NavigationBar来实现了。

       所以首先需要判断当前导航栏是否显示，再来决定是否减去NavigationBar高度。

       先看看老牌的判断方法如下：

       此方法通过比较ScreenHeight和RealHeight是否相等来判断。如果对比上面表中的数据，那只有OPPO Find X可以判断成功。也有一些方法通过ScreenHeight和RealHeight差值来计算导航栏高度。显然这些方法已无法再使用。

       所以搜索了一下相关信息，得到了下面的代码：

       可以看到包含了华为、小米、vivo、oppo、三星甚至诺基亚的判断。这就是适配的现实状况，不要妄想寻找什么通用方法，老老实实一个个判断吧。毕竟幺蛾子就是这些厂家搞出来的，厂家魔改教你做人。

       这种方法在上面的测试机中都亲测准确有效。

       不过这个判断方法不够严谨，比如其他品牌手机使用此方法，那么结果都是false。用这样的结果来计算高度显得不够严谨。

       根据前面提到问题发生的原因是全面屏带来的（7.0及以上）。所以我们可以先判断是否是全面屏手机（屏幕长宽比例超过1.以上），然后判断是否显示导航栏，对于不确定的机型，我们还是使用原先的ScreenHeight。尽量控制影响范围。

       我整理的代码如下（补充了一加、锤子手机判断）：

       有人会问，这些key都是哪里来的？毕竟我在厂商文档也没有翻到。

       我能想到的办法是查看SettingsProvider，它是提供设置数据的Provider，分有Global、System、Secure三种类型，上面代码中可以看到不同品牌存放在的类型都不同。我们可以通过adb命令查看所有数据，根据navigation等关键字去寻找。比如查看Secure的数据：

       或者:

       这样如果有上面兼容不到的机型，可以使用这个方法适配。也欢迎你的补充反馈。

       费了这么大的劲获取到了准确的高度，可能你会说，还不如直接获取ContentView的高度：

       这个结果和上述计算的高度一致，唯一的限制是需要在onWindowFocusChanged之后调用，否则高度为0。这个我们可以根据实际情况自行选用。

       第二种情况就是状态栏强制为黑色。这里我怀疑因为这个设置，导致在有刘海的手机上，ScreenHeight不包含状态栏高度。

       最糟糕的是第三种，隐藏后状态栏在刘海外。例如Redmi K在开启后，ScreenHeight为，RealHeight为，而关闭时为和。这下连万年不变的RealHeight也变化了，这太不real了，大家自行体会。不过目前发现未影响适配方案，不知其他手机如何。

       对于是否隐藏刘海，其实也是有各家的判断的，比如小米：

       getSystem源码如下：

       它不受资源覆盖的影响，我们可以通过它将值转换回来。

       本篇看似聊的获取高度这件事，其实伴随导航栏的发展演进，核心是是如何判断导航栏是否显示。

       通过上面的介绍，总结一下就是在“全面屏时代”，如果你想获取屏幕高度，就不要使用ScreenHeight了。否则会出现UI展示上的问题。而且这种问题，线上也不会崩溃，难以发现。以前在支付宝中就发现过PopupWindow弹出高度不正确的问题，过了好久才修复了。

       至于屏幕宽度，也不清楚随着折叠屏、环绕屏的到来会不会造成影响。但愿不要吧，碎片化越来越严重了。

       最后，如果本文对你有启发有帮助，点个赞可好？

Andriod文件选择器 支持Android/data和Android/obb目录访问 支持安卓4.4 ~

       Android文件选择器功能强大，适用于Android 4.4至版本，支持访问Android/data和Android/obb目录。此组件提供自定义用户界面（UI）选项，并兼容SD卡。开发者只需集成文件或路径选择功能，系统会自动申请存储权限。此选择器支持多种构建模式，包括Activity、Fragment和Dialog，方便用户在不同场景中使用。

       快速开始步骤包括添加仓库、远程依赖和基本用法示例。在项目中，开发者需开启调试模式，设置Activity、Fragment或Dialog构建方式，并在布局文件中占位显示文件选择器。为确保返回按钮功能正常，开发者需要重写onBackPressed()方法，优先处理路径选择器的返回事件。对于自定义UI需求，组件提供选项样式和高度自定义UI功能，允许开发者根据项目需求进行个性化设置。

       通过配置IConfigDataBuilder接口，开发者可以调整选择器的配置参数。特别注意，该文件选择器已适配分区存储，无需额外适配，只需专注于业务逻辑开发。然而，如项目对体积有严格要求，建议开发者下载源码后精简AndroidUtilCode模块。代码混淆处理通常在构建流程中进行，以优化代码大小。

       开源项目以及其依赖组件对代码质量有重要贡献，特别感谢这些贡献者的努力。请根据项目需求和版本要求，按照文档或注释指示进行集成和配置。