企业官网建设流程全解析

做AndroidTV开发的朋友，十有八九都遇到过这个情况：遥控器焦点在按钮和卡片之间跳得好好的，一到EditText上就彻底卡死。按上按下没反应，按左按右光标却在文本里来回动，焦点死活出不去。这个“EditText焦点无法转移”的问题，几乎每个TV应用里都会遇到，但网上资料又分散，很多帖子只丢一段代码就说能解决，实际拿到自己的项目里一测，照样失灵。这篇文章把我自己在TV开发中踩过的坑、最终的解决方案、以及对焦点机制的完整理解都整理出来，项目里的同学可以直接抄作业。

1. 问题现场与影响分析

1.1 三个典型场景，看你中过几个

先说最常见的场景。搜索页输入框，遥控器按上或者按左，正常情况下应该让焦点跳到搜索按钮或者联想词列表，但实际表现是：屏幕上的高亮框纹丝不动，EditText里光标往左边挪一格。连续按几下，光标到了文本开头，焦点还是出不去。这是最典型的“方向键被EditText吃掉”的情况。

第二个场景是表单页面。用户名输入完，想跳到密码输入框，按遥控器向下，结果光标在用户名里往下移动——不对，单行EditText里根本没有“下一行”，这个按键就变成没有任何响应。用户只能干瞪眼，最后发现按OK键弹出了软键盘，用软键盘上的Next按钮才能跳转。

第三个场景更隐蔽。焦点明明已经离开EditText了，但你在别的控件上按方向键想回来时，焦点会“反弹”一下又跳走，或者回来了之后方向键又卡住。这种问题在RecyclerView嵌套EditText的时候特别明显，后面我专门讲。

这三个场景的根子是同一个：EditText在处理方向键时，优先把它们当成光标移动指令消费掉了，系统根本走不到“焦点转移”这一步。

1.2 为什么在TV平台上这个问题是致命的

手机上有触摸屏，用户想跳出输入框，手指一点别的地方就完事。TV上没有触摸，所有交互全靠遥控器那几个物理按键，焦点就是用户在界面上唯一的“鼠标”。焦点一旦被锁死在输入框里，用户唯一的出路就是按返回键退出整个页面，或者连按N次方向键碰运气看能不能跳出去。

更麻烦的是，TV盒子上的EditText默认还会弹软键盘。软键盘一出来，焦点问题就更复杂了：输入框虽然还有焦点，但软键盘上的按键焦点是另外一套逻辑，遥控器按方向键要么被软键盘截获，要么把输入框光标弄乱。用户面对一个半屏的软键盘，根本搞不清楚焦点到底在哪。

我在某款电视盒子项目里接手过一个搜索页面，用户反馈“搜索框卡死，按什么键都没反应”，排查到最后不是SearchView的问题，就是EditText方向键消费导致焦点永远停留在输入框里，界面上看起来就像整个页面死机了。所以这个问题必须彻底解决，不能靠“给用户加个默认值”这种土办法糊弄。

2. 焦点机制与问题根因

2.1 Android焦点系统是如何工作的

先建立基本概念。Android里View可以请求焦点，焦点一旦落在某个View上，遥控器按方向键时，焦点系统会在这个View的父容器层级里执行一次“焦点搜索”。具体算法是使用FocusFinder查找在当前方向上最合适的下一个View，找到后调用View.requestFocus()。

这个流程中有一个关键变量：事件是否被当前持有焦点的View消费了。系统的按键事件分发顺序是：

1. 分发到当前焦点View的onKeyDown()。
2. 当前View如果返回true，事件就被消费，流程结束。
3. 返回false，事件会向上抛，最终由ViewRootImpl尝试做焦点搜索。

所以，焦点能不能转移，本质上取决于当前焦点View怎么处理方向键事件。普通Button对方向键的默认处理是返回false，所以焦点可以自由跳转。EditText不同，它在onKeyDown里对方向键有一套专门的光标移动逻辑，返回true把事件消费了，焦点就出不去了。

2.2 EditText消费方向键的完整链路

