在《如何开展您的第1次企业直播》帖子中【第4步：推流直播】有以下表述：进入"个人中心"，点击"显示推流地址二维码"，就可找到推流所需全部参数，用合育宝APP/腾讯视频云小程序/OBS即可推流；推流成功后，观众通过预告网址在各种设备上观看直播并留言互动。至此，恭喜您，您的企业已经成功迈出了数字化转型的第一步。本文通过图文方式重点讲解如何用合育宝APP推流，确保任何人都能像用相机一样轻松做企业直播。 图1：打开合育宝APP 图2：登录/注册 图3：输入手机号码和密码登录，如果手机号未注册，则自动切换成注册 图4：确保直播应用选中了【RTMP直播及录播】选项 图5：确保直播V课有效，如果是【无】，则点击【创建V课活动】 图6：按照上图所示表格要求，创建一个V课活动 图7：创建完V课之后，可以修改和补充更多有关V课的信息 图8-1：新建直播活动(简称V课)进入预告列表 图8-2：点击直播预告详情页右上角【分享】直播预告 图8-3：直播预告分享图文海报，点击左下角分享图标 图8-4：将直播预告图片分享给微信好友/微信群和朋友圈 图9：点击图2顶端【推流】图标，进入本直播推流预览页面，上图是竖屏直播 图10：强烈推荐采用横屏直播，即按下上述红色推流按钮前，先把手机横屏 图11：按下推流按钮后，系统弹出上述对话提示框，【确定】正式推流，【取消】更改V课 图12：正式推流画面，点击【方形红色按钮】停止推流，点击【暂停按钮】暂停推流 图13：直播结束后，可以立即回看 图14：点击【我的】页面右上角的三点图标 图15：点击【我的V课】 图16：点击【我的V课视频】 图17：对直播视频进行【剪去头部段、剪去中间段、剪去尾部段、逆时针旋转90度，顺时针旋转90度】五类剪辑操作 图18：删除不用的直播回看视频 图19：删除不用的V课活动 图20：直播数据分析列表 图21：直播观众分析 图22：另一个删除直播活动的入口(跟图19操作等效) 图23：确认删除 读取更多关于用合育宝APP推流直播图文教程 »

现象：观看直播时出现图像卡顿或者声音断断续续？ 原因：在上下行网络带宽有1MB的前提下，主播推流端参数设置太高或者推流端的电脑或者手机配置太低导致推流端计算能力跟不上，导致时断时续。 解决方案：降低推流参数，特别是以下几个参数，不要超过建议值 参数 建议值(不高于) 分辨率 720p 帧速率 24fps x264预设值 Very fast 比特率 1721kbps 音频质量 44.1KHz,128kbps 读取更多关于观看直播时出现图像卡顿或者声音断断续续时怎么办？ »

企业运营模式向线上转移，企业直播成为必要部署由于企业直播用户数量全面攀升，据公开资料统计，2020年2月，企业直播在用户端完成高位迭代，相比1月，用户数实现约7倍的增长。上亿的用户群体对企业直播尝试，且用户留存率大于90%。2020年第一季度，企业直播用户数量持续走高，月度最高约3.4亿人。企业运营模式整体向线上转移，企业直播已然成为企业发展核心竞争力。因企业直播的营销效果与在线用户的活跃量最直接影响。加大企业直播用户引流成为企业线上运营关键。 第1步：免费注册直播账号 点击免费注册合育宝会员，输入手机号码、登录密码和短信验证码之后即可注册成功。 第2步：免费创建V课 登录成功后，进入"个人中心-我的直播"，添加一个V课。 第3步：分享直播预告 点击"个人中心-我的直播-我的V课"，打开直播预告，将预告网址分享到微信好友/微信群/朋友圈，朋友点击该网址即可通过关注您或者输入手机号码就能完成该直播的预约，开播前15分钟预约用户能够收到短信或者微信提醒。 第4步：推流直播 进入"个人中心"，点击"显示推流地址二维码"，就可找到推流所需全部参数，用合育宝APP/腾讯视频云小程序/OBS即可推流；推流成功后，观众通过预告网址在各种设备上观看直播并留言互动。至此，恭喜您，您的企业已经成功迈出了数字化转型的第一步。如何用合育宝APP推流，详见《用合育宝APP推流直播图文教程》。 合育宝直播跟抖音、快手、视频号、微视有何不同？ 第一，合育宝直播为学校/教育局以及不希望将视频数据托管在第三方平台的机构提供系统自建服务，将直播以及点播流媒体服务所需的软硬件系统交付到用户自备服务器上； 第二、合育宝直播支持回看，适合直播结束后持续观看； 第三、合育宝直播时间不限，直播10小时也没有问题，回看也是； 第四，合育宝直播支持【直播免费,回看收费】或者【直播收费,回看免费】等各种知识付费； 第五，合育宝直播适合在微信朋友圈和微信群以及微信好友内分享H5直播链接，观众门槛低，容易触达，适合商业直播； 第六，合育宝直播提供"观众、留言、打赏、预约、新客"5类观众数据分析，提供"短信联系、互加好友、店铺留言"等多种互动手段，让每一场直播都有价值。 读取更多关于如何开展您的第1次企业直播? »

