现象：在公司的203.*.*.40服务器上Ping heyubao.com 出现 unknown host，但是ping baidu.com正常。 原因：/etc/resolv.conf 中的 nameserver 设置不对。 解决方案：vi /etc/resolv.conf ，修改dns服务器ip地址即可。 读取更多关于Ping heyubao.com unknown host »

Cross Origin Resource Sharing (CORS) is a mechanism that is used by browsers, primarily to validate permissions for access to content from a different origin. What is CORS? When a browser loads a web page, it enforces the Same-origin Policy, which means that it only allows content to be fetched from the same origin as the web page. However, in some cases, a web page might need access to assets from multiple origins that trust that website. This is where CORS comes in. This security mechanism exists only if an application has or is an HTTP client, and if that application implements CORS. Nearly all modern browsers, such as Chrome, Firefox, and Safari, implement CORS. To clarify, an origin with respect to CORS does not have to be the same as a CDN origin. An origin in CORS is defined by a URI scheme, domain, and any possible port number. For example, https://www.example.com:1443 is a different origin than http://www.example.com. And so, a CDN can also be considered as a CORS origin from a browser's perspective. How CORS works CORS can handle two types of requests: simple requests and preflighted requests, which are more complex. Simple requests First request (resource access): Simple requests through CORS are either GET or POST requests from the web page of one origin that's attempting to gain access to the URL of another origin for resources. When making such a request, the browser automatically sets CORS request headers. Primarily, it sets the origin of the web page making the request in the Origin HTTP header, automatically. The CORS request also can contain a set of certain, standard HTTP headers , while maintaining its status as a simple CORS request, from the browser's perspective. The server that receives the CORS request processes the request, and might send a set of CORS response headers back to the browser, with the requested content. These CORS response headers contain values specifying whether the current web page is allowed access to those resources, whether the headers sent are acceptable for that request, and so forth. If the browser is unable to see its CORS request satisfied by the CORS response headers, it automatically prevents the access to and loading of the content. Otherwise, it sees that the CORS origin is giving permission to use the resource, and it allows the access to and loading of the requested content. Preflighted requests First request (preflight): Second request (resource access): For more complex CORS communication between the browser and a CORS origin that's different than the requesting web page, a preflight request is required before an actual resource access. Certain situations might require preflighting CORS requests, such as HTTP methods that are not GET or POST methods, or using non-standard HTTP headers with the request - even if it is a GET or POST request, and so forth. If a preflight request is needed, here's how the events unfold: The browser sends a request using the HTTP OPTIONS method to the server with all of the intended CORS request headers. The server processes those CORS request headers, and can respond with CORS response headers containing no actual content data. The browser checks those CORS response headers to make sure that the CORS request is allowed. If the browser sees that the intended resource request should be allowed by the server, it makes a second request to the browser with the intended HTTP method, whether GET, POST, PUT and so on, with the same CORS request headers. Afterward, the communication between the browser and CORS origin (different than that of the web page) proceeds as if it was a simple CORS request. Similar to a simple CORS request, content and resources are accessible and can be loaded if this second CORS request is allowed. Setting up CORS at your origin As shown in the previous diagrams, CORS is initiated by the requesting HTTP client. However, the effects depend on the requested origin. For your content to be ready for CORS requests, your origin must be configured correctly to respond with the correct CORS response headers and the correct access permissions. The following example shows a basic CORS configuration for a Nginx server: http { # some http context configs server { # some server context configs # URI path to some content location /my-static-content { # some location context configs # Handle simple requests # # Consider only "HTTP GET" requests (content fetching) if ($request_method = 'GET') { # Allows the browser to access data from this server during CORS, # only if the request comes from a web page from the following origin add_header 'Access-Control-Allow-Origin' 'https://www.example.com'; } # Handle preflight requests if ($request_method = 'OPTIONS') { # Allows the browser to access data from this server during CORS, # only if the request comes from a web page from the following origin add_header 'Access-Control-Allow-Origin' 'https://www.example.com'; # Allows only GET requests add_header 'Access-Control-Allow-Methods' 'GET'; # Allows the following headers in the browser's request headers # that may have been added by anything other than what the browser had added automatically add_header 'Access-Control-Allow-Headers' 'pragma'; # Specifies to the browser how long it should cache this preflight response add_header 'Access-Control-Max-Age' 1728000; # HTTP 204 response code means success, # but also that it should expect no content from this (preflight) response return 204; } # more location context configs # If it is not a complex CORS situation requiring a preflight response, # then finally attempt to serve the file whose path falls under this location block's URI path match # # If no such file is found, then present an HTTP 404 code (not found) try_files $uri =404; } # more server context configs } # more http context configs } Generally, the browser should freely load content when it sees a Access-Control-Allow-Origin: * in the server's CORS response headers according to the w3 specification regarding that wildcard value . However, not all browsers support Access-Control-Allow-Origin: *. If the server must support access from multiple web pages, each served from a different origin, a single origin value for Access-Control-Allow-Origin should be dynamically generated per request. The following is a basic example of such a use case for an Nginx server: http { # some http context config ###### # Input from $http_origin, the value in Origin HTTP header # Output to $cors_allowed_origin, a string # # Full string match on the Origin header value # # Attempt to find a match for the value from $http_origin using regex on the left column. # If a match is found, then evaluate $cors_allowed_origin to the same value as $http_origin # Else, default evaluate $cors_allowed_origin to an empty string, so browsers will disallow the CORS request ###### map $http_origin $cors_allowed_origin { default ''; ~^http(s)?://(www|www2|cdn|dev)\.example\.com$ $http_origin; } server { # some server context configs # URI path to some content location /my-static-content { # some location context configs # Handle simple requests if ($request_method = 'GET') { add_header 'Access-Control-Allow-Origin' $cors_allowed_origin; } # Handle preflight requests if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' '$cors_allowed_origin; add_header 'Access-Control-Allow-Methods' 'GET'; add_header 'Access-Control-Allow-Headers' 'pragma'; add_header 'Access-Control-Max-Age' 1728000; return 204; } # more location context configs try_files $uri =404; } # more server context configs } # more http context configs } The previous example uses the map directive to avoid overusing the if Nginx statement. Now, when a CORS request is made to this server and matches that URI path, the server responds with the Access-Control-Allow-Origin header containing the value http://www.example.com, https://cdn.example.com, or http://dev.example.com, when the content is requested from http://www.example.com, https://cdn.example.com, http://dev.example.com, and so forth. Setting up CORS for CDN CDN is largely transparent to the CORS setup of the origin so it does not require a specific CDN configuration. If the CDN Edge server cannot find a cached response for the first request for some content, it forwards the request to the origin host. If the origin host is set up to handle CORS requests, and this request has the Origin header, then it should respond back to the Edge with a CORS header of Access-Control-Allow-Origin and the associated value. The overall response, including that header and value, is cached in the CDN. Any subsequent request for the object at the same URI path is served from the cache and includes the Access-Control-Allow-Origin header value that was originally received from the origin. Multiple CORS origin support In some cases, you can allow a list of specific origins (not all) to access your CDN contents, and need CDN to serve different Access-Control-Allow-Origin response headers for different origins (not wildcard * for any origins). However, CDN caches the headers along with contents, so it might serve the cached Access-Control-Allow-Origin header to the request, which might not match. You can leverage the Cache Key query optimization to add different parameters in the URLs for different origins. This way, the content and headers are cached differently. For example, suppose you've set the CDN cdn.example.com to serve contents for the two origins (abc.com and 123.com), and want to add different parameters for each origin; for example, https://cdn.example.com/test.json?domain=abc.com and https://cdn.example.com/test.json?domain=123.com. CDN would return different Access-Control-Allow-Origin headers that are served by your back-end server: Request from abc.com origin returns access-control-allow-origin: https://abc.com: # curl -H "Origin: https://abc.com" -H "Referer: https://abc.com/" -i https://cdn.example.com/test.json?domain=abc.com HTTP/2 200 access-control-allow-origin: https://abc.com access-control-allow-methods: GET access-control-allow-credentials: true ... Request from 123.com origin returns access-control-allow-origin: https://123.com: # curl -H "Origin: https://123.com" -H "Referer: https://123.com/" -i https://cdn.example.com/test.json?domain=123.com HTTP/2 200 access-control-allow-origin: https://123.com access-control-allow-methods: GET access-control-allow-credentials: true ... Troubleshooting CORS and CORS requests If your origin server is set up for CORS, and you do not see the Access-Control-Allow-Origin header that is returned to the browser’s request, it is possible that the response header cached in CDN was for a request that didn't have the origin header in the request. CDN caches response headers from the origin host. However, the cached headers are based on the request that triggered the request to origin. In that case, the response headers might not include the CORS headers. Clear the cache in CDN for that path using CDN’s purge functionality, and retry the request from the client. The Vary response header from your origin server can also cause unexpected behavior when fetching content through your CDN. Other than one specific exception, the CDN does not cache content (and its associated response header) from your origin server, if the server responds with a Vary header. Currently, our service removes the Vary header from the origin to render the object cacheable, if the object is one of the following file types: aif, aiff, au, avi, bin, bmp, cab, carb, cct, cdf, class, css, doc, dcr, dtd, exe, flv, gcf, gff, gif, grv, hdml, hqx, ico, ini, jpeg, jpg, js, mov, mp3, nc, pct, pdf, png, ppc, pws, swa, swf, txt, vbs, w32, wav, wbmp, wml, wmlc, wmls, wmlsc, xsd, zip, webp, jxr, hdp, wdp, pict, tif, tiff, mid, midi, ttf, eot, woff, otf, svg, svgz, jar, woff2, json. If the object to cache is not one of these file types, remove the Vary header from the origin server's response for that object and try again after using CDN's Purge functions. location /delete*****file/ { # Handle simple requests # # Consider only "HTTP DELETE" requests (content delete) if ($request_method = 'DELETE') { # Allows the browser to access data from this server during CORS, # only if the request comes from a web page from the following origin add_header 'Access-Control-Allow-Origin' 'https://heyubao.com'; } # Handle preflight requests if ($request_method = 'OPTIONS') { # Allows the browser to access data from this server during CORS, # only if the request comes from a web page from the following origin add_header 'Access-Control-Allow-Origin' 'https://heyubao.com'; # Allows only DELETE requests add_header 'Access-Control-Allow-Methods' 'DELETE'; # Allows the following headers in the browser's request headers # that may have been added by anything other than what the browser had added automatically add_header 'Access-Control-Allow-Headers' 'pragma'; # Specifies to the browser how long it should cache this preflight response add_header 'Access-Control-Max-Age' 1728000; # HTTP 204 response code means success, # but also that it should expect no content from this (preflight) response return 204; } # more location context configs # If it is not a complex CORS situation requiring a preflight response, # then finally attempt to serve the file whose path falls under this location block's URI path match # # If no such file is found, then present an HTTP 404 code (not found) try_files $uri =404; alias /usr/local/*****/html/vod/; dav_access user:rw group:rw all:rw; dav_methods DELETE; min_delete_depth 1; } 读取更多关于Nginx CORS 跨域解决方案 »

