企业官网建设流程全解析

1. AutoCompleteTextView 到底解决了我什么实际痛点

1.1 没有自动完成的年代，输入框让我有多头疼

早些年做工具类应用时，我遇到过一个特别现实的场景：给用户做城市选择。数据量大概三百多个城市，如果直接放一个 Spinner 下拉列表，用户从里面翻找要滚动很久；如果放一个 EditText 让用户自己敲，经常有人把"乌鲁木齐"打成"乌鲁木其"，匹配不上就白费功夫。就在这种进退尴尬的处境里，AutoCompleteTextView 这种"边输入边提示"的自动完成文本框，成了最合适的选择。

它本质上不是一个全新的控件，而是继承自 EditText，在普通输入框之上叠加了一层"输入联想"逻辑。用户敲入几个字符后，控件会拿当前已输入的文本去过滤一个预设的数据集合，然后在下拉面板中展示命中的候选条目，点击任意一条，就能把完整内容回填进输入框。这个交互模式在日常应用里太常见了——搜索框、邮箱输入、标签填写、城市选择、商品搜索记录，几乎都是这套逻辑。

所以开篇先明确适用范围：AutoCompleteTextView 适合"数据源已知、枚举值有限，用户希望少敲键盘"的场景。它的核心价值不是帮你做算法推荐引擎，而是把"从输入到命中"之间的体验鸿沟填平，让用户少打几个字、少犯几次拼写错误。这篇文章我会从零开始，讲清楚布局怎么写、适配器怎么接、数据怎么过滤、下拉样式怎么定制，以及实际项目中容易被忽略的配置细节和坑点。

1.2 输入框、下拉弹层、过滤触发，它是怎么配合工作的

我一直觉得，理解一个新控件最快的办法，是把它拆成三个部件来看。AutoCompleteTextView 可以简单地分三层认知：最表层的输入框，就是大家熟悉的 EditText 行为；中层是它内置的下拉弹层，由 PopupWindow 的思想演化而来；底层是一套"数据源 + 过滤器 + 回调接口"的组合逻辑。

在 Android 的源码结构里，AutoCompleteTextView 的核心成员很精简：一个数据集适配器 ListAdapter，一个数据过滤器 Filter，一个描述当前输入与候选集之间匹配规则的内部逻辑，以及一个下拉列表的展示容器。用户每敲一个字符，输入框文本发生变化，就会触发一次数据刷新请求。这个请求交给适配器持有的 Filter 对象执行过滤，再把过滤后的结果塞回下拉列表里重新渲染。

这套分工机制，让它和普通 EditText 有一个关键区别：EditText 只关心"用户输入了什么"，AutoCompleteTextView 额外关心"当前输入能关联到哪些候选"。所以它的数据层天然围绕 Adapter 转，布局里常见的 android:completionThreshold 属性，决定了用户至少要输入几个字符，下拉列表才肯露面。这个门槛设得太低，数据稍微多一点的场景，人还没打完一个字，匹配列表就先糊了一屏幕；设得太高，联想功能就形同虚设。某种程度上，AutoCompleteTextView 的调优过程，就是在这两个极端之间找平衡。

1.3 哪些场景它最顺手，哪些场景建议你换人

在实际开发里，我总结过几类适合它的典型用法。第一类是枚举型数据输入，比如性别、部门、车型、城市名称，数据量几百条以内，用 AutoCompleteTextView 能让输入速度明显提升。第二类是带历史记录的输入，比如搜索框联想用户之前搜过的关键词，数据量即便到几千条，只要做了本地过滤和索引，跑起来依然流畅。第三类是邮箱、域名、标签这类强规律文本，配合 MultiAutoCompleteTextView 多段输入，可以做到分段联想。