随着直播行业的发展，企业直播的数量及频率也随之上升。 企业为什么要做企业直播？今天一次性回答你企业为什么需要直播营销？ 1.都说移动互联网的时代就是直播的时代，这句话对吗？ 随着智能手机的普及，4G业务发展成熟，移动互联网的发展，手机上网用户激增，手机终端成为首要上网工具。直播符合移动互联网的大趋势，直播表现形式丰富，真实性、互动性、实时性强，能够带来更好的娱乐属性以及信息属性，符合移动互联网场景化、碎片化、个性化、去中心化的特点和趋势。所以说，移动互联网的时代就是直播的时代并无为过。 2.直播比传统媒体好在哪里？ 随着互联网的兴起，传统媒体逐渐衰落，各种向外宣传途径的增多，无论是企业或是个人都意识到，只靠基础图文的日常传播已经满足不了粉丝日益增长的优质内容需求。越来越多的企业利用直播营销去实现与用户的实时互动。这相较于传统电视，直播的一大优势就是能够满足用户更为多元的需求。 当观众在观看屏幕内容的时候。不仅仅是单向的观看，还能通过直播，更直观的知晓商品的各种属性，甚至可以挑起关注性高的话题讨论，这种互动的真实性和立体性，也只有在直播才能展现。 3.企业直播与娱乐直播有什么区别？ 企业直播是专注于企业级的直播平台，适合企业或商家做直播营销或宣传活动，而娱乐直播则比较适合主播做一些游戏、才艺类等类型的娱乐性直播。还有活跃于娱乐直播平台的用户，都是抱着娱乐休闲的心态看直播的，很少有购买的意向，当他们看到广告时，很有可能立马退出，寻找新的娱乐直播节目，这些流量对企业或商家来说用处不大。 4.传统行业可以做企业直播吗？ 当然，公司一般有对外和对内两种活动，对外可以用直播来做营销宣传，成本低、速度快、效果好，轻松达到成交获客的目标；对内用来做培训或会议等活动，可以记录回放，降低运营成本。很多知名传统公司也在借助直播跟上市场的潮流。 5.做一场企业直播麻烦吗？ 并不，企业直播技术日益成熟，专业的直播技术人员可以在短时间将设备及线路调整完备，相比于其他类型直播也并不麻烦。 6.传统行业可以做企业直播吗？ 随着技术的成熟和移动互联的发展，未来的企业，都需要建立一个视频直播，使直播与企业宣传营销完美结合，帮自己吸引粉丝，吸引客户，转化成交。 企业直播可以将整个企业的文化通过视频的模式直接表达给目标用户，通过大数据、用户画像等技术，可以优化企业品牌宣传的战略，意义可想而知。 原文：https://www.sohu.com/a/479166198_120775766 读取更多关于为什么要做企业直播？企业直播有什么意义？ »

现象：在公司的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)的使用 »

每一个程序员，在刚入行时学的第一个框架应该就是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框架，体会当大神的乐趣 »

什么是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？该如何使用？ »

如何 开展网络直播评课活动？ 开展网络直播评课活动的总流程跟《释锐 听课评课应用系统 使用总流程》基本一致，但是有两点需要特别注意： 第一点，参赛教师在提交参赛作品时必须【创建一个直播类教育资源】，该资源要预先发布并且完成审核工作； 第二点，由于是直播评课，评委必须在老师上课的时间段内完成评课，评课方式跟录播视频评课完全一样，直播视频可能有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所示，上课的时间，评委远程同步参与评课。 读取更多关于如何 发布直播资源并开展在线直播评课活动？ »

微信服务随着应用的不断深入，会越来越多，截至2018年3月29日，已经支持下列服务，所有消息都通过绑定号校园帐户的用户手机微信传送。 校务办公系统（家校通）： 教工内部通知及反馈。 家长通知及反馈。 教职工工资查询。 日程提醒。 会议申请、审核、提醒。 用车，用餐，采购及临时加班的申请、审核、提醒。 电教报修申请、受理、提醒。 总务报修申请、受理、提醒。 文印申请、核准、交印、领取、提醒。 学生成绩系统： 学生本人或者家长接收每次考试的成绩单。 教学管理系统（走班排课系统）： 每个星期天下午1点钟系统定时发送下周课表给班主任、任课老师、学生及家长。 一旦有网上选课安排，系统即时发送选课通知给学生或家长，确保学生在规定时间内按时选课。 一旦有调课安排，系统即时发送调课通知给跟调课有关联的班主任，任课老师，学生及家长。 每节课的上课考勤通知给家长和班主任。 一旦任课老师在课堂上给某位同学添加了课堂表现评语，系统即时通知给班主任和家长。 读取更多关于微信服务有哪些项目？ »