回音消除Google 开发文档原文： /** * Acoustic Echo Canceler (AEC). * <p>Acoustic Echo Canceler (AEC) is an audio pre-processor which removes the contribution of the * signal received from the remote party from the captured audio signal. * <p>AEC is used by voice communication applications (voice chat, video conferencing, SIP calls) * where the presence of echo with significant delay in the signal received from the remote party * is highly disturbing. AEC is often used in conjunction with noise suppression (NS). * <p>An application creates an AcousticEchoCanceler object to instantiate and control an AEC * engine in the audio capture path. * <p>To attach the AcousticEchoCanceler to a particular {@link android.media.AudioRecord}, * specify the audio session ID of this AudioRecord when creating the AcousticEchoCanceler. * The audio session is retrieved by calling * {@link android.media.AudioRecord#getAudioSessionId()} on the AudioRecord instance. * <p>On some devices, an AEC can be inserted by default in the capture path by the platform * according to the {@link android.media.MediaRecorder.AudioSource} used. The application should * call AcousticEchoCanceler.getEnable() after creating the AEC to check the default AEC activation * state on a particular AudioRecord session. * <p>See {@link android.media.audiofx.AudioEffect} class for more details on * controlling audio effects. */ 场景就是在手机播放声音和声音录制同时进行，但是手机播放的声音不会被本机录制，达到了消除的效果。微信对讲的最适合不过了，但是微信的回音消除好像是不是自己弄的。 文档大致意思：创建android.media.AudioRecord 对象的时候，可以通过这个对象获取到一个audio session 的ID，获取方法getAudioSessionId()，这个ID在创建AcousticEchoCanceler的时候要用到（创建对象：AcousticEchoCanceler.create(audioSessionId)），最后播放音频时（这里是用AudioTrack播放）传入这个ID就行了。 1.首先创建AudioRecord对象，里面的参数可以自己查资料知道什么是采样率，声道，位数。 private AudioRecord mRecorder; private byte[] pcm; private int mRecorderBufferSize; /** * 初始化录音 */ public void initRecorder() { mRecorderBufferSize = AudioRecord.getMinBufferSize(8000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); pcm = new byte[320]; mRecorder = new AudioRecord(MediaRecorder.AudioSource.VOICE_COMMUNICATION, 8000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, mRecorderBufferSize); } 2.其次，初始化AudioTrack（注意下传入的audioSessionId） private AudioRecord mRecorder; private byte[] pcm; private int mRecorderBufferSize; /** * 初始化录音 */ public void initRecorder() { mRecorderBufferSize = AudioRecord.getMinBufferSize(8000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); pcm = new byte[320]; mRecorder = new AudioRecord(MediaRecorder.AudioSource.VOICE_COMMUNICATION, 8000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, mRecorderBufferSize); } 3.最后创建AcousticEchoCanceler private AcousticEchoCanceler acousticEchoCanceler; private void initAEC() { if (AcousticEchoCanceler.isAvailable()) { if (acousticEchoCanceler == null) { acousticEchoCanceler = AcousticEchoCanceler.create(audioSessionId); Log.d(TAG, "initAEC: ---->" + acousticEchoCanceler + "\t" + audioSessionId); if (acousticEchoCanceler == null) { Log.e(TAG, "initAEC: ----->AcousticEchoCanceler create fail."); } else { acousticEchoCanceler.setEnabled(true); } } } } 4.最后播放就可以了（OK） public void write(byte[] data) { if (mAudioTrack != null && mAudioTrack.getPlayState() == AudioTrack.PLAYSTATE_PLAYING) { mAudioTrack.write(data, 0, data.length); } } 读取更多关于Android 回音消除(AcousticEchoCanceler)的使用 »

