将手机系统更新到iOS14，发现一个问题，几乎所有APP在打开时都会访问剪贴板效果就是这样，比方说在「微信」中复制了一段内容，然后打开「微信读书」，iOS14会在手机顶部弹窗提示「微信读书粘贴自微信」提示好不好呢？那肯定很好，让用户知道正在使用的APP访问了自己的剪贴板数据，至于APP会拿着这个数据去干啥，用户就不知道了不是有那种嘛，比方说在微信中给好友发一个tao口令啥的，好友复制后打开tb，就是打开指定的页面，这算是APP访问剪贴板的一个作用吧但是其他时候APP访问剪贴板会做些什么呢？咱们就不知道了。所以像密码什么的，尽量还是不要复制到剪贴板而且我发现的还只是刚打开APP的时候，如果后台还在继续操作呢？之前当升降式摄像头手机出来的时候，不是就爆出了某些APP擅自调用摄像头嘛！嗯，它只是想瞄你一眼！想想还是挺可怕的，某些APP会静默调用摄像头，麦克风等等iOS14还有个好处就是，当APP调用摄像头时右上角会显示一个小绿点，当APP调用手机的麦克风时右上角会显示一个小橙点算是提醒用户，此时有APP在调用摄像头还是麦克风，用户就会确认到底是不是自己正在使用，如果不是，那么就需要赶紧检查下自己已下载的APP是否有在干坏事儿了事关你自己的隐私，可必须得重视啊！

	

前不久vivo发布了NEX手机，这款手机原本是一款极具科技色彩的产品，而且凭借独特的设计成为旗舰手机当中最受关注的。但没想到的是，因为他的前置隐藏式摄像头设计引发了一系列对于安全的探讨。现在南京软件开发公司软件来和大家分享下
起初原因是有段子在网络上流传，因为使用隐藏式摄像头，在打开某些应用软件之后前置摄像头会偷偷跑出来“偷看”你一眼。后来QQ浏览器发布了一份声明，解释摄像头弹出的原因是源于程序问题而不是未经允许调用。尽管时间很快平息，但之后百度后台录音的事情又一次将探讨推向高潮。
原本智能手机摄像头的唤醒不需要弹出，所以普通用户很难察觉APP是否在当时调用了前置摄像头。用户隐私安全的问题再次成为热议焦点。那么APP真的可以在用户没有操作的时候随意调用这些传感器么？
据报道，马萨诸塞州东北大学的研究人员针对APP研究发现，实际上我们的安全问题可能更令人担忧。因为他们得出结论，APP一般来说是需要授权才能调用这些传感器的，但很多情况下，他们可以越过授权，直接给当前画面截图，并录制屏幕所作所为，偷偷发送到远端服务器。
相比录音或者调用前置摄像头这些方式，秘密截图并发送到远端服务器的形式似乎更加危险，因为我们的浏览记录，账户安全甚至是个人行为都会通过截图泄露。
该研究团队通过大量的应用程序测试发现，一部分应用程序会记录屏幕信息，并发送给移动分析商，当然大部分应用是不会有类似行为的，但不可避免用户的信息会泄露。
该研究发布后，涉事的移动分析上Appsee紧急发布声明，表示是APP违法了他们的影视保护条约导致的，随后涉事APP也修改了影视条款并移除了相关的SDK。
不过也有人看了他们的测试发现，这种分析方式只能分析出少量有截图行为的APP，还有很多更隐蔽的截屏不容易被发现，后续有很多优化空间。不过这一问题的出现也让我们对智能手机终端的隐私有了更深层次的担忧。作为普通消费者而言，我们只能通过更谨慎的使用行为来保证隐私和安全，但这并不是智能手机发明的初衷，更安全的环境还需要所有互联网企业、手机终端、以及系统供应商共同维护。

介绍
Fing是适用于Android和iOS的移动应用程序，可扫描并提供完整的网络信息，例如IP地址，MAC地址，设备供应商和ISP位置。 它使攻击者可以发现连接到Wi-Fi网络的所有设备及其IP和MAC地址，以及供应商/设备制造商的名称。 它还允许攻击者通过特定端口（例如，SSH，FTP，NetBIOS等）执行网络ping和traceroute活动。本文着重介绍非IT专业者如何利用Fing来查找新入住的酒店、民宿或者出租房内是否存在偷拍摄像头的方法。
FIng在App Store中的下载界面如下所示：