EditText继承自TextView，TextView内部处理方向键的逻辑核心在Editor类。按DPAD_LEFT时，TextView会调用onKeyDown中的movementKey处理，把按键解释为“光标左移一位”，执行完成返回true。这个动作发生在onKeyDown这一层，甚至轮不到ViewRootImpl去查焦点。

事件顺序还可以再看细一点。整个分发链路上有一个容易被忽视的方法onKeyPreIme，它在InputMethodManager窗口之前调用。在TV设备上，如果系统自带输入法，方向键事件会先经过InputMethod，再交给View。这就会出现另一个情况：你明明在EditText里重写了onKeyDown返回false，方向键还是没触发焦点转移，原因是InputMethod已经先把事件消费掉了。这就是很多人的“解决方案”无效的原因。

完整调用顺序大致是：

InputMethod -> View.onKeyPreIme() -> 输入法消费？ 如果没消费 -> View.onKeyDown() -> TextView移动光标 -> 返回true 如果消费 -> 焦点系统不参与

从这里可以看出，要在EditText里救回方向键，需要同时在onKeyPreIme和onKeyDown两层做拦截，确保事件不会被输入法和文本编辑器消费。

2.3 根因总结：不是布局问题，是事件分发问题

一句话总结：EditText本身不是不能失去焦点，而是它在处理方向键时把事件消费掉了，导致系统的焦点搜索机制压根没有机会运行。这个问题和布局层级、是否嵌套都无关，换成LinearLayout、RelativeLayout还是ConstraintLayout都一样，只要EditText不松开方向键，焦点就永远困在里面。

明白了根因，解决方案就清晰了：让EditText在合适的时机“让出”方向键事件。难点在于如何把握“合适的时机”——你总不能把方向键完全废掉，毕竟用户还需要在文本里移动光标。

3. 三种主流方案横向对比

3.1 方案A：无脑重写onKeyDown返回false

这是网上流传最广的写法，核心代码就这几行：

@Override public boolean onKeyDown(int keyCode, KeyEvent event) { if (keyCode == KeyEvent.KEYCODE_DPAD_LEFT || keyCode == KeyEvent.KEYCODE_DPAD_RIGHT || keyCode == KeyEvent.KEYCODE_DPAD_UP || keyCode == KeyEvent.KEYCODE_DPAD_DOWN) { return false; } return super.onKeyDown(keyCode, event); }

一句话评价：能用，但很粗暴。它把所有方向键无条件交出去，带来的后果是用户在EditText里再也无法用遥控器移动光标。假设用户输入完发现中间有个字输错了，想改一下，按左按右焦点直接跑到旁边的Button上去了，用户根本没法精准定位光标位置。这在实际产品评审里绝对会被打回。

这个方案唯一的优点是简单，适合那种“输入框里内容很短、一次输完不许改”的极简场景。

3.2 方案B：用focusSearch手动转移焦点

不依赖系统自动处理，自己接管方向键后手动查找目标焦点：

@Override public boolean onKeyDown(int keyCode, KeyEvent event) { if (isDpadKey(keyCode)) { View current = getRootView().findFocus(); View next = focusSearch(getDirectionFromKey(keyCode)); if (next != null) { next.requestFocus(); } return true; } return super.onKeyDown(keyCode, event); }

这个方案的好处是可控性强，不管上层布局多么混乱，你都能精确指定下一个要聚焦的控件，甚至可以通过自定义规则跳过某些View。坏处是工作量变大，每个输入框都要处理方向映射，而且focusSearch返回的结果可能是EditText自己（如果旁边没有别的可聚焦View），这种情况下要记得默认转移给父容器的下一个元素，不然就是死循环。

我在一个需要“按方向键只在几个输入框之间循环跳转”的表单项目里用过这个方案，效果很好，但对团队协作不太友好——后来新来的同事接手，完全不理解这套逻辑，维护成本偏高。

3.3 方案C：编辑模式与方向键模式分离

这是我个人最推荐，也是最后一直沿用的方案。核心思路是给EditText增加两种模式：