什么是Lambda? 我们知道，对于一个Java变量，我们可以赋给其一个“值”。 如果你想把“一块代码”赋给一个Java变量，应该怎么做呢？ 比如，我想把右边那块代码，赋给一个叫做aBlockOfCode的Java变量： 在Java 8之前，这个是做不到的。但是Java 8问世之后，利用Lambda特性，就可以做到了。 当然，这个并不是一个很简洁的写法。所以，为了使这个赋值操作更加elegant, 我们可以移除一些没用的声明。 这样，我们就成功的非常优雅的把“一块代码”赋给了一个变量。而“这块代码”，或者说“这个被赋给一个变量的函数”，就是一个Lambda表达式。 但是这里仍然有一个问题，就是变量aBlockOfCode的类型应该是什么？ 在Java 8里面，所有的Lambda的类型都是一个接口，而Lambda表达式本身，也就是”那段代码“，需要是这个接口的实现。这是我认为理解Lambda的一个关键所在，简而言之就是，Lambda表达式本身就是一个接口的实现。直接这样说可能还是有点让人困扰，我们继续看看例子。我们给上面的aBlockOfCode加上一个类型： 这种只有一个接口函数需要被实现的接口类型，我们叫它”函数式接口“。为了避免后来的人在这个接口中增加接口函数导致其有多个接口函数需要被实现，变成"非函数接口”，我们可以在这个上面加上一个声明@FunctionalInterface, 这样别人就无法在里面添加新的接口函数了： 这样，我们就得到了一个完整的Lambda表达式声明： Lambda表达式有什么作用? 最直观的作用就是使得代码变得异常简洁。 我们可以对比一下Lambda表达式和传统的Java对同一个接口的实现： 这两种写法本质上是等价的。但是显然，Java 8中的写法更加优雅简洁。并且，由于Lambda可以直接赋值给一个变量，我们就可以直接把Lambda作为参数传给函数, 而传统的Java必须有明确的接口实现的定义，初始化才行： 有些情况下，这个接口实现只需要用到一次。传统的Java 7必须要求你定义一个“污染环境”的接口实现MyInterfaceImpl，而相较之下Java 8的Lambda, 就显得干净很多。 Lambda结合FunctionalInterface Lib, forEach, stream()，method reference等新特性可以使代码变的更加简洁！ 直接上例子。 假设Person的定义和List<Person>的值都给定。 现在需要你打印出guiltyPersons List里面所有LastName以"Z"开头的人的FirstName。 原生态Lambda写法：定义两个函数式接口，定义一个静态函数，调用静态函数并给参数赋值Lambda表达式。 这个代码实际上已经比较简洁了，但是我们还可以更简洁么？ 当然可以。在Java 8中有一个函数式接口的包，里面定义了大量可能用到的函数式接口（java.util.function (Java Platform SE 8 )）。所以，我们在这里压根都不需要定义NameChecker和Executor这两个函数式接口，直接用Java 8函数式接口包里的Predicate<T>和Consumer<T>就可以了——因为他们这一对的接口定义和NameChecker/Executor其实是一样的。 第一步简化 - 利用函数式接口包： 静态函数里面的for each循环其实是非常碍眼的。这里可以利用Iterable自带的forEach()来替代。forEach()本身可以接受一个Consumer<T> 参数。 第二步简化 - 用Iterable.forEach()取代foreach loop： 由于静态函数其实只是对List进行了一通操作，这里我们可以甩掉静态函数，直接使用stream()特性来完成。stream()的几个方法都是接受Predicate<T>，Consumer<T>等参数的（java.util.stream (Java Platform SE 8 )）。你理解了上面的内容，stream()这里就非常好理解了，并不需要多做解释。 第三步简化 - 利用stream()替代静态函数： 对比最开始的Lambda写法，这里已经非常非常简洁了。但是如果，我们的要求变一下，变成print这个人的全部信息，及p -> System.out.println(p); 那么还可以利用Method reference来继续简化。所谓Method reference, 就是用已经写好的别的Object/Class的method来代替Lambda expression。格式如下： 第四步简化 - 如果是println(p)，则可以利用Method reference代替forEach中的Lambda表达式： 这基本上就是能写的最简洁的版本了。 Lambda配合Optional<T>可以使Java对于null的处理变的异常优雅 这里假设我们有一个person object，以及一个person object的Optional wrapper: Optional<T>如果不结合Lambda使用的话，并不能使原来繁琐的null check变的简单。 只有当Optional<T>结合Lambda一起使用的时候，才能发挥出其真正的威力！ 我们现在就来对比一下下面四种常见的null处理中，Java 8的Lambda+Optional<T>和传统Java两者之间对于null的处理差异。 情况一 - 存在则开干 情况二 - 存在则返回，无则返回屁 情况三 - 存在则返回，无则由函数产生 情况四 - 夺命连环null检查 由上述四种情况可以清楚地看到，Optional<T>+Lambda可以让我们少写很多ifElse块。尤其是对于情况四那种夺命连环null检查，传统java的写法显得冗长难懂，而新的Optional<T>+Lambda则清新脱俗，清楚简洁。 来源：https://www.zhihu.com/question/20125256/answer/324121308 读取更多关于什么是 Lambda？该如何使用？ »