反过来说，如果数据源是几万条实时从服务器拉回来的商品列表，或者需要分词、拼音缩写、模糊音匹配这类复杂检索逻辑，AutoCompleteTextView 自带的 Filter 机制就不太够用了。它不是搜索引擎，它的过滤本质上是"给定一个字符串，在候选集里找出包含它的条目"。真要处理大规模模糊搜索，不如把数据和匹配逻辑拿到后端去做，再通过接口回传候选集，用自定义的 BaseAdapter 喂给它展示。选型想清楚了，后面写的每一行代码才不容易白费。

2. 搭一个能跑起来的自动补全，总共分几步

2.1 布局文件里的核心配置，一个都别漏

先从最直观的布局部分开始。AutoCompleteTextView 在 XML 里的声明方式和 EditText 几乎一致，因为它就是一个带增强功能的输入框。最基础的写法如下：

<AutoCompleteTextView android:id="@+id/actv_city" android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入城市名称" android:completionThreshold="1" android:dropDownWidth="match_parent" android:dropDownHeight="wrap_content" android:background="@drawable/bg_input_normal" />

这里有几个属性值得多说两句。completionThreshold 是指输入多少个字符后开始弹出联想，我建议至少设为 1，也就是说敲一个字就出现候选。这个值取决于你的数据源规模和控件的使用频率，搜索类场景可以设为 1，表单类场景我喜欢设成 2，因为像"广东"和"广西"这种一两个字就能命中的场景，候选列表太灵敏反而干扰用户输入。

dropDownWidth 和 dropDownHeight 是很多人忽略的点。默认情况下，下拉列表的宽度和输入框一致，但有些主题下会出现"宽度超出屏幕"的奇怪视觉问题，这时候给它显式设置一个 match_parent 或者制定一个具体的数值，通常会更快归一。dropDownVerticalOffset 可以调整下拉面板和输入框之间的空隙，某些界面上两个元素贴得太近，用这个属性加一点垂直间距之后，视觉上会舒服很多。

2.2 接入数据：为什么我首推 ArrayAdapter

对于基础入门场景，数据接入最简单的方式就是用 ArrayAdapter。这一步理解了，后面所有玩法都是在这条主线上做扩展。假设我要做一个城市联想，代码可以这样写：

AutoCompleteTextView actvCity = findViewById(R.id.actv_city); String[] cities = {"北京", "上海", "广州", "深圳", "成都", "杭州", "武汉"}; ArrayAdapter<String> adapter = new ArrayAdapter<>(this, android.R.layout.simple_dropdown_item_1line, cities); actvCity.setAdapter(adapter);

在两三行代码里，隐藏着几个容易被忽略的细节。构造方法里的那个布局资源 android.R.layout.simple_dropdown_item_1line，指定的是候选列表中每一行条目长什么样，默认就是一个黑底或白底的 TextView。如果你想要每一条候选都带个图标，或者左侧显示一个类型标签，那就要自己写布局文件，然后用 ArrayAdapter 的另一个构造方法或者干脆自定义 Adapter。

Kotlin 版的写法同样简洁：

val actvCity = findViewById<AutoCompleteTextView>(R.id.actv_city) val cities = arrayOf("北京", "上海", "广州", "深圳", "成都", "杭州", "武汉") val adapter = ArrayAdapter(this, android.R.layout.simple_dropdown_item_1line, cities) actvCity.setAdapter(adapter)

这里要提一个很实际的体验问题：ArrayAdapter 调用 toString() 来显示条目，如果是普通 String 列表自然没问题，可如果是自定义对象，比如一个 City 类包含中文名、拼音、代码多种字段，那么一定要正确覆写 toString()，否则下拉列表里会出现一串类似com.example.model.City@1a2b3c的乱码。很多人第一次用自定义对象做数据源时都会在这里卡住。

2.3 文本变化和候选命中，监听器应该怎么挂

自动补全的下拉展示是系统帮你搞定的，但交互的收尾动作经常需要开发人员介入。最常见的一个需求是：用户在下拉列表里选中了某个候选条目，接下来要立刻触发一次搜索或者跳转。这就需要挂监听。

