面试总结1
我是从来都不做面试总结的人，希望能就这些问题和大叫交流下～
这次面试问的都是和简历相关的知识，还有就是其他的一些，在此做下记录。
题目一：在你们项目中，弱网环境下的网络如何适配，缓存策略是什么？
缓存策略
其实在我的项目中，因为数据需求量比较小，我们在全局界面使用了一个名为UserInfo的一张表来存储当前App需要使用的模版数据，这个工作在每次登陆的时候会更新，每次在从后台切入前台的时候也会校验，在必要的网络请求中也会带上一个Version的东西进行校验。
也就是说我会在我的用户登陆的时候我就拿到接近15个左右的模版数据，我的界面逻辑（因为用户不同，界面是不同的）几乎全部包含在内。设计的字段包含有:见注1
这样做本质上是一个优化策略，而不是用来应对弱网环境。其实这个答案已经很接近缓存策略的正确答案了，我们拆分出来看，这个本质上包含了3个东西:
- 本地数据缓存映射表以及过期时间（客户端写死）
- 本地要缓存的数据及Version
- 服务器数据
借鉴我之前看过的一篇文章，主要内容我在这里做下搬运： - 使用ETag来代替Version，一般使用Hash算法来生成，这种方式是模仿Git对文件的缓存机制。
- 新增If_none_match字段，和ErrorCode=304字段来判断数据是否与服务端一致。
- 新增响应头CC(Cache-Contorl), 来控制具体的缓存机制
| CC中的响应头 | 响应头描述 |
|---|---|
| max_age | 最大过期时间 |
| pubilc/private | 是否允许中间服务器（例如:CDN）来保存缓存信息 |
| no_cache | 客户端使用缓存数据的时候必须与服务器进行确认后才可以使用 |
| no_store | 客户端必须从服务器获取新的数据 |
使用了这种方式，就可以不用每次发版都更新客户端的缓存策略了，只需要在客户端维护一个缓存映射表，将缓存数据和映射数据当作字段传入，做网络请求的时候读取就好了～
提高数据传输速度
之前我哥们给我讲，弱网优化上可以使用UDP协议+减少握手次数，从而减小时间上的开销，回去翻了下书，UDP虽然比TCP速度更加快速，但是总体省略掉的是数据正确性和数据顺序，UDP比TCP省略的是TCP中各种校验位，而我们所说弱网不单单是网络速度慢，而是网络不稳定，导致丢包率\时延比较大，相比于使用UDP协议我更倾向于使用更加安全的TCP协议。
UDP应用场景： 1.面向数据报方式 2.网络数据大多为短消息 3.拥有大量Client 4.对数据安全性无特殊要求5.网络负担非常重，但对响应速度要求高
解释
也就是本地维护一个映射文件，当然这个文件要满足以下几个条件：
文件要从服务器上分发。
这个配置表要在本地可配置。
要有默认的配置，一般是全网都可以访问的服务器。
减少时延，和丢包
DNS
- 多服务器筛选：在启动App之后，启一个后台进程，来扫描你们公司所有服务器域名的链接速度，和丢包率，优先选择服务器。在本地端口做适配。
- IP：使用IP地址而不是使用域名，（其实客户端本身就存在DNS_cache机制，也有自己的过期策略，iOS端一般是24h/飞行模式/开关机/重置网络），在做多服务器筛选表的时候我们可以顺带把这部分的东西一起做出来。
界面和服务端
监控优化
- Web页：在开发者模式下找到加载/运行缓慢的点，然后优化。
- Image：使用缓存，并根据网络判定请求图片大小，在经过源哥指点下，这里还可以使用Web格式的Image来对Image进行压缩，感谢
- Data： 缓存json，使用游标来确定当前缓存的画像-数据时效性要求差。
- Text&Image: 优先加载Text数据，Image数据延后加载
- Servers：使用慢查询监控，并建立索引表。
容忍度
- 提示框：不从0开始，而是从50%开始。
- 显示预计时间= 实际预计时间/2
预加载
在WebView中我们可以使用本地Html，css，js文件来预加载。
本地User_App界面数据采用数据预加载的方式。
User_info数据采用在登陆时候预先加载的方法是来做。
补充
其实我还看到很多优化的方式，欢迎评论补充
- 如使用base64预先压缩数据（虽然压缩比能达到34%，但是一般在大数据上才做压缩，小数据）。
- 如使用XML可以变解析边下载。但是我觉得有些靠谱，有些因为过于消耗性能，有些因为需要代码的统一，被我pass。
附录
注1
[user:（id, name, token, version, sig, update, next_update）] SQL如下
[viewData:(hash_token, view_id, view_data, version)]
create table
if not exists User (
id int primary key AUTO_INCREMENT,
name varchar(16)
token int,
version int,
sig int,
update int,
next_update int
);
注2:
2.png
1.png
题目二： 2万条数据的通讯录，你是如何存储和展示的！
其实对于10万条以内的数据我认为都没必要对原生做大的修改，然后面试官又说还要显示图片什么的。。What？？加图片？加图片干嘛？。。算了..考虑到我还是个初学者..在这里老老实实分析需求就好了。。。
首先先简单分析问题！
- 数据可能是没有上限的。需要考虑超级少人使用，和超级多人使用的不同需求
- 因为涉及到图片，可能需要设计下载，缓存，渲染等
- 因为数据量庞大，是否使用数据库，建立一个什么样的表
- 因为表格本身就涉及动画的，更涉及到图片，可能还会有图片渲染的一些问题等～
- 可能涉及到🔍，就是快速比较～
进一步细化问题
- 图片
下载到哪里？Cache，FileSystem
预处理？时机
预处理的图片是否缓存。 - 动画
使用什么方式加载Image：
（1）CGContextWithoutAlpha,
（2）CGContextWithAlpha,
（3）ImageIO,
（4）UIGraphic
是否在滑动时候阻断动画/使用更低质量的图？
是否在渲染的时候使用动画？ - 存储
存储方式SQL？UserDefault？FailSystem？
都存储什么？UserInfo？UserPhoto？ - 缓存
在加载/移出图片的时候是否使用缓存？ - 界面差异化
是否对500人以上的大客户使用其他的界面代替掉当前的界面？
是否对500人以上的大客户使用不同的解决方案/迁移方案？
是否对500人以上的大客户使用数据备份方案？容错方案 - 查找
查找方式？（1）SQL（2）内存
逐一解答上面的问题
图片
- 下载到哪里？Cache，FileSystem
首先在这里可以考虑使用FileSystem而不是Cache，因为这里的数据要保证用户数据安全，而不是使用一次就扔掉，应该对数据在下载的时候进行保存，并留有副本～ - 预处理？时机、做什么
（1）在数据下载之后直接进行预处理。
（2）对图片进行格式调整、去除透明通道、圆角调整，分辨率调整，小图单独存储 - 预处理的图片是否缓存。
只分文件夹存储，不缓存。
动画
- 使用什么方式加载Image：
（1）CGContextWithoutAlpha,
（2）CGContextWithAlpha,
（3）ImageIO,
（4）UIGraphic
SDWebImage使用的CGContextWithoutAlpha，和CGContextWithAlpha，这两种加载方式在在性能上由于UIGraphic，在单线程中ImageIO（370）却优于CGContextWithAlpha（550），可见苹果在ImageIO上确实是下了大功夫的，但在多线程中CGContextWithAlpha（420）表现优于ImageIO（730），由此可见在使用ImageIO可以能发挥更高的性能。（而且使用单线程就好了～）
- 是否在滑动时候阻断动画/使用更低质量的图？
在快速滑动的时候我建议是停止Image的绘制的，在ScrollView的回调方法中可以做到
在慢速滑动的时候还是使用更加低质量的图片会让帧数有更好的表现。 - 是否在渲染的时候使用动画？
建议使用延迟加载的额方式，而不是当时加载～这个主要看需求～
存储
存储方式SQL？UserDefault？FailSystem？
照顾到可能需要查找，应该使用SQL，SQL在iOS上支持的还是很好的。如果使用SQL就逃脱不了表的使用，这里要着重说一下，面试官问我是否每一个索引都要建一张表？（索引为a的表、b的表……）Why?完全不理解为什么这么做..理由呢？速度快么？维护简单？代码简洁？凸显自己设计牛逼？感觉并不会啊..考虑到我还是个初学者这里需要大神指点！
都存储什么？UserInfo？UserPhoto？
是的都需要而且是分别存储～
缓存
在加载/移出图片的时候是否使用缓存？
不使用缓存～
界面差异化
- 是否对500人以上的大客户使用其他的界面代替掉当前的界面？
界面差异化其实是可以考虑的，因为在小规模数据上，Photo在查找人员上会很方便，但是在200人以上的时候就会大大不便了，应该更注重搜索和索引～这才是对用户更大的帮助 - 是否对500人以上的大客户使用不同的解决方案/迁移方案？
可以考虑使用不同的解决方案，数据迁移方案应该是统一的～ - 是否对500人以上的大客户使用数据备份方案？容错方案
应该强制让500人以上用户打开通讯录备份功能，导出功能应该提供导出到通讯录，但是不应该提供其他的导出功能，毕竟考虑到用户的隐私问题，我们应该尽可能把数据留在安全的地方！
我建议把容错改成容灾方案，在服务器保存一张更复杂的表格来加密存储用户数据！使用hash算法来做数据进行校验位！当然这些都是在服务器中的！～
查找
查找方式？（1）SQL（2）内存
SQL速度更慢，但是计算性能消耗并不多～
内存速度快，实现难度大，计算性能消耗大仁者见仁吧～请各位大神指正～
后记 安全性
在考虑到这里的时候我就在想，我们的数据安全性谁来保证，我们存在iPhone上的数据如果是被越狱的手机，那样其他的流氓软件不是可以很轻易的获取我们联系人数据了么，如果上面有身份证号码，这简直不敢想象。吓得我都炸毛了～
考虑到我是一个新手，随便使用一个我们公司的通用密钥算出publicKey，采用非对称算法加密吧～反正注意到的人又不多。。
网友评论