每一个程序员，在刚入行时学的第一个框架应该就是ssm了，其他的各种学习框架都是后期在工作中，随着业务的不断复杂，在工作和bug中不断成长起来的，但是最经典的应该还是最一开始的时候ssm框架吧 当时刚学习这个时候，就觉得，好牛啊，这样就可以实现一个网站，这群大神是怎么做到的啊，嘿嘿嘿，不知道大家当时有没有这样的问题产生，所以今天就带大家来搭建一个简单的mvc框架，从原理讲起，也能帮助大家更好的理解底层源码 好了，话不多说，我们来看一下 Springmvc基本原理流程 SpringMvc本质上就是对Servlet的封装。 因为创建一个Maven项目，然后在pom文件中增加一个依赖： <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.5</version> <!-- 部署在服务器时，不使用这个servlet-api 而使用tomcat的--> <scope>provided</scope> </dependency> 2，创建DispatcherServlet，并注册到web.xml中 package com.dxh.edu.mvcframework.servlet; import javax.servlet.ServletConfig; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.IOException; public class DxhDispatcherServlet extends HttpServlet { /** * 接收处理请求 */ @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { doPost(req, resp); } @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { } } web.xml： <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" > <web-app> <display-name>Archetype Created Web Application</display-name> <servlet> <servlet-name>dxhmvc</servlet-name> <servlet-class>com.dxh.edu.mvcframework.servlet.DxhDispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>springmvc.properties</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>dxhmvc</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> </web-app> 2，注解开发 因为要使用到注解，所以首先要自定义几个注解： 这里就不赘述如何自定义注解了，详情请看：https://www.cnblogs.com/peida/archive/2013/04/24/3036689.html Controller注解： @Documented @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) public @interface DxhController { String value() default ""; } Service注解： @Documented @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) public @interface DxhService { String value() default ""; } RequestMapping注解： @Documented @Target({ElementType.TYPE,ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) public @interface DxhRequestMapping { String value() default ""; } Autowired注解： @Documented @Target(ElementType.FIELD) @Retention(RetentionPolicy.RUNTIME) public @interface DxhAutowired { String value() default ""; } 编写测试代码： 测试代码我们放在同项目中的com.dxh.demo包中： package com.dxh.demo.controller; import com.dxh.demo.service.IDemoService; import com.dxh.edu.mvcframework.annotations.DxhAutowired; import com.dxh.edu.mvcframework.annotations.DxhController; import com.dxh.edu.mvcframework.annotations.DxhRequestMapping; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; @DxhController @DxhRequestMapping("/demo") public class DemoController { @DxhAutowired private IDemoService demoService; /** * URL:/demo/query */ @DxhRequestMapping("/query") public String query(HttpServletRequest request, HttpServletResponse response, String name){ return demoService.get(name); } } package com.dxh.demo.service; public interface IDemoService { String get(String name); } package com.dxh.demo.service.impl; import com.dxh.demo.service.IDemoService; import com.dxh.edu.mvcframework.annotations.DxhService; @DxhService("demoService") public class IDemoServiceImpl implements IDemoService { @Override public String get(String name) { System.out.println("Service实现类中的Name："+ name); return name; } } 目录结构： 3，编写自定义DispatcherServlet中的初始化流程： 在创建好的DxhDispatcherServlet中重写init（）方法，并在init方法中做初始化配置： 加载配置文件 springmvc.properties 扫描相关的类——扫描注解 初始化Bean对象（实现IOC容器，基于注解） 实现依赖注入 构造一个handleMapping处理器映射器，将配置好的url和method建立映射关系 @Override public void init(ServletConfig config) throws ServletException { //1. 加载配置文件 springmvc.properties String contextConfigLocation = config.getInitParameter("contextConfigLocation"); doLoadConfig(contextConfigLocation); //2. 扫描相关的类——扫描注解 doScan(""); //3. 初始化Bean对象（实现IOC容器，基于注解） doInstance(); //4. 实现依赖注入 doAutoWired(); //5. 构造一个handleMapping处理器映射器，将配置好的url和method建立映射关系 initHandleMapping(); System.out.println("MVC 初始化完成"); //6. 等待请求进入处理请求 } 以及5个空方法，这篇文章自定义MVC框架其实就是需要对这5个步骤的编写。 //TODO 5，构造一个映射器 private void initHandleMapping() { } //TODO 4,实现依赖注入 private void doAutoWired() { } //TODO 3,IOC容器 private void doInstance() { } //TODO 2,扫描类 private void doScan(String scanPackage) { } //TODO 1，加载配置文件 private void doLoadConfig(String contextConfigLocation) { } 3.1 加载配置文件 首先在resource目录中创建一个配置文件——springmvc.properties 表示要扫描com.dxh.demo下的所有注解。 然后在web.xml中进行配置： 这样，就可以通过config.getInitParameter("contextConfigLocation")获得这个路径。 在DxhDispatcherServlet中定义一个属性，我们把加载后的配置文件中的信息，存储在Properties 中 private Properties properties = new Properties();; //1，加载配置文件 private void doLoadConfig(String contextConfigLocation) { //根据指定路径加载成流： InputStream resourceAsStream = this.getClass().getClassLoader().getResourceAsStream(contextConfigLocation); try { properties.load(resourceAsStream); } catch (IOException e) { e.printStackTrace(); } } 3.2 扫描相关的类，扫描注解 上一步骤，我们已经把需要扫描的包存在Properties中，所以这里需要取出： //2. 扫描相关的类——扫描注解 doScan(properties.getProperty("scanPackage")); 把扫描到的类型的全类名存在一个List中缓存起来，等待使用，在DxhDispatcherServlet中定义一个list： //缓存扫描到的类的全类名 private List<String> classNames = new ArrayList<>(); 从配置文件中我们得到了一个需要扫描的包名（com.dxh.demo），我们需要根据classPath+包名，来得到它实际上在磁盘上存的路径，然后递归，直到把所有的该包下（包括子包...）所有的类文件（.class结尾）。然后存在在List classNames中。 //2,扫描类 //scanPackage :com.dxh.demo package--->磁盘的文件夹（File） private void doScan(String scanPackage) { //1.获得classPath路径 String clasPath = Thread.currentThread().getContextClassLoader().getResource("").getPath(); //2.拼接,得到scanPackage在磁盘上的路径 String scanPackagePath= clasPath + scanPackage.replaceAll("\\.","/"); File pack = new File(scanPackagePath); File[] files = pack.listFiles(); for (File file : files) { if (file.isDirectory()){ //子 package //递归 doScan(scanPackage+"."+file.getName()); //com.dxh.demo.controller }else if(file.getName().endsWith(".class")){ String className = scanPackage + "." + file.getName().replace(".class", ""); classNames.add(className); } } } 3.3 初始化Bean对象（实现IOC容器，基于注解） 上一步骤我们把扫描到的类的全类名放到了，list中，那么本次步骤需要遍历整个list： 遍历List，依次得到所有的全类名 通过反射得到类对象 根据类对象判断有没有注解，并区分controller和servicecontroller，它的id此处不做过多处理，不取value了，用类的首字母小写作为id，保存到IOC容器中。service，service层往往是有接口的，再以接口名为id再存入一份bean到ioc，便于后期根据接口类型注入 完成 代码实现： //IOC容器 private Map<String,Object> ioc = new HashMap<>(); //3,IOC容器 //基于classNames缓存的类的全限定类名，以及反射技术，完成对象创建和管理 private void doInstance() { if (classNames.size()==0) return; try{ for (int i = 0; i < classNames.size(); i++) { String className = classNames.get(i); //com.dxh.demo.controller.DemoController //反射 Class<?> aClass = Class.forName(className); //区分controller ，区分service if (aClass.isAnnotationPresent(DxhController.class)){ //controller的id此处不做过多处理，不取value了，用类的首字母小写作为id，保存到IOC容器中 String simpleName = aClass.getSimpleName();//DemoController String lowerFirstSimpleName = lowerFirst(simpleName); //demoController Object bean = aClass.newInstance(); ioc.put(lowerFirstSimpleName,bean); }else if (aClass.isAnnotationPresent(DxhService.class)){ DxhService annotation = aClass.getAnnotation(DxhService.class); //获取注解的值 String beanName = annotation.value(); //指定了id就以指定的id为准 if (!"".equals(beanName.trim())){ ioc.put(beanName,aClass.newInstance()); }else{ //没有指定id ，首字母小写 String lowerFirstSimpleName = lowerFirst(aClass.getSimpleName()); ioc.put(lowerFirstSimpleName,aClass.newInstance()); } //service层往往是有接口的，再以接口名为id再存入一分bean到ioc，便于后期根据接口类型注入 Class<?>[] interfaces = aClass.getInterfaces(); for (Class<?> anInterface : interfaces) { //以接口的类名作为id放入。 ioc.put(anInterface.getName(),aClass.newInstance()); } }else { continue; } } }catch (Exception e){ e.printStackTrace(); } } 3.4 实现依赖注入： 上一步骤把所有需要加载的bean，存入了ioc Map中，此时，我们就需要遍历这个map然后依次得到每个bean对象，然后判断对象中有没有被@****DxhAutowired修饰的属性。 遍历ioc这个map，得到每个对象 获取对象的字段（属性）信息 判断字段是否被@DxhAutowired修饰 判断@DxhAutowired有没有设置value值有，直接从ioc容器中取出，然后设置属性。无，需要根据当前字段的类型注入（接口注入） 代码实现： //4,实现依赖注入 private void doAutoWired() { if (ioc.isEmpty()){return;} //1，判断容器中有没有被@DxhAutowried注解的属性，如果有需要维护依赖注入关系 for (Map.Entry<String,Object> entry: ioc.entrySet()){ //获取bean对象中的字段信息 Field[] declaredFields = entry.getValue().getClass().getDeclaredFields(); for (Field declaredField : declaredFields) { if (!declaredField.isAnnotationPresent(DxhAutowired.class)){ continue; } //有该注解： DxhAutowired annotation = declaredField.getAnnotation(DxhAutowired.class); String beanName = annotation.value(); //需要注入的bean的Id if ("".equals(beanName.trim())){ //没有配置具体的beanId，需要根据当前字段的类型注入（接口注入） IDemoService beanName = declaredField.getType().getName(); } //开启赋值 declaredField.setAccessible(true); try { //字段调用，两个参数：(哪个对象的字段，传入什么) declaredField.set(entry.getValue(),ioc.get(beanName)); } catch (IllegalAccessException e) { e.printStackTrace(); } } } } 3.5 构造一个handleMapping处理器映射器 构造一个handleMapping处理器映射器，将配置好的url和method建立映射关系****。 手写MVC框架最关键的环节 假设有一个： 那么如何通过/demo/query定位到 DemoController类中的query这个方法 ？ 之前我们所有被@DxhController（自定义Controller注解）的类，都存在了ioc 这个map中。 我们可以遍历这个map，得到每个bean对象 然后判断是否被@DxhController所修饰（排除@DxhService所修饰的bean） 然后判断是否被@DxhRequestMapping所修饰，有的话，就取其value值，作为baseUrl 然后遍历该bean对象中的所有方法，得到被@DxhRequestMapping修饰的方法。得到其value值，作为methodUrl。 baseUrl + methodUrl = url 我们把url和当前method绑定起来，存在map中，也就是建立了url和method建立映射关系。 代码实现： //handleMapping ，存储url和method直接的映射关系 private Map<String,Object> handleMapping = new HashMap<>(); //5，构造一个映射器,将url和method进行关联 private void initHandleMapping() { if (ioc.isEmpty()){return;} for (Map.Entry<String,Object> entry: ioc.entrySet()){ //获取ioc中当前遍历对象的class类型 Class<?> aClass = entry.getValue().getClass(); //排除非controller层的类 if (!aClass.isAnnotationPresent(DxhController.class)){ continue; } String baseUrl = ""; if (aClass.isAnnotationPresent(DxhRequestMapping.class)){ //Controller层 类上 注解@DxhRequestMapping中的value值 baseUrl = aClass.getAnnotation(DxhRequestMapping.class).value(); } //获取方法 Method[] methods = aClass.getMethods(); for (Method method : methods) { //排除没有@DxhRequestMapping注解的方法 if (!method.isAnnotationPresent(DxhRequestMapping.class)){continue;} //Controller层 类中方法上 注解@DxhRequestMapping中的value值 String methodUrl = method.getAnnotation(DxhRequestMapping.class).value(); String url = baseUrl+methodUrl; //建立url和method之间的映射关系，用map缓存起来 handleMapping.put(url,method); } } } 4，测试一下： 到目前位置，还没有完全写完，但是不妨碍我们测试一下看看刚才写的那部分内容有没有什么问题： 完整的pom文件： <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.dxh.edu</groupId> <artifactId>mvc</artifactId> <version>1.0-SNAPSHOT</version> <packaging>war</packaging> <name>mvc Maven Webapp</name> <url>http://www.example.com</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>11</maven.compiler.source> <maven.compiler.target>11</maven.compiler.target> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.5</version> <!-- 部署在服务器时，不使用这个servlet-api 而使用tomcat的--> <scope>provided</scope> </dependency> </dependencies> <build> <plugins> <plugins> <!-- 编译插件定义编译细节--> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.2</version> <configuration> <source>11</source> <target>11</target> <encoding>utf-8</encoding> <!-- 告诉编译器，编译的时候记录下形参的真实名称--> <compilerArgs> <arg>-parameters</arg> </compilerArgs> </configuration> </plugin> <plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.2</version> <configuration> <port>8080</port> <path>/</path> </configuration> </plugin> </plugins> </build> </project> pom文件中加入了一个tomcat插件，并设置端口为8080，因此我们通过tomcat启动项目： 启动完成后，打开浏览器url中输入： http://localhost:8080/demo/query 浏览器中什么都没返回（我们的代码还没真正的完成，尚未编写处理请求步骤），同时控制台中打印了MVC初始化完成，可以认为，目前的代码没有明显的缺陷。 我们继续~~~~~ 5，改造initHandleMapping() 5.1 为什么改造？ DxhDispatcherServlet这个类继承了HttpServlet，并重写了doGet和doPost方法，在doGet中调用了doPost方法，当我们使用反射调用方法时(method.invoke(......))发现少了一部分参数： 因此我们要改造initHandleMapping()，修改url和method的映射关系（不简简单单的存入map中）。 5.2 新建Handler类 package com.dxh.edu.mvcframework.pojo; import java.lang.reflect.Method; import java.util.HashMap; import java.util.Map; import java.util.regex.Pattern; public class Handler { //method.invoke(obj,)需要 private Object controller; private Method method; //spring中url支持正则 private Pattern pattern; //参数的顺序，为了进行参数绑定 ，Key 参数名， Value 代表第几个参数 private Map<String,Integer> paramIndexMapping; public Handler(Object controller, Method method, Pattern pattern) { this.controller = controller; this.method = method; this.pattern = pattern; this.paramIndexMapping = new HashMap<>(); } //getset方法这里省略，实际代码中需要... } 在Handler类中编写了4个属性： private Object controller：method.invoke(obj,)需要 private Method method：与url绑定的方法 private Pattern pattern：可以通过正则匹配，也可以直接写String url。 private Map<String,Integer> paramIndexMapping：参数的顺序，为了进行参数绑定 ，Key 参数名， Value 代表第几个参数 5.3 修改initHandleMapping() 首先，就不能直接通过Map<url,Method>的得方式进行关系映射了，使用一个list，泛型是刚才创建的Handler。 //handleMapping ，存储url和method直接的映射关系 // private Map<String,Method> handleMapping = new HashMap<>(); private List<Handler> handlerMapping = new ArrayList<>(); 改动前，改动后代码对比： 改动后的initHandleMapping()： //5，构造一个映射器,将url和method进行关联 private void initHandleMapping() { if (ioc.isEmpty()){return;} for (Map.Entry<String,Object> entry: ioc.entrySet()){ //获取ioc中当前遍历对象的class类型 Class<?> aClass = entry.getValue().getClass(); //排除非controller层的类 if (!aClass.isAnnotationPresent(DxhController.class)){ continue; } String baseUrl = ""; if (aClass.isAnnotationPresent(DxhRequestMapping.class)){ //Controller层 类上 注解@DxhRequestMapping中的value值 baseUrl = aClass.getAnnotation(DxhRequestMapping.class).value(); } //获取方法 Method[] methods = aClass.getMethods(); for (Method method : methods) { //排除没有@DxhRequestMapping注解的方法 if (!method.isAnnotationPresent(DxhRequestMapping.class)){continue;} //Controller层 类中方法上 注解@DxhRequestMapping中的value值 String methodUrl = method.getAnnotation(DxhRequestMapping.class).value(); String url = baseUrl+methodUrl; //把method所有信息以及url封装为Handler Handler handler = new Handler(entry.getValue(),method, Pattern.compile(url)); //处理计算方法的参数位置信息 Parameter[] parameters = method.getParameters(); for (int i = 0; i < parameters.length; i++) { Parameter parameter = parameters[i]; //不做太多的参数类型判断，只做：HttpServletRequest request, HttpServletResponse response和基本类型参数 if (parameter.getType()==HttpServletRequest.class||parameter.getType()==HttpServletResponse.class){ //如果时request和response对象，那么参数名称存 HttpServletRequest 和 HttpServletResponse handler.getParamIndexMapping().put(parameter.getType().getSimpleName(),i); }else{ handler.getParamIndexMapping().put(parameter.getName(),i); } } handlerMapping.add(handler); } } } 6, 请求处理开发 doPost()： 上一步骤，我们配置了 uri和method的映射关系，并封装到了Handler中存入list，那么接下来，就要通过HttpServletRequest，取出uri，然后找到具体的Handler： 通过HttpServletRequest取出uri找到具体的Handler 得到将调用方法的参数的数组 根据上述数组长度创建一个新的数组（参数数组，传入反射调用的） 通过req.getParameterMap()得到前台传来的参数parameterMap 遍历parameterMap 通过StringUtils.join方法把name=1&name=2格式的参数变为name[1,2] （需要commons-lang依赖） 参数匹配并设置 private Handler getHandler(HttpServletRequest req) { if (handlerMapping.isEmpty()){return null;} String url = req.getRequestURI(); //遍历 handlerMapping for (Handler handler : handlerMapping) { Matcher matcher = handler.getPattern().matcher(url); if (!matcher.matches()){continue;} return handler; } return null; } @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException { //根据uri获取到能够处理当前请求的Handler（从handlerMapping中（list）） Handler handler = getHandler(req); if (handler==null){ resp.getWriter().write("404 not found"); return; } //参数绑定 //该方法所有参数得类型数组 Class<?>[] parameterTypes = handler.getMethod().getParameterTypes(); //根据上述数组长度创建一个新的数组（参数数组，传入反射调用的） Object[] paramValues = new Object[parameterTypes.length]; //以下就是为了向参数数组中设值，而且还得保证参数得顺序和方法中形参顺序一致。 Map<String,String[]> parameterMap = req.getParameterMap(); //遍历request中所有的参数 ，（填充除了request、response之外的参数） for (Map.Entry<String,String[]> entry: parameterMap.entrySet()){ //name=1&name=2 name[1,2] String value = StringUtils.join(entry.getValue(), ",");// 如同 1,2 //如果参数和方法中的参数匹配上了，填充数据 if (!handler.getParamIndexMapping().containsKey(entry.getKey())){continue;} //方法形参确实有该参数，找到它得索引位置，对应得把参数值放入paramValues Integer index = handler.getParamIndexMapping().get(entry.getKey()); //把前台传递过来的参数值，填充到对应得位置去 paramValues[index] = value; } Integer requestIndex = handler.getParamIndexMapping().get(HttpServletRequest.class.getSimpleName()); paramValues[requestIndex] = req; Integer responseIndex = handler.getParamIndexMapping().get(HttpServletResponse.class.getSimpleName()); paramValues[responseIndex] = resp; //最终调用handler得method属性 try { Object invoke = handler.getMethod().invoke(handler.getController(), paramValues); //简单操作，把方法返回的数据以字符串的形式写出 resp.getWriter().write(invoke.toString()); } catch (IllegalAccessException e) { e.printStackTrace(); } catch (InvocationTargetException e) { e.printStackTrace(); } } 7，测试： 打开浏览器，url中输入：http://localhost:8080/demo/query?name=lisi 返回： 控制台中打印出： OK完成~ 转自：https://www.toutiao.com/i6903531694301676035/ 读取更多关于从MVC原理开始手敲一个MVC框架，体会当大神的乐趣 »

