MediaCodec 基本介绍 MediaCodec类可用于访问Android底层的多媒体编解码器，例如，编码器/解码器组件。它是Android底层多媒体支持基础架构的一部分（通常与MediaExtractor, MediaSync, MediaMuxer, MediaCrypto, MediaDrm, Image, Surface, 以及AudioTrack一起使用）。 Android 底层多媒体模块采用的是 OpenMax 框架，任何 Android 底层编解码模块的实现，都必须遵循 OpenMax 标准。Google 官方默认提供了一系列的软件编解码器：包括：OMX.google.h264.encoder，OMX.google.h264.decoder， OMX.google.aac.encoder， OMX.google.aac.decoder 等等，而硬件编解码功能，则需要由芯片厂商依照 OpenMax 框架标准来完成，所以，一般采用不同芯片型号的手机，硬件编解码的实现和性能是不同的。 Android 应用层统一由 MediaCodec API 来提供各种音视频编解码功能，由参数配置来决定采用何种编解码算法、是否采用硬件编解码加速等。 MediaCodec的工作流程如下： 从上图可以看出 MediaCodec 架构上采用了2个缓冲区队列，异步处理数据，并且使用了一组输入输出缓存。 你请求或接收到一个空的输入缓存（input buffer），向其中填充满数据并将它传递给编解码器处理。编解码器处理完这些数据并将处理结果输出至一个空的输出缓存（output buffer）中。最终，你请求或接收到一个填充了结果数据的输出缓存（output buffer），使用完其中的数据，并将其释放给编解码器再次使用。 具体工作如下： Client 从 input 缓冲区队列申请 empty buffer [dequeueInputBuffer] Client 把需要编解码的数据拷贝到 empty buffer，然后放入 input 缓冲区队列 [queueInputBuffer] MediaCodec 模块从 input 缓冲区队列取一帧数据进行编解码处理 编解码处理结束后，MediaCodec 将原始数据 buffer 置为 empty 后放回 input 缓冲区队列，将编解码后的数据放入到 output 缓冲区队列 Client 从 output 缓冲区队列申请编解码后的 buffer [dequeueOutputBuffer] Client 对编解码后的 buffer 进行渲染/播放 渲染/播放完成后，Client 再将该 buffer 放回 output 缓冲区队列 [releaseOutputBuffer] MediaCodec的基本调用流程是： createEncoderByType/createDecoderByType configure start while(true) { dequeueInputBuffer //从输入流队列中取数据进行编码操作 getInputBuffers //获取需要编码数据的输入流队列，返回的是一个ByteBuffer数组 queueInputBuffer //输入流入队列 dequeueOutputBuffer //从输出队列中取出编码操作之后的数据 getOutPutBuffers // 获取编解码之后的数据输出流队列，返回的是一个ByteBuffer数组 releaseOutputBuffer //处理完成，释放ByteBuffer数据 } stop release 第1步.初始化MediaCodec，方法有两种，分别是通过名称和类型来创建，对应的方法为： MediaCodec createByCodecName (String name); MediaCodec createDecoderByType (String type); 第一种创建方式根据 mineType 以及是否为编码器，选择出一个 MediaCodecInfo，然后使用第一种方式初始化MediaCodec private MediaCodecInfo selectSupportCodec(String mimeType) { int numCodecs = MediaCodecList.getCodecCount(); for (int i = 0; i < numCodecs; i++) { MediaCodecInfo codecInfo = MediaCodecList.getCodecInfoAt(i); // 判断是否为编码器，否则直接进入下一次循环 if (!codecInfo.isEncoder()) { continue; } // 如果是编码器，判断是否支持Mime类型 String[] types = codecInfo.getSupportedTypes(); for (int j = 0; j < types.length; j++) { if (types[j].equalsIgnoreCase(mimeType)) { return codecInfo; } } } return null; } 第二种方式比较简单 mMediaCodec = MediaCodec.createDecoderByType (MIME_TYPE);//MIME_TYPE例如"video/avc"等。 第2步.配置编码器，设置各种编码器参数（MediaFormat），这个类包含了比特率、帧率、关键帧间隔时间等。然后再调用 mMediaCodec .configure，对于 API 19 以上的系统，我们可以选择 Surface 输入：mMediaCodec .createInputSurface。 format= MediaFormat.createVideoFormat(MIME_TYPE, width, height); format.setInteger(MediaFormat.KEY_BIT_RATE, bitrate); format.setInteger(MediaFormat.KEY_FRAME_RATE, framerate); format.setInteger(MediaFormat.KEY_COLOR_FORMAT,MediaCodecInfo.CodecCapabilities.COLOR_FormatSurface); format.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 1); //关键帧间隔时间 单位s mMediaCodec .configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE); mInputSurface = mMediaCodec.createInputSurface(); 第3步.启动(打开)编码器，获取输入输出缓冲区。 mMediaCodec.start(); mInputBuffers = mMediaCodec.getInputBuffers(); mOutputBuffers = mMediaCodec.getOutputBuffers(); 获取输入输出缓冲区在api19 上是以上方式获取，api21以后 可以使用直接获取ByteBuffer ByteBuffer intputBuffer = mMediaCodec.getInputBuffer(inputBufferIndex); ByteBuffer outputBuffer = mMediaCodec.getOutputBuffer(outputBufferIndex); 第4步.输入数据，有两种方式：“普通输入、Surface 输入”。 普通输入又可区分为两种情况，一种是配合MediaExtractor ，一种是取原数据。 获取可使用的缓冲区索引 int outputBufferIndex = mMediaCodec.dequeueInputBuffer(TIMES_OUT); 返回一个填充了有效数据的input buffer的索引，如果没有可用的buffer则返回-1，参数为超时时间(TIMES_OUT)，单位是微秒，当timeoutUs==0时，该方法立即返回；当timeoutUs<0时，无限期地等待一个可用的input buffer，当timeoutUs>0时， 等待时间为传入的微秒值。 普通输入之获取原数据方式 ByteBuffer inputBuffer = mInputBuffers[inputbufferindex]; inputBuffer.clear();//清除原来的内容以接收新的内容 inputBuffer.put(bytes, 0, len);//len是传进来的有效数据长度 mMediaCodec .queueInputBuffer(inputbufferindex, 0, len, timestamp, 0); 上面输入缓存的index，通过getInputBuffers()得到的是输入缓存数组，通过index和输入缓存数组可以得到当前请求的输入缓存，在使用之前要clear一下，避免之前的缓存数据影响当前数据，接着就是把数据添加到输入缓存中，并调用queueInputBuffer(…)把缓存数据入队。 普通输入之配合MediaExtractor 解码其他的音视频数据 ByteBuffer inputBuf = decoderInputBuffers[inputBufIndex]; int chunkSize = SDecoder.extractor.readSampleData(inputBuf, 0); if (chunkSize < 0) { SDecoder.decoder.queueInputBuffer(inputBufIndex, 0, 0, 0L, MediaCodec.BUFFER_FLAG_END_OF_STREAM); } else { SDecoder.decoder.queueInputBuffer(inputBufIndex, 0, chunkSize, SDecoder.extractor.getSampleTime(), 0); SDecoder.extractor.advance(); } 使用Surface输入，Surface输入是Android 4.3(api 18)引入。但用在某些 API 18 的机型上会导致编码器输出数据量特别小，画面是黑屏，所以 Surface 输入模式从 API 19 启用比较好。 //Requests a Surface to use as the input to an encoder, in place of input buffers. This may only be //called after configure(MediaFormat, Surface, MediaCrypto, int) and before start(). //调用此方法，官方有这么一段话，意思是必须在configure之后 start()之前调用。 mInputSurface = mMediaCodec.createInputSurface(); 第5步.输出数据。通常编码传输时每个关键帧头部都需要带上编码配置数据（PPS，SPS），但 MediaCodec 会在首次输出时专门输出编码配置数据，后面的关键帧里是不携带这些数据的，所以需要我们手动做一个拼接。 获取可使用的缓冲区：获取输出缓存和获取输入缓存类似，首先通过dequeueOutputBuffer(BufferInfo info, long timeoutUs)来请求一个输出缓存，这里需要传入一个BufferInfo对象，用于存储ByteBuffer的信息，TIMES_OUT为超时时间。TIMES_OUT传的是 0，表示不会等待，由于这里并没有一个单独的线程不停调用，所以这样没什么问题，反倒可以防止阻塞，但如果我们单独起了一个线程专门取输出数据，那这就会导致 CPU 资源的浪费了，可以加上一个合适的值，例如 3~10ms。 BufferInfo mBufferInfo = new MediaCodec.BufferInfo(); int outputBufferIndex = mMediaCodec.dequeueOutputBuffer(mBufferInfo,TIMES_OUT); 获取数据 ByteBuffer outputBuffer = null; if (Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP) { outputBuffer = outputBuffers[outputBufferIndex]; } else { outputBuffer = mMediaCodec.getOutputBuffer(outputBufferIndex); } if ((mBufferInfo.flags & MediaCodec.BUFFER_FLAG_CODEC_CONFIG) != 0) { MediaFormat format = mMediaCodec.getOutputFormat(); format.setByteBuffer("csd-0",outputBuffer); mBufferInfo.size = 0; } // 如果API<=19，需要根据BufferInfo的offset偏移量调整ByteBuffer的位置 // 并且限定将要读取缓存区数据的长度，否则输出数据会混乱 if (mBufferInfo.size != 0) { if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.KITKAT) { outputBuffer.position(mBufferInfo.offset); outputBuffer.limit(mBufferInfo.offset + mBufferInfo.size); } // mMuxer.writeSampleData(mTrackIndex, encodedData, bufferInfo); } 释放缓冲区 mMediaCodec.releaseOutputBuffer(outputBufferIndex,false); 第6步.使用完MediaCodec后释放资源。要告知编码器我们要结束编码，Surface 输入的话调用 mMediaCodec .signalEndOfInputStream，普通输入则可以为在 queueInputBuffer 时指定 MediaCodec.BUFFER_FLAG_END_OF_STREAM 这个 flag；告知编码器后我们就可以等到编码器输出的 buffer 带着 MediaCodec.BUFFER_FLAG_END_OF_STREAM 这个 flag 了，等到之后我们调用 mMediaCodec .release 销毁编码器。 if (mMediaCodec != null) { mMediaCodec.stop(); mMediaCodec.release(); mMediaCodec = null; } MediaCodec 流控 流控就是流量控制。为什么要控制，就是为了在一定的限制条件下，收益最大化！涉及到了 TCP 和视频编码：对 TCP 来说就是控制单位时间内发送数据包的数据量，对编码来说就是控制单位时间内输出数据的数据量。 TCP 的限制条件是网络带宽，流控就是在避免造成或者加剧网络拥塞的前提下，尽可能利用网络带宽。带宽够、网络好，我们就加快速度发送数据包，出现了延迟增大、丢包之后，就放慢发包的速度（因为继续高速发包，可能会加剧网络拥塞，反而发得更慢）。 视频编码的限制条件最初是解码器的能力，码率太高就会无法解码，后来随着 codec 的发展，解码能力不再是瓶颈，限制条件变成了传输带宽/文件大小，我们希望在控制数据量的前提下，画面质量尽可能高。 一般编码器都可以设置一个目标码率，但编码器的实际输出码率不会完全符合设置，因为在编码过程中实际可以控制的并不是最终输出的码率，而是编码过程中的一个量化参数（Quantization Parameter，QP），它和码率并没有固定的关系，而是取决于图像内容。 这一点不在这里展开，感兴趣的朋友可以阅读视频压缩编码和音频压缩编码的基本原理。 无论是要发送的 TCP 数据包，还是要编码的图像，都可能出现“尖峰”，也就是短时间内出现较大的数据量。TCP 面对尖峰，可以选择不为所动（尤其是网络已经拥塞的时候），这没有太大的问题，但如果视频编码也对尖峰不为所动，那图像质量就会大打折扣了。如果有几帧数据量特别大，但仍要把码率控制在原来的水平，那势必要损失更多的信息，因此图像失真就会更严重。这种情况通常的表现是画面出现很多小方块，看上去像是打了马赛克一样，导致画面的局部或者整体看不清楚的情况。 Android 硬编码流控 MediaCodec 流控相关的接口并不多，一是配置时设置目标码率和码率控制模式，二是动态调整目标码率(Android 19+)。配置时指定目标码率和码率控制模式： mediaFormat.setInteger(MediaFormat.KEY_BIT_RATE, bitRate); mediaFormat.setInteger(MediaFormat.KEY_BITRATE_MODE, MediaCodecInfo.EncoderCapabilities.BITRATE_MODE_VBR); mMediaCodec.configure(mediaFormat, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE); 码率控制模式有三种：在 MediaCodecInfo.EncoderCapabilities类中定义了三种，在 framework 层有另一套名字和它们的值一一对应: CQ 对应于 OMX_Video_ControlRateDisable，它表示完全不控制码率，尽最大可能保证图像质量； CBR 对应于 OMX_Video_ControlRateConstant，它表示编码器会尽量把输出码率控制为设定值，即我们前面提到的“不为所动”； VBR 对应于 OMX_Video_ControlRateVariable，它表示编码器会根据图像内容的复杂度（实际上是帧间变化量的大小）来动态调整输出码率，图像复杂则码率高，图像简单则码率低。 动态调整目标码率： Bundle param = new Bundle(); param.putInt(MediaCodec.PARAMETER_KEY_VIDEO_BITRATE, bitrate); mediaCodec.setParameters(param); Android 流控策略选择： 质量要求高、不在乎带宽、解码器支持码率剧烈波动的情况下，可以选择 CQ 码率控制策略。 VBR 输出码率会在一定范围内波动，对于小幅晃动，方块效应会有所改善，但对剧烈晃动仍无能为力；连续调低码率则会导致码率急剧下降，如果无法接受这个问题，那 VBR 就不是好的选择。 编码例子 下面展示使用MediaExtractor获取数据后，用MediaMuxer重新写成一个MP4文件的简单例子。 private void doExtract() throws IOException { MediaCodec.BufferInfo info = new MediaCodec.BufferInfo(); boolean outputDone = false; boolean inputDone = false; while (!outputDone) { if (!inputDone) { int inputBufIndex = mMediaCodec.dequeueInputBuffer(10000); if (inputBufIndex >= 0) { ByteBuffer inputBuf = mMediaCodec.getInputBuffers()[inputBufIndex]; int chunkSize = mMediaExtractor.readSampleData(inputBuf, 0); if (chunkSize < 0) { mMediaCodec.queueInputBuffer(inputBufIndex, 0, 0, 0L, MediaCodec.BUFFER_FLAG_END_OF_STREAM); inputDone = true; } else { mMediaCodec.queueInputBuffer(inputBufIndex, 0, chunkSize, mMediaExtractor.getSampleTime(), 0); mMediaExtractor.advance(); } } } if (!outputDone) { int decoderStatus =mMediaCodec.dequeueOutputBuffer(mBufferInfo, 10000); if (decoderStatus == MediaCodec.INFO_TRY_AGAIN_LATER) { Log.d(TAG, "no output from decoder available"); } else if (decoderStatus == MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED) { Log.d(TAG, "decoder output buffers changed"); } else if (decoderStatus == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) { MediaFormat newFormat = SDecoder.decoder.getOutputFormat(); Log.d(TAG, "decoder output format changed: " + newFormat); } else { if ((mBufferInfo.flags & MediaCodec.BUFFER_FLAG_END_OF_STREAM) != 0) { mMediaCodec.releaseOutputBuffer(outputBufferIndex,false); outputDone = true; break; } // 获取一个只读的输出缓存区inputBuffer ，它包含被编码好的数据 ByteBuffer outputBuffer = null; if (Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP) { outputBuffer = mMediaCodec.getOutputBuffers()[outputBufferIndex]; } else { outputBuffer = mMediaCodec.getOutputBuffer(outputBufferIndex); } if ((mBufferInfo.flags & MediaCodec.BUFFER_FLAG_CODEC_CONFIG) != 0) { MediaFormat format = mMediaCodec.getOutputFormat(); format.setByteBuffer("csd-0",outputBuffer); mBufferInfo.size = 0; } // 如果API<=19，需要根据BufferInfo的offset偏移量调整ByteBuffer的位置 // 并且限定将要读取缓存区数据的长度，否则输出数据会混乱 if (mBufferInfo.size != 0) { if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.KITKAT) { outputBuffer.position(mBufferInfo.offset); outputBuffer.limit(mBufferInfo.offset + mBufferInfo.size); } // mMuxer.writeSampleData(mTrackIndex, encodedData, bufferInfo); } mMediaCodec.releaseOutputBuffer(decoderStatus, false); } } } } 文章来源：https://blog.csdn.net/gb702250823/article/details/81627503 读取更多关于Android原生编解码接口 MediaCodec 完全解析 »

MediaCodec MediaCodec类可以用来访问底层媒体编解码器，即编码器/解码器的组件。 它是Android底层多媒体支持架构的一部分（通常与MediaExtractor，MediaSync，MediaMuxer，MediaCrypto，MediaDrm，Image，Surface和AudioTrack一起使用）。 从广义上讲，一个编解码器处理输入数据以生成输出数据。 它异步地处理数据，并使用一组输入和输出缓冲器。 从一个简单的层面上看，可请求（或接收）一个空的输入缓冲器，然后用数据填满它，并将其发送到编解码器去处理。 编解码器使用这些数据并转换这些数据到它某个空的输出缓冲区。 最后，您请求（或接收）一个已填充数据的输出缓冲区，消耗其内容并将其释放回并回到编解码器。 数据类型（Data Types） 编解码器对3种数据进行操作：压缩后的数据，原始音频数据和原始视频数据。可以使用ByteBuffers处理所有三种数据，但对原始视频数据，您应该使用Surface以提高编解码的性能。Surface使用本地视频缓冲区而不是映射或复制到ByteBuffers，因此，效率更高。 通常在使用Surface时无法访问原始视频数据，但您可以使用ImageReader类访问不安全的解码（原始）视频帧。 这可能比使用ByteBuffers更有效，因为一些本机缓冲区可能被映射到直接ByteBuffers。 当使用ByteBuffer模式时，您可以使用Image类和getInput / OutputImage（int）访问原始视频帧。 压缩缓冲区（Compressed Buffers） 输入缓冲器（用于解码器）和输出缓冲器（用于编码器）根据格式的类型来存放已压缩的数据。 对于视频类型，这是一个单一的压缩后的视频帧。 对于音频数据，这通常是单个访问单元（一个编码后的音频片段段通常包含由格式类型指定的几毫秒音频），但是这个要求可以稍微放宽，因为缓冲器可以包含多个编码的音频访问单元。 在任一情况下，缓冲区不会以随意的字节边界开始或结束，而是在帧/访问单元边界上开始或者结束。 原始音频缓冲器（Raw Audio Buffers） 原始音频缓冲器包含PCM音频数据的整个帧，它是每个通道样本的集合，每个样本按照通道顺序排。 每个样本是一个16位有符号整数，按照本机字节顺序排列。 short[] getSamplesForChannel(MediaCodec codec, int bufferId, int channelIx) { ByteBuffer outputBuffer = codec.getOutputBuffer(bufferId); MediaFormat format = codec.getOutputFormat(bufferId); ShortBuffer samples = outputBuffer.order(ByteOrder.nativeOrder()).asShortBuffer(); int numChannels = formet.getInteger(MediaFormat.KEY_CHANNEL_COUNT); if (channelIx < 0 || channelIx >= numChannels) { return null; } short[] res = new short[samples.remaining() / numChannels]; for (int i = 0; i < res.length; ++i) { res[i] = samples.get(i * numChannels + channelIx); } return res; } 原始视频缓冲区（Raw Video Buffers） 在ByteBuffer模式下，视频缓冲区根据其颜色格式进行布局。 您可以通过 getCodecInfo().getCapabilitiesForType(...).colorFormats 获取支持的颜色格式数组。 视频编解码器可能支持三种颜色格式： 原生原始视频格式：由COLOR_FormatSurface标记，可以与输入或输出Surface一起使用。 灵活的YUV缓冲（如COLOR_FormatYUV420Flexible）：这些可以通过使用getInput / OutputImage（int）与输入/输出Surface以及ByteBuffer模式一起使用。 其他或特定格式：这些通常只在字节缓冲区模式支持。 一些颜色格式是供应商特定的。 其他的在 MediaCodecInfo.CodecCapabilities中定义。 对于等同于灵活格式的颜色格式，您仍然可以使用 getInput/OutputImage(int)。 从LOLLIPOP_MR1开始，所有视频编解码器都支持灵活的YUV 4：2：0缓冲区。 访问旧设备上的原始视频字节缓冲区 在LOLLIPOP和Image支持之前，您需要使用KEY_STRIDE和KEY_SLICE_HEIGHT输出格式值来了解原始输出缓冲区的布局。 请注意，在某些设备上，切片高度被标示为0.这可能意味着切片高度与帧高度相同，或者切片高度与帧高度对齐为某个值（通常是2的幂）。 不幸的是，在这种情况下，没有标准和简单的方式来说明实际的切片高度。此外，平面格式的U平面的垂直跨度也没有被指定或定义，尽管通常它是切片高度的一半。 KEY_WIDTH和KEY_HEIGHT键指定视频帧的大小; 然而，对于大多数包络，视频（图片）仅占据视频帧的一部分。 这由“裁剪矩形”表示。 您需要使用以下键从输出格式获取原始输出图像的裁剪矩形。 如果这些键不存在，则视频占据整个视频帧。在应用任何旋转之前，裁剪矩形在输出帧应结合上下文中来理解。 格式键 类型 描述 “crop-left” Integer The left-coordinate (x) of the crop rectangle “crop-top” Integer The top-coordinate (y) of the crop rectangle “crop-right” Integer The right-coordinate (x) MINUS 1 of the crop rectangle “crop-bottom” Integer The bottom-coordinate (y) MINUS 1 of the crop rectangle 右侧和底部坐标可以被理解为裁剪输出图像的最右侧的有效的列/底部最有效行的坐标。 视频帧的大小（旋转之前）可以这样计算： MediaFormat format = decoder.getOutputFormat(…); int width = format.getInteger(MediaFormat.KEY_WIDTH); if (format.containsKey("crop-left") && format.containsKey("crop-right")) { width = format.getInteger("crop-right") + 1 - format.getInteger("crop-left"); } int height = format.getInteger(MediaFormat.KEY_HEIGHT); if (format.containsKey("crop-top") && format.containsKey("crop-bottom")) { height = format.getInteger("crop-bottom") + 1 - format.getInteger("crop-top"); } 另请注意，BufferInfo.offset的含义在设备之间不一致。 在某些设备上，偏移指向裁剪矩形的左上角像素，而在大多数设备上，它指向整个帧的左上角像素。 状态（States） 在其生命周期中，编解码器在概念上处于三种状态中的某一个：停止，执行或释放。 停止状态实际上是三个状态的集合：未初始化，配置就绪和出错，而执行状态在概念上通过三个子状态进行：刷新，运行和结束。 当您使用出厂方法之一创建编解码器时，编解码器处于未初始化状态。 首先，您需要通过configure(…)进行配置，使其进入Configured状态，然后调用start()让其进入到执行状态。 在这种状态下，您可以通过上述缓冲区队列操作来处理数据。 执行状态有三个子状态：已刷新，运行和流结束。 在start()后，编解码器立即处于Flushed子状态，它拥有所有的缓冲区。 一旦第一个输入缓冲区出出队，编解码器就会移动到运行的子状态，生命周期中的大部分时间都处于该状态。 当您对输入缓冲区入队时带有流末尾标记时，编解码器将转换到流末端子状态。 在这种状态下，编解码器不再接受以后的输入缓冲器，但仍然产生输出缓冲器，直到输出端到达流末尾。 在执行状态下，可以随时使用flush()来回到Flushed子状态。 调用stop()将编解码器返回到未初始化状态，然后可以重新配置。 使用完毕编解码器后，您必须通过调用release()来释放它。 在极少数情况下，编解码器可能会遇到错误并移动到错误状态。 这通过来自排队操作的无效返回值告知，或有时通过异常来传递。 调用reset()使编解码器再次可用。 您可以从任何状态调用它，将编解码器移回未初始化状态。 否则，调用release()到最终的释放状态。 创建（Creation） 使用MediaCodecList为特定的MediaFormat创建一个MediaCodec。 解码文件或流时，可以从MediaExtractor.getTrackFormat获取所需的格式。 使用MediaFormat.setFeatureEnabled添加任何特定的特性，然后调用MediaCodecList.findDecoderForFormat得到可以处理特定媒体格式的编解码器的名称。 最后，使用createByCodecName（String）创建编解码器。 注意：在LOLLIPOP上，MediaCodecList.findDecoder / EncoderForFormat的格式不能包含帧速率。 使用format.setString（MediaFormat.KEY_FRAME_RATE，null）以格式清除任何现有的帧速率设置。 您也可以使用createDecoder / EncoderByType（String）为特定的MIME类型创建首选编解码器。 然而，这不能用于添加特性，并且可能创建无法处理特定所需媒体格式的编解码器。 创建安全的解码器 在KITKAT_WATCH及更早版本上，安全编解码器可能未列在MediaCodecList中，但仍可能在系统上可用。 存在的安全编解码器可以通过名称实例化，通过将“.secure”附加到常规编解码器的名称（所有安全编解码器的名称必须以“.secure”结尾）。如果编解码器在系统上不存在，createByCodecName（String）将抛出IOException。 从LOLLIPOP开始，您应该使用媒体格式的FEATURE_SecurePlayback功能来创建安全解码器。 初始化（Initialization） 创建编解码器后，如果要异步处理数据，则可以使用setCallback设置回调。 然后，使用特定的媒体格式配置编解码器。 这时您可以为视频生产者—生成原始视频数据的编解码器（例如视频解码器）指定输出的Surface。这时您可以设置安全编解码器的解密参数（请参阅MediaCrypto）。最后，由于某些编解码器可以在多种模式下运行，因此您必须指定是否要将其用作解码器或编码器。 从LOLLIPOP开始，您可以在Configured状态下查询生成的输入和输出格式。在启动编解码器之前，您可以使用它来验证结果配置，例如颜色格式。 如果您想要与视频消费者——一个处理原始视频输入的编解码器（如视频编码器）本地处理原始输入视频缓冲区，可在配置后使用createInputSurface()创建输入目标Surface。 或者，通过调用setInputSurface(Surface)来设置编解码器以使用先前创建的持久输入Surface。 编解码器特定的数据（Codec-specific Data） 一些格式，特别是AAC音频和MPEG4，H.264和H.265视频格式要求实际数据以包含设置数据或编解码器特定数据的缓冲区为前缀。 处理这种压缩格式时，必须在start()之后和任何帧数据之前将该数据提交到编解码器。 在调用queueInputBuffer时，必须使用标志BUFFER_FLAG_CODEC_CONFIG标记此类数据。 Codec特定的数据也可以以传递给配置的格式包含在带有“csd-0”，“csd-1”等字符串的ByteBuffer条目中。这些键始终包含在从MediaExtractor获取的MediaFormat中。 在其中的编解码器特定数据在start()时自动提交到编解码器；您不能显示地提交此数据。 如果结构不包含编解码器特定数据，您可以根据格式要求选择使用指定数量的缓冲区以正确的顺序提交它。 在H.264 AVC的情况下，您还可以连接所有编解码器专用数据，并将其作为单个编解码器配置缓冲区提交。 Android使用以下编解码器特定的数据缓冲区。 这些还需要按照适合MediaMuxer轨道配置的轨道格式进行设置。 每个参数集和标有（*）的编解码器特定数据段必须以起始代码“\x00\x00\x00\x01”开头。 Format CSD buffer #0 CSD buffer #1 CSD buffer #2 AAC Decoder-specific information from ESDS* Not Used Not Used VORBIS Identification header Setup header Not Used OPUS Identification header Pre-skip in nanosecs(unsigned 64-bit native-order integer.)This overrides the pre-skip value in the identification header. Seek Pre-roll in nanosecs(unsigned 64-bit native-order integer.) MPEG-4 Decoder-specific information from ESDS* Not Used Not Used H.264 AVC SPS (Sequence Parameter Sets*) PPS (Picture Parameter Sets*) Not Used H.265 HEVC VPS (Video Parameter Sets*) +SPS (Sequence Parameter Sets*) +PPS (Picture Parameter Sets*) Not Used Not Used VP9 VP9 CodecPrivate Data (optional) Not Used Not Used 注意：当编解码器在启动后立刻或稍后不久久刷新时，当任何输出缓冲区或输出格式的更改返回之前，必须要小心，因为在刷新过程中编解码器特定数据可能会丢失。 您必须在这样的刷新之后使用标记为BUFFER_FLAG_CODEC_CONFIG的缓冲区重新提交数据，以确保正确的编解码器操作。 编码器（或产生压缩数据的编解码器）将创建带有codec-config标志的输出缓冲器，并在其中存放配置编解码器特定的数据并返回，这个动作将在输出任何存放有效数据的缓冲器之前进行。 包含编解码器特定数据的缓冲区的时间戳是没有意义的。 数据处理（Data Processing） 每一个编解码器拥有一套在API调用中由buffer-ID引用的输入和输出缓冲器，在一次对start()成功调用后，客户端“拥有”既不输入也不输出的缓冲区。 在同步模式下，调用dequeueInput / OutputBuffer(…)从编解码器获取（获得）输入或输出缓冲区的所有权。 在异步模式下，您将通过MediaCodec.Callback.onInput / OutputBufferAvailable(…)回调自动接收可用的缓冲区。 在获得输入缓冲区时，填写数据并使用queueInputBuffer或queueSecureInputBuffer将其提交到编解码器（如果使用解密）。不要提交具有相同时间戳的多个输入缓冲区（除非是特定于编解码器的数据）。 反过来该编解码器将在异步模式下经由onOutputBufferAvailable回调返回只读输出缓冲器，或者响应于在同步模式中的dequeuOutputBuffer呼叫。 输出缓冲器已被处理后，调用的releaseOutputBuffer方法中的一个将缓冲器返回到编解码器。 尽管你不需要立即重新提交/释放缓冲器到编解码器，但持续持有输入或输出缓冲器会使编解码器停止，而这种行为是设备相关的。 具体来说，编解码器可能会在生成输出缓冲区之前停止，直到所有未完成的缓冲区被释放/重新提交为止。 因此，尽可能短地持有可用的缓冲区。 取决于API版本，您可以通过三种方式处理数据： Processing Mode API version <= 20 Jelly Bean/KitKat API version >= 21 Lollipop and later Synchronous API using buffer arrays Supported Deprecated Synchronous API using buffers Not Available Supported Asynchronous API using buffers Not Available Supported 使用Buffers异步地处理 从LOLLIPOP开始，优选的方法是在配置之前设置一个回调然后采用异步方式来处理数据。 异步模式稍微地更改状态，因为必须在flush()之后调用start()将编解码器转换为r运行子状态并开始接收输入缓冲区。 类似地，在初始调用启动编解码器将直接移动到运行子状态，并通过回调开始传递可用的输入缓冲区。 MediaCodec使用异步模式的典型例子如下： MediaCodec codec = MediaCodec.createByCodecName(name); MediaFormat mOutputFormat; // member variable codec.setCallback(new MediaCodec.Callback() { @Override void onInputBufferAvailable(MediaCodec mc, int inputBufferId) { ByteBuffer inputBuffer = codec.getInputBuffer(inputBufferId); // fill inputBuffer with valid data … codec.queueInputBuffer(inputBufferId, …); } @Override void onOutputBufferAvailable(MediaCodec mc, int outputBufferId, …) { ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId); MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A // bufferFormat is equivalent to mOutputFormat // outputBuffer is ready to be processed or rendered. … codec.releaseOutputBuffer(outputBufferId, …); } @Override void onOutputFormatChanged(MediaCodec mc, MediaFormat format) { // Subsequent data will conform to new format. // Can ignore if using getOutputFormat(outputBufferId) mOutputFormat = format; // option B } @Override void onError(…) { … } }); codec.configure(format, …); mOutputFormat = codec.getOutputFormat(); // option B codec.start(); // wait for processing to complete codec.stop(); codec.release(); 使用Buffers同步地处理 从LOLLIPOP开始，即使在同步模式下使用编解码器，也应该使用getInput / OutputBuffer(int)和/或getInput / OutputImage(int)来检索输入和输出缓冲区。 这允许框架进行某些优化，例如。 处理动态内容时。 如果您调用getInput /OutputBuffers()，则此优化将被禁用。 注意：不要同时混合使用缓冲区和缓冲区数组的方法。 具体来说，只有在start（）之后才能直接调用getInput / OutputBuffers，或者在输出缓冲区ID的值为INFO_OUTPUT_FORMAT_CHANGED之后才调用。 MediaCodec使用同步模式的典型例子如下： MediaCodec codec = MediaCodec.createByCodecName(name); codec.configure(format, …); MediaFormat outputFormat = codec.getOutputFormat(); // option B codec.start(); for (;;) { int inputBufferId = codec.dequeueInputBuffer(timeoutUs); if (inputBufferId >= 0) { ByteBuffer inputBuffer = codec.getInputBuffer(…); // fill inputBuffer with valid data … codec.queueInputBuffer(inputBufferId, …); } int outputBufferId = codec.dequeueOutputBuffer(…); if (outputBufferId >= 0) { ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId); MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A // bufferFormat is identical to outputFormat // outputBuffer is ready to be processed or rendered. … codec.releaseOutputBuffer(outputBufferId, …); } else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) { // Subsequent data will conform to new format. // Can ignore if using getOutputFormat(outputBufferId) outputFormat = codec.getOutputFormat(); // option B } } codec.stop(); codec.release(); 使用Buffer数组同步地处理（已过期） 在版本KITKAT_WATCH和之前，输入和输出缓冲区的集合由ByteBuffer[] 数组表示。 在成功调用start()之后，使用getInput/OutputBuffers()获得缓冲区数组。如下面的示例所示，使用缓冲区ID作为这些数组中的索引（当为非负数时）。 请注意，数组的大小与系统使用的输入和输出缓冲区的数量之间没有固有的相关性，尽管数组大小有一个上限。 MediaCodec codec = MediaCodec.createByCodecName(name); codec.configure(format, …); codec.start(); ByteBuffer[] inputBuffers = codec.getInputBuffers(); ByteBuffer[] outputBuffers = codec.getOutputBuffers(); for (;;) { int inputBufferId = codec.dequeueInputBuffer(…); if (inputBufferId >= 0) { // fill inputBuffers[inputBufferId] with valid data … codec.queueInputBuffer(inputBufferId, …); } int outputBufferId = codec.dequeueOutputBuffer(…); if (outputBufferId >= 0) { // outputBuffers[outputBufferId] is ready to be processed or rendered. … codec.releaseOutputBuffer(outputBufferId, …); } else if (outputBufferId == MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED) { outputBuffers = codec.getOutputBuffers(); } else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) { // Subsequent data will conform to new format. MediaFormat format = codec.getOutputFormat(); } } codec.stop(); codec.release(); 处理流末尾（End-of-stream Handling） 当您到达输入数据的末尾时，必须通过在对queueInputBuffer的调用中指定BUFFER_FLAG_END_OF_STREAM标志来将其发送到编解码器。 您可以在最后一个有效的输入缓冲区中执行此操作，也可以通过提交一个额外的空输入缓冲区来设置流终止标志。 如果使用空的缓冲区，时间戳将被忽略。 编解码器将继续返回输出缓冲区，直到最终通过在dequeueOutputBuffer中设置的MediaCodec.BufferInfo中指定相同的流出尾标志，或通过onOutputBufferAvailable返回信号来输出流的结尾。 这可以在最后一个有效的输出缓冲区上设置，也可以在最后一个有效输出缓冲区之后的空缓冲区中设置。 这样的空缓冲区的时间戳应该被忽略。 在信号输入流结束后，请勿提交其他输入缓冲区，除非编解码器已被刷新，或停止并重新启动。 使用一个输出Surface（Using an Output Surface） 当使用输出Surface时，数据处理与ByteBuffer模式几乎相同; 然而，输出缓冲区将不可访问，并被表示为空值。 例如，getOutputBuffer/Image(int)将返回null，而getOutputBuffers()将返回一个仅包含null的数组。 使用输出Surface时，可以选择是否在Surface上渲染每个输出缓冲区。 你有三个选择： 不要渲染缓冲区：调用releaseOutputBuffer(bufferId，false)。 使用默认时间戳渲染缓冲区：调用releaseOutputBuffer(bufferId，true)。 使用特定时间戳渲染缓冲区：调用releaseOutputBuffer(bufferId，timestamp) 从M开始，默认时间戳是缓冲区的显示时间戳（转换为纳秒），之前没有定义。 此外，从M开始，您可以使用setOutputSurface动态更改输出Surface。 在渲染到Surface上时的变换 如果编解码器配置为Surface模式，任何裁剪矩形，旋转和视频缩放模式将被自动应用，但有一个例外： 在Android M之前，当渲染到Surface上时，软件解码器可能没有应用旋转。 不幸的是，没有标准和简单的方法来识别软件解码器，或者除了通过尝试外，它们应用旋转。 还有一些注意事项。 请注意，当在Surface上显示输出时，不考虑像素长宽比。 这意味着如果您使用VIDEO_SCALING_MODE_SCALE_TO_FIT模式，则必须定位输出的Surface，使其具有正确的最终显示宽高比。 相反，您只能对具有方形像素（像素宽高比或1：1）的内容使用VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING模式。 另请注意，从Android N开始，VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING模式在视频旋转90或270度时可能无法正常工作。 当设置视频缩放模式时，请注意，每当输出缓冲区更改后，必须进行Reset。 由于已不推荐使用INFO_OUTPUT_BUFFERS_CHANGED事件，因此可以在每次输出格式更改后执行此操作（Reset操作）。 使用Surface作为输入 当使用Surface作为输入时，没有输入缓冲区可供访问，因为缓冲区会从输入Surface自动传递到编解码器。 调用dequeueInputBuffer将抛出一个IllegalStateException，getInputBuffers()将返回一个伪造的ByteBuffer[]数组，切记不要去对该数组执行写入操作 调用signalEndOfInputStream来发送流末尾信号。 输入Surface将在此调用后立即停止向编解码器提交数据。 对选进度和自适应播放的支持 视频解码器（以及消耗经过压缩的视频数据的一般编解码器）的行为不同关于寻求和格式改变他们是否支持并配置了自适应播放。 您可以通过CodecCapabilities.isFeatureSupported(String)来检查解码器是否支持自适应播放。 支持自适应播放的视频解码器仅在将其的输出配置为Surface时才能使用自适应播放。 流边界和关键帧 很重要的一点，在start()或flush()之后的输入数据开始于合适的流边界：第一帧必须是关键帧。关键帧可以自己完全解码（对于大多数编解码器，这代表I帧），并且在关键帧之后，没有帧会以该关键帧之前的帧作为参考帧。 下表总结了各种视频格式的合适关键帧。 Format Suitable key frame VP9/VP8 a suitable intraframe where no subsequent frames refer to frames prior to this frame.(There is no specific name for such key frame.) H.265 HEVC IDR or CRA H.264 AVC IDR MPEG-4 H.263 MPEG-2 a suitable I-frame where no subsequent frames refer to frames prior to this frame.(There is no specific name for such key frame.) 对于不支持自适应播放的解码器（包括解码输出不是Surface的情况） 为了开始解码与先前提交的数据不相邻的数据（即在进度拖动之后），您必须刷新解码器。由于所有输出缓冲区在刷新点立即被撤销，因此您可能需要首先发出信号，然后在等待流末尾到来再调用flush。 重要的是，刷新后的输入数据起始于合适的流边界/关键帧。 注意：数据的格式在一次flush后不得改变；flush()不支持格式不连续；为此，需要一个完整的stop()-configure()-start()过程。 另请注意：如果在start()之后很快刷新编解码器—— 一般来说，在接收到第一个输出缓冲区或接收到输出格式更改之前，您将需要重新提交编解码器特定数据到编解码器。有关更多信息，请参阅编解码器特定数据部分。 对于支持并且已配置为自适应播放的解码器 为了开始解码与先前提交的数据不相邻的数据（即，在寻找之后），不需要刷新解码器; 然而，在中断之后的输入数据必须在一个合适的流边界/关键帧开始。 对于某些视频格式，即H.264，H.265，VP8和VP9，也可以在流中部改变画面大小或配置。为此，您必须将整个新的编解码器特定配置数据与关键帧一起打包到单个缓冲区（包括起始代码）中，并将其作为常规输入缓冲区提交。 在画面尺寸发生改变之后，任何新尺寸的帧返回之前，您将通过dequeueOutputBuffer的返回值或onOutputFormatChanged的回调收到一个INFO_OUTPUT_FORMAT_CHANGED。 注意：就像编解码器特定的数据一样，在更改图片大小后不久调用flush()时要小心。 如果您没有收到图片尺寸更改的确认，您将需要重复提交更改图片大小的请求。 错误处理 工厂方法createByCodecName和createDecoder / EncoderByType在失败时抛出IOException，您必须捕获或声明向上传递该异常。当调用某个方法时，编解码器正好处于不能调用该方法的状态时，MediaCodec的方法会抛出IllegalStateException；这通常是由于应用程序API使用不当导致的。涉及安全缓冲区的方法可能会抛出MediaCodec.CryptoException，错误信息可从getErrorCode()获取。 在应用程序正确调用了API时，编解码器的内部错误会引起MediaCodec.CodecException，导致该异常的原因可能为媒体内容损坏、硬件故障、资源耗尽等。 接收到CodecException时推荐的操作可通过调用isRecoverable()和isTransient()来确定： 可恢复的错误：如果isRecoverable()返回true，则调用stop()，configure(…)和start()来恢复。 瞬时错误：如果isTransient()返回true，则资源暂时不可用，并且可能会在稍后重试该方法。 致命错误：如果isRecoverable()和isTransient()都返回false，则CodecException是致命的，并且必须重置或释放编解码器。 isRecoverable()和isTransient()都不会同时返回true。 版权所有：https://blog.csdn.net/YSSJZ960427031 读取更多关于MediaCodec官方文档译文 »

民小编说 疫情当下，部分地区的线上教育教学经历了适应、调整、提升后， 步入了相对平稳期，通过对上述阶段的回顾和反思，我们是否对基础教育线上教学工作的定位有了更清楚的认识？本为以浙江省为例，对一段时间以来开展的线上教学工作进行反思，以期探索适合国情省情的基础教育线上工作新模式，一起来看。 当前，线上教育教学的组织和实施工作无疑是中小学校教育工作者和学生家长最为关注的内容。虽然近几年来浙江省中小学教育信息化，特别是学生个性化学习和技术辅助学习等方面得到了显著发展，但教育技术一直充当着补位者和辅助者的职责。当疫情影响下所有教育教学工作都依托线上开展时，绝大多数师生毫无准备地卷入到了在线教育教学工作中，原有的教育教学秩序被迫做出改变，无论是教育技术硬软件，还是师生对于线上学习的适应性都迎来了极大冲击，保障线上教育教学工作有序开展，确保原有教育目标如期实现成为了所有人的共同责任。 01 浙江省线上教育教学的几个阶段 从2月10日至今，浙江省线上教育教学实施已超过一个月，经历了前期的适应和调整后，当前线上教育教学工作逐步走向平稳有序。回顾这一个多月的线上教育教学探索，我们认为浙江省的线上教育教学走过了这么几个阶段。 适应期：智库支持下的社会实验 此阶段主要回答的是线上教育教学能不能做的问题。 初始阶段，线上教学的实施更多属于被迫，而非主动，两者之间的不同带来的是全省师生准备和适应程度的不同。由于疫情的突然和不可控，留给学校、教师和学生适应线上教育教学工作准备的时间只有1-2周，这加大了此项工作的难度。杨晓哲博士的调研数据显示，大多数（63.06%）教师认为在线教学难度较高，主要的困难中“教师自己对技术不熟悉”排在前三位。 带着各种不确定性，全国基础教育开展了一次“全球最大的信息化教学社会实验”和一次“开发教育资源运动”，为最大程度减少缺乏前备经验带来的不适应性，浙江省在这一阶段主要做的就是充分利用浙江省基础教育课程改革专业指导委员会的智库资源，汇集全省中小学优秀教师的智慧参与编制了《关于防控疫情延迟开学期间在全省中小学全面实施线上教育教学工作的指导意见》和各学段各学科的延迟开学期间线上教学提示，有效缓解了教师层面的焦虑感。 调整期：基于调研反馈的本源回溯 此阶段回答的是线上教育教学应该做什么的问题。 当线上教学逐步走上常态化，关于线上教育教学工作的本质到底是什么的问题引发了全省基础教育界的关注。一方面，各地市各区域为体现教育的担当和惯性思维，花大力气在开发线上教育的直播课程上，教师当上“十八线主播”的调侃成为热议；另一方面，大规模的直播互动造成的网络崩溃及直播课程学生参与度不高等问题也不断涌现，线上教育教学走在了十字路口。 在这一阶段，全国出现了各种对于线上教育教学工作的问卷调查，数据显示直播课程占比最多，但学生满意度最高的却是资源包的学习方式（限于理解水平，当时并未对资源包学习方式的具体内涵进行丰富和拓展），这一判断为后期的线上教育教学工作提供了有力支持，后期上海、安徽等地实施的线上教育教学工作也大体按与这一思路相仿。 提升期：群众智慧的形成与总结 这一阶段回答的是线上教育教学怎么做得更好的问题。 当前浙江正处于这一阶段，经过一个月的实践，线上教育教学各要素已相对齐全，随着全国疫情防控工作的有效推进，人民群众对线上教学的了解认可程度也得到提升，如何将这一工作做得更好成为对教育工作者的挑战，各地推出了丰富多彩的举措。 浙江省教育厅教研室抓住疫情的特殊背景，提出了利用这段时间开展项目学习探索的倡议，并向全省征集优秀的项目学习案例，希望能挖掘优秀的群众智慧，化疫情防控为教学资源以及立德树人根本任务落实的有效媒介。 需要特别说明的是，上述几个阶段并没有明确的时间划分，也没有显著的逻辑递进关系，此外上述阶段的出现情况还会因区域实际情况及信息化程度不同等因素也会产生影响。目前疫情结束复学还有一段不确定的时间，线上教学继续发展还会经历哪些阶段？我们预估至少还会出现两个阶段：一是再调整期，是群众智慧的辐射和应用，回答的是“我能不能也做的这么好”的问题；二是反思期，既是对这一时期工作成效的反思，同时也是对回归正常后如何衔接的思考，回答的是“我做得怎么样”以及“我还能怎么做”等问题。 02 教师指导下的自主学习能力培养： 线上教育教学的定位重构 线上教育教学工作逐步进入提升期代表此项工作逐步稳定，但随着线上教学时间持续，学生对于线上学习的满意度也在下降，根据3月5日与2月18日两次浙江省高中学生（主要是高三）线上满意度调查数据对比显示，持续半月的线上学习后，学生整体满意度下降近10个百分点。如何提升学生的自我效能成为当前阶段的主要任务。 从前期问卷调查结果显示，虽然网络直播课程是各区各校的主要形式，但学生最满意的线上学习方式却是资源包的学习。所谓资源包学习是对传统定时定表课堂教学的颠覆，它更多关注学生的自学，资源包是教师远程指导的主要媒介，同时资源包学习的自由性使得“以终为始”的教学设计更为凸显。显然，我们对于线上教育教学工作的认识并不充分，我们需要借助各阶段的转变反思线上教育教学到底为何。 一是对线上教育教学的概念进行勘误 线上教育教学≠直播/录播课程 初期，对教材知识点的直播或者录播课程几乎等同于线上教育教学全部，绝大多数学校都陷入了“临时开发直播课程-教师缺乏直播技能-网络平台不支持-学生反响较差-继续升级直播课程”的怪圈，这一思想的形成也与教育技术近几年与互联网的紧密结合有关。 事实上，线上教育教学绝不等同于单纯的直播或录播课程。一方面，从教学形式上，除了直播和录播外，还有更多的方式，例如学习任务式、互动研讨式、作品展现式等，从我们的实践看，直播课程更适合基础薄弱学生学习，录播或视频课程则更适合学有余力学生的提升释疑。另一方面，在学习内容上，线上教育教学的核心和指向都应该凸显育人目标，绝不能将其简单等同于知识点传授。 线上教育教学≠线下教育线上化 当前的在线教学中，很多教育行政领导和一线老师将重心放在了如何将学习内容的电子化、数字化和网络化上，然后将传统的教学“照搬”到网络上，形成了所谓的“线上教学”，这其实是对线上教学的错误理解。我们认为线上教学应当是正常教育教学的组成部分，其与常规教育的关系并不是并列的关系，而是后者包含前者的关系，只不过因为现在的特殊时期，由线上教学承担了更多的责任罢了。 线上教育教学≠纯粹学生自学 目前还有一种社会的声音就是“线上教学无效论”，该观点认为线上教学是教育部门的理想状态，实际效果差，也会引起学生近视、两极分化等现象。这种观点的产生很大原因是部分老师推卸了原本属于他的教学指导职责，将线上教学简单的等同于学生自学，教师的唯一作用即定时将学习资料发送给学生，成为名副其实的“资料发送机”。 线上教学是个完整的教学活动，必然包含了学生的学和教师的教，两者是紧密相连、互不可替代的，缺少了任意一个环节都不能成为严格意义上的教学。 二是线上教育教学的定位重构。 既然对于线上教育教学有这么多错误的认知，那么真正的线上教育教学到底是什么？正如上文提及的，我们认为线上教学是正常教育教学活动的有机组成部分，因此线上教学自然也应该符合对于教育教学的认知，回答线上教育教学是什么的问题其实也是在回答教学是什么的问题。 同课堂教学一样，我们认为线上教育教学应该是教师与学生互动的过程，学生的线上学习依赖于教师的帮助，也就是我们经常提及的“支架”。但与线下教育教学不同的是，线上教学的落脚点更多的关注学生的“自学”：因为缺乏“课堂”“学校”等具有仪式感和空间感的地域制约，学生的学习成为了一种主动性、自觉性的行为；同时，由于学习的过程中也缺乏“随叫随到”的教学互动支持，因此更依赖于个体的学习方法和能力。概括而言，我们认为当前实施的线上教学应该具备三个特征： 1.线上教育教学首先是教育教学的组成部分，需要师生互动，缺乏任一主体都将无法形成教学的回路。 2.线上教学依赖于教师的指导和帮助，和常规学习相比，教师需要提供更多数量和形式的学习支架才能达成既定教学目标。 3.线上教学的用力点在学生方，凸显自主学习的重要性，这里的自主学习既包括知识点的学习，也包括学习方法的学习。 要想同时具备这三条特征，就必须架构“教师指导下的自主学习能力培养”教学模式，这一概念应当成为当下各地开展线上教学所秉持并实践的共识。 03 与“教师指导下的自主学习能力培养” 相适应的线上教学要素 线上教育教学是正常教育教学的组成部分，而非另一种形式的教育教学，因此无论哪种模式下的线上教学都遵循着目标、资源、实施、评价等课程四要素。但不同的是，线上教育教学在上述四方面有其独特的关注点和着力点，而所有的关注点和着力点都必须充分体现教师指导下的自主学习能力培养这一线上教学的基本共识。 制定合理教学目标 怎样的目标是合理的？崔允漷教授提出了教师在学生学习中的三种责任，如果将这三种责任用线上教学的语言描述和阐释，就是合理教学目标的三大要素。 第一要引起学习。合理的教学目标首要条件是要激发学生的学习动机，使学生想学或者更想学。教师可以结合本次疫情用项目式学习课程的目标作为引起学生兴趣的手段。 例如某初中数学老师提出了让学生为学校门口设计一个体温移动监测房的任务，学生需要整合数学、科学、技术等知识来解决这一真实问题，极大地调动了学生学习的兴趣。 第二要维持学习。维持学习比激发学生学习难度更大，特别是在屏幕两端，教师在无法实时快捷掌握学生学习状态的情况下，维持学生学习难度骤升。我们认为教师需要在教学目标的达成设计上下功夫。 以高中数学学科为例，由于导数等概念学习内容相对比较抽象，对思维水平要求较高，因此在制定教学目标时可凸显录播+直播的达成方式；对于概念、法则、公式应用类及习题课等教学内容的目标设计上可以探索翻转课堂形式。 第三是促进学习。这次的线上学习应该也必须成为促进学生学习能力提升和学习方法完善的重要途径，因此教师在教学目标设计上，需要时刻将促进学习作为目标的重要内容之一。一方面教师应该设计一定情境性、难度和挑战的教学目标，促进学生知识的拓展和迭代；另一方面要将学习指导工作纳入教学目标中，明确不同内容的学习方法，指导学生总结概括有个人特征的自主学习方式。 设计明晰学习任务 线上教育教学存在滞后性和不可观察性，因此学习任务设计的明晰性就显得尤为重要。 从现有实践来看，结合教学内容，借助问题链或任务串的方式进行任务的设计和布置是线上学生自主学习的有效路径。一方面问题链或任务串给学生思维的深化点明了方向，学生的自主学习有了明确目标和路径；另一方面，通过控制问题链或任务串的数量和内容，可以有效发挥教学支架的作用，并通过支架的不断拆除帮助学生实现知识的内化和方法的习得。 例如湖州市弁南小学的“防疫”校车站点设计项目中，教师设计了包括了解新冠肺炎、调查校车接送站点、校车站点体温检测站的要求等三个大任务若干个小任务，帮助学生从现有的学科知识体系与生活实际的结合中完成了这一看似复杂的STEM微项目。 此外，教师指导下的学生自主学习构建需要教师克服传统的一言堂和灌输式的教学任务设计，需要调整原先学校日常教学中“教”与“学”的时间比例，尽量压缩直播（录播）课的时间，用更多的时间关注学生的学习状况，并通过根据教学内容安排学生做好预习，指导学生摘录内容要点、标记疑惑之处等方式为任务设计更有针对性提供支持。 教学设计仍有余力的学校和教师还应考虑分层分类学习任务的设计。例如对学有余力学生与基础薄弱学生分别设计同一主题的不同任务，或者以小组合作方式，通过将不同水平学生的合理搭配分工，接近学生最近发展区，引导或驱动学生预学思考和探究。 提供充实资源支持 需要强调的是，线上教学对于资源支持的需求远比线下教学大，大规模调研显示的最受欢迎的“资源包学习”方式就是对线上教学资源支持重要性的有效体现，所以这里强调的是充实而不是充足：充足代表了数量，充实体现了数量与质量并重。 此外，要实现教师指导下的学生自主学习能力提升，资源的概念应该进一步扩充。我们认为充实的资源应该至少包含两大类。其一是包含教科书在内的学习资源。例如针对线上学习的直播课、教学视频（录播课、微课）、配发的学习材料（导向任务单、习题）、其它链接资源等。在教学资料提供上，一方面可以探索区域共享下的学习资源模式，另一方面也要实现知识学习的个性化，让学生有差异地拓展提升，例如有些是说明性的，已经掌握的学生可以跳过；有些是拓展性的，有兴趣与能力的学生可以进入。 其二是指教学方法的资源。无论是直播课堂还是资源包学习，其实本质是一样的，即更为重要的因素是教学方法，即学习的策略的学习。学校可拍摄制作兼顾学段和学科通识性学法指导类的微课视频，引导学生反思自己的学习方法，促进学生自主学习与自我管理能力的提升。要鼓励学生在线上主动分享、积极提问并记录听课过程中的思考，引导学生通过回看课程视频以查漏补缺；指导学生整理课后笔记，促进消化和吸收。 杭州市江干区推行的“八个一”就是这两种资源的有效整合。该区域教研部门经过需求调研，提出“八个一”资源包建设，即一份教学内容及进度安排表，一份教材资源链接；一套教学资料包（含课件、教学设计、微课），一份空中课堂学习、辅导要求，一套每日预习手册，一套每日作业手册，一份居家活动要求，一份家长学校的课程资源表等八类资源。这个资源包以真实问题为指导，从组织管理、施教资源、作业设计等三个方面为一线教师提供在线教学的“零配件”，解决“疫”时所需。 实施合理评价反馈 与常规教学相比，线上教学在作业布置、上交统计、批改反馈等方面存在较大问题，特别是部分原创性作业和低年段学生的作业如何电子化成为一个麻烦的问题。目前浙江省的大多数学校借助信息技术平台的优势实现了这一问题的有效解决，例如部分学校采用腾讯、阿里等大公司开发的作业管理软件，也有部分学校采用校本的平台和途径解决这些问题。 与作业相同，线上教学的反馈也存在操作上的难度，特别是在班级容量较大、学生硬软件条件不足的情况下尤为明显。我们建议可以以学校为单位建立学生提问答疑的交互平台，采用生动活泼的形式与激励机制，吸引学生积极参与；可以利用线上教学留言功能，及时收集学生的预习疑惑及课后困难，以便及时调整教学内容与方法；答疑反馈要遵循全体与个体相结合的原则，依据学科特点和作业形式选择快捷方便的反馈方式，要有利于学生的知识掌握、思维发展和后续学习。 作 者 | 王小平，作者单位系浙江省教育厅教研室 责任编辑 |董筱婷 微信排版 | 魏梦瑶 读取更多关于线上教学一个月之后，深度反思 »

问题：校务办公模块，查看“站内信”时，为什么在线预览附件，会显示错误？ 答：官方推荐使用Chrome浏览器 ；如果使用其它浏览器，建议设置成极速模式并及时清理缓存。 读取更多关于校务办公模块，查看“站内信”时，为什么在线预览附件，会显示错误？ »

现象：重新编译nginx前忘记先停止nginx运行，编译后 nginx -t 提示 nginx: [error] invalid PID number "" in "/run/nginx.pid" 等错误。 解决方案： 1.[root@localhost conf]# nginx -t nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful 2.nginx -c /usr/local/nginx/conf/nginx.conf 3.nginx -t 就能成功了，然后 -s reload 重启即可。 读取更多关于nginx: [error] invalid PID number »

一、comet基本概念 1.comet是一个用于描述客户端和服务器之间交互的术语，即使用长期保持的http连接来在连接保持畅通的情况下支持客户端和服务器间的事件驱动的通信。 2.传统的web系统的工作流程是客户端发出请求，服务器端进行响应，而comet则是在现有技术的基础上，实现服务器数据、事件等快速push到客户端，所以会出现一个术语”服务器推“技术。 二、push实现方式 1.原理：利用jsp/servel技术，在不关闭http流的情况下push数据到客户端浏览器； 2.实现：基于ajax的长轮询（long-polling）方式 ajax的出现使得javascript可以调用xmlhttprequest对象发出http请求，javascript响应处理函数根据服务器返回的信息对html页面的显示进行更新。使用ajax实现“服务器推”与传统的ajax应用不同之处在于： 1)、服务器端会阻塞请求直到有数据传递或超时才返回。 2)、客户端 javascript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。 3)、当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重 新建立连接，客户端会一次把当前服务器端所有的信息取回。 Pushlet实例 一、首先建立一个web工程pushlet，将pushlet.jar放到lib目录中，引入到工程。并且将pushlet.properties和sources.properties两个文件拷贝到WEB-INF目录中去。工程的目录结构如图示： 我们一般只需要对sources.properties进行修改即可，创建的消息源必须在这个文件中进行配置。消息源需要实现EventSource接口。 二、配置web.xml文件 <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> <!-- 注意，缺省不需要修改<url-pattern>/pushlet.srv</url-pattern>，如果修改， 需要在对应的js文件中也要修改。pushlt缺省就是通过pushlet.srv触发servlet的。 --> <servlet> <servlet-name>pushlet</servlet-name> <servlet-class> nl.justobjects.pushlet.servlet.Pushlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>pushlet</servlet-name> <url-pattern>/pushlet.srv</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app> 三、看一下index.jsp这个文件的内容 <%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%> <% String path = request.getContextPath(); String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/"; %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <base href="<%=basePath%>"> <title>HelloWorld</title> <meta http-equiv="pragma" content="no-cache"> <meta http-equiv="cache-control" content="no-cache"> <meta http-equiv="expires" content="0"> <meta http-equiv="keywords" content="keyword1,keyword2,keyword3"> <meta http-equiv="description" content="This is my page"> <script type="text/javascript" src="ajax-pushlet-client.js"></script> <script type="text/javascript"> //对pushlet的初始化，触发web.xml中的servlet。 PL._init(); //这里的监听的主题，必须在sources.properties中配置的对象中声明这个主题。 //sources.properties配置着事件源（EventSources），在服务器启动时会自动激活。 //可以通过服务器的启动记录查看得到。可以将这个文件放到WEB-INF目录下面或者classess目录下面都可以。 PL.joinListen('/linjiqin/hw'); function onData(event) { alert(event.get("hw")); } </script> </head> <body> </body> </html> 四、修改sources.properties文件 source1=nl.justobjects.pushlet.test.TestEventPullSources$TemperatureEventPullSource source2=nl.justobjects.pushlet.test.TestEventPullSources$SystemStatusEventPullSource source3=nl.justobjects.pushlet.test.TestEventPullSources$PushletStatusEventPullSource source4=nl.justobjects.pushlet.test.TestEventPullSources$AEXStocksEventPullSource source5=nl.justobjects.pushlet.test.TestEventPullSources$WebPresentationEventPullSource source6=nl.justobjects.pushlet.test.TestEventPullSources$PingEventPullSource #source1~source6是系统缺省自带的，source7是我自己配置的，并且在index.jsp中的脚本中， #配置的/linjiqin/hw是和这儿是对应的。具体是这样的。HwPlushlet是com.ljq.test.HelloWorldPlushlet对象的一个内部类， #并且继承EventPullSource接口。 source7=com.ljq.test.HelloWorldPlushlet 五、核心代码HelloWorldPlushlet 这样这个基本的例子就OK了，运行一下，看看吧。 package com.ljq.test; import java.io.Serializable; import nl.justobjects.pushlet.core.Event; import nl.justobjects.pushlet.core.EventPullSource; @SuppressWarnings("serial") public class HelloWorldPlushlet extends EventPullSource implements Serializable { /** * 设置休眠时间 */ @Override protected long getSleepTime() { return 1000; } /** * 创建事件 * * 业务部分写在pullEvent()方法中，这个方法会被定时调用。 */ @Override protected Event pullEvent() { Event event = Event.createDataEvent("/linjiqin/hw"); event.setField("hw", "HelloWorld!!!!"); return event; } } 访问http://localhost:8083/pushletprj 会定时弹出alert窗口，窗口的内容如下图： 如果这个页面关闭了，服务器会自动取消订阅，和移除对应的session信息。下面是我关闭页面后，服务器端的输出信息，如图： 读取更多关于开源框架Pushlet入门 »

