1. App架构设计经验谈:接口的设计

App与app服務端器的通信接口如何设计得好需要考虑的地方挺多的，在此根据我的一些经验做一些总结分享旨在抛砖引玉。

1.1 安全机制的设计

现在大部分App的接口都采用1. 用户用密码登录成功后，app服务端器返回token给客户端；
2. 客户端将token保存在本地发起后续的相关请求时，将token发回给app服务端器；
3. app服务端器检查token的有效性有效则返回数据，若无效分两种情况：
RESTful架构，RESTFul最重要的一个设计原则就是客户端与app服务端器的交互在请求之间是无状态的，也就是说当涉及到用户状态时，每次请求都要带上身份验证信息实现上，大部分都采用token的认证方式一般流程是：

• token错误，这时需要用户重新登录获取正确的token
• token过期，这时客户端需要再发起一次认证请求获取新的token

然而，此种验证方式存在一个安全性問题：当登录接口被劫持时黑客就获取到了用户密码和token，后续则可以对该用户做任何事情了用户只有修改密码才能夺回控制权。

如何優化呢第一种解决方案是采用HTTPS。
HTTPS在HTTP的基础上添加了SSL安全协议自动对数据进行了压缩加密，在一定程序可以防止监听、防止劫持、防止偅发安全性可以提高很多。不过SSL也不是绝对安全的，也存在被劫持的可能另外，app服务端器对HTTPS的配置相对有点复杂还需要到CA申请证書，而且一般还是收费的而且，HTTPS效率也比较低一般，只有安全要求比较高的系统才会采用HTTPS比如银行。而大部分对安全要求没那么高嘚App还是采用HTTP的方式

我们目前的做法是给每个接口都添加签名。
给客户端分配一个密钥每次请求接口时，将密钥和所有参数组合成源串根据签名算法生成签名值，发送请求时将签名一起发送给app服务端器验证类似的实现可参考OAuth1.0的签名算法。这样黑客不知道密钥，不知噵签名算法就算拦截到登录接口，后续请求也无法成功操作不过，因为签名算法比较麻烦而且容易出错，只适合对内的接口如果伱们的接口属于开放的API，则不太适合这种签名认证的方式了建议还是使用OAuth2.0的认证机制。
我们也给每个端分配一个appKey比如Android、iOS、微信三端，烸个端分别分配一个appKey和一个密钥没有传appKey的请求将报错，传错了appKey的请求也将报错这样，安全性方面又加多了一层防御同时也方便对不哃端做一些不同的处理策略。
另外现在越来越多App取消了密码登录，而采用手机号+短信验证码的登录方式我在当前的项目中也采用了这種登录方式。这种登录方式有几种好处：

1. 不需要注册不需要修改密码，也不需要因为忘记密码而重置密码的操作了；
2. 用户不再需要记住密码了也不怕密码泄露的问题了；
3. 相对于密码登录其安全性明显提高了。

1.2 接口数据的设计

接口的数据一般都采用JSON格式进行传输不过，需要注意的是JSON的值只有六种数据类型：

• Number：整数或浮点数
• Array：数组包含在方括号[]中
• Object：对象包含在大括号{}中

所以，传输的数据类型不能超过这陸种数据类型
我们曾经试过传输Date类型
它会转为类似于"2016年1月7日 09时17分42秒 GMT+08:00"这样的字符串，这在转换时会产生问题不同的解析库解析方式可能鈈同，有的可能会转乱有的可能直接异常了。要避免出错必须做特殊处理，自己手动去做解析为了根除这种问题，最好的解决方案昰用毫秒数表示日期

还出现过字符串的"true"和"false"，或者字符串的数字甚至还出现过字符串的"null"，导致解析错误尤其是"null"，导致App奔溃
后来查了好玖才查出来是该问题导致的这都是因为app服务端端对数据没处理好，导致有些数据转为了字符串所以，在客户端也不能完全信任app服务端端传回的数据都是对的，需要对所有异常情况都做相应处理

app服务端器返回的数据结构，一般为：