如何 开展网络直播评课活动？ 开展网络直播评课活动的总流程跟《释锐 听课评课应用系统 使用总流程》基本一致，但是有两点需要特别注意： 第一点，参赛教师在提交参赛作品时必须【创建一个直播类教育资源】，该资源要预先发布并且完成审核工作； 第二点，由于是直播评课，评委必须在老师上课的时间段内完成评课，评课方式跟录播视频评课完全一样，直播视频可能有20秒左右的时间延迟。 如何创建一个直播视频类在线教育资源？ 图1：HLS直播拉流网址 第1步：图1所示，登录云桌面系统，进入“我的个人资料-音视频”栏目，找到您的HLS直播拉流网址（如果空，代表手机号无效，填上有效的手机号即可开通），格式 https://XXX/YYY/ZZZ.m3u8，其中，XXX是直播服务器地址，YYY是直播应用地址(hls代表只直播不录播,hls4vip代表直播结束后自动录播，请在厂家指导下设置音视频参数)，ZZZ是流媒体名称，一般是您的注册手机号或者电子邮件地址； 图2：发布一个直播视频类教育资源 第2步：图2所示，进入“教育资源公共服务平台-上传资源”页面，将第1步找到的HLS直播拉流网址填入资源输入框内（切记不要点击“选择一个资源文件”按钮）； 图3：发布直播时间预告和活动封面图 第3步：图3所示，进入“ 第2步：首次编目资源”，完善画圈处的内容，尤其是 直播时间预告； 第4步：等待管理员审核通过，上线后即可作为参赛作品报名参赛评课； 图4：直播前评委评课界面（上课直播开始30秒之内，评委就能看到直播画面） 第5步：图4所示，上课的时间，评委远程同步参与评课。 读取更多关于如何 发布直播资源并开展在线直播评课活动？ »

