自己做网站需要固定ip吗公众号平台注册

张

张建站

2026/4/11 0:00:27

10分钟阅读

自己做网站需要固定ip吗,公众号平台注册,化州网站开发公司,ip动态地址做网站1. 为什么你的App改不了息屏时间#xff1f;从“小白”到“老手”的第一道坎你是不是也遇到过这样的需求#xff1f;开发一个阅读类App#xff0c;希望用户沉浸在内容里时#xff0c;屏幕能一直亮着#xff0c;别动不动就自己黑了#xff1b;或者做一个健身指导应用&…1. 为什么你的App改不了息屏时间从“小白”到“老手”的第一道坎你是不是也遇到过这样的需求开发一个阅读类App希望用户沉浸在内容里时屏幕能一直亮着别动不动就自己黑了或者做一个健身指导应用用户在跟着视频做动作时不需要频繁去触碰屏幕。这时候你自然会想到去修改系统的“屏幕超时”时间。安卓系统本身是提供了这个接口的就是Settings.System.SCREEN_OFF_TIMEOUT。听起来很简单对吧我刚开始也是这么想的不就是找到那个键值然后往里塞一个毫秒数嘛。代码可能五分钟就写完了但真正跑起来你会发现事情远没有这么简单。最常见的就是迎面给你一个SecurityException告诉你“此路不通权限不够”。这个权限就是android.permission.WRITE_SETTINGS。它可不是你在AndroidManifest.xml里简单声明一下就能用的普通权限。从 Android 6.0API 23开始它被归为“危险权限”中的特殊类别需要动态申请而且申请的方式和访问通讯录、定位那些还不太一样。很多开发者包括我早期都卡在了这一步看着系统弹出的那个“修改系统设置”的开关一脸茫然不知道该怎么引导用户去打开它。更“坑”的还在后面。你以为搞定了标准流程App就能在所有手机上畅行无阻了太天真了。国内各手机厂商比如OPPO、小米、华为、vivo都在原生安卓的基础上套了自己的“壳”——深度定制的UI和权限管理系统。它们把“修改系统设置”这个入口像捉迷藏一样藏在了系统设置里各种稀奇古怪的路径下。用户找不到你的功能就形同虚设。所以今天我就把自己这些年踩过的坑、总结出来的经验从最基础的权限申请到头疼的厂商适配完整地分享给你。目标就一个让你能真正实现一个稳定、可用的系统级息屏时间定制功能。2. 核心原理与标准实现不止是putInt那么简单我们先抛开那些复杂的适配回到最本质的问题安卓系统是如何管理屏幕超时的Settings.System.SCREEN_OFF_TIMEOUT这个常量本质上是一个键Key它对应着系统数据库SettingsProvider里的一个整数值单位是毫秒。系统服务会持续监听这个值当用户无操作的时间达到这个阈值就触发熄屏。所以我们的核心操作就两步写Settings.System.putInt和读Settings.System.getInt。代码骨架看起来确实简单但魔鬼藏在细节里。2.1 权限的“双重认证”声明与动态请求首先在AndroidManifest.xml文件中你必须声明这个权限。注意由于这个权限级别很高Android Studio 可能会给出警告我们可以用tools:ignore属性忽略它。uses-permission android:nameandroid.permission.WRITE_SETTINGS tools:ignoreProtectedPermissions /但声明了只是拿到了“准考证”能不能进考场还得看动态申请的结果。从 Android 6.0 开始你需要引导用户跳转到专门的授权页面。这里不能使用ActivityResultLauncher像申请其他危险权限那样直接弹窗而是需要启动一个特定的Intent。我写了一个通用的检查与申请方法你可以直接拿去用import android.content.Intent import android.net.Uri import android.os.Build import android.provider.Settings import androidx.appcompat.app.AppCompatActivity fun checkAndRequestWriteSettingsPermission(activity: AppCompatActivity) { // 1. 检查当前是否有权限 val hasPermission if (Build.VERSION.SDK_INT Build.VERSION_CODES.M) { Settings.System.canWrite(activity.applicationContext) } else { // 在 Android M 之前声明了权限即被认为拥有但部分厂商机仍需特殊处理 true } if (!hasPermission) { // 2. 没有权限跳转到系统设置页面 val intent Intent(Settings.ACTION_MANAGE_WRITE_SETTINGS).apply { data Uri.parse(package:${activity.packageName}) // 添加一个Flag确保从我们的App跳转过去 addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) } // 3. 检查是否有Activity能处理这个Intent理论上所有手机都有 if (intent.resolveActivity(activity.packageManager) ! null) { activity.startActivity(intent) } else { // 极少数情况兜底提示 Toast.makeText(activity, 无法找到系统设置页面请手动在设置中寻找‘修改系统设置’权限, Toast.LENGTH_LONG).show() // 这里可以引导用户去更通用的应用信息页 val appInfoIntent Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).apply { data Uri.parse(package:${activity.packageName}) } activity.startActivity(appInfoIntent) } } else { // 已有权限可以执行修改操作 modifyScreenOffTimeout(activity) } }当用户点击我们App内的一个按钮比如“开启长亮屏模式”时调用这个方法。它会先检查如果没有权限就会跳转到类似下图所示的系统设置页面。这里有个关键点这个页面是系统级的我们的App无法直接知道用户是“允许”了还是“拒绝”了因为不会有回调返回我们的App。所以通常的做法是在onResume生命周期里再次检查权限状态。override fun onResume() { super.onResume() // 假设用户从系统设置页面返回 if (Settings.System.canWrite(this)) { // 用户已授权执行修改 modifyScreenOffTimeout(this) Toast.makeText(this, 权限已获取息屏时间设置成功, Toast.LENGTH_SHORT).show() } else { // 用户未授权或拒绝了 Toast.makeText(this, 需要‘修改系统设置’权限才能生效哦, Toast.LENGTH_SHORT).show() } }2.2 读写息屏时间注意值的有效范围拿到了权限读写操作就安全了。但这里也有讲究。系统对于SCREEN_OFF_TIMEOUT的值是有隐性约束的。虽然理论上你可以设置任意毫秒数比如1000*60*60*24代表24小时但某些系统或厂商可能会有一个最大上限或者只接受某些特定值如与系统设置里那些选项匹配的值。设置一个极大的值通常会被系统接受但行为可能不一致。写入一个超长的息屏时间fun setScreenOffTimeoutToVeryLong(context: Context) { if (!Settings.System.canWrite(context)) { // 没有权限先引导申请 return } try { // 设置为24小时毫秒 val timeoutMs 1000 * 60 * 60 * 24 val result Settings.System.putInt( context.contentResolver, Settings.System.SCREEN_OFF_TIMEOUT, timeoutMs ) if (result) { Log.d(ScreenTimeout, 息屏时间已设置为24小时) } else { Log.e(ScreenTimeout, 写入系统设置失败) } } catch (e: SecurityException) { // 理论上已检查过权限但以防万一 Log.e(ScreenTimeout, 权限异常: ${e.message}) } }读取当前的息屏时间fun getCurrentScreenOffTimeout(context: Context): Int { return try { Settings.System.getInt(context.contentResolver, Settings.System.SCREEN_OFF_TIMEOUT) } catch (e: Settings.SettingNotFoundException) { // 如果这个设置项不存在极罕见返回一个默认值比如2分钟 Log.w(ScreenTimeout, 未找到SCREEN_OFF_TIMEOUT设置返回默认值120000ms) 120000 } }重要提示当你的App修改了全局系统设置一定要记得在适当的时机比如App退出、相关功能关闭时将其恢复原状。这是一个良好的开发习惯避免影响用户手机的其他使用场景。你可以先读取旧值保存起来需要恢复时再写回去。3. 厂商适配深水区破解OPPO、小米、华为们的“权限迷宫”好了标准流程走通了在你的测试机上完美运行。但当你把APK发给使用OPPO手机的朋友测试时他可能会告诉你“我在设置里根本找不到你说的那个‘修改系统设置’开关啊” 恭喜你正式进入了安卓开发的“地狱难度”副本——厂商适配。国内主流厂商为了系统安全、省电管理或打造差异化都对这块权限进行了深度定制。它们没有禁用这个功能但把入口藏得很深或者增加了额外的弹窗确认。下面就是我整理的各家“迷宫地图”你可以按图索骥。3.1 OPPO/一加 ColorOSOPPO系包括一加后期机型是第一个给我“下马威”的。它的路径和原生安卓差异很大。标准路径可能无效设置-应用管理-找到你的App-权限管理。在这里你可能只看到通讯录、短信等普通权限找不到“修改系统设置”。正确路径ColorOS 11-13 实测打开设置。找到应用管理或直接搜索“应用”。点击右上角或列表中的特殊应用权限或“权限管理”子分类下的“特殊权限”。在特殊权限列表里找到修改系统设置。进入后在应用列表中找到你的App将开关打开。给你的建议在App内检测到是OPPO机型且没有权限时可以弹出一个自定义的引导图清晰地画出上述路径。甚至可以用Intent尝试直接跳转到这个深层页面如果系统暴露了相应的Action但直接跳转到“特殊应用权限”页面的Intent并不通用最稳妥的还是图文引导。3.2 小米 MIUI小米的权限管理也非常严格而且不同MIUI版本路径可能有调整。常见路径设置-应用设置-应用管理- 找到你的App。进入应用详情后找到权限管理。在权限列表里向下滑动找到其他权限。在“其他权限”列表中寻找修改系统设置或后台弹出界面、显示悬浮窗等放在一起的特殊权限打开开关。另一个入口直接在设置顶部搜索“修改系统设置”搜索结果可能会直接带你到权限控制页。小米系统在授予此权限时有时还会额外弹出一个系统警告对话框告知用户风险需要用户再次确认。这一点在引导用户时最好也提一下让用户有个心理准备。3.3 华为 HarmonyOS / EMUI华为的路径相对规整但同样藏在多层菜单下。常见路径设置-应用和服务-应用管理。找到你的App并点击进入。点击权限。在权限页面点击底部或侧边的所有权限或需要滚动到底部。在展开的所有权限列表中仔细查找修改系统设置然后授予权限。华为在一些新版本中可能会将“修改系统设置”归类为“特殊访问权限”可能需要从“应用启动管理”或“电池优化”相关的入口迂回找到。同样提供清晰的截图引导是最有效的。3.4 vivo FuntouchOS / OriginOSvivo的路径也比较独特。常见路径设置-应用与权限-权限管理。在权限管理页面找到并点击权限选项卡有时是直接列表。在权限分类列表中寻找系统设置或修改系统设置这类条目点击进入。在有权使用该权限的应用列表中找到你的App并开启开关。为了应对这种碎片化的情况一个健壮的App不应该只依赖标准的Settings.ACTION_MANAGE_WRITE_SETTINGS跳转。我的策略是“分层引导”第一层尝试标准跳转。使用Settings.ACTION_MANAGE_WRITE_SETTINGS这对原生安卓和部分厂商有效。第二层跳转到应用详情页。如果标准跳转后用户还是找不到或者检测到是特定厂商机型则引导用户进入Settings.ACTION_APPLICATION_DETAILS_SETTINGS应用详情页并配合一张针对该厂商的、高亮的、带箭头标注的指引图告诉用户“请点击‘权限’-找到‘所有权限’-打开‘修改系统设置’”。第三层图文视频教程。在App的帮助页面或第一次触发权限申请时直接提供针对主流机型的图文甚至短视频教程。虽然开发成本高一点但用户体验是最好的。4. 实战进阶封装一个健壮的息屏时间管理类纸上得来终觉浅我把上面的所有逻辑封装成一个工具类ScreenTimeoutManager。这个类处理了权限检查、兼容性跳转、设置读写和状态回调你可以直接集成到项目中。import android.content.Context import android.content.Intent import android.net.Uri import android.os.Build import android.provider.Settings import android.util.Log class ScreenTimeoutManager(private val context: Context) { companion object { private const val TAG ScreenTimeoutManager // 一些预设值毫秒 const val PRESET_NEVER Int.MAX_VALUE // 注意实际使用中慎用可能被系统限制 const val PRESET_30_MINUTES 30 * 60 * 1000 const val PRESET_1_HOUR 60 * 60 * 1000 const val PRESET_24_HOURS 24 * 60 * 60 * 1000 } private var originalTimeout: Int -1 // 用于保存原设置方便恢复 /** * 检查是否拥有 WRITE_SETTINGS 权限 */ fun hasPermission(): Boolean { return if (Build.VERSION.SDK_INT Build.VERSION_CODES.M) { Settings.System.canWrite(context.applicationContext) } else { true // Android M 之前声明即拥有理论上 } } /** * 引导用户去开启权限。根据机型提供最佳跳转方案。 * return true 表示成功启动了权限设置页面false 表示无法启动。 */ fun navigateToPermissionSetting(): Boolean { val intent Intent(Settings.ACTION_MANAGE_WRITE_SETTINGS).apply { data Uri.parse(package:${context.packageName}) addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) } // 优先尝试标准Intent return if (intent.resolveActivity(context.packageManager) ! null) { context.startActivity(intent) true } else { // 标准Intent无效跳转到应用详情页让用户自己找 val fallbackIntent Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).apply { data Uri.parse(package:${context.packageName}) addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) } if (fallbackIntent.resolveActivity(context.packageManager) ! null) { context.startActivity(fallbackIntent) true } else { Log.e(TAG, 无法启动任何系统设置页面) false } } } /** * 保存当前的系统息屏时间用于后续恢复 */ fun backupOriginalTimeout(): Boolean { return try { originalTimeout Settings.System.getInt(context.contentResolver, Settings.System.SCREEN_OFF_TIMEOUT) Log.i(TAG, 原始息屏时间已备份: ${originalTimeout}ms) true } catch (e: Settings.SettingNotFoundException) { Log.e(TAG, 备份原始息屏时间失败, e) false } } /** * 设置自定义的息屏时间 * param timeoutMs 超时时间毫秒 * return 是否设置成功 */ fun setScreenOffTimeout(timeoutMs: Int): Boolean { if (!hasPermission()) { Log.w(TAG, 无 WRITE_SETTINGS 权限无法修改) return false } // 可选检查 timeoutMs 是否在合理范围内避免设置极端值 if (timeoutMs 15000) { // 比如小于15秒系统可能不支持 Log.w(TAG, 设置的息屏时间 ${timeoutMs}ms 可能过短系统可能忽略) } return try { val success Settings.System.putInt( context.contentResolver, Settings.System.SCREEN_OFF_TIMEOUT, timeoutMs ) if (success) { Log.i(TAG, 息屏时间已设置为: ${timeoutMs}ms (${timeoutMs / 1000 / 60}分钟)) } else { Log.e(TAG, 写入系统数据库失败) } success } catch (e: SecurityException) { Log.e(TAG, 权限异常可能动态权限已失效, e) false } catch (e: Exception) { Log.e(TAG, 设置息屏时间未知错误, e) false } } /** * 恢复之前备份的原始息屏时间 */ fun restoreOriginalTimeout(): Boolean { if (originalTimeout -1) { Log.w(TAG, 未备份原始息屏时间无法恢复) return false } return setScreenOffTimeout(originalTimeout) } /** * 获取当前系统生效的息屏时间 */ fun getCurrentTimeout(): Int { return try { Settings.System.getInt(context.contentResolver, Settings.System.SCREEN_OFF_TIMEOUT) } catch (e: Settings.SettingNotFoundException) { Log.w(TAG, 未找到 SCREEN_OFF_TIMEOUT 设置项) -1 // 返回-1表示错误 } } }使用示例// 在Activity或ViewModel中 val timeoutManager ScreenTimeoutManager(this) // 点击按钮准备开启长亮屏模式 fun onEnableLongScreenClick() { if (!timeoutManager.hasPermission()) { // 1. 先备份原设置可选但推荐 timeoutManager.backupOriginalTimeout() // 2. 引导用户去开启权限 val started timeoutManager.navigateToPermissionSetting() if (!started) { Toast.makeText(this, 请手动在系统设置中授予‘修改系统设置’权限, Toast.LENGTH_LONG).show() } // 3. 等待用户从设置页返回在 onResume 中检查并设置 } else { // 已有权限直接设置 val success timeoutManager.setScreenOffTimeout(ScreenTimeoutManager.PRESET_1_HOUR) if (success) { Toast.makeText(this, 已设置息屏时间为1小时, Toast.LENGTH_SHORT).show() } } } // 在 onResume 中处理用户返回后的逻辑 override fun onResume() { super.onResume() if (timeoutManager.hasPermission()) { // 用户刚刚授予了权限执行我们想做的设置 val success timeoutManager.setScreenOffTimeout(ScreenTimeoutManager.PRESET_1_HOUR) // ... 处理结果 } } // 当功能结束时如退出阅读模式恢复原设置 fun onExitSpecialMode() { timeoutManager.restoreOriginalTimeout() }这个管理器将复杂性封装了起来让业务逻辑变得清晰。它处理了权限状态管理、安全的设置读写以及最重要的——原始值的备份与恢复这是一个负责任的应用该做的。5. 避坑指南与最佳实践少走弯路的经验之谈走通了核心代码和厂商适配最后再分享几个我踩过坑才学到的经验能帮你把功能做得更稳、用户体验更好。坑1权限状态的持久性。WRITE_SETTINGS权限一旦授予除非用户在系统设置中手动撤销否则会一直有效。但是有些厂商在系统大版本升级、或者通过“手机管家”类应用一键优化后可能会重置某些特殊权限。因此比较稳健的做法是在App每次启动或进入需要此功能的核心模块时都检查一次Settings.System.canWrite()而不是只在第一次请求。坑2后台服务与息屏。修改了SCREEN_OFF_TIMEOUT只是延长了系统判断“无操作”的时限。如果屏幕因其他原因如用户按下电源键关闭或者你的App转入后台后被系统强制休眠屏幕依然会关闭。如果你需要屏幕在App处于后台时也保持常亮可能需要结合WakeLock唤醒锁的PARTIAL_WAKE_LOCK或SCREEN_DIM_WAKE_LOCK来使用但这会显著增加耗电需要谨慎评估并且同样需要申请WAKE_LOCK权限。坑3与其他应用的冲突。系统息屏时间是全局的。你的App将其设置为2小时当用户切换到另一个视频播放App它可能也会修改这个值值就会被覆盖。当你的App再次回到前台时之前的设置就失效了。因此你的逻辑应该是“进入我的场景时设置离开时恢复”。这就是为什么backupOriginalTimeout()和restoreOriginalTimeout()如此重要。理想的情况是在onPause或onStop中立即恢复而不是等到onDestroy。坑4用户体验与引导。直接弹出一个跳转到系统设置的请求对小白用户很不友好。他们不明白“修改系统设置”是什么担心安全问题。最好的做法是前置说明在触发权限申请前用一个友好的对话框解释“为了让您阅读时屏幕不会自动熄灭我们需要您授权‘修改系统设置’权限。这仅用于控制屏幕超时不会修改其他系统设置。”分步引导如果检测到是OPPO、小米等机型在跳转前就展示该机型的截图指引告诉用户“接下来会跳转到系统设置请按照下图所示找到开关并打开”。降级方案对于无论如何都不愿授予权限的用户可以提供降级方案比如提示用户“您也可以在手机的‘显示’设置中手动将‘休眠’时间调整为‘10分钟’”虽然体验打折但比没有好。坑5测试要全面。务必在你能找到的尽可能多的真机上进行测试特别是不同品牌、不同系统版本Android 11, 12, 13, 14的机型。重点关注权限申请流程是否能正确跳转。授予权限后你的设置是否立即生效可以锁屏等待验证。你的App退到后台或被杀死后恢复逻辑是否正常工作。在电量节省模式、省电模式下你的长亮屏设置是否会被系统策略覆盖很多时候会的。实现系统级息屏定制就像一场和安卓碎片化生态的博弈。从理解核心的Settings.SystemAPI 和WRITE_SETTINGS权限开始到深入各家厂商的权限迷宫最后用严谨的代码和良好的用户体验设计把功能做实。这个过程虽然繁琐但当你看到自己的App能在各种手机上稳定地提供“长亮屏”体验那种成就感还是很足的。希望这篇结合了大量实战经验的分享能帮你省下大量摸索的时间。如果在具体实现中遇到新的“坑”不妨多看看对应厂商的开放平台文档或者和社区里的开发者多交流总能找到解决办法。