方法
首先，在手机接入酒店WI-FI的情况下打开Fing，界面如下所示（安卓用户或许界面细节略有差别）



在主界面首页顶部，可以看到当前所连接的Wi-Fi路由器的名字及其MAC地址，点击设备扫描（免费功能），几秒钟后，即可看到所有联入这一路由器的全部设备，如下图所示：



由于很多偷拍摄像头是通过联入酒店Wi-Fi进行实时数据传输的，因此，通过发现联入Wi-Fi的所有设备，可以帮助受害者发现可疑设备，进而初步判断是否存在偷拍摄像头。另外，在主界面中存在一个查找隐藏的摄像头功能（付费功能），该功能可以用于长期租客，帮助检测和发现新联入Wi-Fi网络的设备，并在有可疑设备联入时进行报警提示。
局限性
利用Fing来查找偷拍摄像头的方法具备以下局限性：

无法检测到自带NIC的偷拍摄像头
无法检测到使用存储卡的非实时偷拍摄像头
无法检测到联入临近Wi-Fi的摄像头

首先，有一些摄像头自带网卡（NIC），不需要经过路由器即可联网，这样的摄像头无法通过Fing进行检测；但由于此类摄像头价格更为高昂，因此并不常见。其次，有一些摄像头并不是通过网络进行实时数据传输，而是将偷拍的内容保存在设备的存储卡中，等待偷拍者来取走读取数据，这样的摄像头也是无法被检测到的；但此类摄像头在早期普遍存在，而在今天因为其不便利性，也逐渐变得少见了。第三种Fing无法检测的摄像头是联入临近Wi-Fi而不是本地Wi-Fi的摄像头（例如连接酒店隔壁房间的Wi-Fi），解决此类摄像头可以通过逐次将手机连接进可接收到的Wi-Fi重复上文所讲的扫描过程即可。