释锐 听课评课应用系统 使用总流程 步骤 事项 备注 1 创建评课方案 评课方案就是一套评价课堂的打分标准，由“评估方案和评估技能”构成。 评估方案需要指定方案名称、方案描述和排序序号，可以按需创建多套评估方案，每套评估方案都必须指定合适的评估技能，包括主技能和子技能，每项技能都要有明确的能描述、分值和序号。 2 创建评课活动 开展一次听课评课活动都需要创建一个评课活动，评课活动包含了下列基本信息。 活动主题 报名开始时间 报名截止时间 评估方案，此项特别重要，是量化指标 评选标准，评分标准的文字详细说明 活动说明 3 报名开始 在报名有效期内，受邀老师都能报名参加。 在评课系统首页，选择正在报名中的活动，进入活动之后点击“报名参赛”按钮；报名成功后，务必在规定的时间段内提供参赛作品；参赛作品可以是一门网络课程，也可以是一个教学资源，也可以是一个专题资源；如果要做直播评课，则只能选择一个指定直播地址的在线资源，而不能选择一门网络课程。 4 教师报名参加 在报名有效期内，受邀老师都能报名参加。 在评课系统首页，选择正在报名中的活动，进入活动之后点击“报名参赛”按钮；报名成功后，务必在规定的时间段内提供参赛作品；参赛作品可以是一门网络课程，也可以是一个教学资源，也可以是一个专题资源。 5 报名截止 报名截止日期过后，就不能报名了。 6 评课开始 报名截止之后，自动进入评课时间。 7 评委评课 在评课时间段内（直播评课时间必须跟参赛老师的上课时间一致），受邀评委老师完成“在线听课、在线评课(按评估方案打分)和填写听课记录/评课建议”等评课工作。 每一位评委完成评课后，都会给参赛老师一个评分，系统自动计算该参赛作品的总得分和平均得分。 8 评课结束 评课结束后，评委和参赛老师都能看到听课记录表，记录表内详细记载了每位评委的评课详情以及打分细项。 9 结果公示 评课截止时间到，就代表评课结束，评课结束后，需要由管理员主动执行“结果公示”操作，填写完评课公示之后，才能公示本次活动的最终排名结果。 读取更多关于释锐 听课评课应用系统 使用总流程 »

