showAsAction="always"报错

本文解决了使用appcompat-v7包时出现的should use android:showAsAction报错问题,并提供了解决方案,包括如何正确设置showAsAction属性以及如何处理低版本SDK的兼容性问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

当你使用[app_name] showAsAction="always"报错:
Should use android:showAsAction when not using the appcompat library
但是你已经引入appcompat-v7包布局文件     [app_name]xmlns:e="http://schemas.android.com/apk/res-auto">
android:id="@+id/menu_actionbar_home"
android:icon="@drawable/android_search_button_icon"

app_name:showAsAction="always"

依然报错 xml文件报错 编译不成功 

提示:

Should use android:showAsAction when not using the appcompat library

楼主觉得应该是编译版本的问题,但是改了版本之后依然不好用,楼主才疏学浅,谁如果知道根本原因,望不吝赐教,万分感谢

楼主前天也是遇见这种问题,百思不得其解,然后再网上各种搜索方法,然后在外国一个网站上找到答案

这里楼主吐槽一下:中国的技术论坛好多都是拷贝粘贴,然后各种雷同,能解决的问题真的不多;话不多说直接上解决方法


解决方法:

app_name:title="二维码"app_name:showAsAction="always"报错 直接编译不了

所以就改成android::showAsAction="always"

然后你在重写

@Override
	public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
		super.onCreateOptionsMenu(menu, inflater);
		inflater.inflate(R.menu.actionbar_psersonal_menu, menu);
		for (int j = 0; j < menu.size(); j++) {
	        MenuItem item = menu.getItem(j);
	        item.setShowAsActionFlags(MenuItem.SHOW_AS_ACTION_ALWAYS);
	    }
	}
这就是app_name:showAsAction="always的作用,因为楼主用的是两个所以就循环,这代码可以自己修改,就是在java代码实现

app_name:showAsAction="always这个效果;

如果你的android:minSdkVersion<14

问题就来了 编译的时候又来了Call requires API level 14 (current min is 11): android.view.MenuItem#setShowAsActionFlags

这就是然后你引入@SuppressLint("NewApi")就好了

如果大于等于14则没影响



<think>好的,我现在需要处理用户关于Docker中`restart=always`配置的问题。首先,用户希望了解这个配置的详细说明和使用场景。我需要确保回答准确,并且结构清晰,符合用户的要求。 首先,我应该回忆Docker的重启策略有哪些类型。记得Docker有四种重启策略:no、on-failure、always和unless-stopped。用户特别关注的是`always`策略,所以需要重点解释这个。需要明确说明`always`的行为,即无论容器退出状态如何都会自动重启,包括正常退出或手动停止的情况吗?可能需要注意,除非手动停止容器,否则`always`会在容器停止后总是重启。但需要确认这一点是否正确。 接下来,用户可能需要知道如何配置这个策略。记得可以通过`docker run`命令在创建容器时指定,例如`docker run --restart=always ...`,或者使用`docker update`来修改已存在的容器。这里需要给出具体的命令示例,确保语法正确,比如`docker update --restart=always <container_name>`。 然后,使用场景部分需要考虑哪些情况适合使用`always`策略。比如需要保持服务长期运行的场景,如Web服务器、数据库等关键服务。但同时也要指出潜在的问题,比如如果容器因为配置错误不断崩溃,可能会导致频繁重启,影响系统资源。这时候可能需要结合监控和日志分析来处理。 另外,用户可能想知道`always`和其他策略的区别,尤其是和`unless-stopped`的区别。需要说明`always`在系统重启后会自动启动容器,而`unless-stopped`在容器被手动停止后不会自动启动,即使Docker服务重启。这部分可能需要进一步验证,确保信息准确。 还要注意引用用户提供的参考内容。用户提到了引用[1]中的`docker update`命令来更改重启策略,应该在回答中提到这个方法,并正确标注引用。引用[2]中的常用命令可能也需要提及,但用户的问题主要围绕重启策略,所以重点放在引用[1]。 需要检查是否有其他注意事项,比如与存储驱动或网络配置的关系,但根据用户的问题,可能不需要深入这些方面,除非直接相关。不过用户提供的引用[2]提到了存储驱动,但这里可能不相关,所以可以忽略。 最后,生成相关问题时要确保问题与主题相关,并引导用户进一步探索。例如,其他重启策略的区别、如何查看当前策略、生产环境中的最佳实践等。 现在需要组织这些信息,确保符合用户的要求:使用中文,行内公式正确(虽然这里可能用不上数学公式,但要注意其他格式),结构清晰,分点说明,并添加引用标识。同时,生成的相关问题要合理,帮助用户深入理解。</think>### Docker restart=always 配置详解 #### 1. 核心定义与行为特性 `restart=always` 是 Docker 容器的重启策略之一,用于确保容器在**非手动干预退出时自动重启**,适用于需要**持续服务保障**的场景。其行为逻辑为: - **自动触发条件**:容器因任何原因停止(包括正常退出、非零状态退出、Docker守护进程重启) - **例外情况**:仅当用户通过 `docker stop` 或 `docker rm` **显式终止容器时**,自动重启机制才会失效[^1] #### 2. 配置方式 | 场景 | 命令示例 | 说明 | |------|----------|------| | 创建容器 | `docker run --restart=always nginx` | 初始部署时直接指定策略 | | 修改运行中容器 | `docker update --restart=always <容器名>` | 动态调整策略无需重建容器[^1] | #### 3. 典型应用场景 1. **关键业务服务** Web服务器(Nginx/Apache)、数据库(MySQL/Redis)等需要持续在线的基础设施 ```bash docker run --restart=always -d mysql:8.0 ``` 2. **微服务架构** 确保服务网格中的各个组件在意外退出后自动恢复 ```bash docker run --restart=always -d user-service:latest ``` 3. **硬件环境不稳定场景** 应对物理机/虚拟机可能发生的意外重启,配合Docker守护进程自启实现服务自动恢复 #### 4. 注意事项 - **资源监控需求**:可能掩盖容器崩溃的根本原因,建议配合 `docker logs` 和监控系统使用 - **启动间隔控制**:Docker默认采用**指数退避算法**,重启间隔会逐渐增加(立即重启 → 延迟2秒 → 延迟4秒...) - **策略优先级**:与 `--rm` 参数互斥,同时使用时 `--rm` 会失效 #### 5. 与其他策略对比 | 策略 | 触发条件 | 系统重启行为 | 适用场景 | |------|----------|--------------|----------| | no | 永不重启 | 不重启 | 临时测试容器 | | on-failure[:max-retries] | 非零退出码 | 不重启 | 批处理任务 | | always | 任何停止 | 自动重启 | 关键服务 | | unless-stopped | 非手动停止 | 保留最后状态 | 需人工干预场景[^1] |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值