• 焦点模式：默认状态，方向键全部让出，焦点正常在控件之间转移。
• 编辑模式：用户按OK键进入，此时方向键用来移动文本光标。

切换模式通过OK键或者长按某个键触发，状态变化时通过接口通知外部（比如改变输入框边框颜色提示用户当前模式）。这样做的好处是既解决了焦点转移问题，又保留了文本编辑能力，而且在TV上“按OK进入编辑、按返回退出编辑”非常符合遥控器操作直觉。

@Override public boolean onKeyDown(int keyCode, KeyEvent event) { if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER || keyCode == KeyEvent.KEYCODE_ENTER) { setEditMode(!isEditMode()); return true; } if (isDpadKey(keyCode) && !isEditMode()) { return false; } return super.onKeyDown(keyCode, event); }

代码并不复杂，但交互逻辑完整，真实TV应用里用起来很顺手。很多手机上常见的输入框在TV上都需要这种“点击进入文本编辑”的设计，主流TV应用里的搜索框、设置页输入框都是这个交互。

3.4 选型建议

如果你接手的是一个长期维护的TV项目，方案C基本是标准答案。如果只是临时救火，方案A几分钟就能交差，但要接受它带来的交互损失。

4. 完整实现与代码解析

4.1 自定义TvEditText完整代码

直接上代码，这是我实际项目里用的版本，注释都写在关键位置了：