如何用电脑版VLC工具观看合育宝直播？ 从VLC官网下载并安装好VLC Player软件； 打开VLC Player软件； 点击“媒体-打开网络串流”菜单； 输入 rtmp://live.heyubao.com/live/139****4057?key=06***2 或者 https://heyubao.com/hls/139****4057.m3u8 格式的网络URL，点击播放即可观看合育宝直播视频。 如何用手机版VLC工具观看合育宝直播？ 从苹果手机的 app store 或者 安卓 应用商店搜索 VLC for mobile 手机应用程序，并且安装好该APP； 打开VLC应用程序； 点击“网络-打开网络串流”栏目； 输入 rtmp://live.heyubao.com/live/139****4057?key=06***2 或者 https://heyubao.com/hls/139****4057.m3u8 格式的网络URL，点击“打开网络串流”按钮即可观看合育宝直播视频。 如何用微信APP观看合育宝直播？ 打开微信APP； 搜索并打开 腾讯视频云 小程序； 点击 直播播放； 扫码 rtmp://live.heyubao.com/live/139****4057?key=06***2 格式的合育宝直播视频源 二维码，好像不支持 m3u8格式的直播视频源； 点击 播放 即可观看合育宝直播视频。 读取更多关于如何 用VLC和微信APP看合育宝直播视频？ »