学校需要满足下列2个条件： 只有释锐智慧校园系列软件v7.3.2.0之后的版本才提供微信支持，该版本系2018年2月1日发布，因此只有升级到v7.3.2.0版本及其后续更高版本之后才能开通微信服务。诚邀2018年2月1日之前交付的所有释锐老客户联系申请产品升级！释锐公司技术团队跟您回访确认升级事宜。请点击微信开通申请链接。电话咨询 021-60753206 购买释锐保服务就能升级，或者在产品交付1年之内或还在释锐保运维服务或者SaaS托管服务期内的客户免费升级。点击了解释锐保服务详情。 读取更多关于哪些学校可以开通微信服务？ »

释锐校园软件终端用户是指：购买了释锐校园级软件产品学校的在职教职工、在校学生和家长，释锐软件为每一位教职工、学生及家长都提供了一个用户账号和初始密码。如果您属于上述3类用户之一，就能将学校所用的释锐软件平台和您个人微信APP进行绑定。绑定好之后，能够免去每次进系统都需要登录验证的麻烦，并且从微信上就能收到来自学校的各类官方消息和通知（消息类型清单详见 https://access.threeoa.com/bbs/-/message_boards/message/189207），而且新消息时会即时提醒。 释锐校园软件终端用户绑定微信服务的步骤如下（教职工、学生、家长绑定步骤一致，没有区别）： 第1步：关注产品研发厂商（上海释锐教育软件有限公司或OEM合作伙伴）的官方微信公众号 上海释锐教育软件有限公司的微信公众号是 threegroup ，二维码 第2步：绑定校园账号 个人中心》绑定校园账号》请选择一所学校》选择贵校所在省份》选择贵校所在地市》“点击查询”列表当前地市开通了微信服务的所有学校列表》选择您所在的学校》系统会自动检测网络是否畅通》如果网络畅通，点击“确定”按钮》系统自动跳往贵校释锐软件平台运行的网址，等待您的输入》请输入正确的用户名和密码（如果您不知道账号和初始密码，请向贵校的网络管理员老师索取）》验证通过代表完成绑定。 第3步：学校信息提醒 第4步：手机微信上查阅来自学校的信息 第5步：手机微信上回复来自学校的信息 点击第4步图中的“编辑留言”或者“留言”即可参与回复。回复的内容不但保存在微信留言列表中，还会自动同步到学校的释锐校务办公平台对应的站内信的留言列表内。 视频教程(请点击播放) 您的浏览器版本不支持video技术，此处视频无法播放，建议用Chrome谷歌浏览器。 绑定过程中，碰到问题或者困难找谁？ 首先：找学校的网络管理员老师，学生或者学生家长可以先找到班主任，由班主任告知网络管理员老师的电话； 其次：直接释锐公司工作人员，售后服务咨询电话 021-60753203 ，售后服务咨询QQ 313908888。 读取更多关于释锐校园软件终端用户如何绑定微信服务？ »

简化上线流程，确保极速上线可用。 如果绑定学校自有公众号，除了厂家要按年收取技术维护费外，一个支持二次开发的公众号还需要经过联系腾讯公司办理付费认证、开发配置、模版消息配置等多个环节，从申请到上线需要1-2周时间。 况且，不论是学校公众号，还是厂家公众号，都是腾讯公司的微信公众号技术，起到的作用就是“消息快递员”的作用，没有本质的区别，好处都是可以快速在手机上收到来自校园平台的各类实用消息。 读取更多关于为什么需要关注厂家的微信公众号，而不是学校自己的公众号？ »

不会。释锐微信公众服务系统采用了“释锐校园软件平台、释锐中转分发服务器、腾讯微信服务器、用户手机微信APP”四层架构，微信用户在首次绑定校园账号时也绑定了校园软件网址。 读取更多关于多校绑定同一个公众号会导致信息错发吗？ »

现象：微信公众号绑定学校时，提示“CAS is Unavailable”，如下图；但是在浏览器上可以正常登录系统。 [img]https://access.threeoa.com/documents/10182/218667/%E5%BE%AE%E4%BF%A1%E7%BB%91%E5%AE%9A%E6%8A%A5%E9%94%99/ded43bc5-ed3f-4952-8723-ab723bf16b4b?t=1571819536000[/img] 原因：桌面系统-设置-微信服务器栏为空，导致后台报”空值错误”； 解决方案：   登陆网页版桌面系统→设置→启用微信总开关并填写微信服务器地址"[b]http://license.threeoa.com[/b]" 读取更多关于绑定微信提示“CAS is Unavailable” »