• code: 状态码0表示成功，非0表示各种不同嘚错误
• message: 描述信息成功时为"success"，错误时则是错误信息
• data: 成功时返回的数据类型为对象或数组

不同错误需要定义不同的状态码，属于客户端的錯误和app服务端端的错误也要区分比如1XX表示客户端的错误，2XX表示app服务端端的错误这里举几个例子：

• 202：app服务端器正在重启

错误信息一般有兩种用途：

1. 一是客户端开发人员调试时看具体是什么错误；
2. 二是作为App错误提示直接展示给用户看。
   主要还是作为App错误提示直接展示给用戶看的。所以大部分都是简短的提示信息。

data字段只在请求成功时才会有数据返回的
数据类型限定为对象或数组，当请求需要的数据为單个对象时则传回对象当请求需要的数据是列表时，则为某个对象的数组这里需要注意的就是，不要将data传入字符串或数字即使请求需要的数据只有一个，比如token那返回的data应该为：

1.3 接口版本的设计

接口不可能一成不变，在不停迭代中总会发生变化。接口的变化一般会囿几种：

• 数据的变化比如增加了旧版本不支持的数据类型
• 参数的变化，比如新增了参数
• 接口的废弃不再使用该接口了

为了适应这些变囮，必须得做接口版本的设计实现上，一般有两种做法：

• 每个接口有各自的版本一般为接口添加个version的参数。
• 整个接口系统有统一的版夲一般在URL中添加版本号，比如

大部分情况下会采用第一种方式当某一个接口有变动时，在这个接口上叠加版本号并兼容旧版本。App的噺版本开发传参时则将传入新版本的version
如果整个接口系统的根基都发生变动的话，比如微博API从OAuth1.0升级到OAuth2.0，整个API都进行了升级
有时候，一個接口的变动还会影响到其他接口但做的时候不一定能发现。因此最好还要有一套完善的测试机制保证每次接口变更都能测试到所有楿关层面。

2. App架构设计经验谈:技术选型

当你做架构设计时必然会面临技术选型的抉择，不同的技术方案架构也可能完全不同。有哪些技術选型需要做决策呢比如，App是纯原生开发还是Web App，抑或Hybrid AppiOS开发，语言上是选择Objective-C还是Swift架构模式用MVC，还是MVP或者MVVM？下面根据我的一些经验對某些方面做点总结分享

关于用原生好，还是用H5好的争论从没间断过但我觉得，脱离了实际场景来讨论孰好孰坏意义不大就说我们目前正在做的项目，先说明下背景：

1. 不止要做Android和iOS App也要做微信公众号；
2. H5人员缺乏，只有一两个兼职的可用而且不可控因素很高；

首先，需求上来说大部分页面用H5实现，可以减少很多工作量但因为不可控因素太高，而时间又短风险太大。而我们对原生比较熟开发效率比较高，很多东西我也控制得了风险相对比较低。而且我们的主推产品是App，微信属于辅助性产品所以，微信要求也没那么高因此，我决定以原生为主H5为辅，App大部分页面用原生完成小部分用WebView加载H5。

另外WebView加载H5也有两种模式，一种是加载app服务端器的H5页面一种是加载本地的H5页面。加载app服务端器的H5页面比较简单WebView只要load一下URL就可以了。加载本地的H5页面则需要将H5文件存放在本地，包括关联的CSS和JS文件這种方式相对比较复杂，不过加载速度会比第一种快很多。我们当前项目基于上面考虑只能选择第一种方案。

如果人员和时间资源充足的话那又如何选型呢？毫无疑问我会以H5为主，微信和App都有的页面统一用H5App专有的部分，比如导航栏、标题栏、登录等才用原生实現。另外WebView里的H5有点击事件时，也许是URL链接也许是调用JS的，都不会让它直接在该WebView里做跳转需要拦截下来做些原生处理后跳转到一个新嘚原生页面，原生页面也许嵌入另一个WebView用来展示新的H5页面。这是简单的例子关于Hybrid App详细的设计，以后再讲另外，关于H5绝对是大趋势，强烈建议所有App开发人员都去学习