打开合育宝APP； 点击“播放器”，在这里可以观看直播和录播视频（图1），其中，支持的直播视频有RTMP,HLS和DASH三种格式，点播视频有HLS,MP4和FLV三种格式； 点击图标，扫码输入待观看的视频地址并且直接调用播放器自动播放，可能是一个直播视频拉流地址，也可能是一个VOD视频点播地址，扫入的地址会自动保存到地址输入框内； 如果不用扫码输入，还能直接在输入框内手工输入视频地址，并且按圆形按钮开始播放，如果是VOD点播视频，本播放器能够显示字幕； 长按屏幕底部的二维码图形，可以分享当前用户的直播观看码给好友，好友用APP播放器扫码就可观看本人的直播。 图1：扫二维码或者手工输入待播放视频地址（含直播拉流地址） 图2：二维码扫码界面 读取更多关于如何 使用合育宝自带网络媒体播放器观看直播和点播视频？ »

现象：巫溪县教育资源公共服务平台【学科】没有正常显示。 原因：添加了三个职业高中学段，而系统默认以学段3为分界点，高于学段3的学校归属高校范畴，而低于等于学段3（即0-12年级）的学校归属k12中小学范畴。 解决方案：修改云桌面系统，将学段分界点从3改到6，即中专含中专及一下的学段都归属为中小学。 读取更多关于K12有关学段问题导致学科没有正常显示 »