import android.content.Context; import android.graphics.Color; import android.text.Editable; import android.text.TextWatcher; import android.util.AttributeSet; import android.view.KeyEvent; import android.view.View; import android.view.inputmethod.EditorInfo; import androidx.appcompat.widget.AppCompatEditText; public class TvEditText extends AppCompatEditText { private static final int[] DPAD_KEYS = { KeyEvent.KEYCODE_DPAD_UP, KeyEvent.KEYCODE_DPAD_DOWN, KeyEvent.KEYCODE_DPAD_LEFT, KeyEvent.KEYCODE_DPAD_RIGHT }; private boolean editMode = false; private OnEditModeChangeListener mModeListener; public interface OnEditModeChangeListener { void onEditModeChanged(TvEditText view, boolean editMode); } public TvEditText(Context context) { this(context, null); } public TvEditText(Context context, AttributeSet attrs) { this(context, attrs, android.R.attr.editTextStyle); } public TvEditText(Context context, AttributeSet attrs, int defStyleAttr) { super(context, attrs, defStyleAttr); init(); } private void init() { // 默认单行，去掉多余的IME动作，避免软键盘Next干扰焦点逻辑 setSingleLine(true); setImeOptions(EditorInfo.IME_ACTION_NEXT); // 给一个明显的焦点背景提示 setFocusableInTouchMode(false); setHighlightColor(Color.parseColor("#33FFC107")); setSelectAllOnFocus(true); } public boolean isEditMode() { return editMode; } public void setEditMode(boolean editMode) { this.editMode = editMode; if (mModeListener != null) { mModeListener.onEditModeChanged(this, editMode); } // 切换模式时更新背景提示 setBackgroundColor(editMode ? Color.parseColor("#2200BCD4") : Color.TRANSPARENT); } public void setOnEditModeChangeListener(OnEditModeChangeListener listener) { this.mModeListener = listener; } private boolean isDpadKey(int keyCode) { for (int code : DPAD_KEYS) { if (code == keyCode) { return true; } } return false; } private int getFocusDirection(int keyCode) { switch (keyCode) { case KeyEvent.KEYCODE_DPAD_UP: return View.FOCUS_UP; case KeyEvent.KEYCODE_DPAD_DOWN: return View.FOCUS_DOWN; case KeyEvent.KEYCODE_DPAD_LEFT: return View.FOCUS_LEFT; case KeyEvent.KEYCODE_DPAD_RIGHT: return View.FOCUS_RIGHT; default: return View.FOCUS_DOWN; } } @Override public boolean onKeyPreIme(int keyCode, KeyEvent event) { // 关键点1：在输入法拿到按键前，先把方向键拦下来。 // 如果不在编辑模式，方向键不交给输入法，返回false让焦点系统处理。 if (isDpadKey(keyCode) && !isEditMode()) { if (event.getAction() == KeyEvent.ACTION_DOWN) { boolean moved = moveFocus(keyCode); return moved; } return true; } return super.onKeyPreIme(keyCode, event); } @Override public boolean onKeyDown(int keyCode, KeyEvent event) { // 关键点2：DPAD_CENTER/ENTER切换编辑模式 if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER || keyCode == KeyEvent.KEYCODE_ENTER || keyCode == KeyEvent.KEYCODE_NUMPAD_ENTER) { if (event.getAction() == KeyEvent.ACTION_DOWN && !isEditMode()) { setEditMode(true); selectAll(); // 清一下焦点信息，保证下次方向键能正常查找 return true; } } // 非编辑模式下，方向键全部让出，交给焦点系统 if (isDpadKey(keyCode) && !isEditMode()) { return false; } // 编辑模式下，方向键仍然可以让左/右移动光标，但上/下/OK用于退出编辑 if (isDpadKey(keyCode) && isEditMode()) { if (event.getAction() == KeyEvent.ACTION_DOWN) { if (keyCode == KeyEvent.KEYCODE_DPAD_UP || keyCode == KeyEvent.KEYCODE_DPAD_DOWN) { setEditMode(false); return false; } } } return super.onKeyDown(keyCode, event); } private boolean moveFocus(int keyCode) { View current = getRootView().findFocus(); if (current == null) { current = this; } View next = focusSearch(getFocusDirection(keyCode)); if (next != null && next != this) { next.requestFocus(); return true; } // 找不到下一个可聚焦控件时，退回给父容器处理 return false; } @Override protected void onFocusChanged(boolean focused, int direction, android.graphics.Rect previouslyFocusedRect) { super.onFocusChanged(focused, direction, previouslyFocusedRect); if (!focused) { // 焦点离开时自动退出编辑模式，避免下次进入还是编辑状态 setEditMode(false); } } }

这里有个细节值得单独说明：onFocusChanged里面退出编辑模式，是为了防止焦点跳到其他控件后，用户再跳回来时，EditText还处于编辑状态，导致方向键又只能移动光标。实测很多次，没有这一步的话，用户在搜索框和搜索结果之间来回切几次之后，输入框就莫名其妙又变成“锁死”状态了。

4.2 布局与Activity中的配套配置

布局文件中正常使用这个自定义控件，不要额外设置nextFocusDown之类的属性，避免和代码里的focusSearch冲突：

<com.yourpackage.widget.TvEditText android:id="@+id/etSearch" android:layout_width="match_parent" android:layout_height="48dp" android:hint="请输入关键词" android:textColor="#FFFFFF" android:textColorHint="#888888" android:background="@drawable/bg_edittext_focus" android:maxLines="1" android:inputType="text" android:imeOptions="actionNext" />

Activity里面设置监听：

TvEditText etSearch = findViewById(R.id.etSearch); etSearch.setOnEditModeChangeListener((view, editMode) -> { // 这里可以更新搜索框背景、提示文字，提示用户当前处于哪种模式 }); etSearch.setOnEditorActionListener((v, actionId, event) -> { if (actionId == EditorInfo.IME_ACTION_NEXT) { // 软键盘点了Next，跳转到下一个输入组件 View next = v.focusSearch(View.FOCUS_DOWN); if (next != null) { next.requestFocus(); } return true; } return false; });

4.3 核心逻辑解析，为什么这样写

先把代码里几条关键分支捋一遍：

第一条，onKeyPreIme中的拦截。为什么事件在这里处理而不是只放在onKeyDown？因为部分预装输入法在onKeyPreIme之前就会把方向键消费掉，导致你onKeyDown里面写得再多都触发不了。实测某品牌盒子的系统输入法，按DPAD_LEFT直接就是IME在响应，View层根本收不到方向键。所以必须先站在输入法前面把事件截住，这个位置就是onKeyPreIme。

第二条，编辑模式切换放在onKeyDown而不是onKeyUp。按遥控器OK键时，如果不对按下和抬起做区分，同一个按键会触发两次切换。我用event.getAction() == ACTION_DOWN做条件，按一次切一次，实测稳定。有些项目的遥控器还会同时发出KEYCODE_DPAD_CENTER和KEYCODE_ENTER两个keyCode，所以两个都判了。

第三条，调用focusSearch(RequestFocus的方向)后，为什么还要手动next.requestFocus()。因为focusSearch只负责找到候选View，它不会自动触发请求焦点，必须显式调用requestFocus才能真正完成转移。focusSearch可能返回null（周围没有可聚焦View），这时返回false，把事件还回去让上层继续处理，而不是自己吞掉。

第四条，文本全选selectAll()。进入编辑模式时把已有文本全选，好处是用户直接输入就能覆盖旧内容，这个在TV搜索框里非常实用。手机上用户会用手指双击，遥控器可没有双击这种操作，全选是最友好的方案。

5. 复杂场景实战与避坑

5.1 RecyclerView中的EditText焦点问题

列表里塞EditText的场景在TV上更麻烦，因为RecyclerView自己对方向键也有拦截逻辑，用于切换子Item的焦点。EditText和RecyclerView双向争夺方向键，最终结果就是焦点既不在EditText里顺畅移动，也不在Item之间正常跳转。

常规解法有两种。第一种，如果EditText只是列表中的某一个子项，那就在RecyclerView的onKeyDown里判断当前焦点：当前焦点是TvEditText且非编辑模式时，让RecyclerView走自己的焦点逻辑，不要调用super.onKeyDown。写成这样：

@Override public boolean onKeyDown(int keyCode, KeyEvent event) { View focus = getFocusedChild(); if (focus != null && focus instanceof TvEditText) { TvEditText tvEt = (TvEditText) focus; if (!tvEt.isEditMode()) { return false; } } return super.onKeyDown(keyCode, event); }

第二种，把EditText作为列表的Header或者Footer，干脆别让它在RecyclerView内部。焦点转移逻辑会简单很多，但要看产品设计允不允许。

我在一个商品搜索页面用过第二种，搜索框放在列表外部的顶部固定位置，列表只负责展示搜索结果，这样EditText的焦点问题彻底隔离开，再也没出过状况。但有时候需求明确要求“搜索结果列表和搜索框一体滚动”，那就只能用第一种了。

5.2 配合nextFocusDown等属性时的注意事项

TV布局里经常会给View设置nextFocusDown/nextFocusLeft这些属性，手动指定焦点走向。这些属性和自定义TvEditText里的focusSearch手动逻辑会互相作用，有两种情况要注意。

一种是你给EditText设置了nextFocusDown属性来指定下一个焦点，但你在自定义控件里用的是focusSearch，focusSearch会忽略nextFocusDown，直接按几何位置找最近的View。结果就是你指定的target没生效，焦点跳到了别的地方。要避免的话，在自定义代码里先查nextFocusDown属性：

View next = super.focusSearch(...); if (next == null) { int nextId = getNextFocusDownId(); if (nextId != View.NO_ID) { next = getRootView().findViewById(nextId); } }

另一种是直接在布局里不设置nextFocus属性，完全靠focusSearch的几何查找。大部分TV页面的焦点布局都是规则的，几何查找已经够用，硬编码指定反而增加维护成本。

5.3 软键盘弹出与焦点框被顶出屏幕

TV上弹软键盘比手机上更折腾，因为电视屏幕本来就大，软键盘通常会占掉一半高度，EditText如果在下半部分，很容易被软键盘顶出可视区域。方案里要处理两个维度。

窗口软键盘模式，清单文件中给Activity设置：

android:windowSoftInputMode="adjustPan"

adjustPan会在软键盘弹出时自动滚动RootView，确保当前焦点控件可见。不要用adjustResize，因为很多TV的Launcher不会正确处理Resize事件，反而会造成背景变形或者焦点错乱。

还有一点，软键盘一旦弹出，输入的焦点和遥控器的焦点是两套系统在交替工作。实测发现软键盘弹出后，EditText里的onKeyDown依然会收到方向键事件，但用户看到的却是软键盘上的键在移动。这个状态下编辑模式基本没有意义，建议在输入法显示时自动退出编辑模式，让方向键完全交给软键盘和焦点导航。判断输入法是否显示，可以用重写onWindowFocusChanged或者监听窗口Insets，但这个扩展比较复杂，先不做展开。

6. 常见问题排查表与独家心得

6.1 常见问题速查表

6.2 独家踩坑记录和调试技巧

第一个坑：不要selectAllOnFocus和editMode联动出问题。我最初给TvEditText设置了selectAllOnFocus(true)，它的效果是每次获得焦点时全选文本。结果用户跳出去再跳回来，文本被全选，他们一按方向键，期待的“光标移动”变成了“取消全选”，整个文本状态就乱了。后来改成只在进入编辑模式时全选，强制进入方法里selectAll()，别用属性配置，控制粒度更细。

第二个坑：事件分发链路的DEBUG。这个问题的难点是分不清按键到底被谁消费了。我调试时常用的命令是在关键View和Activity里同时打印日志，输出onKeyDown和onKeyUp的时间戳，再对照事件流看哪一层丢掉了事件。这一招帮我定位过好几个“看似在EditText里面、实际是被外层LinearLayout拦截”的诡异case。简单来说就是每个ViewGroup都可能在dispatchTouchEvent里拦截KeyEvent，不只是焦点View的问题。

第三个坑：手柄兼容。遥控器方向键的keyCode是KEYCODE_DPAD_UP，但游戏手柄的左摇杆方向键在某些设备上会变成KEYCODE_BUTTON_A、KEYCODE_BUTTON_DPAD_UP或者KEYCODE_NAVIGATION_UP。如果只判断DPAD的四个keyCode，手柄用户就完全不能导航。除非项目明确不做手柄适配，否则建议把按键判断条件统一提取成config，方便后期扩展。

第四个坑：焦点离开后输入文字丢失。在某些TvInput框架里，EditText失焦时会把文本提交给输入框架，但如果你在onFocusChanged里做了setEditMode(false)，而且这个操作触发了文本监听，可能导致文字内容被清掉。解决办法是把文本保存操作放在onEditorAction里，明确由用户点击Next才提交，而不是失焦就提交。

6.3 调试输出的一个小技巧

任何焦点问题，先画一遍当前的焦点树。在Activity的onWindowFocusChanged里写个日志方法，遍历View树打印每个View的focusable和hasFocus状态。这一招比看堆栈快得多，TV屏幕上的焦点高亮有时候会被布局遮挡，你以为焦点在A，实际在B，日志一看就明白。

private void dumpFocusTree(ViewGroup root, int depth) { StringBuilder sb = new StringBuilder(); for (int i = 0; i < depth; i++) { sb.append(" "); } sb.append(root.getClass().getSimpleName()); sb.append(" focusable=").append(root.isFocusable()); sb.append(" hasFocus=").append(root.hasFocus()); // 可以再打印ViewId for (int i = 0; i < root.getChildCount(); i++) { View child = root.getChildAt(i); if (child instanceof ViewGroup) { dumpFocusTree((ViewGroup) child, depth + 1); } else { // 打印叶子View状态 } } }

7. 最后再分享一点实际体会

这个EditText焦点问题，单看代码量很小，但背后涉及Android焦点分发机制、输入法拦截、RecyclerView焦点竞争这几个层级，任何一个环节没考虑全面，就会导致线上用户反馈“遥控器乱跳”或者“焦点卡死”。我自己在好几个TV项目里反复遇到，每次换一种场景就多踩一个新坑，最后沉淀出的方案就是上面这套“编辑模式+方向键让行+上层兜底”的组合拳。如果你也是做TV应用开发，不用照着我的代码一字不差抄，关键是理解那几个分支为什么存在，然后根据你们产品的遥控器型号、输入法行为去调。调试的时候耐心一点，把事件日志打出来，看清楚了再动手改，这个问题的坑远没有你想象的那么深，但细节确实多。