简介这份《Android实现聊天机器人——课程设计报告》面向移动应用开发课程设计阶段的学生适合需要完成聊天机器人App选题、撰写规范课设报告或梳理Android综合实践思路的读者。压缩包共1个doc文件约1.46MB以Word文档形式完整呈现实验目的、实验内容、程序设计与说明并配有各界面设计思路、类说明和运行界面截图。报告围绕图灵机器人平台API接入展开涉及聊天界面线性布局与左右消息条目样式、欢迎信息配置、ChatBean对消息状态与内容的封装、ChatAdapter数据适配、OkHttp网络请求及Json解析回显还说明了初始化、显示、发送、获取回复、更新界面五类方法的分工与后退键退出处理。已有2708人学习可作为课程设计报告的框架参照和功能模块自查清单帮助读者理解从界面搭建到网络通信的完整实现脉络。1. 一份能直接交的 Android 聊天机器人课程设计报告值不值得拆开看期末前两周某高校移动应用开发课的作业习题里通常会挂一道“做一个能对话的安卓app”不少人的第一反应是搜现成源码下载解压之后发现包里只有几张运行截图布局文件、适配器、网络请求全是空的。这份安卓app课程设计报告的价值就在完整度上从申请机器人身份标识、写 activity_main、定义 ChatBean、实现 ChatAdapter到用 OkHttp 请求服务端再解析 JSON 回填列表整条链路没有断点报告里的类说明和截图能一一对上代码。它适合三类人——赶课程设计报告 deadline 的学生、第一次碰 Android 网络编程想找个最小闭环的初学者、以及需要一份现场能演示 demo 的答辩党。资源达人分享计划里这类“报告 配套源码”的组合不算少见但能把方法分工、布局结构和运行效果对应得这么细的拆起来才有点意思。2. 把报告拆成可交付的模块依赖、四个类和一张文件对应表拿到这种“文档 源码”配套的资源最忌讳的就是直接双击打开工程然后一路点运行。报告写的是设计思路源码写的是实现细节中间那层“哪个文件负责哪件事”的映射关系如果没建立起来改一个功能就会牵动三四个文件最后连自己都说不清改坏了什么。合理的拆法是先钉环境依赖再定数据结构最后才动网络层——顺序反了必返工。2.1 报告章节和工程目录怎么对上报告的三级结构很清楚3.1 设计思路写的是布局文件3.2 类的说明写的是 MainActivity、ChatBean、ChatAdapter3.3 是运行截图。把这三节翻译成 Android Studio 里的实际路径大概是这样一张表报告里的描述工程中的实际文件承担的作用activity_main 聊天界面布局res/layout/activity_main.xml标题栏、消息列表、输入区三段式骨架chatting_left_item 机器人气泡res/layout/chatting_left_item.xml机器人头像 左侧消息文本chatting_right_item 用户气泡res/layout/chatting_right_item.xml用户头像 右侧消息文本消息实体类java/包名/ChatBean.java消息状态、内容、时间三个字段数据适配器java/包名/ChatAdapter.javaListView 与 ChatBean 列表之间的桥梁界面交互逻辑java/包名/MainActivity.java五个方法串起发送、请求、解析、刷新这张表看着朴素但它是后面所有改动的坐标系。比如你想把气泡改成圆角矩形只需要动两个 item XML 和对应的 drawable想把 ListView 换成 RecyclerView只动 ChatAdapter 和 activity_mainChatBean 和 MainActivity 里的网络方法基本不动。很多课程设计报告写得漂亮但代码一改就崩问题往往出在没有这条边界。顺着这张表还有一个隐含的收益报告里的运行截图可以直接当验收清单用。截图里出现了欢迎语、数字回复、字母接龙、单字“额”这几种情况说明作者至少测过纯文本、纯数字、连续短句和无意义输入四类场景你在自己机器上跑的时候照着这四类过一遍基本能覆盖 80% 的低级错误。2.2 环境依赖先钉死别边写边升这类课程设计报告的资源最大的坑不是代码逻辑而是版本。报告里明确写了用 okhttp 3.12.0这是个关键信号——说明示例代码是按 OkHttp 3.x 的 API 写的而 3.x 和 4.x 在 RequestBody 的构造上有签名变化随手在 Dependencies 里点一下“升级到最新”编译能过但运行行为会变。// app/build.gradle android { compileSdkVersion 28 defaultConfig { applicationId com.example.chatrobot minSdkVersion 21 // 21 以上 runOnUiThread、OkHttp 都没有兼容问题 targetSdkVersion 28 // 与报告保持一致避免明文流量策略差异 versionCode 1 versionName 1.0 } } dependencies { // 报告指定版本不要随手升到 4.x implementation com.squareup.okhttp3:okhttp:3.12.0 implementation com.android.support:appcompat-v7:28.0.0 }这里有三处参数值得说清楚。minSdkVersion 21是因为 OkHttp 3.12 的最低要求是 API 21同时runOnUiThread在这个级别上行为稳定不需要额外做线程兼容。targetSdkVersion 28是重点Android 9 开始默认禁止明文 HTTP 请求如果平台给的接口地址是 http 开头targetSdk 提到 28 以上就会直接抛CLEARTEXT communication not permitted而报告里是不会写这一条的。compileSdkVersion 28则要和 appcompat 版本对齐混用 28 和 29 的 support 库会在资源合并阶段报错。权限和 Activity 声明也得在 AndroidManifest 里补齐少一行 INTERNET后面所有网络问题都会表现得像“接口挂了”!-- AndroidManifest.xml -- uses-permission android:nameandroid.permission.INTERNET / application ... activity android:name.MainActivity android:windowSoftInputModeadjustResize !-- 键盘弹出时压缩布局不遮挡输入框 -- intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity /applicationadjustResize这个属性很多人不加后果是软键盘弹起来把输入框和发送按钮一起盖住演示的时候特别尴尬。它配合 activity_main 里给列表区域设的layout_weight1才能形成“键盘顶起、列表压缩、底部固定”的正确布局行为。2.3 ChatBean 的字段设计和五个方法的职责ChatBean 是整份报告里最容易被低估的一个类。它看起来只是个普通 JavaBean但字段设计直接决定了适配器怎么写、布局怎么分。public class ChatBean { public static final int TYPE_SEND 1; // 用户发出的消息 public static final int TYPE_RECEIVE 2; // 机器人回复的消息 private int state; // 取值 1 或 2决定加载左边还是右边布局 private String content; // 气泡里显示的文本 private String time; // 可选用于在气泡下方显示时间戳 public ChatBean(int state, String content) { this.state state; this.content content; } public int getState() { return state; } public void setState(int state) { this.state state; } public String getContent() { return content; } public void setContent(String content) { this.content content; } public String getTime() { return time; } public void setTime(String time) { this.time time; } }把state定义成 1 和 2 而不是 0 和 1是报告里一个挺有意思的选择语义上更直观读代码时“1 是我发的、2 是对方发的”比“0 和 1”好记。但它和 ListView 的多布局机制对不上getItemViewType要求返回值落在[0, getViewTypeCount())区间内所以适配器里必须做一次减一转换这个转换点后面第 5 章还会专门说。再看 MainActivity 里的五个方法报告的原文只给了名字和一句话说明实际写下来每个方法的输入输出是这样的方法输入输出 / 副作用initView()无绑定 ListView、EditText、Button初始化适配器和数据集合showData()无从 strings.xml 随机取一条欢迎语作为 TYPE_RECEIVE 消息插入列表sendData()输入框文本校验非空、生成 TYPE_SEND 消息、清空输入框、触发网络请求getDataFromServer()用户文本发起异步请求成功后回调解析函数updateView()回复文本生成 TYPE_RECEIVE 消息、通知适配器、滚动到底部这个拆法比“把所有逻辑塞进 onClick”要好得多理由不是“代码规范”这种空话而是它把一次交互拆成了可独立测试的四段输入校验、网络请求、JSON 解析、UI 刷新。哪一段出问题Logcat 里对应的日志位置是明确的。常见做法是在每个方法入口打一条Log.d(TAG, ...)跑一次完整对话就能看出流程断在哪。3. 界面落地三段式布局、左右气泡和 ChatAdapter 的复用写法界面这一块课程设计的评分点往往不在“好看”而在“结构清楚、能解释为什么这么写”。报告里用的 ListView 加 BaseAdapter 是相当经典的组合虽然现在新项目普遍用 RecyclerView但拿它来讲清楚“多布局 视图复用”这件事反而比 RecyclerView 更直白因为 RecyclerView 把 ViewHolder 和回收逻辑都封装进框架了看不见。3.1 activity_main 的三段式骨架布局结构报告里描述得很明确最外层线性布局顶部一个 TextView 显示会话标题中间一个 RelativeLayout 装 ListView底部一个小的 RelativeLayout 装 EditText 和 Button。落到 XML 上关键是中间那块要吃掉剩余高度。!-- res/layout/activity_main.xml -- LinearLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightmatch_parent android:orientationvertical android:background#F5F5F5 !-- 第一段标题栏固定高度 -- TextView android:layout_widthmatch_parent android:layout_height48dp android:gravitycenter android:text聊天窗口 android:textSize18sp android:background#FFFFFF / !-- 第二段消息列表weight1 吃掉中间全部剩余空间 -- ListView android:idid/lv_chat android:layout_widthmatch_parent android:layout_height0dp android:layout_weight1 android:dividernull android:dividerHeight0dp android:listSelectorandroid:color/transparent android:transcriptModenormal / !-- 第三段输入区高度自适应键盘弹起时被顶起 -- RelativeLayout android:layout_widthmatch_parent android:layout_heightwrap_content android:padding8dp android:background#FFFFFF EditText android:idid/et_input android:layout_widthmatch_parent android:layout_heightwrap_content android:layout_toLeftOfid/btn_send android:hint说点什么吧 android:maxLines3 android:inputTypetext / Button android:idid/btn_send android:layout_width72dp android:layout_heightwrap_content android:layout_alignParentRighttrue android:text发送 / /RelativeLayout /LinearLayoutlayout_height0dp加layout_weight1是这段布局的核心它让 ListView 的高度等于父容器减去标题栏和输入区而不是被内容撑开。如果误写成wrap_content消息一多列表就会顶出屏幕底部输入区直接看不见。dividernull和listSelector设为透明属于细节优化。ListView 默认带分隔线点击时还有一块灰色高亮聊天界面里这两样都很突兀。同理transcriptModenormal让列表在数据变化时保持底部对齐配合后面手动调用滚动方法能避免新消息藏在屏幕外。EditText 的maxLines3和inputTypetext也不是随便设的前者限制输入框最多长高三行防止用户输入一大段文字把输入区挤满后者关掉回车换行让软键盘上显示的是“发送”而不是“换行”。在很多课程设计里这两项没设好评审老师一句“输入多行会怎样”就能问住人。3.2 左右气泡与 selector 背景两个 item 布局的结构几乎一样都是 RelativeLayout 套一个 ImageView 和一个 TextView差异只在头像资源、TextView 的对齐方向、以及背景 drawable。左边机器人消息的写法大致如下!-- res/layout/chatting_left_item.xml -- RelativeLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightwrap_content android:padding8dp ImageView android:idid/iv_robot_head android:layout_width40dp android:layout_height40dp android:srcdrawable/robot_head android:layout_alignParentLefttrue android:layout_alignParentToptrue / TextView android:idid/tv_chat_content android:layout_widthwrap_content android:layout_heightwrap_content android:layout_toRightOfid/iv_robot_head android:layout_marginLeft8dp android:maxWidth260dp android:padding10dp android:textSize15sp android:textColor#333333 android:backgrounddrawable/chat_left_selector / /RelativeLayout右边那份只需要把layout_alignParentLeft换成alignParentRight、layout_toRightOf换成layout_toLeftOf、背景换成chat_right_selector。报告里说的 “style 里写好的格式文件” 指的是把 padding、textSize、maxWidth 这些公共属性抽成一个 style在两个 item 里引用改一次两边都生效。maxWidth260dp是个很实用但常被忽略的属性。不设它机器人回一段长文本时长气泡会横穿整个屏幕把头像挤到边缘视觉上很难看。260dp 大概对应 1080p 屏幕上三分之二的宽度超过就自动换行。selector 文件负责按压态和默认态的颜色切换!-- res/drawable/chat_left_selector.xml -- selector xmlns:androidhttp://schemas.android.com/apk/res/android item android:state_pressedtrue shape android:shaperectangle solid android:color#DDDDDD / !-- 按下时变深 -- corners android:radius8dp / /shape /item item shape android:shaperectangle solid android:color#FFFFFF / !-- 默认白色气泡 -- corners android:radius8dp / stroke android:width1dp android:color#E0E0E0 / /shape /item /selector用 shape 画背景比用 9-patch 图片省事圆角和描边参数直接写在 XML 里改颜色不用重新切图。缺点是做不出带小尖角的气泡如果课程设计想加分可以把 shape 换成.9.png但要注意切图时留好拉伸区域否则不同长度的文字会把圆角拉变形。3.3 ChatAdapter多布局复用的正确姿势适配器是这块最容易翻车的地方。报告里提到“getView 方法内用 if 和 else 判断当前消息是发送还是接收不同消息加载不同的 view”这句话只说了表象没说不重写getViewTypeCount会出什么事。public class ChatAdapter extends BaseAdapter { private static final int TYPE_COUNT 2; // 两种布局 private final ListChatBean data; private final LayoutInflater inflater; public ChatAdapter(Context context, ListChatBean data) { this.data data; this.inflater LayoutInflater.from(context); } Override public int getCount() { return data.size(); } Override public Object getItem(int position) { return data.get(position); } Override public long getItemId(int position) { return position; } // 关键告诉 ListView 有几种 item 布局 Override public int getViewTypeCount() { return TYPE_COUNT; } // 关键state 是 1/2必须转成 0/1 才能落在合法区间 Override public int getItemViewType(int position) { return data.get(position).getState() - 1; } Override public View getView(int position, View convertView, ViewGroup parent) { int type getItemViewType(position); ViewHolder holder; if (convertView null) { holder new ViewHolder(); if (type 0) { convertView inflater.inflate(R.layout.chatting_left_item, parent, false); holder.head convertView.findViewById(R.id.iv_robot_head); } else { convertView inflater.inflate(R.layout.chatting_right_item, parent, false); holder.head convertView.findViewById(R.id.iv_my_head); } holder.content convertView.findViewById(R.id.tv_chat_content); convertView.setTag(holder); // 缓存视图引用 } else { holder (ViewHolder) convertView.getTag(); } ChatBean bean data.get(position); holder.content.setText(bean.getContent()); return convertView; } static class ViewHolder { ImageView head; TextView content; } }逐段看逻辑。getViewTypeCount()返回 2是告诉 ListView 内部维护两个回收池左气泡和右气泡各自复用不会串。如果不重写默认返回 1只有一个池子那么当getItemViewType返回 1 时ListView 会直接抛ArrayIndexOutOfBoundsException崩溃日志停在AbsListView.obtainView那一行很多人对着它发呆半天也想不到是这里。getItemViewType里的- 1是配套的state 定成 1 和 2 是为了可读性但类型索引必须从 0 开始。这两处是一对改一个不改另一个必崩。if (convertView null)的判断配getItemViewType使用时有个前提ListView 保证同一个回收池里的 convertView 类型一致所以在这个分支里按 type 加载布局是安全的。反过来如果没重写 type 相关方法就得在 if 外面判断当前 convertView 的布局是否匹配代码会脏很多。inflate(R.layout.xxx, parent, false)里第三个参数必须传 false。传 true 会把 item 视图直接挂到 ListView 上抛IllegalStateException不传用两参重载则丢失父容器的布局参数item 的宽度会变成 wrap_content气泡贴不到边。ViewHolder是纯优化把findViewById的结果缓存进 tag省掉滚动时反复查找。消息少的时候感觉不出来滑到几十条就能明显看到掉帧。4. 打通对话链路OkHttp 请求、JSON 取值和主线程回写前两章做的是“看得见的部分”这一章开始碰“看不见的部分”。报告里这部分只有寥寥几句——“机器人会根据用户发送的聊天内容从服务器上获取回复信息并将获取的回复信息通过 Json 解析显示到界面上”——但实际代码量占到整个工程的一半以上出错概率也最高。Android 的网络编程有几个固定门槛权限、线程、请求体格式、响应解析、UI 线程回写任何一环没接好表现都是同一个点了发送什么也没发生。4.1 先确认身份标识和请求体长什么样报告第一步就是“申请机器人身份标识”在开放平台注册后创建机器人拿到一个 Key。这个 Key 的作用是把请求归到你的账号下同时用于计费和质量统计。除了 Key一般还需要一个userId字段来区分不同终端用户——虽然课程设计里只有一个人在用但接口通常要求必填随便填个固定字符串就行。请求体是嵌套的 JSON 结构reqType表示输入类型0 代表纯文本perception.inputText.text装用户说的话userInfo里放身份信息。{ reqType: 0, perception: { inputText: { text: 你好 } }, userInfo: { apiKey: 你在控制台申请到的Key, userId: 1001 } }对应的响应体也做了分层回复文本藏在results[0].values.text里{ intent: { code: 10004, actionName: }, results: [ { resultType: text, values: { text: 你好呀今天想聊点什么 } } ] }这里有个很容易踩的隐形坑不同平台、甚至同一平台不同版本的接口字段结构可能完全不同。老版本接口是key、info、userid三个字段平铺在根节点返回也是{code:100000, text:...}这种扁平结构。如果照着旧教程写成平铺请求会返回参数错误如果照着新结构写到老接口上也是同样的结果。判断依据只有一个——控制台里的接口文档别看别人博客里的示例。关键参数的作用整理成表字段取值示例说明reqType00 表示文本输入其他值对应图片、音频等perception.inputText.text“你好”用户原始输入做一次 trim 再发userInfo.apiKey32 位字符串控制台申请泄露后可在后台重置userInfo.userId“1001”会话标识同一 userId 的上下文可能被关联userId这一项值得多说一句。有些平台会基于 userId 维护多轮对话的上下文如果你的课程设计里想演示“记住上一句”的效果就得保证所有请求用同一个 userId反之如果想每次都是全新会话就每次随机生成一个。报告里用的是固定值属于后者行为可预测答辩演示时不会出现“它怎么突然记得我说过什么”的意外。4.2 getDataFromServer 的异步请求写法网络请求绝对不能写在主线程。Android 从 3.0 开始就禁止主线程发起网络操作触发NetworkOnMainThreadException。OkHttp 提供了两种方式execute()是同步阻塞必须自己开子线程enqueue()是异步内部线程池调度回调在子线程执行。课程设计用enqueue()更省事。private static final String TAG ChatRobot; private static final String API_URL https://平台域名/openapi/api/v2; private static final String API_KEY 填入你的Key; private static final String USER_ID 1001; // 全局复用避免每次请求都新建连接池 private final OkHttpClient client new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) // 连接超时 .readTimeout(15, TimeUnit.SECONDS) // 读取超时机器人回复可能慢一点 .build(); private void getDataFromServer(String text) { try { JSONObject input new JSONObject().put(text, text); JSONObject perception new JSONObject().put(inputText, input); JSONObject userInfo new JSONObject() .put(apiKey, API_KEY) .put(userId, USER_ID); JSONObject payload new JSONObject() .put(reqType, 0) .put(perception, perception) .put(userInfo, userInfo); // 注意参数顺序OkHttp 3.x 是 (MediaType, String)4.x 反过来了 RequestBody body RequestBody.create( MediaType.parse(application/json; charsetutf-8), payload.toString()); Request request new Request.Builder() .url(API_URL) .post(body) .build(); client.newCall(request).enqueue(new Callback() { Override public void onFailure(Call call, IOException e) { Log.e(TAG, request failed, e); runOnUiThread(() - updateView(网络好像不太顺稍后再试试)); } Override public void onResponse(Call call, Response response) throws IOException { if (!response.isSuccessful() || response.body() null) { runOnUiThread(() - updateView(服务返回异常 response.code())); return; } String json response.body().string(); // 只能调用一次 Log.d(TAG, response: json); final String reply parseReply(json); runOnUiThread(() - updateView(reply)); } }); } catch (JSONException e) { Log.e(TAG, build payload failed, e); } }逐项说清楚。OkHttpClient放在成员变量而不是方法里是因为它内部维护连接池和线程池每次 new 一个等于每次重建整套资源连续发几十条消息之后内存和句柄都会涨。connectTimeout设 10 秒、readTimeout设 15 秒是因为机器人生成回复有时会慢于普通接口读取超时设太短会出现“请求发了但显示网络错误”的假故障。RequestBody.create的参数顺序是 OkHttp 3.x 的写法MediaType在前、字符串在后。到了 4.x 变成create(String, MediaType)代码不报错但序列化结果可能变成空体服务端收到空请求返回 400。这就是为什么第 2 章强调把版本钉死。enqueue的两个回调都在 OkHttp 的工作线程上执行所以onResponse里不能直接碰 UI。runOnUiThread把刷新动作投递回主线程是最省事的写法。用 Handler 也行但要记得在 Activity 销毁时移除回调否则会持有引用导致泄漏。response.body().string()只能调用一次第二次会抛IllegalStateException: closed。所以先存成局部字符串再交给解析函数别在解析函数里再拿一次 body。4.3 parseReply 与 updateView把 JSON 变成气泡解析这一步防御性写法比技巧更重要。响应结构里results可能是空数组values可能不存在text字段名在不同resultType下也不一样。一路getJSONObject下去只要有一处缺失就抛异常整个回调直接崩掉用户看到的就是“发了没反应”。private String parseReply(String json) { try { JSONObject root new JSONObject(json); JSONArray results root.optJSONArray(results); if (results ! null results.length() 0) { JSONObject first results.optJSONObject(0); if (first ! null) { JSONObject values first.optJSONObject(values); if (values ! null values.has(text)) { return values.getString(text); } } } // 兼容老版本扁平结构便于迁移旧代码 if (root.has(text)) { return root.getString(text); } } catch (JSONException e) { Log.e(TAG, parse failed: json, e); } return 这个问题我还没学会换个说法试试; }用optJSONArray、optJSONObject代替getJSONArray、getJSONObject缺失时返回 null 而不是抛异常配合逐层判空就能安全降级。最后的兜底文案不是摆设——线上环境里接口偶尔返回非文本类型比如链接、新闻卡片这时候按纯文本解析必然失败有一句兜底回复至少保证对话不中断用户不会以为应用卡死了。刷新这一步报告里叫updateView()实际做的事是“追加一条消息 通知适配器 滚到底部”private void updateView(String content) { mData.add(new ChatBean(ChatBean.TYPE_RECEIVE, content)); mAdapter.notifyDataSetChanged(); // 必须在主线程调用 lvChat.smoothScrollToPosition(mData.size() - 1); // 通知之后再滚动 }顺序很关键。先notifyDataSetChanged再滚动ListView 才知道新的条目数smoothScrollToPosition(size - 1)才能定位到最后一条。反过来写滚动会停在旧数据的末尾新消息藏在屏幕下方看着就像“没收到回复”。sendData()里还有几件小事要做全取输入框文本时做一次trim()空字符串直接 return 不发送发送成功后setText()清空输入框调用hideSoftKeyboard()收起键盘不然每发一条都要手动收一次。这些细节报告里没写但演示时老师一眼就能看出来。5. 跑不起来先看这里六条按现象排查的记录这类课程设计最容易出现的情况不是“写不出来”而是“写完了点了没反应也不知道从哪查”。下面六条是这类项目里复现率最高的故障按“现象 → 原因 → 解决”整理建议照着顺序过一遍基本能覆盖九成问题。5.1 网络与配置类的三条第一条点击发送后毫无反应Logcat 里刷出NetworkOnMainThreadException。现象是按钮点下去界面没有任何变化既不报错弹窗也不出现新气泡只有 Logcat 里有红色堆栈。原因是在主线程调用了client.newCall(request).execute()Android 直接拦截了这次网络操作。解决方式是换成enqueue()异步调用或者把execute()包进new Thread(() - {...}).start()。推荐前者代码短且不用自己管理线程生命周期。改完之后记得确认onResponse里的 UI 刷新仍然走runOnUiThread否则会从“网络异常”变成“只有主线程才能更新 UI”的异常。第二条请求明确发出去了返回 400 或 403或者响应里 code 不是成功值。现象是 Logcat 里能看到响应体但内容是错误提示界面上显示的是兜底文案。原因基本集中在三处Key 复制时带了空格或换行请求体的字段结构和你调用的接口版本不匹配老接口要平铺的key、info、userid新接口要嵌套的perception、userInfoContent-Type没设成application/json服务端按表单解析失败。解决方式是先把payload.toString()完整打一条日志肉眼比对字段名和层级再用 Postman 之类的工具单独发一次确认是客户端问题还是账号问题。这一步花五分钟比在代码里反复猜一小时有效。第三条Android 9 以上真机运行请求直接失败日志里出现CLEARTEXT communication to ... not permitted。现象是模拟器上跑得好好的换到真机或者升级了系统版本就打不开。原因是 targetSdk 提到 28 之后系统默认禁止明文 HTTP。解决方式有两条路优先把接口地址换成 https如果平台只提供 http就在 manifest 的 application 节点加android:usesCleartextTraffictrue或者配置 network_security_config 只对特定域名放行。课程设计场景下前者更省事但要注意 http 和 https 混用时 cookie 和重定向行为可能不同别一半接口 http 一半 https。5.2 列表与线程类的三条第四条一进聊天界面就崩溃堆栈指向AbsListView.obtainView报ArrayIndexOutOfBoundsException。现象是应用启动瞬间闪退日志里能看到indexOutOfBounds和 ListView 的内部方法。原因是getItemViewType返回了 2但没有重写getViewTypeCount默认值是 1合法区间只有[0, 1)。解决方式是补上getViewTypeCount()返回 2同时检查getItemViewType的返回值是不是做了state - 1的转换。这两处是一对只改一处会出现“不崩了但气泡左右错位”的新问题因为类型和布局对不上号。第五条消息发了机器人也回复了但列表里看不到新条目或者要手动滑一下才出现。现象是 Logcat 里能打印出解析成功的回复文本但界面纹丝不动。原因有两个常见分支一是在 OkHttp 的回调线程里直接调用了notifyDataSetChanged()Android 的视图系统忽略了这次调用或者抛CalledFromWrongThreadException二是 adapter 持有的List对象和 Activity 里的不是同一个引用sendData往 A 列表里加adapter 读的是 B 列表。解决方式是所有 UI 刷新统一走runOnUiThread并且在 Activity 里只维护一个ListChatBean构造 adapter 时把这个引用传进去不要在 adapter 里new ArrayList()复制一份。第六条滑动列表时气泡内容乱掉明明是机器人说的话显示在了右边头像下面。现象是消息少的时候正常滑上来回几次之后内容串位。原因是多布局场景下没有正确处理 convertView 的复用if 分支按类型加载了布局else 分支直接拿旧 view 改文字但旧的 view 可能是另一种类型的布局。解决方式是确保getItemViewType和getViewTypeCount正确实现让 ListView 按类型分池回收如果出于某种原因必须单池那就在 else 分支里判断当前 view 的布局是否和需要的类型一致不一致就重新 inflate。前一种做法代码更干净也是 BaseAdapter 设计时预期的用法。6. 从“能跑”到“答得上来”三个加分改动和一次演示彩排课程设计报告交上去之后还有答辩环节这时候决定分数的往往不是功能多少而是你能不能解释清楚某个选择的理由。有三个改动成本很低但能让演示效果和答辩表现明显不同。第一个是把欢迎语做成随机。报告里提到“进来会有随机的欢迎消息”实现上就是在strings.xml里放一个string-arrayshowData()里用new Random().nextInt(arr.length)取一条。这个改动只有几行代码但演示时反复启动几次每次文案不同观感比固定一句“你好我是机器人”好很多。答辩时问“随机怎么做的”直接答string-arrayRandom.nextIntgetResources().getStringArray三句话讲完。第二个是消息持久化。现在退出应用再进来历史消息全没了。用 SharedPreferences 存 JSON 字符串数组或者开一张 SQLite 表存state、content、time三列在onCreate里读回来。这个改动能覆盖报告里提到的“数据存储”知识点答辩时也有话说。代价是要处理序列化和反序列化建议用JSONArray存整个列表putString之前toString()读的时候new JSONArray(str)再逐条转 ChatBean比手写 SQL 快得多。第三个是输入体验。发送后清空输入框、收起键盘、列表滚到底部这三件事要一起做顺序是setText()→hideSoftKeyboard()→notifyDataSetChanged()→smoothScrollToPosition。少做一步演示时就会卡壳不清空用户会误以为没发出去不收键盘界面上半截被挡住不滚动新消息看不见。最后说个血泪经验。我第一次做这类演示前没有完整走一遍“从冷启动到连续对话二十轮”的流程结果现场跑到第七八条消息时列表开始卡顿原因是每次getView都重新findViewById加上每次请求都 new 了一个 OkHttpClient。这两个问题在短对话里完全看不出来一旦消息条数上来就暴露。从那以后我每次交课程设计之前都会把对话手动刷到三十条以上再滑一遍同时开着 Profiler 看内存曲线有没有一路往上走。希望帮到你。本文还有配套的精品资源点击获取
简介这份《Android实现聊天机器人——课程设计报告》面向移动应用开发课程设计阶段的学生适合需要完成聊天机器人App选题、撰写规范课设报告或梳理Android综合实践思路的读者。压缩包共1个doc文件约1.46MB以Word文档形式完整呈现实验目的、实验内容、程序设计与说明并配有各界面设计思路、类说明和运行界面截图。报告围绕图灵机器人平台API接入展开涉及聊天界面线性布局与左右消息条目样式、欢迎信息配置、ChatBean对消息状态与内容的封装、ChatAdapter数据适配、OkHttp网络请求及Json解析回显还说明了初始化、显示、发送、获取回复、更新界面五类方法的分工与后退键退出处理。已有2708人学习可作为课程设计报告的框架参照和功能模块自查清单帮助读者理解从界面搭建到网络通信的完整实现脉络。1. 一份能直接交的 Android 聊天机器人课程设计报告值不值得拆开看期末前两周某高校移动应用开发课的作业习题里通常会挂一道“做一个能对话的安卓app”不少人的第一反应是搜现成源码下载解压之后发现包里只有几张运行截图布局文件、适配器、网络请求全是空的。这份安卓app课程设计报告的价值就在完整度上从申请机器人身份标识、写 activity_main、定义 ChatBean、实现 ChatAdapter到用 OkHttp 请求服务端再解析 JSON 回填列表整条链路没有断点报告里的类说明和截图能一一对上代码。它适合三类人——赶课程设计报告 deadline 的学生、第一次碰 Android 网络编程想找个最小闭环的初学者、以及需要一份现场能演示 demo 的答辩党。资源达人分享计划里这类“报告 配套源码”的组合不算少见但能把方法分工、布局结构和运行效果对应得这么细的拆起来才有点意思。2. 把报告拆成可交付的模块依赖、四个类和一张文件对应表拿到这种“文档 源码”配套的资源最忌讳的就是直接双击打开工程然后一路点运行。报告写的是设计思路源码写的是实现细节中间那层“哪个文件负责哪件事”的映射关系如果没建立起来改一个功能就会牵动三四个文件最后连自己都说不清改坏了什么。合理的拆法是先钉环境依赖再定数据结构最后才动网络层——顺序反了必返工。2.1 报告章节和工程目录怎么对上报告的三级结构很清楚3.1 设计思路写的是布局文件3.2 类的说明写的是 MainActivity、ChatBean、ChatAdapter3.3 是运行截图。把这三节翻译成 Android Studio 里的实际路径大概是这样一张表报告里的描述工程中的实际文件承担的作用activity_main 聊天界面布局res/layout/activity_main.xml标题栏、消息列表、输入区三段式骨架chatting_left_item 机器人气泡res/layout/chatting_left_item.xml机器人头像 左侧消息文本chatting_right_item 用户气泡res/layout/chatting_right_item.xml用户头像 右侧消息文本消息实体类java/包名/ChatBean.java消息状态、内容、时间三个字段数据适配器java/包名/ChatAdapter.javaListView 与 ChatBean 列表之间的桥梁界面交互逻辑java/包名/MainActivity.java五个方法串起发送、请求、解析、刷新这张表看着朴素但它是后面所有改动的坐标系。比如你想把气泡改成圆角矩形只需要动两个 item XML 和对应的 drawable想把 ListView 换成 RecyclerView只动 ChatAdapter 和 activity_mainChatBean 和 MainActivity 里的网络方法基本不动。很多课程设计报告写得漂亮但代码一改就崩问题往往出在没有这条边界。顺着这张表还有一个隐含的收益报告里的运行截图可以直接当验收清单用。截图里出现了欢迎语、数字回复、字母接龙、单字“额”这几种情况说明作者至少测过纯文本、纯数字、连续短句和无意义输入四类场景你在自己机器上跑的时候照着这四类过一遍基本能覆盖 80% 的低级错误。2.2 环境依赖先钉死别边写边升这类课程设计报告的资源最大的坑不是代码逻辑而是版本。报告里明确写了用 okhttp 3.12.0这是个关键信号——说明示例代码是按 OkHttp 3.x 的 API 写的而 3.x 和 4.x 在 RequestBody 的构造上有签名变化随手在 Dependencies 里点一下“升级到最新”编译能过但运行行为会变。// app/build.gradle android { compileSdkVersion 28 defaultConfig { applicationId com.example.chatrobot minSdkVersion 21 // 21 以上 runOnUiThread、OkHttp 都没有兼容问题 targetSdkVersion 28 // 与报告保持一致避免明文流量策略差异 versionCode 1 versionName 1.0 } } dependencies { // 报告指定版本不要随手升到 4.x implementation com.squareup.okhttp3:okhttp:3.12.0 implementation com.android.support:appcompat-v7:28.0.0 }这里有三处参数值得说清楚。minSdkVersion 21是因为 OkHttp 3.12 的最低要求是 API 21同时runOnUiThread在这个级别上行为稳定不需要额外做线程兼容。targetSdkVersion 28是重点Android 9 开始默认禁止明文 HTTP 请求如果平台给的接口地址是 http 开头targetSdk 提到 28 以上就会直接抛CLEARTEXT communication not permitted而报告里是不会写这一条的。compileSdkVersion 28则要和 appcompat 版本对齐混用 28 和 29 的 support 库会在资源合并阶段报错。权限和 Activity 声明也得在 AndroidManifest 里补齐少一行 INTERNET后面所有网络问题都会表现得像“接口挂了”!-- AndroidManifest.xml -- uses-permission android:nameandroid.permission.INTERNET / application ... activity android:name.MainActivity android:windowSoftInputModeadjustResize !-- 键盘弹出时压缩布局不遮挡输入框 -- intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity /applicationadjustResize这个属性很多人不加后果是软键盘弹起来把输入框和发送按钮一起盖住演示的时候特别尴尬。它配合 activity_main 里给列表区域设的layout_weight1才能形成“键盘顶起、列表压缩、底部固定”的正确布局行为。2.3 ChatBean 的字段设计和五个方法的职责ChatBean 是整份报告里最容易被低估的一个类。它看起来只是个普通 JavaBean但字段设计直接决定了适配器怎么写、布局怎么分。public class ChatBean { public static final int TYPE_SEND 1; // 用户发出的消息 public static final int TYPE_RECEIVE 2; // 机器人回复的消息 private int state; // 取值 1 或 2决定加载左边还是右边布局 private String content; // 气泡里显示的文本 private String time; // 可选用于在气泡下方显示时间戳 public ChatBean(int state, String content) { this.state state; this.content content; } public int getState() { return state; } public void setState(int state) { this.state state; } public String getContent() { return content; } public void setContent(String content) { this.content content; } public String getTime() { return time; } public void setTime(String time) { this.time time; } }把state定义成 1 和 2 而不是 0 和 1是报告里一个挺有意思的选择语义上更直观读代码时“1 是我发的、2 是对方发的”比“0 和 1”好记。但它和 ListView 的多布局机制对不上getItemViewType要求返回值落在[0, getViewTypeCount())区间内所以适配器里必须做一次减一转换这个转换点后面第 5 章还会专门说。再看 MainActivity 里的五个方法报告的原文只给了名字和一句话说明实际写下来每个方法的输入输出是这样的方法输入输出 / 副作用initView()无绑定 ListView、EditText、Button初始化适配器和数据集合showData()无从 strings.xml 随机取一条欢迎语作为 TYPE_RECEIVE 消息插入列表sendData()输入框文本校验非空、生成 TYPE_SEND 消息、清空输入框、触发网络请求getDataFromServer()用户文本发起异步请求成功后回调解析函数updateView()回复文本生成 TYPE_RECEIVE 消息、通知适配器、滚动到底部这个拆法比“把所有逻辑塞进 onClick”要好得多理由不是“代码规范”这种空话而是它把一次交互拆成了可独立测试的四段输入校验、网络请求、JSON 解析、UI 刷新。哪一段出问题Logcat 里对应的日志位置是明确的。常见做法是在每个方法入口打一条Log.d(TAG, ...)跑一次完整对话就能看出流程断在哪。3. 界面落地三段式布局、左右气泡和 ChatAdapter 的复用写法界面这一块课程设计的评分点往往不在“好看”而在“结构清楚、能解释为什么这么写”。报告里用的 ListView 加 BaseAdapter 是相当经典的组合虽然现在新项目普遍用 RecyclerView但拿它来讲清楚“多布局 视图复用”这件事反而比 RecyclerView 更直白因为 RecyclerView 把 ViewHolder 和回收逻辑都封装进框架了看不见。3.1 activity_main 的三段式骨架布局结构报告里描述得很明确最外层线性布局顶部一个 TextView 显示会话标题中间一个 RelativeLayout 装 ListView底部一个小的 RelativeLayout 装 EditText 和 Button。落到 XML 上关键是中间那块要吃掉剩余高度。!-- res/layout/activity_main.xml -- LinearLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightmatch_parent android:orientationvertical android:background#F5F5F5 !-- 第一段标题栏固定高度 -- TextView android:layout_widthmatch_parent android:layout_height48dp android:gravitycenter android:text聊天窗口 android:textSize18sp android:background#FFFFFF / !-- 第二段消息列表weight1 吃掉中间全部剩余空间 -- ListView android:idid/lv_chat android:layout_widthmatch_parent android:layout_height0dp android:layout_weight1 android:dividernull android:dividerHeight0dp android:listSelectorandroid:color/transparent android:transcriptModenormal / !-- 第三段输入区高度自适应键盘弹起时被顶起 -- RelativeLayout android:layout_widthmatch_parent android:layout_heightwrap_content android:padding8dp android:background#FFFFFF EditText android:idid/et_input android:layout_widthmatch_parent android:layout_heightwrap_content android:layout_toLeftOfid/btn_send android:hint说点什么吧 android:maxLines3 android:inputTypetext / Button android:idid/btn_send android:layout_width72dp android:layout_heightwrap_content android:layout_alignParentRighttrue android:text发送 / /RelativeLayout /LinearLayoutlayout_height0dp加layout_weight1是这段布局的核心它让 ListView 的高度等于父容器减去标题栏和输入区而不是被内容撑开。如果误写成wrap_content消息一多列表就会顶出屏幕底部输入区直接看不见。dividernull和listSelector设为透明属于细节优化。ListView 默认带分隔线点击时还有一块灰色高亮聊天界面里这两样都很突兀。同理transcriptModenormal让列表在数据变化时保持底部对齐配合后面手动调用滚动方法能避免新消息藏在屏幕外。EditText 的maxLines3和inputTypetext也不是随便设的前者限制输入框最多长高三行防止用户输入一大段文字把输入区挤满后者关掉回车换行让软键盘上显示的是“发送”而不是“换行”。在很多课程设计里这两项没设好评审老师一句“输入多行会怎样”就能问住人。3.2 左右气泡与 selector 背景两个 item 布局的结构几乎一样都是 RelativeLayout 套一个 ImageView 和一个 TextView差异只在头像资源、TextView 的对齐方向、以及背景 drawable。左边机器人消息的写法大致如下!-- res/layout/chatting_left_item.xml -- RelativeLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightwrap_content android:padding8dp ImageView android:idid/iv_robot_head android:layout_width40dp android:layout_height40dp android:srcdrawable/robot_head android:layout_alignParentLefttrue android:layout_alignParentToptrue / TextView android:idid/tv_chat_content android:layout_widthwrap_content android:layout_heightwrap_content android:layout_toRightOfid/iv_robot_head android:layout_marginLeft8dp android:maxWidth260dp android:padding10dp android:textSize15sp android:textColor#333333 android:backgrounddrawable/chat_left_selector / /RelativeLayout右边那份只需要把layout_alignParentLeft换成alignParentRight、layout_toRightOf换成layout_toLeftOf、背景换成chat_right_selector。报告里说的 “style 里写好的格式文件” 指的是把 padding、textSize、maxWidth 这些公共属性抽成一个 style在两个 item 里引用改一次两边都生效。maxWidth260dp是个很实用但常被忽略的属性。不设它机器人回一段长文本时长气泡会横穿整个屏幕把头像挤到边缘视觉上很难看。260dp 大概对应 1080p 屏幕上三分之二的宽度超过就自动换行。selector 文件负责按压态和默认态的颜色切换!-- res/drawable/chat_left_selector.xml -- selector xmlns:androidhttp://schemas.android.com/apk/res/android item android:state_pressedtrue shape android:shaperectangle solid android:color#DDDDDD / !-- 按下时变深 -- corners android:radius8dp / /shape /item item shape android:shaperectangle solid android:color#FFFFFF / !-- 默认白色气泡 -- corners android:radius8dp / stroke android:width1dp android:color#E0E0E0 / /shape /item /selector用 shape 画背景比用 9-patch 图片省事圆角和描边参数直接写在 XML 里改颜色不用重新切图。缺点是做不出带小尖角的气泡如果课程设计想加分可以把 shape 换成.9.png但要注意切图时留好拉伸区域否则不同长度的文字会把圆角拉变形。3.3 ChatAdapter多布局复用的正确姿势适配器是这块最容易翻车的地方。报告里提到“getView 方法内用 if 和 else 判断当前消息是发送还是接收不同消息加载不同的 view”这句话只说了表象没说不重写getViewTypeCount会出什么事。public class ChatAdapter extends BaseAdapter { private static final int TYPE_COUNT 2; // 两种布局 private final ListChatBean data; private final LayoutInflater inflater; public ChatAdapter(Context context, ListChatBean data) { this.data data; this.inflater LayoutInflater.from(context); } Override public int getCount() { return data.size(); } Override public Object getItem(int position) { return data.get(position); } Override public long getItemId(int position) { return position; } // 关键告诉 ListView 有几种 item 布局 Override public int getViewTypeCount() { return TYPE_COUNT; } // 关键state 是 1/2必须转成 0/1 才能落在合法区间 Override public int getItemViewType(int position) { return data.get(position).getState() - 1; } Override public View getView(int position, View convertView, ViewGroup parent) { int type getItemViewType(position); ViewHolder holder; if (convertView null) { holder new ViewHolder(); if (type 0) { convertView inflater.inflate(R.layout.chatting_left_item, parent, false); holder.head convertView.findViewById(R.id.iv_robot_head); } else { convertView inflater.inflate(R.layout.chatting_right_item, parent, false); holder.head convertView.findViewById(R.id.iv_my_head); } holder.content convertView.findViewById(R.id.tv_chat_content); convertView.setTag(holder); // 缓存视图引用 } else { holder (ViewHolder) convertView.getTag(); } ChatBean bean data.get(position); holder.content.setText(bean.getContent()); return convertView; } static class ViewHolder { ImageView head; TextView content; } }逐段看逻辑。getViewTypeCount()返回 2是告诉 ListView 内部维护两个回收池左气泡和右气泡各自复用不会串。如果不重写默认返回 1只有一个池子那么当getItemViewType返回 1 时ListView 会直接抛ArrayIndexOutOfBoundsException崩溃日志停在AbsListView.obtainView那一行很多人对着它发呆半天也想不到是这里。getItemViewType里的- 1是配套的state 定成 1 和 2 是为了可读性但类型索引必须从 0 开始。这两处是一对改一个不改另一个必崩。if (convertView null)的判断配getItemViewType使用时有个前提ListView 保证同一个回收池里的 convertView 类型一致所以在这个分支里按 type 加载布局是安全的。反过来如果没重写 type 相关方法就得在 if 外面判断当前 convertView 的布局是否匹配代码会脏很多。inflate(R.layout.xxx, parent, false)里第三个参数必须传 false。传 true 会把 item 视图直接挂到 ListView 上抛IllegalStateException不传用两参重载则丢失父容器的布局参数item 的宽度会变成 wrap_content气泡贴不到边。ViewHolder是纯优化把findViewById的结果缓存进 tag省掉滚动时反复查找。消息少的时候感觉不出来滑到几十条就能明显看到掉帧。4. 打通对话链路OkHttp 请求、JSON 取值和主线程回写前两章做的是“看得见的部分”这一章开始碰“看不见的部分”。报告里这部分只有寥寥几句——“机器人会根据用户发送的聊天内容从服务器上获取回复信息并将获取的回复信息通过 Json 解析显示到界面上”——但实际代码量占到整个工程的一半以上出错概率也最高。Android 的网络编程有几个固定门槛权限、线程、请求体格式、响应解析、UI 线程回写任何一环没接好表现都是同一个点了发送什么也没发生。4.1 先确认身份标识和请求体长什么样报告第一步就是“申请机器人身份标识”在开放平台注册后创建机器人拿到一个 Key。这个 Key 的作用是把请求归到你的账号下同时用于计费和质量统计。除了 Key一般还需要一个userId字段来区分不同终端用户——虽然课程设计里只有一个人在用但接口通常要求必填随便填个固定字符串就行。请求体是嵌套的 JSON 结构reqType表示输入类型0 代表纯文本perception.inputText.text装用户说的话userInfo里放身份信息。{ reqType: 0, perception: { inputText: { text: 你好 } }, userInfo: { apiKey: 你在控制台申请到的Key, userId: 1001 } }对应的响应体也做了分层回复文本藏在results[0].values.text里{ intent: { code: 10004, actionName: }, results: [ { resultType: text, values: { text: 你好呀今天想聊点什么 } } ] }这里有个很容易踩的隐形坑不同平台、甚至同一平台不同版本的接口字段结构可能完全不同。老版本接口是key、info、userid三个字段平铺在根节点返回也是{code:100000, text:...}这种扁平结构。如果照着旧教程写成平铺请求会返回参数错误如果照着新结构写到老接口上也是同样的结果。判断依据只有一个——控制台里的接口文档别看别人博客里的示例。关键参数的作用整理成表字段取值示例说明reqType00 表示文本输入其他值对应图片、音频等perception.inputText.text“你好”用户原始输入做一次 trim 再发userInfo.apiKey32 位字符串控制台申请泄露后可在后台重置userInfo.userId“1001”会话标识同一 userId 的上下文可能被关联userId这一项值得多说一句。有些平台会基于 userId 维护多轮对话的上下文如果你的课程设计里想演示“记住上一句”的效果就得保证所有请求用同一个 userId反之如果想每次都是全新会话就每次随机生成一个。报告里用的是固定值属于后者行为可预测答辩演示时不会出现“它怎么突然记得我说过什么”的意外。4.2 getDataFromServer 的异步请求写法网络请求绝对不能写在主线程。Android 从 3.0 开始就禁止主线程发起网络操作触发NetworkOnMainThreadException。OkHttp 提供了两种方式execute()是同步阻塞必须自己开子线程enqueue()是异步内部线程池调度回调在子线程执行。课程设计用enqueue()更省事。private static final String TAG ChatRobot; private static final String API_URL https://平台域名/openapi/api/v2; private static final String API_KEY 填入你的Key; private static final String USER_ID 1001; // 全局复用避免每次请求都新建连接池 private final OkHttpClient client new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) // 连接超时 .readTimeout(15, TimeUnit.SECONDS) // 读取超时机器人回复可能慢一点 .build(); private void getDataFromServer(String text) { try { JSONObject input new JSONObject().put(text, text); JSONObject perception new JSONObject().put(inputText, input); JSONObject userInfo new JSONObject() .put(apiKey, API_KEY) .put(userId, USER_ID); JSONObject payload new JSONObject() .put(reqType, 0) .put(perception, perception) .put(userInfo, userInfo); // 注意参数顺序OkHttp 3.x 是 (MediaType, String)4.x 反过来了 RequestBody body RequestBody.create( MediaType.parse(application/json; charsetutf-8), payload.toString()); Request request new Request.Builder() .url(API_URL) .post(body) .build(); client.newCall(request).enqueue(new Callback() { Override public void onFailure(Call call, IOException e) { Log.e(TAG, request failed, e); runOnUiThread(() - updateView(网络好像不太顺稍后再试试)); } Override public void onResponse(Call call, Response response) throws IOException { if (!response.isSuccessful() || response.body() null) { runOnUiThread(() - updateView(服务返回异常 response.code())); return; } String json response.body().string(); // 只能调用一次 Log.d(TAG, response: json); final String reply parseReply(json); runOnUiThread(() - updateView(reply)); } }); } catch (JSONException e) { Log.e(TAG, build payload failed, e); } }逐项说清楚。OkHttpClient放在成员变量而不是方法里是因为它内部维护连接池和线程池每次 new 一个等于每次重建整套资源连续发几十条消息之后内存和句柄都会涨。connectTimeout设 10 秒、readTimeout设 15 秒是因为机器人生成回复有时会慢于普通接口读取超时设太短会出现“请求发了但显示网络错误”的假故障。RequestBody.create的参数顺序是 OkHttp 3.x 的写法MediaType在前、字符串在后。到了 4.x 变成create(String, MediaType)代码不报错但序列化结果可能变成空体服务端收到空请求返回 400。这就是为什么第 2 章强调把版本钉死。enqueue的两个回调都在 OkHttp 的工作线程上执行所以onResponse里不能直接碰 UI。runOnUiThread把刷新动作投递回主线程是最省事的写法。用 Handler 也行但要记得在 Activity 销毁时移除回调否则会持有引用导致泄漏。response.body().string()只能调用一次第二次会抛IllegalStateException: closed。所以先存成局部字符串再交给解析函数别在解析函数里再拿一次 body。4.3 parseReply 与 updateView把 JSON 变成气泡解析这一步防御性写法比技巧更重要。响应结构里results可能是空数组values可能不存在text字段名在不同resultType下也不一样。一路getJSONObject下去只要有一处缺失就抛异常整个回调直接崩掉用户看到的就是“发了没反应”。private String parseReply(String json) { try { JSONObject root new JSONObject(json); JSONArray results root.optJSONArray(results); if (results ! null results.length() 0) { JSONObject first results.optJSONObject(0); if (first ! null) { JSONObject values first.optJSONObject(values); if (values ! null values.has(text)) { return values.getString(text); } } } // 兼容老版本扁平结构便于迁移旧代码 if (root.has(text)) { return root.getString(text); } } catch (JSONException e) { Log.e(TAG, parse failed: json, e); } return 这个问题我还没学会换个说法试试; }用optJSONArray、optJSONObject代替getJSONArray、getJSONObject缺失时返回 null 而不是抛异常配合逐层判空就能安全降级。最后的兜底文案不是摆设——线上环境里接口偶尔返回非文本类型比如链接、新闻卡片这时候按纯文本解析必然失败有一句兜底回复至少保证对话不中断用户不会以为应用卡死了。刷新这一步报告里叫updateView()实际做的事是“追加一条消息 通知适配器 滚到底部”private void updateView(String content) { mData.add(new ChatBean(ChatBean.TYPE_RECEIVE, content)); mAdapter.notifyDataSetChanged(); // 必须在主线程调用 lvChat.smoothScrollToPosition(mData.size() - 1); // 通知之后再滚动 }顺序很关键。先notifyDataSetChanged再滚动ListView 才知道新的条目数smoothScrollToPosition(size - 1)才能定位到最后一条。反过来写滚动会停在旧数据的末尾新消息藏在屏幕下方看着就像“没收到回复”。sendData()里还有几件小事要做全取输入框文本时做一次trim()空字符串直接 return 不发送发送成功后setText()清空输入框调用hideSoftKeyboard()收起键盘不然每发一条都要手动收一次。这些细节报告里没写但演示时老师一眼就能看出来。5. 跑不起来先看这里六条按现象排查的记录这类课程设计最容易出现的情况不是“写不出来”而是“写完了点了没反应也不知道从哪查”。下面六条是这类项目里复现率最高的故障按“现象 → 原因 → 解决”整理建议照着顺序过一遍基本能覆盖九成问题。5.1 网络与配置类的三条第一条点击发送后毫无反应Logcat 里刷出NetworkOnMainThreadException。现象是按钮点下去界面没有任何变化既不报错弹窗也不出现新气泡只有 Logcat 里有红色堆栈。原因是在主线程调用了client.newCall(request).execute()Android 直接拦截了这次网络操作。解决方式是换成enqueue()异步调用或者把execute()包进new Thread(() - {...}).start()。推荐前者代码短且不用自己管理线程生命周期。改完之后记得确认onResponse里的 UI 刷新仍然走runOnUiThread否则会从“网络异常”变成“只有主线程才能更新 UI”的异常。第二条请求明确发出去了返回 400 或 403或者响应里 code 不是成功值。现象是 Logcat 里能看到响应体但内容是错误提示界面上显示的是兜底文案。原因基本集中在三处Key 复制时带了空格或换行请求体的字段结构和你调用的接口版本不匹配老接口要平铺的key、info、userid新接口要嵌套的perception、userInfoContent-Type没设成application/json服务端按表单解析失败。解决方式是先把payload.toString()完整打一条日志肉眼比对字段名和层级再用 Postman 之类的工具单独发一次确认是客户端问题还是账号问题。这一步花五分钟比在代码里反复猜一小时有效。第三条Android 9 以上真机运行请求直接失败日志里出现CLEARTEXT communication to ... not permitted。现象是模拟器上跑得好好的换到真机或者升级了系统版本就打不开。原因是 targetSdk 提到 28 之后系统默认禁止明文 HTTP。解决方式有两条路优先把接口地址换成 https如果平台只提供 http就在 manifest 的 application 节点加android:usesCleartextTraffictrue或者配置 network_security_config 只对特定域名放行。课程设计场景下前者更省事但要注意 http 和 https 混用时 cookie 和重定向行为可能不同别一半接口 http 一半 https。5.2 列表与线程类的三条第四条一进聊天界面就崩溃堆栈指向AbsListView.obtainView报ArrayIndexOutOfBoundsException。现象是应用启动瞬间闪退日志里能看到indexOutOfBounds和 ListView 的内部方法。原因是getItemViewType返回了 2但没有重写getViewTypeCount默认值是 1合法区间只有[0, 1)。解决方式是补上getViewTypeCount()返回 2同时检查getItemViewType的返回值是不是做了state - 1的转换。这两处是一对只改一处会出现“不崩了但气泡左右错位”的新问题因为类型和布局对不上号。第五条消息发了机器人也回复了但列表里看不到新条目或者要手动滑一下才出现。现象是 Logcat 里能打印出解析成功的回复文本但界面纹丝不动。原因有两个常见分支一是在 OkHttp 的回调线程里直接调用了notifyDataSetChanged()Android 的视图系统忽略了这次调用或者抛CalledFromWrongThreadException二是 adapter 持有的List对象和 Activity 里的不是同一个引用sendData往 A 列表里加adapter 读的是 B 列表。解决方式是所有 UI 刷新统一走runOnUiThread并且在 Activity 里只维护一个ListChatBean构造 adapter 时把这个引用传进去不要在 adapter 里new ArrayList()复制一份。第六条滑动列表时气泡内容乱掉明明是机器人说的话显示在了右边头像下面。现象是消息少的时候正常滑上来回几次之后内容串位。原因是多布局场景下没有正确处理 convertView 的复用if 分支按类型加载了布局else 分支直接拿旧 view 改文字但旧的 view 可能是另一种类型的布局。解决方式是确保getItemViewType和getViewTypeCount正确实现让 ListView 按类型分池回收如果出于某种原因必须单池那就在 else 分支里判断当前 view 的布局是否和需要的类型一致不一致就重新 inflate。前一种做法代码更干净也是 BaseAdapter 设计时预期的用法。6. 从“能跑”到“答得上来”三个加分改动和一次演示彩排课程设计报告交上去之后还有答辩环节这时候决定分数的往往不是功能多少而是你能不能解释清楚某个选择的理由。有三个改动成本很低但能让演示效果和答辩表现明显不同。第一个是把欢迎语做成随机。报告里提到“进来会有随机的欢迎消息”实现上就是在strings.xml里放一个string-arrayshowData()里用new Random().nextInt(arr.length)取一条。这个改动只有几行代码但演示时反复启动几次每次文案不同观感比固定一句“你好我是机器人”好很多。答辩时问“随机怎么做的”直接答string-arrayRandom.nextIntgetResources().getStringArray三句话讲完。第二个是消息持久化。现在退出应用再进来历史消息全没了。用 SharedPreferences 存 JSON 字符串数组或者开一张 SQLite 表存state、content、time三列在onCreate里读回来。这个改动能覆盖报告里提到的“数据存储”知识点答辩时也有话说。代价是要处理序列化和反序列化建议用JSONArray存整个列表putString之前toString()读的时候new JSONArray(str)再逐条转 ChatBean比手写 SQL 快得多。第三个是输入体验。发送后清空输入框、收起键盘、列表滚到底部这三件事要一起做顺序是setText()→hideSoftKeyboard()→notifyDataSetChanged()→smoothScrollToPosition。少做一步演示时就会卡壳不清空用户会误以为没发出去不收键盘界面上半截被挡住不滚动新消息看不见。最后说个血泪经验。我第一次做这类演示前没有完整走一遍“从冷启动到连续对话二十轮”的流程结果现场跑到第七八条消息时列表开始卡顿原因是每次getView都重新findViewById加上每次请求都 new 了一个 OkHttpClient。这两个问题在短对话里完全看不出来一旦消息条数上来就暴露。从那以后我每次交课程设计之前都会把对话手动刷到三十条以上再滑一遍同时开着 Profiler 看内存曲线有没有一路往上走。希望帮到你。本文还有配套的精品资源点击获取
