SDK API 结构变更

SDK API 结构进行了重组。IOS变更不大，主要是因为IOS不存在代码共享的问题。
android API集中在com.intercom这个包名下，其中common下为常用类，只用在java中，与底层没有关系，比如 BundleToJSON,JINIParser等
service目录下的代码是对底层接口的封装，这些类又在所有工程中都会使用到，为了代码管理的便利，都归纳到service目录下。不同的项目在这个目录下的代码完全一致，主要包含：
设备连接，设备信息获取，http 接口，MCU控制器，媒体格式转换，访客录制，远程服务等
来自于chromium中的代码都放在org.chromium 和 org.webrtc.voiceengine两个包下。这些代码分别来自于chromium 和 webrtc的某个版本，除了略有扩展，本质上没有任何修改。

回调事件变更

底层回调事件的变更略大，其中包含：
onAppListener：这些响应底层的全局事件，也就是与家庭无关的事件，比如app初始化结果，音频设备和视频设备的占用状态，摄像头的错误，预览视频的尺寸变更，激活状态，以及创建家庭的状态。
其中： onIntercomAppHangup() 方法需要在平板端响应。一旦出现这个事件，表明底层需要上层重启APP，否则系统无法继续工作。
onCaptureDimensionChanged()，此方法表明预览画面大小变更，此刻需要重新设置预览的surface

OnProxyListener：代理事件回调
其中新增的有：
onIntercomProxyFamilyMessageArrival：来自此家庭中其他设备发送的自定义消息。 消息结构使用intercommessage包装，位于content字段中。
onIntercomProxyMessageSendFailed：消息发送失败，可以不管
onIntercomExtendedMessageArrival：扩展消息，一般而言，是管理平台发送的消息。当然，终端也可以给管理平台发送消息。

OnIntercomListener：门禁事件，这些都与某个家庭相关。 其中： onIntercomStreamDTMFArrival(IntercomManager.Intercom intercom,String session_id,int protocol,int dtmf)：表明收到DTMF事件，室外机尤其需要注意，这里是远端发送的开门指令，一般来说。protocol：表明DTMF发送的协议，可以有两种，都是经过RTP协议发送的，但是可以是带外或者带内。当然上层可以不关心。
onSipDTMFReady： 这里处理的也是DTMF事件，只不过是通过SIP协议发送的。同样的可以开门。

方法的变更

app级别的初始化：
globalInitialize，这个在android上一定要在app起来的就是调用。参考demo。
IntercomManager.init(String prot_conf)，这个在app起来的时候调用，此刻底层的工作线程就可以启动。 在app运行过程中无需再次调用，也就是说，工作线程无需销毁。
IntercomManager.start()和stop()，这个成对调用，可以启动门禁和卸载门禁，但工作线程依然运行。 如果中途切换账号，可以先stop，再次start即可。
swtichCamera：可以再任何时候切换摄像头。但只有再摄像头工作的时候才会马上生效，否则就是下次启动摄像头生效。
sendPushMessage：这个可以将云端推送的消息送到底层解析。(纯云方案不通过此接口，而是调用Intercom.SendIntercomMessage，直接将云端收到的推送消息打包成IntercomMessage送到底层）
Intercom对象增加： sendFamilyMessage，可以给其他家庭设备发送消息。再上述的callback中收到。

IntercomSessionManager接口变更：
sendDTMF：这个再纯云方案的时候可能要用到，可以直接开室外机的门。
enableVideo，这个没有变更。
enableMicrophone：这个表明在当前会话中，将microphone静音，实际上是用静音数据传给对方，对方将听不到本机的声音。
enableSpeaker：在当前会话中，将对方的声音静音。
setupAutoAnswer：这个在3.0中存在，设置自动回复的语音。语音文件需要事先保存在sdcard指定位置，格式为8000，单声道的非压缩音频。

配置的变更

media_dir：更换到media_conf结构中，原先的IntercomConfig改成media_conf.
静态图片由原先上层提供二进制图像数据改成文件。video_mask_filename属性进行设置。 IOS使用绝对路径。
android可以使用绝对路径，也可以放在 /assets/目录下。可以直接指定 /assets/xxx.jpg即可。

图像采集和编码的变更

图像采集去掉了竖屏等属性。指定采集的宽高，那么预览就获得这个宽高，不再做任何处理。当然，在竖屏的时候会旋转，以便看到的是正像。
比如，要求摄像头按照640X480采集，那么在竖屏尤其是手机端，预览得到的图像分辨率是480640.
编码尺寸： 编码给对方的图像分辨率可以等同于上述摄像头的分辨率，也可以不同。 尤其是室外机，一般输出640480，底层会按照要求进行处理。
对于移动端，如果想按照当前视频分辨率传输，那么在VideoCodecConfig中将 video_encode_codec_width,video_encode_codec_height都设置为0.
底层将按照摄像头的分辨率进行编码。如果摄像头旋转，编码器将重置，并按照新的分辨率进行编码。对方看到的视频也是改变了分辨率。 如同其他可视聊天软件呈现。

MediaConfig.audio_layer:选择音频引擎。这个以前就存在，这里重新定义下。

纯云方案的支持

intercomtype=1，表明为纯云方案。 此刻startproxy需要提供一些不同的参数。最重要的是管理平台的url地址。
底层会仿真一个云端代理，并根据上述url向管理平台请求设备配置清单（这个有具体的json格式）。然后底层会在proxylistener中报告代理上线。
此刻上层可以看到该房间应该看到的设备清单，可以进行呼叫。
纯云方案中，室外机的呼叫是通过推送消息到达指定的移动端。这个可以自行定义，不要和以前的格式一样。应该使用易于解析的格式，类似全时通云端的推送。
移动端收到推送消息，并按照IntercomMessage格式组装一个 callout命令发送给底层进行呼叫。其他的都是一样的。

4.0不再支持的功能

1.ONVIF 摄像头不再支持。 2.http server不再支持。

底层变更

1.减少了70%的线程。进一步减低CPU负载。
2.使用较新的chromium基础代码。
3.对户户通自定义消息的完善支持
4.原先的ext设备自定义消息机制还存在。不过不建议使用。请使用 sendFamilyMessage。 5.MediaConverter。将访客录像转换成MP4是，只保存混音音轨。另外，IOS转换出来无法看到视频，这个问题以后再看。不要暴露此接口给第三方客户。