最近在做一功能不大、业务也不复杂的小众App，以往做App是发现自己从来没有考虑过一些架构方面的问题，只是按照自己以往的习惯去写代码，忽略了App的设计。本次分享主要包含一些开发App的小经验和技巧，来一次App开发与设计的分享。
先和分享下一下实体类的设计与组织形式
实体类的组织
在做App开发的时候有很多的实体类，项目越复杂实体类就会越多，经过我的一番思考大致这可以将实体分为以下几大数：
面向数据库的
服务端返回的数据实体
用于渲染View的实体(使用Databinding)
一般情况下实体类的操作会经过以下步骤：
App请求服务器获取数据
将数据存入数据库(可选)
渲染页面展示数据
现在的实体的产生只用在请求服务器数据的时候才需要新建，后续的数据库、页面渲染其实是可以使用一套实体：
先不说这样做的行不行，首先三个地方使用同一实体就会引起字段歧义比如服务器数据有Id、本地数据也有Id，那两个id字段就有冲突了不得不改字段名。
另一种情况渲染和数据本身并不会一一对应，有时候后端数据给的是一个纯数字而前端页面显示的是字符串两个都对应不上，强行放在一起会起来更多的问题。
所为实体类的的正确组织形式应该是：相互隔离、互不干扰：
数据实体的在渲染之前都需要准备好，比如在ViewModel中将int型的数据转换成文本型的数据然后再使用Databinding＋页面渲染实体来渲染页面。
优雅的处理网络数据
现在Android开发使用的网络库大部分都是Okhttp + Retrofit，使用Retrofit网络交互变的非常简单一个Service接口就能搞定一切，美兹兹~~，现在大部分后端返回的数据都会是以下形式：
{ "code":0, "data": {}, "msg": ""}
虽然不能涵盖所有，但还是可以非常赞的数据、消息、成功与否啥都有！对于前面主要是关注data字段，其他msg、code等都属于辅助字段。前端对应的实体对象应该是这样的(假代码)：
public class ApiResponse { private int code; private T data; private String msg;}
对应的Service那就得定义成这样(使用了RxJava)：
public intface UserService { @GET("/xx/{id}") Single getUserInfoById(@Path("id") Long userId);}
从接口中可以看出来，方法的返回值就包了几层，如果要拿data字段需要经过：ApiResponse -> UserInfo，而且在拿之前还要判断code字段：
...if(ApiResponse.code == 0){ UserInfo info = ApiResponse.getData();}...
为了消除这些冗余的代码可以使用CallAdapter来使Service方法返回的数据直接就是实体类：
public intface UserService { @GET("/xx/{id}") Single getUserInfoById(@Path("id") Long userId);}
CallAdapter的代码就不贴了，可以自行查找。这样做带来的另外一个问题就是业务代码如何判断接口是否成功或失败，前端必需友好的把错误提示给用户而不是一直搞个Loading在那里瞎转~~。现阶段最方便的的错误传递方式是使用**Java异常**，前端可以定义**业务异常**或**网络异常**：
public class BizException extends RuntimeException { ...}
在CallAdapter中检查ApiResponse的返回值是否成功：
if(!ApiResponse != 0){ throw new BizExcepiton(ApiResponse);}
如果后端返回业务异常那前端就对应抛出一个BizExcepiton，如果是http错误如：404、400那可以抛出HttpException。除了BizExcepiton和HttpException外还可使用特定的异常比如后端返回密码错误异常：
public class InvalidPasswordException extends BizException { ...}
如需特殊处理，也可以满足要求。
健壮的数据层
现在很多应用都开发使用MVVM开发模式数据层都使用Repository来表示，面向数据驱动的开发模式，页面变化都需要随着数据变更而更新，数据发生变化然后页面再做出响应。Repository的拆分要细一点，不建议简单的弄个UserRepository包含登陆、注册、更新密码等等操作，设计Repository的一些想法：
面向接口编程
保持单一原则
功能边界要清晰(如：登陆、注册可以分开)
业务逻辑尽可能的少(复杂的业务考虑Presenter)
一个判断是否是好的设计的办法可以这样：一个登陆页面从Activive/Fragment到ViewModel再到Repository，有没有多余的代码。比如上面说的UserRepository包含登陆、注册但是在一个登陆页面就不需要有注册功能，从登陆页面上来看注册的代码就是多余的(有些App登陆/注册在一个页面的~~)。
一个包含登陆、注册的UserRepository简单图：
另外一点是尽量将repository使用到的一些东西集中管理，可引入一个基础的repository：
public class SimpleRepository {  protected final  T getService(Class clz){ return Services.getService(clz); }}
做为SimpleRepository的子类，就不需要考虑从哪里获取service的问题。
简洁的UI层
UI层面可以分为ViewModel和View(Activity/Fragment)， View的职责应当只有二点：
展示业务数据
收集业务数据
例如一些数据的组织、判断都不应该出现在View中比如：
 if (Strings.isNullOrEmpty(phone)) { ... return; } if (Strings.isNullOrEmpty(pwd)) { ... return; }
像上面这类的代码都不应该出现在View中，而在放置在ViewModel里面，View只收集用户数据传递给ViewModel由它来进行数据校验。再比如像这样的if/else代码也应该放置在ViewModel中：
 int age = 10; String desc = ""; if(age < 18){ desc = "青年"; }else if(age < 29){ desc = "中年"; }
如果数据的显示和数据的收集过多，建议使用Databinding来进行双向绑定数据。再搭配LiveData使View作为观察者实时监听数据变化：
registerViewModel.getRegistryResult().observe(this, new SimpleObserver(this));
一旦数据发生变化LiveData就会通知Observer更新，通过DataBinding更新各个页面数据。
再说ViewModel应该只包含一些简单的判断、检查、打通数据的代码，如果业务过于复杂可以考虑加Presetner，如果真的超级复杂那可以反思下这个复杂的逻辑应不应该放在前端，能不能放在后端呢？
欢迎关注微信公众号《架构文摘》，高质量技术文章第一时间推送。