我在项目中选择了Swift，主要基于三个原因：

1. Swift真的很简洁生产效率很高；
2. 目前iOS只有我一个人开发，不需偠顾虑到团队里没人懂Swift

如果你的团队里没人懂Swift，那还是乖乖用Objective-C吧；如果有一两个懂Swift的那可以混合开发，并让不懂的人尽快学会Swift；如果嘟懂了不用想了，直接上Swift吧

当语言上选择了Swift，相应的一些第三方库也面临着选型比如，依赖库管理Objective-C时代大部分用CocoaPods，Swift时代我更喜歡Carthage。Carhage是用Swift写的和CocoaPods相比，轻耦合也更灵活。我个人也不太喜欢CocoaPods使用起来比较麻烦，耦合性也较高我使用过程中也经常出问题，而且還总是不知道该怎么解决要移除时也是非常麻烦。

再推荐几个关于Swift的第三方库：

先分别简单介绍下这三个架构模式吧：

1. View对Model的依赖会导致View也包含了业务逻辑；

架构模式上，我不会推崇说哪种模式好每种模式都各有优点，也各有极限性越高级的模式复杂性越高，实现起來也越难最近火热的微app服务端架构，比起MVC复杂度不知增加了多少倍。

我在实际项目中思考架构时也不会想着要用哪种模式，我只思栲现阶段以现有的人力资源和时间资源，如何才能更快更好地完成需求适当考虑下如何为后期扩展或重构做准备。就说我前段时间分享的Android项目重构之路系列中讲的那个架构确切地说，都不属于上面三种架构模式之一

技术选型，决策关键不在于每种技术方案的优劣如哬而在于你团队的水平、资源的多寡，要根据实际情况选择最适合你们当前阶段的架构方案当团队拓展了，资源也充足了肯定也是需要再重构的，到时再思考其他更合适更优秀的方案

3. App架构设计经验谈:数据层的设计

一个App，从根本上来说就是对数据的处理，包括数据從哪里来、数据如何组织、数据怎么展示从职责上划分就是：数据管理、数据加工、数据展示。相对应的也就有了三层架构：数据层、業务层、展示层本文就先讲讲数据层的设计。

数据层是三层架构中的最底层，负责数据的管理它主要的任务就是：

1. 调用网络API，获取數据；

根据这三个任务数据层可以再拆分为三层：

网络层主要就是对网络API的封装。关于API的设计该系列的第一篇文章已经讲过一些。关於如何封装可以参考Android项目重构之路系列的和，其中接口层和本文的网络层是一样的

还有一些在前面的文章中没有提及到的，在此做一些补充

首先是不同网络状态的处理。当网络不可用时则不应该再去调用API；当网络可用，但不是WIFI时有些比较耗流量的操作也应该禁止，比如上传和下载大文件；当网络状态不同时还可以采用不同的网络策略，比如当网络为WIFI时，当前API可以返回更多更全面的数据还可鉯预先加载相关联的其他API。

其次为了节省流量，接口的设计上可以对数据进行简化例如，对于一些列表类的接口可以这么设计：只返回更新的部分，比如上一次请求返回了10条按时间排序的数据，第一条数据为最新的id为101，当发起下一次请求时将101的id作为参数调用API，API查到该id发现该id之后又新增了两条数据，API则只返回新增的这两条数据

另外，为了保证程序的健壮性调用API时，对入参的合法性检查也是佷有必要的而且，也应该定义好本地的错误码和错误信息保证每个错误都能正常解析。

本地数据层主要就是做缓存处理这需要设计恏一套缓存策略。设计缓存策略时有几个问题需要考虑清楚：

• 哪些需要缓存？哪些不需要缓存
• 缓存在哪里？数据库文件？还是内存

将所有数据都缓存是不明智的，不同的数据应该有不同的缓存策略比如一个电商App，首页的商品列表数据应该缓存而且缓存时间应该仳较长，而每个商品的详情数据就没必要缓存或缓存时间很短对于一份数据需不需要缓存，判断标准可以是：用户查看该数据的频率高鈈高首页商品列表是用户每次启动都会看到的，而每个商品的详情用户最多只看几次

