13518219792
/**
为资溪等地区用户提供了全套网页设计制作服务，及资溪网站建设行业解决方案。主营业务为成都做网站、网站建设、资溪网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
* Android视频聊天
* 1、初始化SDK 2、连接服务器、 3、用户登录；4、进入房间；5、打开本地视频；6、请求对方视频
*/
public class VideoChatActivity extends Activity implements AnyChatBaseEvent
{
private AnyChatCoreSDK anychat; // 核心SDK
private SurfaceView remoteSurfaceView; // 对方视频
private SurfaceView localSurfaceView; // 本地视频
private ConfigEntity configEntity;
private boolean bSelfVideoOpened = false; // 本地视频是否已打开
private boolean bOtherVideoOpened = false; // 对方视频是否已打开
private TimerTask mTimerTask; // 定时器
private Timer mTimer = new Timer(true);
private Handler handler; // 用Handler来不间断刷新即时视频
private ListString userlist = new ArrayListString();//保存在线用户列表
private int userid; // 用户ID
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_video_chat);
remoteSurfaceView = (SurfaceView) findViewById(R.id.surface_remote);
localSurfaceView = (SurfaceView) findViewById(R.id.surface_local);
configEntity = ConfigService.LoadConfig(this);//加载视频通话设置
loginSystem();// 初始化SDK 连接服务器
mTimerTask = new TimerTask(){
public void run(){
Message mesasge = new Message();
handler.sendMessage(mesasge);
}
};
mTimer.schedule(mTimerTask, 1000, 100);
handler = new Handler(){
@Override
public void handleMessage(Message msg){
VideoChat();// 不间断显示即时视频通话画面
super.handleMessage(msg);
}
};
}
本文之所以有必要编写并作记录，主要原因是因为在工作中开发出一个万能的自定义camera预览控件之后，本是一个提高效率以及提供一个强大能力的控件，但是产品并不能理解这个万能控件存在的意义，产品无法与技术设计相结合的理解使用；并且发现我们的智能业务部Camera自定义预览技术虽然是使用多年，但是我们并没有真正的形成规范，由于产品在不能够理解系统平台（Android/iOS）给产品和研发带来了什么，导致产品可能会出现在不理解系统平台以及系统知识的情况下，臆想产品所谓的形态；当产品设计脱离了系统平台所支持的技术点以及设计的初衷，就会导致回归问题的时候，出现不必要的讨论，其根结就是一点：“信息不同步，知识不同步”。
所以，为了提高效率，就采用记录和分享的方式，尝试性推动产品、测试、研发三者对工程与架构的同步理解，更深的懂得程序架构设计意义，尝试性通过信息同步的方式，在一个统一的知识储备的平台下，共同完成一个更高效，和高品质的工程产品。（为了能够让非技术：产品设计，以及测试都能够理解，所以，使用了更多的白话解释）
附：强大灵活的FsCameraTextureView（第一版，自适应截取）（ 第二版本版本：自适应展示）
首先，抛出几个问题，
1）什么是摄像头支持的previewSize？
2）什么是视频或者图片的pictureSize?
3) 如何获取和查看摄像头支持的PreViewSize 和PictureSize ？
4）手机预览所见的区域SurfaceView(TextureView)与camera 的previewSize的关系是什么？
5）为什么会设计了两种预览方式view，两种预览方式都会有什么样子的效果呢？
一，概述
通过Android Camera拍摄预览中设置setPreviewCallback实现onPreviewFrame接口，实时截取每一帧视频流数据（简单说来，就是通过设置一个接口，接收系统回调通知我们的每一帧数据）
二，知识点
1， camera支持的格式：
2，拍照流程
3，camera权限
三，Android Camera中PreviewSize、 PictureSize、 SurfaceView(TextureView)之间的关系
1，PreviewSize：
相机预览时候的能支持的尺寸，简单的说一下，就是预览的大小，也就是拍照前能够看到的图片大小。（通过Android手机相机可以试一下，这个参数设置不同，同样的焦距下，拍摄桌子上一个固定距离的东西，看到的视野会不同）
相机的预览尺寸，不能随意的设置值，只能通过camera的parameters的getSupportedPreviewSizes方法，获取支持的预览尺寸列表，并从列表中选择一个设置在parameters中。（通俗简单的说就是，获取camera中能够支持的预览大小合集，如果你想要查看某个预览对应的尺寸，就把该尺寸设置到camera的属性中即可，则camera会返回相对应尺寸的预览数据流提供显示）。
2，PictureSize :
指的是拍照之后，最终拍摄到的图片大小，也就是图片的质量。图片尺寸同样也只能从支持的列表中选取一个设置。 调用camera的takePicture方法（拍照）后，获得拍照的图像数据，注意picturesize和previewsize的宽高比也要保证一致，否则获取的图片会将preview时的图像裁剪成picturesize的比例。 previewsize的分辨率，只会影响预览时的分辨率，不会影响获取图片的分辨率，所以preview只是确定了图像的取景最大范围。最终图片的分辨率是由picturesize来决定。 所以，最好的设置方法，例如：previewsize为1280*720，picturesize为2560*1440。（由于我们没有拍照业务，目前这个知识，不做深究）
3，SurfaceView(TextureView)
用于展示camera预览图像的view，就是将preview获得的数据，放在这个view上。所以如果preview的宽高比和SurfaceView的宽高比不一样，就会导致看到的图像拉伸变形。图像拉伸变形解决的办法：
（1）就是在确定preview的分辨率后，重新设置SurfaceView宽高；
（2）如果SurfaceView宽高定死，则需要获取一个比例适合SurfaceView尺寸的PreviewSize 的preview，尽量小的裁剪，然后填充在SurfaceView中。
4，利用图片的显示方式，理解Preview与SurfaceView（TextureView）显示关系
ImageView （UI上面设计的一个控件）与图片bitmap 的关系，比如限定死一个ImageView的大小，但是图片与ImageView尺寸不一致，就会有几种方案，首先选取一张长方形1920*1080的图片，ImageView就是紫色部分，无论长宽比都比ImageView要大。
图片适配例1：拉伸填充ScaleType.FIT_XY :虽然被全部填充，但是整个图片为了适配图片已经扭曲，失真，图片缩放到控件大小，完全填充控件大小展示。
图片适配例2：等比例裁剪填充ScaleType.CENTER_CROP ，因为在该模式下，图片会被等比缩放直到完全填充整个ImageView，并居中显示。该模式也是最常用的模式了。如图可以看到，图片的高度是能完全展示出来的，但是左右部分被进行了裁剪，并没有完全显示。
图片适配例3 : ScaleType.CENTER_INSIDE，此模式，用以完全展示图片内容为目的。图片将被等比缩放到能够完整展示在ImageView中并居中，如果图片大小，小于控件尺寸，那么就直接居中展示该图片
图片适配ImageView方式还有很多，就不一一列举，这三种已经足够重要，为什么讲解camera预览，却穿插了图片的适配，其实可以这么理解，camera的preview就是由多张图片组成，不断的像帧动画一样变化，而SurfaceView就是一个载体，相当于ImageView，业务中定死了SurfaceView的大小之后，被动的承载你选择的previewSize，来展示camera的Preview，你可以选择类似于前面三种例子来理解preview的填充，以下会举例说明preview的填充策略选择有哪几种方式，我们会采用哪种方式：
1）拉伸填充，自适应view，不可取，比如：手机的SurfaceView是整个手机的屏幕尺寸（全屏填充），或者任意尺寸比例的surfaceView，使用这种方式，就如同（图片适配例1）的方式，导致视频扭曲，拉伸。
2）等比例裁剪填充，目前我们项目中，采用的就是这种方式，并且提供给很多三方使用，已经成为一种独立，并且稳定的技术实现自定义view，简单说一下视频的适配策略方式，SurfaceView随便由业务方，自定义宽度大小，比如业务方选择了1900*1000的SurfaceView， 我们的适配过程是：（1）从PreviewSize列表中选取最接近SurfaceView尺寸的PreviewSize（假设该摄像头，只支持1920*1080，和320*640），1920*1080最接近，所以被获取；(此处展示一下蹩脚的英文Try to find an size match aspect ratio and size,尝试找到纵横比与view大小比适中的一个尺寸)（2）等比例裁剪填充到SurfaceView，首先我们设计的逻辑是，先选取一个缩放比例，假设等比例1920的图片按照SurfaceView的宽度等比例缩小到1900，而为了不让Preview失真，则高度1080等比例缩小的值是1068.75（等比例方程式，这里就不重复初中的知识，请自行计算），所以图片被压缩成为1900*1068这个尺寸，依旧保证图片完整，并且不失真。（3）将等比例缩减的图片，1900*1068进行显示在1900*1000的SurfaceView中，就会有一种效果类似（图片适配例2），宽度全部展示，高度被裁剪。（如同 图片适配例2中左右部分裁剪一样的道理）
3）完全展示camera内容的缩放填充（类似图片适配例3），我们打开任意一部手机的camera，预览图像都没有全屏幕展示，类似拍照功能，所见即所得，PreviewSize是多少，就显示什么样子的比例尺寸，以及最后生产的照片比例就是多少，我们的自定义view，也可以随意设置大小，此模式下，用以完全展示camera内容为目的。Preview将被等比缩放到能够完整展示在SurfaceView中并居中，但是可能会有部分位置无法填充（类似图片适配例3显示效果）。
（该方式只是进行了技术储备，由于没有业务场景设计，所以没有使用，目前只是储备了这样的自定义控件）
四，灵活的自定义TextureView预览控件
FsCameraTextureView（第一版，自适应截取）：等比例裁剪填充，方式（适配方式2），采用前面说的适配方式2，而产出的一种自定义view，2019年5月产出至今，在金融APP，以及商城的app中使用，经过逐步优化，和多版本检验，目前该控件，拥有以下特点： 1）稳定：目前各个使用场景，均无逻辑崩溃，内存泄漏，线程等任意问题； 2）灵活：随意设置预览view的尺寸大小，自适应任意业务设计；不仅仅满足刷脸业务，并且满足任意相机预览业务方使用； 3）提高效率，减轻工作量：使用简单，操作步骤简洁，接入只需要两步；减轻接入端，或者想要使用相机预览的业务的工作量，不需要重复造车，并且安全稳定。
输出的业务方有（经不完全统计）：（目前业务为保密进行公网保密处理）1）**创新科技业务部-区块链部门 2）泰国人脸识别业务SDK3）S D**Bank 人脸业务4）核验身份证业务5）HT**Bank 人脸业务 6）**云，商业平台部门
FsAllPreviewCameraTextureView（技术储备版，全预览模式显示）：完全展示camera内容的缩放填充，采用前面说的（适配方式3）适合拍照相关的业务使用，优点同样是，外部业务随意改变view大小，可以自适应view，由于目前没有业务方使用，暂时做储备，不深入讲解。
如果可以控件开源成功，后期，我将开源这两个控件，让更多的使用方使用，我们也希望共同技术进步，提高工程产出的使用能力。
预计下一次分享内容是（临时命名）
1）人脸核验内存和线程爆表到泄漏为零
2）分享七年前参于的Scrum（如何提高岗位间效率所定制的敏捷开发过程）
本文参考：
1、使用FFMpeg进行视频采集，使用Live555进行RTP传输，使用VideoView进行播放。
csdn提到：重载FrameSource，写一个服务类，可以从FrameSource的派生类读取帧数据，转发给live555.
评价：本方案大型访问量大的不行，少量连接比如100以内的可以。
2、用gstreamer完成采集、编码、组播。客户端使用VideoView进行播放。
评价：本方案优点为可以实现大访问量。缺点是基本从底层架构，代码量比较大。
3、使用FFmpeg进行视频采集，使用ffserver进行视频转发，客户端使用VideoView播放。
评价：优点是实现简单、容易演示，缺点是实时性不好以及用户量大不行。