变身线上教师2020快速指南 教研社 2020-02-02 11:16:26 在与线下教育扯头发拌嘴缠斗这么多年后，在线教育做梦都没想到，把他真正推向前台的，是一场春节前的肺炎疫情。 这一推，不仅极为急促突然，而且力道大势头猛，连在线教育自己都没完全准备好，让很多机构与学校的在线教学系统带着刚画了一半的妆就踉跄的摔了出来。 更要命的是，面对特殊环境下的激增的教学与学习需求，很多还在传统课堂的老师们也被从讲台推到了麦克风和摄像头的面前。 一夜之间，可以把课程都放在网络上；但一夜之间，不能将所有习惯于或者还没接触过在线教学环境的教师也一起改变。 于是，我们创建了这个小册子，尝试用简单易懂的表达方式，让习惯于传统教学方式的教师群体，可以快速理解和掌握在线教学的特点与要点，以便在未来一段时间不断持续提升在线课堂质量，通过网络给不能出门上课的学生带来更加优质的课程。 手册版本：Version 1.0.0 适用群体：习惯于传统线下教学环境的教师，无论是学校、机构，或大班、小班、一对一 适用学生：理论上可应用于所有在线课堂的学生，不分年级，不分年龄 阅读时间：12分钟 | 7000字 要想成为好的在线教师，就得了解什么是在线教育 1. 什么是在线教育？ 就是利用互联网渠道与技术进行教育内容或概念的传播分享、组织讨论、提交或批改作业、以及评价与反馈等日常教学行为的过程。 在线教育 (Online Education) 是相对于面授教育 (Face-to-Face Education) 的概念。 在传统课堂中，几乎没有网络参与，主要通过面对面教学 (Face-to-Face Education)；逐渐教师在面授课堂外通过网络开始分享或创造教育内容，为学生提供多样性的学习机会，这是常说的混合教学模式 (Blended Education)；而主要通过网络而很少或几乎不进行面授的教学模式被称为在线教育 (Online Education)。 2. 什么是在线课堂？ 就是通过网络与相关技术模拟的在线课堂环境，可以将学生与教师连接起来，通过视频看到对方、通过音频进行讲解与对话、通过文字、图表、文档形式等进行信息交换。并在此基础上完成教育环节中重要的交流、分享、讨论、提交、评价与反馈等关键行为，从而实现特定教育目标的虚拟环境。 3. 面授与在线教学的异同？ 面授教学是一种同步教学模式 (Synchronous)，强调教师与学生在同一空间内面对面条件下即时性的互动与交流，通过短时间高度思维的同步达到教学目标。 这种模式下即时性更强，由于近距离接触所获取的肢体、声音、视觉冲击更大，对于上下文环境的理解更透彻，适合创造性、建立协作关系、偏重解决问题的课程环境或目标。 在线教学更偏向异步教学模式 (Asynchronous)，它允许学生通过直播或录播形式匹配自己的学习时间，一次或多次重复学习。 这种模式下缺少面授的那种直接感与冲击力，但灵活的匹配了每个学生的自主学习进度与需求，把教师从重复性劳动中解放出来，专注解决问题，反而促进了个性化学习的发展，以及教师自身的专业能力发展。适合远距离、大规模、重复性内容的传递，个性化或混合式教学模型的创建。 无论面授与在线，都是为了实现所设计教学目标的渠道与方式，只不过一个是主要通过线下实现，一个主要通过线上。课程设计得当，还可以将两种实现渠道进行叠加以实现更好的教学效果，即混合教学模式。 决定在线课堂成败的重要指标，就是是否可以在网络环境下让学习者更加开放、协作、参与与反馈 4. 需要准备什么设备？ 宽带网络 目前环境下，大多数教师都是在家中上课，确保家中宽带可以实现基本的视频、音频交流不卡顿即可。这个可以通过观看视频平台高清晰度的电影电视剧，或与朋友家人进行多方微信视频通话进行测试，不卡顿为底线，越清晰越好。上课的人越多，互动越频繁，课程时间越长，对于网络的稳定性和速度要求越高。学校或机构的老师请咨询自己的技术支持部门了解对于网络的要求。上课时减少其他无关设备对于网络的使用所造成的干扰，例如IPTV。 在线教学环境 通常称作学习管理系统 (LMS)，就是上课时所需要登陆的平台。如果你是学校或机构的老师，都会配发账号，登陆后可使用课表查询、上传课件、视频音频交流、教学白板、布置批改作业、文字对话等功能。如果你是独立老师，可以使用免费或付费的第三方平台，创建自己的教室。如果你有技术能力，可以搭建一个专属的在线课堂。 电脑 无论台式机、一体机或笔记本，确保能够达到安装或运行在线教学环境，以及常用软件例如 PowerPoint、Chrome 浏览器的标准即可。上课前务必咨询对应的在线平台或技术支持部门了解电脑以及操作系统是否符合教学要求。如无紧急或特殊直播的需求，一般不建议使用手机进行视频教学，所支持的平台与功能目前限制太多。在线上课时，请关闭无关软件，避免无关的电脑性能占用与干扰。 USB 外接麦克风 请不要使用电脑内置的麦克风进行收音。如果购买麦克风，除非你是音频发烧友或特别了解电脑设备与音频设备的连接，否则请尽量降低设备之间连接的复杂度。USB 麦克风是非常好的选择，即插即用，一般系统会识别并自动连接常见品牌麦克风，不用太复杂的安装与调试。确保麦克风的收音品质，即使你的视频清晰度只有720P，搭配高清晰度的声音依然会带来良好的体验；但如果声音模糊或不清晰，还有杂音或干扰，即使视频达到4K或8K，也会影响效果。 USB 外接摄像头 上课前请了解自己所使用设备所自带摄像头的参数与清晰度，或者自拍一段进行测试。一般不建议使用设备内置的摄像头，大多数电脑的内置摄像头像素和效果都比较差，只是为了应对一般的网络视频聊天和日常交流，并非为了特定环境设定，高端电脑除外。在线课堂环境中，本就缺少面对面交流的冲击感，如果画面模糊，沟通交流效果会更差，让学生清晰清楚的看到你的表情与反应，至关重要。 5. 需要学习什么技能？ 基础教学技能 无论线上线下，对于教学的了解和应用都是相同的，线下教学做不好的老师，到了线上依旧无力，对于教学基础的理解是前提。 面对镜头的能力 很多习惯于面对线下课堂的教师在最初面对摄像头、麦克风和电脑屏幕时，都需要一段适应期，这与教龄无关，甚至教龄越长适应期越长。可以提前彩排让自己快速适应并习惯新的教学视角。 在线讲授能力 从教室环境换为一个人对着电脑，不能直接照搬面授经验，需要调整自己说话的语气、声调、声量与状态，否则会有过HIGH或没精神的感觉。可以看一些知名直播主找找感觉。 时间管理能力 由于环境变化带来讲解方式的改变，会干扰教师对于课堂时间的感知与把握，在线课堂中极易丢失学生的注意力，避免太多开场与拖堂，调整课堂时间节点与学生网络化注意力的分配规律会有效提升课堂效果。 在线组织能力 好的课堂是学生与老师合作的结果，线上更是如此。可以通过课件、讲授与在线工具组织讨论、提问，来不断唤醒学生注意力以及参与度，进一步提升学生与老师、学生与学生之间的协作程度。鼓励他们参与讨论、回答问题，甚至提出好的问题。即使相同的学生在线下与线上课堂中可能会有截然相反的反应与表现。 课件强化能力 学生在屏幕后不能像在面授时直接的从你的肢体、表情、动作以及讲解中获取足够多的信息和要点。相对于线下使用的课件，线上的课件需要更加具体、增加细节以及任何可以辅助你清晰表达的元素，包含但不限于文字、音频、视频、动画、图片等。 在线沟通能力 网络会改变人的沟通思考方式，尤其是新一代在网络时代成长起来的学生。当沟通平台移到网络上，他们会更靠近使用自己的网络沟通方式。教师需要了解这一点，不是压制，而是尝试去了解新一代网络沟通的用语及风格，这会有效刺激学生在线的表达与参与度。 写作能力 网络弱化了面对面沟通的直接性，很多内容需要不断的强化与强调。与沟通能力、表达能力搭配的强化写作能力可以有效的建立网络条件下的教学信任、并强化教学效果。 基础软件能力 能够熟悉并了解经常使用的软件，例如Office、浏览器以及在线教学环境等与教学或互动相关的平台或工具。 基础客服能力 了解关于在线平台使用的常见问题，例如进步不了课堂怎么办？看不见老师怎么办？等问题的基础解决方法。你不必成为专家，但得在学生出现问题的时候知道一些基本方法，并且知道找谁可以解决这些问题，例如平台或学校的技术支持部门。如果之前遇到过比较大的问题，可以提前要求上课时专人支持。 6. 备课过程有何异同？ 线下课堂会对学生注意力和行为产生天然约束，而线下环境所受到的干扰和影响会比较小，传统教学目标指导下，容易按照课堂内容进行线性备课，就是教师会依照课堂时间逐步安排自己的教学行为与课堂活动，有次序，有时间排列的达到教学目标。 在线课堂中，学生注意力和行为是不受约束的，所在环境更靠近生活学习状态而非学校学习状态。再加上网络、技术、时间的约束，不可控的因素很多，环境变化会影响学生不同的反应与行为，加上教师中沟通渠道的增多，不可预知的提问、反馈会更加高频的出现。如果教师采用线性备课思维，会很容易被在线环境所干扰导致教学质量下降。 针对线上课堂，我们建议教师在备课过程中采用模块化备课，即将讲解内容、活动、提问、讨论、反馈等环境拆解成可以组合的模块，依照线上课堂的情况随机组合与采用，即使出现突发情况，也可以有应对内容与方案。这样也有利于教师间协作性备课交流。 7. 如何处理遇到的问题？ 具备基础搜索能力 可以熟练的使用搜索引擎，快速有效的找到一些简单的问题的答案。 建立自己的个人学习网络 PLN (Personal Learning Network) 无论是与线下教研组保持联系，还是通过网络组建虚拟教研组，甚至是有效的网站或工具，找到能够帮助你解决教学问题的人或平台，变成你的教学支撑网络。 寻求机构或平台的技术支持 当出现非教学问题时，知道找谁可以解决。 无论线上线下，之前的文章讨论过到底什么在影响学生的学习，课堂管理排名第一 8. 如何定义在线教学环境？ 实际上因为在线教学主要是通过视频连接教师与学生，教师通过电子课件进行讲解，所以对于教师所在的教学环境要求是极低的。甚至你可以穿着短裤上课，只要视频看不到就行了。可以说没有要求，也容易被忽视。 所谓在线教学环境就是能够达到在线教育目标的符合网络化需求的教学环境，包括教学网络虚拟环境与物理环境。 9. 如何准备在线教学环境？ 网络课堂环境 学生是否可以在你的在线课堂中清晰的找到你所要分享的资料、作业以及分数、评语等反馈。对于课程的描述与课堂目标的表述是否清晰，当学生进入课堂时，他们能够简单快速的找到相关的学习信息，以及知道需要准备什么、学习到什么、课后还要做什么、如何与老师保持沟通、如何与他人协作等等，这些对于虚拟环境的设置成功很加分。 物理上课环境 因为学生不能面对面的见到老师，所以在仅有的视频呈现上更不能随意。这不是意味着你每次要正装或化妆，而是除了穿衣打扮之外，更要注意视频在学生眼里呈现的效果。建议选择日常穿着，符合你的平日上课习惯即可，找到家中安静采光好的空间，背景越简单越好。让上课时，学生能够清晰的看到你的表情、动作，清楚的听到你的声音，而不被其他元素影响注意力。 在线教育阶段，教师备课过程中的形式与思考会影响课程设计，进而影响教学结果 10. 如何有效设计在线课程? 模块化备课 线下课堂那种逐字稿式的备课方式不太适用于在线课堂，在线灵活的上课方式刺激出的是更多即时性和个性化的表达与反馈，需要模块化备课方式来应对，充分的预习教学内容和目标，围绕关键问题形成思路，了解教学对象和环境，才能保障上课时可以灵活的应对。 明确目标与期望 由于在线课堂具备极大的自由度和一定的松散性，所以明确教学的目标、范围、结果与期望比传统课堂更加重要。时刻让学生明白所学的内容在体系中的位置，课前课后所需要的预习与准备，每节课后自己能力或认知的增长，都需要明确的告知，或通过学习任务或测试让学生感受，尤其是隔着屏幕。 有效利用科技 评价在线课堂的优劣其中一个重要指标就是科技与教育的结合程度，并不是通过网络进行传统课堂讲授就叫做好的在线教育。而是要充分利用科技让教育发生变化，这个变化的程度就是在线课程的优秀程度。但可以从简单开始，尝试用一些音视频图片替换原本的文字，在逐步利用例如动画、网络技术来呈现原本不易讲解的知识点，逐步将科技带来的变化引入，最终促进教学效果的提升。 以协作学习为核心 转移到线上教学，可以看作是一个走下讲台的机会，一个尝试以学生为中心进行课程设计的机会。线上教学角色感削弱，对话感增强，正是充分利用网络特性来实现从传统教师中心讲解型课堂，向新形态教师与学生协作学习、学生与学生协作学习的更符合新时代需求的教学形态转型，这恰恰是衡量在线课堂优劣的另外一个重要标准。 11. 如何确定学生是否理解？ 有效利用布鲁姆分类学理论。通过所设计的问题、活动、讨论、测试来综合判断学生行为所属能力阶段。而这些可以通过备课时设置有效的教学目标来体现，以动词开头对教学目标进行描述，例如，通过学习，学生应该能够描述/展示/概括/设计/对比/分辨/创造...等内容或行为。 在线系统可以给出追踪的记录与相关数据，但这都都需要教师通过结合教育基础给出专业的判断与解读。不要让工具或科技主导我们的决定，永远以教学目标和人的成长为出发点，在线教育尤其如此。 12. 如何与学生有效沟通？ 保持真实。因为环境的更换，让学生期待的标准也会潜移默化的发生变化。在学校环境中，学生会在同行业中进行比较；在网络环境中，学生会不自觉地跨行业进行比较。照本宣科式的讲解在线上环境中会特别突兀，所以生活化、真实的表达会更加靠近学生日常的视频、生活状态，接受度会更高，换来的就是注意力提升和有效反馈频率的增加。 13. 如何增强在线课堂互动效果？ 增加游戏化元素。游戏自身所具备的即时反馈、沉浸感等特性会自然的影响专注力持续的时间，适当的利用游戏化元素会有效的提升学习过程中的注意力有效聚集时间以及教学目标的达成。 关于这一点，教研社正在更新的游戏化专题有涉及，请关注教研社进行查看 游戏化教学 101 - 第一眼心动 - 什么是有趣？ 游戏化教学 102 - 第二眼沉浸 - 什么是心流？ 游戏化教学 103 - 吃我三板斧 - 游戏化基础技能 在线教育相较于面授，是一个强化的双向沟通体系，学生会因为场景变化出现行为变化 14. 如何进行有效反馈？ 增加自身网络出现频率 目前网络是主要的教学和沟通方式，保持沟通和反馈的有效方式就是通过网络可以快捷方便的找到教师进行交流。可以但不限于在线教学系统、邮件、QQ、电话、短信或社交媒体等交流渠道，提升沟通频率可显著提升反馈的频率和有效性。 增加过程阶段反馈 反馈分为两种，一种是在学习关键过程中形成的反馈 (Formative Feedback)，例如讲解完知识点的即时讨论、问题或测试，目的是在认知形成初期持续夯实还较为松散的信息；另外一种是在阶段性学习过后的反馈 (Summative Feedback)，例如学习完一门课程、一个单元或一个模块后的测验、提问或考试。线上环境中需要提升形成型反馈，结合阶段型反馈，可有效提升教学效果。 15. 如何评判在线课程质量？ 在线课堂就是教师教学与网络技术叠加的产物，衡量在线课程的优劣就在于科技融入的质量，不是数量，以及科技与教师的结合程度给教学结果所带来的变化。 来自美国的 Ruben Puentedura 博士就创建了一个叫做 SAMR 的评价模型，用来指导教师学习将科技运用在他们自己的课堂中。 [S]ubstitution - 替换 科技直接替换原有方案，并没有功能性的扩展。例如，只是将原本黑板上的字写在了PPT里，没有任何变化。 [A]ugmentation - 加强 科技直接替换原有方案，并作出有限改善。例如，原本PPT里的文字或内容使用视频或动画来增进理解程度，或者工具内置的拼写检查来纠正一些书写错误。 [M]odification - 修改 科技已经明显的影响了原有教学方案的结构，并作出巨大改进。例如，PPT开始支持教师间协作、师生间协作，让教与学更加无缝连接，形成新的课堂协作关系。 [R]edefinition - 重构 科技介入已经促使新形态的教学方案或任务出现。例如，PPT可以呈现出AR或VR的效果，可以让学生更加身临其境的理解教学内容和目标。 其中，S与A属于较为低阶，科技只是在改善或增强教学与学习的效果，本质上并没有太大变化；M与R属于高阶层面，科技开始与教学结合，对教学结果和目标产生显著的影响。 这一点还可以结合布鲁姆分类学 (Bloom's Taxonomy) 理论进行分析，当科技与教育结合让学生产生创造、评价、分析等高阶能力时，证明科技的介入是有效的；反之，当学生体现出记忆、领会和应用这些低阶能力时，证明科技的介入以及与教育的结合程度还不足，需要改善加强。 关于布鲁姆分类学，之前在教研社专题翻转课堂中有详细阐述，可以跳转阅读：翻转课堂 102 - 布鲁姆之眼 | 翻转背后的理论 网络是一个可强可弱的互动平台，要维持强互动需要保持连接和兴趣 16. 如何在课前有效协助学生做好预习？ 明确课前需求，设置相关测试，明确每一节课在整体课程体系中的位置与重要性，明确学习目标与学习内容的关联性，以及与学生学习的关系。 相较于传统课堂学生上课时才能见到老师，在线课堂里，可以将教师前置，在课前就可以通过直播、视频、音频、文字等形式与学生进行交流，会有效提升学生对于课程的兴趣和重视程度，也会更加认真的对待课前任务，进而促进教学目标的达成。 17. 如何在课后有效连接学生注意力？ 保持与学生多渠道的沟通，可以设定特定时间、特定渠道的交流，可以是直播、语音、论坛等任何形式，保持教师的可见度与可见频率。充分了解所在教学平台的功能，好的LMS教学平台都会有辅助教师与学生连接的功能模块。除了作业，设置课后任务也是利用多维度保持连接力的一种有效方式。 18. 新手常犯的错误有哪些？ 眼睛不看镜头或乱飘 线下教师习惯于与学生一对多面对面的眼神接触，并在课堂范围内进行转移。当转移到在线课堂这种天然一对一视角时，需要定点对着一个镜头持续1-2个小时的讲解，让很多老师很不习惯。首先，眼神很容易飘走。其次，看镜头的位置不对。这就导致学生看视频的时候觉得老师是对着镜头外的其他人讲话而不是对着自己。看向镜头的最中央，看进去，这样就会让学生有老师在看着自己的感觉，良好的眼神交流会刺激学生注意力的提升，这一点无论是线上还是线下都是有效的，只是在线环境中，教师需要训练和试讲里提升自己对于镜头的熟悉程度。 使用内置的摄像头和麦克风 导致视频质量差，让好的教学技能和内容不能充分发挥出效果。 使用内置的摄像头和麦克风 导致视频质量差，让好的教学技能和内容不能充分发挥出效果。 我们建议两个灯源即可，一个顶部大灯，你可以选择家中最亮的灯，坐在正下方或偏前一点即可，主要是照亮周边环境和背景；另外可以给脸部打一个灯，让视频中教师的脸部表情更清楚，直播主常用的环形灯就很不错。 背景干扰 上课时视频环境背景不宜太过杂乱，或者太多与课堂不相关的物品，尽量保持与所穿衣服不同的素色，会在凸显教师的同时，减少对于学生注意力的干扰。 这只是一个简略的快速上手建议，让不太熟悉或之前没怎么接触过在线课堂的教师能够在短时间内消除恐惧与不安，在特殊时期合理良好的利用网络进行备课、上课。教研社也会持续推出科技与在线教育专题，来推动并协助每一位老师升级。 在线教育也是一种教育模式，并不是线下模式或其他模式的替代品。每一种通用型的教育模式都服务于一类特定的教学目的。当你能够不断迭代与完善出一个精彩的在线课堂时，恭喜你，你已经成为了一个新时代所需要的混合形态教师，可以应对最适应学生需求的混合教学环境。 当疫情结束后，回归线下课堂时，你会惊喜的发现，看待面前这些学生的视角与感觉也会发生变化，能够从在线课堂的经验中了解到，他们是有那么多的想法和需求希望得到你的回应与肯定，这会更加刺激每一个熬过这个困难阶段，蜕变升级的教师，变得更好。 在线课堂不是一个困难，而是一个机会；科技不是一个困难，而是一种技能。用更开放的视角，你不仅能发现一个新的世界和机会，也会回头看见一个新的自己。 2020，一起加油！ 读取更多关于变身线上教师2020快速指南 »

######################################################################################## #CentOS8 Linux下Python/WSGI应用快速入门实战，作者：Warren.Zhou 上海释锐教育软件有限公司# ######################################################################################## #login as warren user(not root user) #make a new directory mkdir python_web_server cd python_web_server ############## #01.安装uWSGI# ############## #pip3 uninstall uwsgi sudo yum install pcre pcre-devel pcre-static pip3 install uwsgi -I --no-cache-dir --user ################### #02.第一个WSGI应用# ################### vi my_first_wsgi_application.py # my_first_wsgi_application.py:the first WSGI application def application(environ, start_response): status = '200 OK' output = b'Hello World!\nThis is my_first_wsgi_application.py\n' response_headers = [('Content-type', 'text/plain'),('Content-Length', str(len(output)))] start_response(status, response_headers) return [output] ########################### #03.将其部署在HTTP端口8080# ########################### sudo firewall-cmd --query-port=8080/tcp sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent sudo firewall-cmd --reload uwsgi --http :8080 --wsgi-file my_first_wsgi_application.py --master --processes 4 --threads 2 ################################################# #04.将WSGI应用放在一个完整的web服务器(Nginx)之后# ################################################# sudo yum install nginx sudo service nginx start sudo vi /etc/nginx/nginx.conf location / { include uwsgi_params; uwsgi_pass 127.0.0.1:3031; } sudo nginx -s reload ################################################################################################# #05.将运行选项"--http :8080"改成"--socket 127.0.0.1:3031"，本地从原来的http协议改成使用uwsgi协议# ################################################################################################# uwsgi --socket 127.0.0.1:3031 --wsgi-file my_first_wsgi_application.py --master --processes 4 --threads 2 --py-autoreload 1 --stats 127.0.0.1:9191 ################################################# #06.部署Flask(Flask是一个流行的Python web微框架)# ################################################# pip3 install --upgrade virtualenv --user virtualenv -p python3.6 $HOME/.env pip3 install flask --user #################### #07.第一个Flask应用# #################### vi my_first_flask_app.py # my_first_flask_app.app from flask import Flask, redirect, url_for app = Flask(__name__) @app.route("/world") def helloWorld(): return "Hello World" @app.route("/") def default(): #return redirect(url_for('helloWorld')) return "Welcome to threeoa uwsgi server , this is the first <span style='color:red'>Flask</span> app." @app.route("/ai") def helloAi(): return "Hello AI" @app.route("/post/<int:post_id>") def show_post(post_id): return 'Post %d' % post_id if __name__ == '__main__': app.run(host='0.0.0.0', port=8080, debug=True) ##################################### #08.唯一新增"--callable app"运行选项# ##################################### uwsgi --socket 127.0.0.1:3031 --wsgi-file my_first_flask_app.py --processes 4 --threads 2 --py-autoreload 1 --stats 127.0.0.1:9191 --callable app ################################################# #09.部署Django(Django是最常使用的Python web框架)# ################################################# PENDING... ################################## #10.创建uwsgi.ini运行选项配置文件# ################################## vi uwsgi.ini [uwsgi] #工程目录 chdir=/home/warren/python_web_server # python虚拟环境目录 home=/home/warren/.env # 启动flask应用的文件名，不用加.py module=my_first_flask_app # 应用名，与my_first_flask_app.py文件中一致 callable=app master=true # worker的进程个数 processes=4 threads=2 chmod-socket=666 logfile-chmod=644 # uwsgi的进程名称前缀，启动后可通过ps -ef | grep FirstFlask查找到这个进程 procname-prefix-spaced=FirstFlask #py文件修改，自动加载，也就是设置热启动了 py-autoreload=1 vacuum=true # 退出uwsgi是否清理中间文件，包含pid、sock和status文件 # socket监听端口和文件，配置nginx时候使用 socket=127.0.0.1:3031 socket=%(chdir)/auto_generated_files/uwsgi.sock # status文件，可以查看uwsgi的运行状态 stats=%(chdir)/auto_generated_files/uwsgi.status # pid文件，通过该文件可以控制uwsgi的重启和停止 pidfile=%(chdir)/auto_generated_files/uwsgi.pid # 设置后台模式，然后将日志输出到uwsgi.log。当调试时，可先注释掉此内容 daemonize=%(chdir)/auto_generated_files/uwsgi.log #http监听端口，测试时使用 #http=:8080 ############################ #11.start/reload/stop uwsgi# ############################ mkdir auto_generated_files uwsgi --ini uwsgi.ini uwsgi --reload auto_generated_files/uwsgi.pid uwsgi --stop auto_generated_files/uwsgi.pid ##################### #12.测试运行是否正常# ##################### Windows Browser: http://192.168.1.51:8080/ 输出效果如下： Linux Command Line: curl get http://192.168.1.51:8080/ 输出效果如下： ##################################################################### #13.系统重启后自动运行(centos8不建议用rc.local，推荐采用systemd技术)# ##################################################################### #nginx vi /lib/systemd/system/nginx.service [Unit] Description=The nginx HTTP and reverse proxy server After=network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/run/nginx.pid # Nginx will fail to start if /run/nginx.pid already exists but has the wrong # SELinux context. This might happen when running `nginx -t` from the cmdline. # https://bugzilla.redhat.com/show_bug.cgi?id=1268621 ExecStartPre=/usr/bin/rm -f /run/nginx.pid ExecStartPre=/usr/sbin/nginx -t ExecStart=/usr/sbin/nginx ExecReload=/bin/kill -s HUP $MAINPID KillSignal=SIGQUIT TimeoutStopSec=5 KillMode=mixed PrivateTmp=true [Install] WantedBy=multi-user.target #execute this command，create symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service systemctl enable nginx.service #uwsgi vi /etc/init.d/uwsgid.sh #!/bin/bash if [ ! -n "$1" ];then echo "Usages: sh uwsgid.sh [start|stop|restart]" exit 0 fi if [ $1 = start ];then psid=`ps aux | grep "uwsgi" | grep -v "grep" | wc -l` if [[ $psid -gt 4 ]];then echo "uwsgi is running!" exit 0 else /usr/local/bin/uwsgi --ini /home/warren/python_web_server/uwsgi.ini echo "Start uwsgi service [OK]" fi # nginx call uwsgi:13: Permission denied setsebool httpd_can_network_connect=1 echo "setsebool httpd_can_network_connect=1 [OK]" elif [ $1 = stop ];then killall -9 uwsgi echo "Stop uwsgi service [OK]" elif [ $1 = restart ];then killall -9 uwsgi /usr/local/bin/uwsgi --ini /home/warren/python_web_server/uwsgi.ini echo "Restart uwsgi service [OK]" else echo "Usages: sh uwsgid.sh [start|stop|restart]" fi # mark uwsgid.sh with executable permission chmod +x /etc/init.d/uwsgid.sh # add uwsgi.service vi /lib/systemd/system/uwsgi.service [Unit] Description=uWSGId After=network.target [Service] User=warren Group=warren Type=forking ExecStart=/etc/init.d/uwsgid.sh start ExecReload=/etc/init.d/uwsgid.sh restart ExecStop=/etc/init.d/uwsgid.sh stop PrivateTmp=true [Install] WantedBy=multi-user.target # mark uwsgi.service with executable permission chmod +x /lib/systemd/system/uwsgi.service # execute this command，created symlink /etc/systemd/system/uwsgi.service → /lib/systemd/system/uwsgi.service systemctl enable /lib/systemd/system/uwsgi.service #开机自启 systemctl start uwsgid.service systemctl restart uwsgid.service systemctl stop uwsgid.service 转载请注明出处“文章作者：Warren.Zhou 上海释锐教育软件有限公司” 读取更多关于Python/WSGI应用快速入门实战 »

现象： Windows 下编写的脚本文件无法在 Linux 下运行，用 ./ 运行bash脚本文件出现 报错信息 /usr/bin/env: "bash\r": 没有那个文件或目录 原因： Windows 与 Linux 的后缀编写格式不一致，这主要是因为bash后面多了\r这个字符的原因。在linux终端下，输出\r会什么都不显示，只是把光标移到行首。于是终端虽然输出了/usr/bin/env bash，但是碰到\r后，光标会被移到行首，接着输出了:No such file or directory把前面的覆盖掉了。于是出现了那个莫名其妙的出错信息了 解决方案： 用vim打开sh脚本文件， 重新设置文件的格式 ：set ff 然后回车 再重新设置下文件格式： ：set ff=unix 然后保存退出 ：wq! 回车 读取更多关于Linux下运行bash脚本显示没有那个文件或目录 »

[root@localhost ~]# systemctl get-default graphical.target（图形界面模式） [root@localhost ~]# systemctl set-default multi-user.target Removed symlink /etc/systemd/system/default.target. Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/multi-user.target. [root@localhost ~]# systemctl get-default multi-user.target（命令行文本界面模式） 读取更多关于CentOS8两种常用启动模式介绍 »