随着网络技术的发展，各种各样的音视频产品应接不暇，应用场景也越来越多样，使人们的生活更加丰富多彩。与此同时，人们对音频的质量也有越来越高的要求，而如何准确评估音频质量好坏成为了相关行业的研究热点。音频质量评估方法主要分为主观和客观两类。主观方法是通过人根据听觉感受来打分。客观的方法是通过算法来计算评估的，主要分为有参考和无参考两种。有参考的方法在评估音频时需要一个对应的高质量无损音频作为参考，代表算法如PESQ（Perceptual evaluation of speech quality）；而无参考的方法直接对音频进行打分，代表算法如P.563。

目前大多数客观的音频质量评估方法属于无参考这一类，这类方法往往更准确。而在现实生活中，人类在没有参考的情况下能直接分辨出音频质量的好坏，这意味着存在一种评价机制来直接对音频质量进行评估而不需要参考。设想一下，如果我们通过神经网络模型来训练学习这种机制，那么这个模型不就能准确评估任何语音的质量吗？基于这样的思路，我们探索和实践了基于LSTM深度学习模型的音频质量检测方案。

在开发过程中，我们经常会遇到需要显示或隐藏View视图的情况，如果在隐藏或显示View的过程中加上动画，能让交互更加的友好和动感，本文将介绍如何使用圆形揭露动画巧妙地隐藏或显示View。

本文主要介绍前端项目进行服务端渲染的开发和原理，以及如何解决开发期间性能问题的通用解决方案。

在很多应用中，我们经常会看到多个页面之间滑动切换的场景，ViewPager2是ViewPager的升级版，本文将简要介绍如何使用ViewPager2、FragmentStateAdapter和Fragment来实现页面之间的滑动切换。

近期的⾃动化测试项⽬中有个关于测试内部IM通信软件的需求，在了解到各个客户端的相应技术栈实现以后，在mac中的应⽤使⽤的是electron 技术，我们也对相应的技术进⾏调研，此⽂记录⼀下在关于electron应⽤的⾃动化测试。

业务场景为，在摄像机的播放画面上，按下手指左右上下滑动，摄像机跟随滑动。

由于播放页面使用了photo_view提供了画面图片的放大缩小和拖拽功能，导致和嵌套的要实现监听滑动的GestureDetector存在冲突的问题。

最终实现的解决方案为，在photo_view默认状态下，让GestureDetector接收手指滑动事件，摄像机跟随旋转；在photo_view放大状态下，GestureDetector不接收事件，让photo_view处理放大图片的拖拽。比较好的解决了用户的使用场景问题。

在开发中，我们经常需要自定义View去实现各种各样的效果，在这个过程中经常需要用到Canvas画布去绘制各种各样的图形和图案，因此，熟练地掌握Canvas的各种使用方法，就显得尤为重要。本文将简要介绍Canvas的各种用法，加深大家的理解。

属性动画作为Android动画功能的一个重要组成部分，可以实现很多有趣的动画效果，理解属性动画的执行过程有助于我们更好地使用属性动画去实现需求。本文将从源码的角度去探索属性动画的实现过程，加深大家对其的认知和理解。

在做IOS预审的时候，为了检测私有API, 搭建了IOS私有库，当时搭建私有库的版本是13.5版本的，对于现在来说，已经算是比较旧的版本了，在准备更新私有库的时候，才发现，竟然没有最新版本的 Runtime Headers, 也就是15.0 版本的头文件信息，只找到了14.7版本的，好纠结。

在比对了Xcode 和 SDK 版本后，尴尬的发现，竟然找不到14.7版本，纠结许久，还是准备自己提取这些信息，主要有两方面的考虑：

1. Xcode 版本，系统版本指定的版本不好找，但是最新的版本是最容易寻找的，只需要全部升级到最新版本即可。
2. API Headers 的提取也没有尝试过，正好也尝试下，也为了能实时拿到最新的API 信息。