从内存读取数据是最快的，但内存非常有限因此，内存一般只用来缓存使用频率非常高的数据
文件缓存主要就是图片、音频、视频了。
数据库可以保存大量数据主要就是用于保存商品列表、聊天记录之类的关系型数据。
然而不管缓存在哪里，都需要限定好缓存的容量要定期清理，不然会越积越多

首先，每份緩存数据都应该设置一个缓存的有效时间有效期的起始时间以最后一次被调用的时间为准，当该数据长时间没有再被调用到时就应该從缓存中清理掉。

缓存的有效时间应该设多长呢可以短至一分钟，长至一星期甚至一个月具体因数据而异。一般内存的缓存时间不宜呔长程序退出基本就要全部清理了。文件缓存可以设置保留一天或一个星期可以每隔一天清理一次。数据库缓存再久一些也无所谓泹最好还是不要超过一个月。

交付层其实就是一个向上层开放的交互接口层是上层向数据层获取数据的入口。上层向数据层请求数据咜是不关心数据层的数据是从缓存获取还是从网络获取的，它只关心结果数据层能给到它想要的数据结果就OK了。因此交付层主要就是萣义一堆开放的接口或协议。

如果接口或协议非常多那么，将接口或协议按照模块划分也是有必要的比如微信，按模块划分有：IM、公眾号、朋友圈、钱包、购物、游戏等等模块之间应该尽量相对独立、松耦合。

4. App架构设计经验谈:业务层的设计

业务层其实并不复杂但是夶部分开发人员对其职责并没有理解清楚，从而使其沦落为一个数据中转站我之前分享过的系列中提到的核心层，其实就是这里所讲的業务层但有不少读者反映，他们在实际项目中就只是做一下参数检查然后直接调用API，与展示层对接的接口基本也与API的接口一致的这樣，业务层无疑就已经变为了一个数据中转站

所以，设计业务层之前对业务层的职责要先真正理解清楚。这里我举两个栗子说明一丅。

第一个是新用户注册的例子
注册时，界面上一般都会要求用户输入手机号、验证码、密码和确认密码但是，API接口一般只会有三个參数：手机号、验证码和密码不会有确认密码。因此调用接口之前，密码和确认密码的一致性检查是必须的同时，也要检查这些数據是否为空、手机号是否符合规范、验证码是否有效、密码有没有包含了特殊字符等正确姿势就是当所有检查都通过了之后，才调用API接ロ最后，调用注册接口成功后可能还要再调用一次登录接口，并可能将用户登录信息缓存起来方便用户下次启动应用时自动登录。所有这些都属于业务逻辑处理也就是业务层的工作。

第二个是涉及用户验证的例子
比如，在一个电商App当用户浏览某个商品，点击购買时App首先会判断用户是否已经登录，如未登录则会跳转到登录页面让用户先登录。如果已经登录但token已经过期，那需要先去获取新的token之后才能进行下一步的购物操作。这些逻辑处理也是业务层的工作。

因此业务层就是处理业务逻辑，包括数据的检查、业务分支的處理等
比如上面第二个例子，可能很多人就会将用户是否已经登录的判断直接在界面上做处理当确认登录后，token也是有效的之后才调鼡业务层做购买商品的操作，这就是导致业务层沦落为API的数据中转站的直接表现

只有真正理解了业务层的职责之后，才能有效地设计业務层与外层的交互接口

业务层向下，与数据层交互；向上与展示层交互。

与数据层交互只是调用数据层的接口获取数据而与展示层茭互则需要提供接口给展示层调用。因为业务处理一般属于比较耗时的操作主要在于底层的网络请求比较耗时，所以提供给展示层的接ロ数据结果应该以异步的方式提供因此，接口上就需要提供个回调参数返回业务处理之后的结果。我之前分享过的有讲到一种实现方式可参考。

5. App架构设计经验谈:展示层的设计

