Archive for July, 2015

作者:AngryFox 分类: Uncategorized July 12th, 2015 暂无评论

开发时,经常用到NSLog,但release是又想一次过清掉all NSLog,方法是:在xxx-Prefix.pch里添加

 view plaincopy
#ifdef DEBUG
#    define DLog(...) NSLog(__VA_ARGS__)
#else
#    define DLog(...) /* */
#endif
#define ALog(...) NSLog(__VA_ARGS__)

When you want to log only in debug builds use DLog(). In release builds DLog() will be compiled as an empty comment. Otherwise use ALog() for logging in both debug and release builds. (A as in always.)

那么”DEBUG”在哪里定义的呢? 在 “Target > Build Settings > Preprocessor Macros > Debug” 里有一个”DEBUG=1″。

当你Run, Test, Analyze时,就属于debug mode,当Profile, Archive时就属于release mode。见你的ios project的”Edit Scheme…”

#ifdef DEBUG的另外一个用处是:用于push notification。sandbox device token and production device token一定不能mix在一起,否则就可能有些device收不到。见http://blog.csdn.net/totogogo/article/details/8035095

因此我们需要为reg device token准备2个url

 view plaincopy
#ifdef DEBUG
    NSString * const REG_URL=@"http://xxxx/reg_dev_token";
#else
    NSString * const REG_URL=@"http://xxxx/reg_production_token";
#endif  
作者:AngryFox 分类: Uncategorized July 12th, 2015 暂无评论

OpenIM整个系统分为:

接入层(客户端):负责客户端接入,
接入层(服务端):负责App Server和OpenIM服务器的对接。
协议路由:消息路由和业务逻辑层,负责消息路由和各种业务逻辑处理;
数据层:负责用户、业务数据的缓存,持久化等。

极简协议:OpenIM采用完全私有的二进制协议:确保数据加密安全的同时,流量消耗极少。同时心跳包协议对IM的电量和流量影响很大,OpenIM在心跳包协议上进行了极简设计:仅 1 Byte 。
智能心跳:OpenIM独特的保活机制,自动适应不同的网络环境,智能调整心跳频率,将参数调整到最优状态。
智能唤醒: 众所周知,Android手机电量消耗一直为大家所诟病。 后台各种应用不断唤醒手机,致使手机待机时间大为缩短。OpenIM能以最低限度唤醒手机进行必要的保活,保证连接的健康及消息的及时到达: OpenIM与系统以及其他应用进行交互,如果有其他应用唤醒了手机,OpenIM将避免冗余唤醒,节约设备的电量消耗。
多路复用,共享连接:OpenIM的SDK广泛使用在阿里的各移动应用中,如手机淘宝、天猫、旺信、千牛、去啊等。通常来说,多个IM App会有多条物理TCP长连接,OpenIM支持多应用共享复用一条TCP长连接,保活的流量将从N倍变为1倍; 唤醒手机次数也由N个应用唤醒变为1个应用唤醒。由于这些阿里应用覆盖用户群较大,OpenIM会自动共享阿里应用已经存在的物理连接,极大减少电量和流量开销。
多路复用, 共同保活:同时,Android系统资源紧张时会在后台清理进程,当某个OpenIM所在应用被清理后,通常OpenIM消息也就无法实时触达。但由于“多路复用”机制,只要当前任一应用(包括阿里应用)还存活,OpenIM均能顺利工作,有效提升了长连接的健壮性。

微服务架构(Microservice Architect)是一种架构模式,它提倡将单块架构的应用划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。

SOA实现 微服务架构实现
企业级,自顶向下开展实施 团队级,自底向上开展实施
服务由多个子系统组成,粒度大 一个系统被拆分成多个服务,粒度细
企业服务总线,集中式的服务架构 无集中式总线,松散的服务架构
集成方式复杂(ESB/WS/SOAP) 集成方式简单(HTTP/REST/JSON)
单块架构系统,相互依赖,部署复杂 服务都能独立部署

小, 且专注于做⼀件事情
独立的进程中
轻量级的通信机制
松耦合、独立部署

作者:AngryFox 分类: Uncategorized July 9th, 2015 暂无评论

指标: CPU(cpu usage, overload,thread cpu cost)
内存:内存泄露,内存常驻,OOM, GC
网络:流量合理性,流量兜底策略,传输速度
磁盘:文件i/o,数据库,磁盘空间占用,安装包
电量:mAh,wakeup,condition,网络操作频率

开源前端 amaze ui
React Native

数字化运营(实时数据/阶段性统计数据)
开源软件,必须彻底掌握后再使⽤用
寻找系统的关键点,详尽的⽇日志帮助找到问题所在
客户端逻辑尽量简单,逻辑做到服务端去;

高性能保障
多份内存镜像
异步广播
自动热加载数据

多级优先消息队列
资源调度分布式漏水桶服务