用过MySQL的同学肯定都知道表联接，关键字即为 join ，使用的场景就是“当只查询一个表的信息不能满足我们需求”的时候，就需要用到两个甚至多个表联接查询。那么该如何降低查询成本呢？

笔者做了多年的业务开发，以前对逆向知之甚少，好像我们做iOS的开发者对应用本身的安全问题总不是那么上心，总以为Apple自身的加密签名机制足够安全了，我们除了关心业务网络安全，对自身App包的安全重视度总是不够。然而一旦我们的包被有心人破解，那么无论是对自身业务还是用户数据都是致命的。真正开始研究逆向，才发现我们App是如此的不堪一击。所以研究逆向其实是研究Hacker是如何攻破我们的应用，从而更好地保护自身应用安全。

研究逆向，首当其冲的就是重签名，重签名就是用自己的证书签名别人的应用，从而进行分发。重签名说白了就是套壳别人的应用，挺火的微信双开，其实就是对微信进行了重签名。而重签名首先要做的就是对应用砸壳。

iOS内购是指苹果 App Store 的应用内购买，即In-App Purchase，简称IAP（以下本文关于内购都简称为IAP），是苹果为 App 内购买虚拟商品或服务提供的一套交易系统。为什么我们需要掌握IAP这套流程呢，因为App Store审核指南规定：

如果您想要在 app 内解锁特性或功能 (解锁方式有：订阅、游戏内货币、游戏关卡、优质内容的访问 限或解锁完整版等)，则必须使用 App 内购买项目。App 不得使用自身机制来解锁内容或功能， 如许可证密钥、增强现实标记、二维码等。App 及其元数据不得包含按钮、外部链接或其他行动号 召用语，以指引用户使用非 App 内购买项目机制进行购买。

这段话的大概意思就是APP内的虚拟商品或服务，必须使用 IAP 进行购买支付，不允许使用支付宝、微信支付等其它第三方支付方式（包括Apple Pay），也不允许以任何方式（包括跳出App、提示文案等）引导用户通过应用外部渠道购买。如果违反此规定，apple审核人员不会让你的APP上架！！！

随着云计算与网络技术的不断发展，公司内越来越多的业务有着上云的需求。我们底层虚拟化团队基于社区openstack版本提供云服务，借助社区的力量能够快速实现一套满足基本功能的云平台。但原生neutron（openstack网络组件）在公司内场景下使用时网络方面会暴露出一些缺陷：比如计算节点规模达到数百上千台时，控制层面性能会比较差；比如DVR模式下使用浮动ip，每台计算节点会额外占用一个浮动ip资源；比如南北向流量高可用性也做的不好，网络节点的宕机可能会引发全网snat、port forwarding流量的断流，虽然可以部署多台网络节点+VRRP的方式实现高可用，但不能实现流量的快速切换，且会加重网络节点的负担；比如公司的IDC物理网络结构是三层网络（可以理解成网关都在接入交换机上，网络的广播域被终结在接入交换机，这种做法可以避免IDC内大面积的广播风暴出现），但neutron的external网络是二层网络，这样就不能实现虚拟机跨交换机迁移，限制了集群规模；比如服务器与交换机紧耦合，一方出故障就可能会造成集群大面积断网，也增加了运维难度等等。

我们为了解决这些问题，提供一个稳定高效的可商用云网络服务，需要在原生neutron的基础上重新设计云平台架构，最终我们采用虚拟化网络+云网关的形式来设计我们的组网架构，下面我们具体看一下。

系统开发过程中涉及到任务执行超时的问题，大家都知道一旦任务执行超时，任务状态没法自动更新，任务状态没有更新用户就会一直等结果，这样既没法继续重复执行超时任务用户体验也不好，因此需要解决下超时任务的问题。

本文为翻译文，从浏览器不同处理阶段详细解释了WebAssembly 能够快速执行的原因。

使用 React 开发插件解决了事件和数据绑定的问题，Chimee 的插件系统可扩展性比较强，如果对其比较感兴趣的可以看看官方的这篇《为什么要将 Chimee 设计成一个组件化框架？》。