为什么java编译器输入法不能切换到中文?
发布网友
发布时间：2022-04-23 13:59
共2个回答
热心网友
时间：2023-10-17 01:09
将EN那个（下面可能还有其他什么输入法）整个删除，再在默认输入语音下面选择中文（中国）-简中-美式，然后建议你只安一个输入法，就安搜狗吧，这样中英切换就方便许多了，另外，如果你不想只安一个输入法，你只要在用搜狗输入法时，如果想换英文的，只要安shift就行了.
2.在任务栏前多出了CH和EN两个字母：
使用windows操作系统中文版并不表示只能进行中文语言的录入（中文版是指用户界面是面向中文用户的）。
所以你打开 控制面板->区域和语言选项->“语言”选项卡->“详细信息”按钮，在“文字输入和输入语言”窗口中点“添加”按钮，弹出“添加输入语言”对话框中第一栏就是“输入语言”，它表示选录入时的背景语言（第二栏“键盘布局\输入法”是在此录入背景语言下选输入法），其下拉列表中可看到什么 希腊语 匈牙利语 等。任务栏的EN表示背景语言为英语。
一般用户用不上这个。在前面“文字输入和输入语言”窗口中“已安装的服务（I)”区域中“EN
英语（X国）”下的输入法一个一个选中然后点“删除”，最后确定就是了。
后面你说的是Ctrl加Shift应该是各输入法间切换的快捷键，而不是搜狗拼音的中英文状态间的切换。进入搜狗拼音输入法“设置属性”->按键设置 可见其中英文状态切换要么不用快捷键要么单用ctrl或shift。
、首先任务栏上的输入法图标上点右键选择设置。
2、然后选择“高级键设置”，选中第一个“在输入语言之间”，然后点击下面的“更改按键顺序”，先
勾选“切换输入语言”下面选择左手ALT。取消右边“切换键盘布局”前的勾（即选择“未分配”），点
击确定。
然后选中“中文（简体）输入法 - 输入法/非输入法切换”，点击“更改按键顺序”，取消“启用按键顺
序”前的勾，再确定。
3、再次进入步骤2的设置，选中“在输入语言之间”，点击“更改按键顺序”，把右边“切换键盘布局”
的“Ctrl+Shift”打上勾，确定后退出。
4、搞定！
解决了无法使用ctrl+shift以及ctrl+space切换输入法的问题。
热心网友
时间：2023-10-17 01:09
必备！2020 Google 开发者大会全回顾，属于你的进阶秘籍！>>>
把一个Java应用程序转换为Kotlin，编译时间要多久？
这是关于Kotlin的一系列文章。分为三个部分。 第一部分讨论了从Java转换到Kotlin。第二部分是我对Kotlin的看法。
在前面的文章中， 我讨论了把Android 应用从Java 100%转换为Kotlin 。 Kotlin代码比Java的简洁，更易于维护，所以我认为转换是值得的。 但有些人不想试用Kotlin，因为他们担心它编译可能没有Java快。 这个关注点绝对是正确的，如果变得编译很慢，没有人愿意转换他们的代码。 所以，让我们编译Lock App试一下 ，然后我把它转换成Kotlin。 我不会试图比较一行代码的编译速度; 相反，我将尝试回答将代码从Java转换为Kotlin是否会影响其总体构建的时间。
我如何测试构建时间
我写了一个shell来重复执行gradle。 所有测试连续进行10次。 该项目的每个场景之前clean，并使用Gradle daemon ，daemon之前停止一次。
本文中的所有测试都在运行于3.4 GHz的Intel Core i7-6700上，使用32GB的DDR4内存和三星850 Pro SSD。 源代码是用Gradle 2.14.1构建的。
测试
我想在几种常见的使用场景中运行基准：使用和不使用Gradle daemon+clean，没有文件更改的增量编译，以及更改的文件的增量编译。
在转换之前，App Lock的Java代码有5,491个方法和12,371行代码。 改写后，这些数字下降到4,987方法和8,5行Kotlin代码。 在重写期间没有发生大的架构更改，因此在重写之前和之后测试编译时间应该很好地了解Java和Kotlin之间的构建时间的差异。
clean + 不用Gradle daemon Build
这是两种语言中构建时间最差的情况：从冷启动运行一个clean的构建。 对于这个测试，我禁用了Gradle daemon。
这里是十个构建所花费的时间：
在这种情况下的结果是，Java构建时间平均为15.5秒，而Kotlin平均为18.5秒：增加了17％。 这对Kotlin来说并不是一个好的开始，但是大部分人不会这么编译他们的代码。
对于没有Gradle daemon 并且clean构建，Java编译比Kotlin快17％
clean +Gradle daemon Build
这个JIT编译器的问题 ，就像JVM中，是它们需要时间来编译对报告的执行的代码，等等的处理随时间增加的性能，因为它运行。 如果停止JVM进程，那么性能增益会丢失。 在构建Java代码时，通常在每次构建时启动和停止JVM。 这迫使JVM每次构建时重做工作。 为了解决这个问题，Gradle附带了一个守护进程，它将在构建之间保持活跃，以便保持JIT编译的性能提升。 你可以通过在gradle命令行加参数--daemon或者在gradle.properties文件添加一句org.gradle.daemon=true。
可以看到，第一次运行所花费的时间与没有daemon的时间相同，但后续运行的性能提高，直到第四次运行。 在这种情况下，查看第三次运行后的平均构建时间更有用，其中daemon已工作过了。 对于热运行，在Java中执行clean构建的平均时间为14.1秒，而Kotlin以16.5秒的速度运行时间：多了13％。
对于clean + Gralde daemon 编译，Java编译比Kotlin快13％。
Kotlin正在赶上Java，但仍然稍微落后。 但是，无论使用什么语言，Gradle daemon都会将构建时间减少40％以上。 如果你还没有使用它，你应该用上。
所以Kotlin编译在完整代码情况下比Java慢一点。 但是你通常只会对几个文件进行更改后编译，增量构建将有不同的性能。 所以，让我们来看看Kotlin在增量编译是否可以赶上。
增量构建
编译器最重要的性能特性之一是使用增量编译。 正常构建将重新编译项目中的所有源文件，但是增量构建将跟踪自上次构建以来哪些文件已更改，并且只重新编译这些文件和依赖它们的文件。 这可能对编译时间有巨大的影响，特别是对于大型项目。
增量构建在kotlin1.0.2以后版本支持 ，你可以在你的gradle.properties文件添加kotlin.incremental = true实现。
那么当使用增量编译时，Kotlin与Java的编译时相比如何？ 以下是没有更改文件时使用增量编译的基准：
接下来，我们将使用修改后的源文件测试增量编译。 为了测试这个，我在每次构建之前改变了一个java文件，Kotlin也一样。 在这个基准测试中，源文件是没有其他文件依赖的UI文件：
最后，让我们看看使用修改的