actvCity.setOnItemClickListener((parent, view, position, id) -> { String selected = parent.getItemAtPosition(position).toString(); // 此时输入框里的文本已经被替换为 selected Toast.makeText(this, "选中了：" + selected, Toast.LENGTH_SHORT).show(); });

值得留意的是，OnItemClickListener 回调的时机，是在文本已经回填到输入框之后。所以在这个回调里取输入框文本，拿到的就是当前条目的内容，不需要再去 read 一遍 EditText 再赋值一次。如果你想在用户手动输入过程中做"实时搜索结果"的刷新，那就得用 TextWatcher 监听输入框的文本变化：

actvCity.addTextChangedListener(new TextWatcher() { @Override public void beforeTextChanged(CharSequence s, int start, int count, int after) {} @Override public void onTextChanged(CharSequence s, int start, int before, int count) { // 这里可以拿到实时输入内容做其他业务处理 } @Override public void afterTextChanged(Editable s) {} });

不过要提醒一句：TextWatcher 和 AutoCompleteTextView 自带的下拉过滤触发是并行的，不是替代关系。系统内置的过滤逻辑依旧会根据输入文本更新候选列表。如果你自己也发网络请求做联想，那就要把两种路径都想清楚，避免产生重复请求或者新旧数据交替导致的闪烁。

2.4 最容易被忽略的 Empty 状态处理

我遇到过不少同学做完自动补全后，私底下会吐槽"有时候没输入任何内容时，下拉列表也会弹出来"。这个现象其实还有一个常见的原因：没有显式控制下拉列表的显示条件。AutoCompleteTextView 的下拉列表弹出条件，结合了输入框是否获得焦点、输入文本长度是否达到 threshold，以及候选集是否为空。但在某些情况下，比如你设置了数据源，用户点击输入框后没输入任何字符，却发现下拉列表显示出来一整个全集，这通常是因为 threshold 被设置成了 0。

completionThreshold 设为 0 是合法的，但它的含义比较特殊：输入框一获得焦点就会展示所有候选集。这个行为不一定是最佳产品设计。如果你希望用户输入才联想，就得把 threshold 设置成大于等于 1。真要让下拉列表关掉，也没必要去改适配器数据，直接调用 dismissDropDown() 即可，代码干净简单。

3. 数据过滤机制：自动补全背后的工作原理与定制空间

3.1 从字符变化到列表刷新，中间到底发生了什么

很多做客户端开发的朋友对 AutoCompleteTextView 的使用停留在"setAdapter 就能跑"的阶段，并不知道它内部做了哪些事。当我第一次去翻源码的时候，我才意识到这套联想的链路值得理清。用户敲入一个字符，InputConnection 把文本变更事件传递到视图层，AutoCompleteTextView 内部实现了一个 TextWatcher，监听 afterTextChanged，紧接着它会检查当前文本的长度与 completionThreshold 的配置。如果长度不够，直接取消下拉显示；如果长度达标，就从当前适配器里取数据过滤器 Filter，发起一次异步过滤。

Filter 的过滤动作有个引用计数和同步锁的机制。简单说，如果用户输入速度很快，前一秒发出的过滤请求还没返回，新的请求又产生了，系统会通过一个计数器丢弃过期的结果，只接受最新一次过滤请求的回调。UI 线程因此不会被大量无效的 data set 变化阻塞。过滤完成后，结果通过 publishResults 回到 UI 线程，适配器重新绑定数据，然后自动弹出下拉面板。整个过程，主线程不参与复杂的字符串匹配计算，所以即使候选集有上千条数据，输入响应也不会卡顿。

理解这条链路的意义在于，当你在排查"为什么我的输入卡了一下"、"为什么过期的候选数据会闪一下"这类问题时，会自然而然地往 Filter 的异步机制上想，而不是先去怀疑布局渲染。而且你也知道，如果数据源非常大，真正的瓶颈可能不在过滤本身，而是每次过滤都要对整个 List 做一次线性遍历。

3.2 默认过滤规则：contains、忽略大小写、还是前缀匹配

ArrayAdapter 内置的过滤逻辑，是通过一个 ArrayFilter 内部类实现的。这个过滤器从候选集合中取词，然后逐个检查：只要候选字符串包含当前输入的文本，就会被保留。这个"包含"是忽略大小写的，也就是说输入 "an" 可以匹配到 "Android"、"Hangzhou"、"Shanghai" 里的 "an"。如果你期望的是一种"必须从头开始匹配的搜索"，那这个默认逻辑就不满足需求了。

ArrayFilter 的匹配规则在不同 Android 版本上有过细微调整，但大方向一致：把输入文本转成小写，把候选文本转成小写，然后用 indexOf 判断是否包含。这个过程对中英文同样有效，对拼音则无能为力。你想让用户输入全拼或首字母时也能联想出中文候选，那就不能指望默认过滤，需要自定义 Filter 重写过滤规则，或者把拼音字段也写在候选对象的 toString 里，让系统去做包含匹配。

我曾经在一个联系人选择页面做过一个比较简单的优化：把每个联系人对象 toString() 返回成“姓名 拼音首字母 手机号”的拼接串。这样用户在输入名字的拼音首字母时，由于包含了这些字符，也能在默认过滤器中得到命中的结果。这种方案的优点是零成本，缺点是不够精准，输入 "zh" 会把很多既含 "zh" 也含 "sh" 的对象都捞出来。精准一点的做法，还是得自己写 Filter。

3.3 自定义 Filter：打破默认规则的唯一入口

如果你决定自己控制过滤规则，思路就清晰了。ArrayAdapter 内部通过 getFilter() 返回一个 Filter，你只需要覆写 performFiltering 和 publishResults 两个方法。下面是一个简单的自定义 Filter 示例，匹配规则从"包含"改成"前缀匹配"：

public class PrefixFilter extends Filter { private List<String> sourceData; private List<String> filteredData; public PrefixFilter(List<String> sourceData) { this.sourceData = sourceData; } @Override protected FilterResults performFiltering(CharSequence constraint) { FilterResults results = new FilterResults(); List<String> match = new ArrayList<>(); if (constraint == null || constraint.length() == 0) { match.addAll(sourceData); } else { String keyword = constraint.toString().toLowerCase(); for (String item : sourceData) { if (item.toLowerCase().startsWith(keyword)) { match.add(item); } } } results.values = match; results.count = match.size(); return results; } @Override protected void publishResults(CharSequence constraint, FilterResults results) { filteredData = (List<String>) results.values; notifyDataSetChanged(); // 注意：这里需要重新给 adapter 的内部数据源赋值 } }

这里的关键点是 publishResults 之后必须调用 notifyDataSetChanged 才能让列表刷新。很多新手写自定义 Filter 时忘了这一行，导致过滤结果永远不显示。而 arraylist 的过滤还有一些边界情况：如果 constraint 为空字符串，应当如何处理，是展示全部还是展示空列表？这个完全取决于你自己的业务判断，没有标准答案。在我的项目里，我倾向于 constraint 为空时也展示全部，作用是用户一点击输入框就可以看到完整的可选项，形成一种"快捷选择面板"的体验。

自定义 Filter 的另一个常见用途是去服务端查询。你只需要在 performFiltering 里把 constraint 当参数请求后端接口，同步等待结果返回，然后封装成 FilterResults。但注意，performFiltering 是执行在后台线程的，你不能在这里直接更新 UI；只能在 publishResults 中回到主线程刷新适配器。如果你用 Retrofit 的异步回调来请求，那就不能在 performFiltering 里直接 publish，要绕一层处理。这种场景我建议直接放弃系统自带的 Filter，用一个普通 EditText 配合 RecyclerView 做手动实现，或者对 AutoCompleteTextView 做一层封装，反而更自由。

4. 定制下拉列表的显示，让自动补全更贴近业务审美

4.1 自定义条目布局：从简单一行文本到图文混排

用默认的 simple_dropdown_item_1line 布局时，下拉面板里只有一行文字，看起来单调，跟应用的整体风格经常不搭。真正业务里我更常用的是自定义列表项布局。比如做一个搜索历史联想，我希望每条候选左侧是时钟图标，右侧是搜索关键词，再往右一个删除图标。这种需求下，自定义 Adapter 是躲不开的。

写自定义 Adapter 的原则是，继承 BaseAdapter 或 RecyclerView.Adapter 都行，但如果你只是想微调布局样式，更简单的做法是直接继承 ArrayAdapter 并覆写 getView。下面这个例子能说明最基本的思路：

public class CityAdapter extends ArrayAdapter<City> { public CityAdapter(Context context, List<City> cities) { super(context, 0, cities); } @Override public View getView(int position, View convertView, ViewGroup parent) { if (convertView == null) { convertView = LayoutInflater.from(getContext()) .inflate(R.layout.item_city, parent, false); } TextView nameView = convertView.findViewById(R.id.tv_city_name); TextView codeView = convertView.findViewById(R.id.tv_city_code); City city = getItem(position); nameView.setText(city.getName()); codeView.setText(city.getCode()); return convertView; } }

这个 getView 里最需要注意的，是 convertView 的复用逻辑。系统通过复用旧视图大幅度减少 inflate 开销，如果你每次都在 getView 里重新创建视图，列表滑动一快，帧率一定往下掉。一个小习惯：把能用 final 声明的子视图都在首次创建时缓存下来，或者使用 ViewHolder 模式。

4.2 给命中文本加高亮色，用 SpannableString 提升体验

自动补全的下拉列表里，用户最关心的是"我打的字有没有命中间谍"。很多搜索类应用会把命中的关键字在候选条目里标成高亮色，这样做有一个好处：用户能直观地确认这条联想真的跟自己输入的文字有关。

实现思路也有多种。最简单的，是在自定义 Adapter 的 getView 里用 SpannableString 给关键字上色：

String displayText = city.getName(); SpannableString spannable = new SpannableString(displayText); String keyword = getFilter().convertResultToString(getItem(position)); // 这里取的是当前输入关键字 int index = displayText.toLowerCase().indexOf(keyword.toLowerCase()); if (index >= 0) { spannable.setSpan(new ForegroundColorSpan(0xFF2196F3), index, index + keyword.length(), Spanned.SPAN_EXCLUSIVE_EXCLUSIVE); } nameView.setText(spannable);

这段代码每次 getView 时执行一次文本拼接。注意一个坑：我们在这里取"当前输入关键字"时，不能直接读 getText() 拿输入框的文本，因为某些情况下点击候选项后输入框文本会被替换成候选全文，导致高亮位置计算错误。更好的做法是给自定义 Adapter 单独存一个字段，在 setFilterText 或者数据更新时记录当前过滤关键字，这样高亮始终跟随用户真实输入。

4.3 控制下拉面板：宽高、分隔线、最大高度和动画

基础布局之外，AutoCompleteTextView 暴露了一些可直接调用的方法，帮你微调下拉展示行为。setDropDownWidth() 设置下拉面板宽度，setDropDownHeight() 设置高度，setDropDownVerticalOffset() 设置垂直偏移量。如果你希望下拉面板有分隔线或者淡入动画，就得动它的底层属性。

下拉面板的淡入淡出可以通过设置 android:dropDownAnimationStyle 来实现，比如我经常写：

<style name="DropdownAnimation"> <item name="android:windowEnterAnimation">@anim/dropdown_enter</item> <item name="android:windowExitAnimation">@anim/dropdown_exit</item> </style> <AutoCompleteTextView android:dropDownAnimationStyle="@style/DropdownAnimation" />

分隔线通常通过 android:dropDownSelector 设置，也可以把下拉面板当作一个 ListView 来理解。其实它内部确实持有一个 ListView 对象，通过 setDropDownBackgroundResource() 就能设置背景和分隔线资源。当列表项数量很多时，为了防止下拉面板超出屏幕，可以用 setDropDownHeight(dp2Px(300)) 限制一个固定的最大高度；设置成 wrap_content 时系统会自己根据条目数量调整高度，但偶尔也会因为键盘弹出导致遮挡。高度计算这里，我建议在布局文件里直接写一个最小值和最大值，至少保证屏幕上能看到 4 到 5 个候选条目。

5. MultiAutoCompleteTextView：同门师兄，多段输入的补全

5.1 邮箱输入和标签填写里，它的价值比 AutoCompleteTextView 更高

AutoCompleteTextView 是整段文本做联想，用户在任意位置输入时，拿整段输入去过滤候选。但遇到"多个邮箱一起写"或者"多个标签一起输入"这种场景，它就不够用了。比如让用户填写收件人邮箱，格式可能是 "alice@163.com, bob@gmail.com"，用户希望逗号之后换一个新的片段，仍然能对每个片段分别联想。这种场景就轮到 MultiAutoCompleteTextView 上场。

MultiAutoCompleteTextView 继承自 AutoCompleteTextView，核心差异在于它多了一个 Tokenizer 的概念。Tokenizer 的作用是把当前输入框的文本拆分成"多个片段"，并且告诉控件当前光标所在的片段是哪一个。内置实现有 MultiAutoCompleteTextView.CommaTokenizer，以逗号作为分隔符。有了它，每次输入联想时只针对逗号后面的那一段英文地址做匹配，而不是把整串都拿来匹配，联想结果的准确度一下子就上来了。

假设我的邮箱收集场景，候选邮箱列表是有线的常用域名列表，比如 163.com、gmail.com、qq.com，那么布局和代码可以这样写：

<MultiAutoCompleteTextView android:id="@+id/actv_emails" android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入收件人邮箱，多个邮箱用逗号分隔" android:completionThreshold="1" />

MultiAutoCompleteTextView actvEmails = findViewById(R.id.actv_emails); String[] emails = {"163.com", "gmail.com", "qq.com", "outlook.com", "icloud.com"}; ArrayAdapter<String> emailAdapter = new ArrayAdapter<>(this, android.R.layout.simple_dropdown_item_1line, emails); actvEmails.setAdapter(emailAdapter); actvEmails.setTokenizer(new MultiAutoCompleteTextView.CommaTokenizer());

这里有一个小坑：CommaTokenizer 内部判断分隔符时用的是英文逗号，如果你在中文输入法下习惯打全角逗号“，”作为分隔，CommaTokenizer 不会把它当作分隔，于是整个 "alice@163.com，gmail.com" 都会被当作一个输入片段，导致联想失效。所以如果业务支持中文逗号，最好自定义一个 Tokenizer。

5.2 写一个支持中文逗号的自定义 Tokenizer

自定义 Tokenizer 并不复杂，Tokenizer 接口一共三个方法：findTokenStart、findTokenEnd、terminateToken。理解这三个方法的意思，就能完全控制分段逻辑。

findTokenStart 从光标位置往前找到上一个分隔符，返回当前片段的起始位置；findTokenEnd 从某个位置向后找这段文本的结束位置；terminateToken 则用于描述一个片段结束后，应该在文本尾部拼接什么分隔符。下面是一个支持中英文逗号的简单实现：

public class ChineseCommaTokenizer implements MultiAutoCompleteTextView.Tokenizer { @Override public int findTokenStart(CharSequence text, int cursor) { int i = cursor; while (i > 0 && text.charAt(i - 1) != ',' && text.charAt(i - 1) != '，') { i--; } return i; } @Override public int findTokenEnd(CharSequence text, int cursor) { int i = cursor; while (i < text.length() && text.charAt(i) != ',' && text.charAt(i) != '，') { i++; } return i; } @Override public CharSequence terminateToken(CharSequence text) { int i = text.length(); while (i > 0 && (text.charAt(i - 1) == ',' || text.charAt(i - 1) == '，')) { i--; } if (text instanceof Spanned) { Spannable sp = new SpannableString(text.subSequence(0, i) + "，"); return sp; } return text.subSequence(0, i) + "，"; } }

这个实现虽然短，但已经把 Tokenizer 的交互细节吃透了。注意 terminateToken 里面必须处理 Spannable 的情况，否则选中候选条目后文本样式可能丢失。很多从 AutoCompleteTextView 刚转过来的人都会漏掉这个判断，导致输入提示"颜色花掉"。

5.3 多段输入的筛选逻辑：只看当前段，不碰前几段

MultiAutoCompleteTextView 的过滤逻辑，建立在 Tokenizer 之上。每次输入文本变化，它会先拿到光标所在的 token 范围，然后用这个范围内的文字去过滤候选集。这跟 AutoCompleteTextView 的全局过滤完全不一样，所以如果你使用很长的整段文本，千万不要再往里塞关键字数据，否则前几个片段的结尾很容易被包含进当前 token，过滤结果错乱。

实际测试中，我给这个邮箱输入框接入了上千个域名候选，配合自定义 Tokenizer，用户的体验和原生 Gmail 的收件人输入几乎一致。另外一个注意点是，多段输入场景里，如果用户在片段中间插入文本或者删除某个片段，Tokenizer 的切换也要跟上光标位置，否则输入不流畅。这类问题本质上都是 Tokenizer 返回值不够严谨导致的，排错时先打日志看 findTokenStart 返回的位置是否符合预期。

6. 实测中绕不开的三类问题：键盘遮挡、性能卡顿、误触选择

6.1 输入法弹窗和下拉面板打架，怎么协调才不跳屏

AutoCompleteTextView 的下拉面板本质是悬浮在窗口上的，所以当输入法弹出时，面板必然需要根据屏幕底部的可用空间重新计算位置。我这里遇到过最典型的问题是：键盘弹出后，下拉面板有一部分被键盘盖住，用户看不到完整的候选列表。

解决思路有几条。最常用的，是在 AndroidManifest.xml 中给 Activity 设置 windowSoftInputMode 为 adjustResize，让整个布局在键盘弹出时重新分配空间，下拉面板随之被顶上去。不过有时 adjustResize 在横屏或全屏模式下不一定生效，你需要检查状态栏和导航栏的配置。另一个思路，是动态计算输入框在屏幕中的位置，然后给下拉面板设置一个合适的高度。粗笨但可靠的办法是做成"输入时全屏弹层"，把完整候选列表放到一个 Dialog 或 Fragment 中展示，这样天然避免键盘遮挡问题。

这些方案选型的根据很简单：表单页面条目少，优先用 adjustResize；搜索页面要显示大量联想结果，优先用独立弹层；横屏适配紧张的项目，干脆给下拉面板一个固定最大高度，比如键盘上方的 60% 空间。没有万能解，只有最匹配场景的手感。

6.2 候选集很大时，内存和卡顿怎么平衡

AutoCompleteTextView 内置的 ArrayAdapter 在数据量很大时有一个内存隐患：每次过滤都会复制一份 List 对象，如果用户连续删除再输入，频繁创建中间 List 会造成一定的 GC 压力。我在一个城市选择页里塞了 3000 多个乡镇名称，用默认 ArrayAdapter 跑，明显能感觉到输入时偶发卡顿。

性能优化的第一个方向是限制候选集规模。用户输入的过滤结果，最多展示前 20 条或者前 50 条，超出部分直接截断。这既保证了 UI 渲染流畅，也更符合用户预期——没人会把几百条候选翻完，尤其在下拉列表这种一屏只能放七八条的空间里。第二个方向是复用自定义数据源和 Filter，避免每次过滤都新建 Filter，也不要在 performFiltering 里做重量级对象创建。第三，如果数据源本身超过一定规模，比如上万条，我建议把数据预加载到一个 HashMap 索引中，过滤时用二分查找或者直接遍历索引，而不是每次都拿 List 遍历匹配。

另外还有一个关于渲染的细节：自定义 getView 时，尽量避免在条目布局里做过多嵌套层级。单个条目用一个根布局，TextView 和 ImageView 直接平铺，不要把条目设计成三层嵌套的复杂卡片。下拉列表的滚动性能会因此受益明显。

6.3 OnItemClick 的误触与数据回填时机，别在这里踩坑

AutoCompleteTextView 的 OnItemClick 回调里，系统已经把选中值回填到输入框了。这里有一个隐蔽的问题：如果用户在下拉面板上用方向键或触控笔移动光标，按 Enter 可能会触发默认的点击行为，导致选中的值和回填文本不一致。这个问题在模拟器上复现过几次，最后是打开 onKeyDown 处理，主动拦截 ENTER 键事件才稳住。

另外，有些业务会同时监听 TextWatcher 和 OnItemClick。请留意 TextWatcher 在 OnItemClick 之后也会被再次触发，因为回填文本是一次文本变更。如果你在 TextWatcher 里发起了网络请求，那么用户点击候选条目时，就可能在 setText 的过程中又触发一个额外请求。这种"双触发"在列表类页面上简直防不胜防。我的经验是，在 onItemClick 里设置一个标志位，告诉 TextWatcher 本次文本变化是程序引起的，忽略掉这次回调；或者干脆把所有业务逻辑收敛到 onItemClick 里，不再监听 TextWatcher。

这类交互细节没有标准答案，核心是理解事件触发顺序：用户点击条目，先更新输入框文本，再触发 TextWatcher，最后回调 onItemClick。你设计逻辑时，要清楚当前处于哪个时机，才能避免数据源来回覆盖的困惑。

7. 最后再分享一个实用思路：用动态数据源把它做成真联想的入口

我把 AutoCompleteTextView 用在搜索记录联想中的一个做法，是一个很好的收尾。搜索历史通常保存在本地数据库里，数据量不大但更新频繁。我的项目里先用 Room 查最近 20 条历史，存入 ArrayList，再创建一个 ArrayAdapter 放进 AutoCompleteTextView。用户每搜索一次，就会把新词插到列表头部并更新数据库，下一次进入页面时，输入框获得焦点不输入字符，历史记录就能以候选列表的形式自动弹出来。这个交互对整个产品来说，几乎完全不增加门槛，但用户每天的搜索成本直线下降。

如果新词插入位置在头部，记得在更改列表后立即调用 adapter.notifyDataSetChanged()。此时过滤并没发生，系统不会自动刷新下拉列表，不调用的话用户看不到这次更新。还有一点，动态数据源状态下，用户的输入可能命中零候选，那时下拉列表会自动关闭，不用额外处理。但如果你希望在这种状态给出一个提示文案，比如"无匹配记录"，就需要在自定义 Adapter 里返回一个空文本占位条目，再结合 setOnClickListener 做提示，这套扩展玩法彻底跑通了，数据的流转闭环也就完整了。

每次我在新项目里再接触到输入联想需求时，都会优先想起 AutoCompleteTextView 这套机制。多数场景下它已经足够可靠，剩下的功夫都在于你对布局细节、适配器选型和事件时序的把控。按上面的顺序一步步搭，我相信你也能很快把它跑顺，并找到自己业务里最顺手的那套用法。