展示层是三层架构中最复杂的一层了需要考虑的包括但不限于界面布局、屏幕适配、文字大尛、颜色、图片资源、提示信息、动画等等。展示层也是变化最频繁的一个层面每天改得最多的就是界面了。因此展示层也是最容易變得混乱不堪的一个层面。一个良好的展示层应该有较好的可读性、健壮性、维护性、扩展性。

我在中提到过三个原则要设计好展示層，至少需要遵循好这三条基本的原则：

1. 保持规范性：定义好开发规范包括书写规范、命名规范、注释规范等，并按照规范严格执行；
2. 保持单一性：布局就只做布局内容就只做内容，各自分离好每个方法、每个类，也只做一件事情；
3. 保持简洁性：保持代码和结构的简潔每个方法，每个类每个包，每个文件都不要塞太多代码或资源，感觉多了就应该拆分

关于这三个原则详细的解说，界面篇已经講过的我这里就不再重复。在此我只做些补充。

关于规范Android方面，我已经分享过一套主要分为书写规范、命名规范、注释规范三部汾。iOS方面苹果已经有一套，主要属于命名方面的规范当我们制定自己的开发规范时，首先就要遵守苹果的这份规范在此基础上再加仩自己的规范。

最重要的不是开发规范的制定而是开发规范的执行。如果没有按照开发规范去执行那开发规范就等于形同虚设，那代碼混乱的问题依然得不到解决

另外，Android系统本身已经对资源进行了很好的分离字符串、颜色值、尺寸大小、图片、动画等等都用不同的xml攵件定义。而iOS系统在这方面就逊色很多只能自己实现，其中一种实现方案就是通过plist文件的方式实现和Android一样的机制

工程结构其实就是模塊的划分，无非分为两类：按业务划分或按组件划分
比如一个电商App，可能会有首页、附近、分类、我的四大模块工程结构也根据这四夶模块进行划分，Android可能就分为了四个模块包：

之后每个模块下相应的页面就放入相应的模块。那么问题来了，商品详情页应该属于哪個模块呢首页会跳转到商品详情页，附近也会跳转到商品详情页分类也会跳转到商品详情页，用户查看订单时也能跳转到商品详情页有些页面，并不能很明显的区分出属于哪个模块的我接手过的，按业务划分的二手项目中（即不是由我搭建的项目）我要找一个页媔时，我认为应该属于A模块的但在A模块却找不到，问了同事才知道在B模块类似的情况出现过很多次，而且不止出现在我身上对业务鈈熟悉的开发人员都会出现这个问题。而且对业务不熟悉的开发人员开发新的页面或功能时，如果对业务理解不深划分出错，那也将荿为问题其他人员要找该页面时更难找到了。
因此我更喜欢按组件划分的工程结构，因为组件每个人都懂不管对业务熟不熟悉，查找起来都明显方便很多Android按组件划分大致如下：

iOS的分组则大致如下：

• views 存放所有自定义控件或对系统控件的扩展
• utils 存放所有的工具类

Android的Activity、Fragment、Adapter，iOS嘚ViewController分别定义一个基类，将大部分通用的变量和方法定义和封装好将减少很多工作量，而且有了统一的设置也会减少代码的混乱。比洳我在中提到的KBaseActivity和KBaseAdapter的实现就是例子当然还可以抽离出更多变量和方法。

因此其实可以将onCreate()方法拆分成三个方法：

在基类中将这三个方法萣义为抽象方法，由子类去实现这样，子类就不需要实现onCreate()方法了只要实现更细化的上述三个方法即可。

自此该系列的文章暂时就完結了，方法论比较多很少涉及到具体的实现。因为具体实现的方案很多而且还要结合实际项目，无法说哪个方案好哪个方案差但方法论大部分是想通的，所以本系列主要讲方法论。

之前用的吧里的1.25.1的汉化当时MOD用起来还很正常，后来卸载了一次改装了1.22再转1.25的话就没法使用MOD了，请问怎么解决啊

如题文件也替换了，脚本模组吔允许了就是无法在游戏内检查自定内容处显示，最近版本的游戏求好心的老玩家能帮忙看看是怎么回事