HABIT IS POWER

习惯就是力量

0%

Posted on

需求

系统自带的python版本是2.7，之前用homebrew直接安装了一个python 3.6.5，不方便切换版本，想要清理下环境，使用pyenv来统一管理系统内的python版本

清理老版本

清理老的pip安装

之前用sudu pip安装了不少package，太挫了，先把这部分清理一下

1
2
3
4
5
6
7
8
9
10
11
# 确认下当前使用的文件
which pip
which python

# 删除pip
sudu pip uninstall pip

# 卸载之前brew安装的python
brew uninstall python –ignore-dependencies

brew uninstall pyenv

检查是否清理干净

下面这几个命令应该都找不到了

1
2
3
pyenv
python
pip

安装新版本

最先需要安装的是pyenv

1
2
3
4
5
6
7
8
9
10
11
12
13
14
brew install pyenv

# 打开.bash_profile
vim ~/.bash_profile

# 添加下面三行

# pyenv
export PYENV_ROOT=/usr/local/var/pyenv
eval "$(pyenv init -)"

# 重新加载下配置，查看当前的python版本，应该只有一个system版本
source ~/.bash_profile
pyenv versions

安装指定的python版本

本来应该是一条命令搞定的事情，比如:

1
pyenv install 3.6.8

结果遇到了问题：Install fails, “zlib not available” #530

简单来说，我确认了以下几个操作后最终可以了，我也不太确定是那个生效了：

1
2
3
4
5
6
7
8
9
10
# 检查xcode编译工具
xcode-select --install

# 检查几个安装，其实我之前都安装过了，提示是否需要reinstall，我没有重新安装
brew install readline

# 修正zlib的inclue路径
export CFLAGS="-I$(xcrun --show-sdk-path)/usr/include"
export CPPFLAGS="-I/usr/local/opt/zlib/include"
pyenv install 3.6.8

安装成功后，把默认版本修改下

1
2
pyenv versions
pyenv global 3.6.8

检查下版本是否正常，正常的话就算完成了

1
2
python --version
pip --version

Posted on

需求

在Windows下像Mac和Linux那样使用NVM来管理node版本，使用npm

  • 原来的解决方案用的挺好的：
    https://github.com/coreybutler/nvm-windows

  • 今天更新node版本遇到了问题：
    之前安装的8.x的版本能正常使用，nvm install 10.10.0后发现node有但是npm文件没有下载下来

nvm root看了下安装路径是在AppData下，虚拟链接是在%Program Files%目录下，nvm use的时候会弹出UAC提示，照理应该也不会出错，不过nvm的对应版本目录下并没有下载到npm文件。

解决方案

github上看了下，最近（2018-08-02）更新了一个版本1.1.7：
https://github.com/coreybutler/nvm-windows/releases

我把老的版本卸载干净，然后重新安装了下新版本，然后重新安装，重新安装的时候我把安装目录和软连接目录都放到的我的非系统盘D盘的根目录下：

1
2
D:\nodejs\
D:\nvm\

重新使用nvm安装下最新版本的node：

1
2
3
4
5
6
nvm list available
nvm install 10.10.0
nvm use 10.10.0

node --version
npm --version

验证了下版本，没问题：

1
2
3
4
5
6
D:\>npm --version
6.4.1

D:\>node --version
v10.10.0

Posted on

引言

2017年1月份，我和老婆带着未满3岁的儿子，从珠海出发，经由香港机场飞往日本大阪关西机场，并在大阪、京都、神户自由行了一个礼拜。

机票、酒店和游玩的行程安排都是老婆负责，而我负责的部分是游玩过程中的交通，结果只能算勉强及格，至少没走丢；这里我要分享的就是些关西旅行交通方面的经验教训。

地图应用

说交通怎么能不先说地图呢？我使用Google Map，需要提前买个日本3G上网卡；无论是地铁还是公交车，Google Map都能比较好的导航到搭车的地方，还有列车时刻表；你可以选择不同的地铁或公交线路；有个特别好的是，你在搭地铁的过程中，如果听不懂日语报站名，或者有些列车没有电子指示当前到哪一站了，这个时候你拿出手机看下Google Map，之前搜索的地铁路线包含了各个途径地铁站的名字和你当前的位置，非常实用。

关西的铁路交通

日本的铁路交通太发达了，所以铁路交通也是关西旅行交通的重头戏。

如果对日本的铁路交通完全没有概念的话，我建议先看下这个网站：西日本旅客铁道株式会社，这是JR-West的官方网站，有中文版；我是回国之后整理攻略才知道的这个网站，后悔莫及，网上各种攻略很多，但都没这个全面实用，走了不少弯路。

JR只是日本众多铁路公司中的一个，不过乘车的规则什么的基本都是类似的，所以你看了JR的乘车指南，再搭乘其他公司的铁路交通，会比较轻车熟路。

列车种类

官方分类看这里：列车种类

高铁(新幹線)、特快(特急列車)、快速(急行列車)、管内快速(新快速)、普快(快速)、普客(普通列車)

这么多分类，我自己搭乘后的经验是，其实就分三类就够了：
新干线、急行、普通。

不同类型的列车，除了车票价格的区别，买票方式上也有区别：
新干线需要单独买票，不能刷卡；
急行和普通的可以先刷IC卡进站，想要快的话，看到急行车上车后再补票，只是不一定能补到指定席。

车票分类

关键字：乘车券、自由席、指定席、急行券、新干线

在日本搭乘铁路交通，你至少需要“乘车券”；
在购票时你可以选择是自由席还是指定席；
而如果你想要搭乘急行或快速的列车，你还需要购买“急行券”；

上述几个选项是可以组合的，最便宜的是自由席乘车券，最贵的是指定席急行券；
需要注意的是并不是每个路线都有急行列车，需要提前查好车次；
还有就是日本的快车和慢车都是在同一个乘车站台，做错慢车的话很有可能早上车却更晚到达目的地。

还是没看明白的，可以看下JR-West的相关说明：搭乘JR-West的方法 购买车票

交通IC卡

各种日本旅行攻略里经常提到的交通IC卡主要是Suica和ICOCA，这两种卡目前都已经是日本全国通用了。

两个单词的读音可以提前学习下，因为这个卡的使用频率非常高：

Suica（スイカ），读音类似：[su i ga]
ICOCA（イコカ），读音类似：[i ko ga]

我用的是ICOCA，关西机场自动售卖机上能买到的也就是这个了，除了新干线需要单独购买乘车券，其他铁路只要不是指定席或者急行券，都可以直接刷卡上车，不用单独买票；另外市内公交车和便利店也能刷ICOCA。

ICOCA & HARUKA

因为我们的到达机场是关西机场，第一站去的是京都，这里说下从关西机场到京都最快最划算的方式：ICOCA & HARUKA

官方介绍看这里：ICOCA & HARUKA

这个有多快捷呢？
从关西机场到京都站，这是最快的方式，没有之一。

这个有多划算呢？
从关西机场搭大巴车到京都应该是要1800日元，而这个ICOCA & HARUKA折扣券是1600日元。

又快又便宜，哪来这么好的事情；
原因在于他是和ICOCA卡捆绑销售的；
ICOCA本身第一次购买的话是需要2000日元，其中包含500日元押金；
虽然是捆绑销售，但是我上面提到了ICOCA和Suica已经全日本通用，而且便利店买东西也能用，其实2000日元很快就花完了的，万一万一花不完还可以退卡（虽然我不推荐退卡）。

特别要注意的是购买方法：只能在JR的绿色办公室里面购买！
关西机场的JR绿色办公室就在JR地铁入口的对面，在一排自动售卖机的右手边，进去找人买就对了，在自动售卖机上是买不到的（T_T）。

儿童乘车

12岁以上算大人、6岁至11岁算儿童、1岁至5岁算幼儿、未满1岁算婴儿；
每名大人最多可免费携带2名幼儿同行；
简单说就是5岁以下的小朋友，大人带着不要钱，不用买票。

这里再说下新干线买票的事情，因为我们当时带着小孩，没有买指定席，结果上车后带着小孩和行李换了好几次位置，乘务员说没办法补指定席的票，很麻烦，所以带小孩坐新干线的话最好直接买指定席。

公交车

我们只在京都坐了公交车，京都的东西南北分布着各种寺庙，但并不是每个寺庙都有地铁直达，这时候就需要市内公交发挥作用了。

提前用Google Map查好公交转乘的路线，还是挺方便的。

Google Map的路线是没问题的，但公交车站台位置不是很准，如果你到了一个站台发现没有Google Map提示的那个公交线路站牌，比如说你要坐25路，结果站牌上怎么都找不到25路的站牌，那肯定是你走错公交站了，再找找看吧。

坐公交车还需要注意的是，如果你下一站下车，到站之前记得按下车上随处可见的红色按钮（不骗你，真的是随处可见）。

的士

都说日本打车贵，一开始都不太敢尝试，但是行李太多了，我们从酒店去京都站搭新干线的时候，还是打了个的士：

3.2KM，1100日元，折合人民币60多块钱

跟国内比肯定是贵很多，但是你要知道日本的地铁也不便宜；
我们还要拿着两件大行李，一个婴儿车，这么算的话价格还是可以接受的。

的士作为一种交通途径，在合适的时候还是可以选用的，并不是天价。

长途大巴

我们从神户有马温泉去大阪的时候搭乘的是大巴车，车上10个人不到；
想不到的是大巴车上竟然没什么味道，更没有国内大巴车上那种无法描述的奇怪的大巴车味道……

大巴车快到大阪的时候，最左边的车道堵车堵了大概有10公里，但是右边的两个车道都还在正常快速行驶；中间好几次我都在想为什么右边这么快，没有人变道？后面才知道这10多公里的车都在排队下高速，高速出口有点堵车，但是只堵了最左边的一条道而已，佩服。

交通IC卡充值

地铁站买票的自动售卖机可以充值；
地铁站里面有精算机可以充值；
便利店可以充值。

关于问路

日本人英语听力都还不错，只是不太愿意说，你要是英文好的话直接英文问路完全没问题。

我的做法是，用有道翻译，把问路的关键字翻译成日语；注意是只是关键字而已，不要整个句子，因为我的实践结果告诉我，翻译句子比较坑；把关键字的日文给日本人看下，他们基本能猜猜八九不离十；实在不行再配合两句蹩脚的英语，嗯，应该可以了……

还不行的话你就比划比划或者试下眼神交流吧

对这次旅行交通的整体感受

准时，方便，不需要像国内那样预留太多的时间。

费用方面，这次旅行在关西交通上的花费，只是旅行费用中比较小的一部分；
我们也没有使用更划算的周游券，主要是因为我们带着小孩，行程本来就不固定，而且我们是三个城市走马观花式的自由行，不太适合；

只要行程确认，交通攻略上一个Google Map也就够了，还都是中文界面；
日本的交通很发达但也很规范，熟悉了规则之后会发现，日本的交通出行其实比你在国内一个陌生城市还要简单。

== The End ==

Posted on

问题

我的问题是proxychains4 telnet 是没问题的，但是proxychains4 pod update就会报下面这样的警告，然后失败：

[proxychains] preloading ./libproxychains4.dylib
dyld: warning: could not load inserted library ‘./libproxychains4.dylib’ into library validated process because no suitable image found. Did find:
./libproxychains4.dylib: code signing blocked mmap() of ‘./libproxychains4.dylib’

我的环境如下：

  • macOS Sierra 10.12.3
  • proxychains-ng 4.12_1
  • SIP之前配置过用的是：csrutil enable –without debug，查询的状态如下：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    $ csrutil status
    System Integrity Protection status: enabled (Custom Configuration).

    Configuration:
    	Apple Internal: disabled
    	Kext Signing: enabled
    	Filesystem Protections: enabled
    	Debugging Restrictions: disabled
    	DTrace Restrictions: enabled
    	NVRAM Protections: enabled
    	BaseSystem Verification: enabled

    This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

寻找原因

一开始是找到了这篇issues:Proxychains4 with brew for MacOs error #109，以为是我的proxychains4版本问题或者是我的SIP问题，所以做了以下尝试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 进入系统的recovery mode，禁用SIP
csrutil disable
reboot

# 重启后卸载老的proxychains
brew tap beeftornado/rmtree
brew rmtree proxychains-ng

# 重新安装
proxychains-ng --universal

# 确认下proxychains-ng的配置是否正确，如果不正确就再配置下proxychains.conf
# 确认下telnet是否正常
proxychains4 telnet google.com 80

# 再尝试下pod update
proxychains4 pod update

# 问题依旧：code signing blocked mmap()

问题所在

在另外一个issue78:Not working on OS X 10.11 due to SIP #78中看到了被点赞了4次的这个回答，让我最后解决了问题：

It only happens if you execute a system binary using proxychains, e.g. proxychains4 ssh user@server. For now, a workaround is to copy the executable to another location (e.g. cp /usr/bin/ssh ~/XXX), and use it (e.g. proxychains4 ~/XXX/ssh user@server). You can modify the path variable so that ~/XXX/ssh is executed instead of /usr/bin/ssh, when you just type “ssh”.

一句话描述问题：

proxychain尝试注入系统bin目录下的二进制文件会出现这种情况，解决方案就是换个非系统目录的文件来执行和注入就可以了。

解决方案

根据上面的问题描述，再考虑pod update的实际操作，其实就是调用git去更新，而我的git用的是系统自带的：

1
2
3
$ which git
/usr/bin/git

这样一来问题就变成了让pod update使用我自己安装的git就可以了：

1
2
3
4
5
brew install git

# 修改.bash_profile，增加下面的export配置，优先搜索/usr/local/bin目录
# 这样修改后，terminal下使用git就会优先使用我们刚刚安装的git版本了
export PATH=/usr/local/bin:/usr/local/sbin:${PATH}

好了，配置好了，再试一下，成功了:

1
proxychains4 pod update

关于SIP

最后我验证了下，SIP其实不需要disable，csrutil enable –without debug下proxychains也是能正常工作的

总结

说下我这里能够正常运行的环境和因素：

  • macOS Sierra 10.12.3
  • proxychains-ng 4.12_1
  • 进入系统的recovery mode，打开terminal，csrutil enable –without debug
    可以使用这个命令查询的状态，我的状态如下：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    $ csrutil status
    System Integrity Protection status: enabled (Custom Configuration).

    Configuration:
    	Apple Internal: disabled
    	Kext Signing: enabled
    	Filesystem Protections: enabled
    	Debugging Restrictions: disabled
    	DTrace Restrictions: enabled
    	NVRAM Protections: enabled
    	BaseSystem Verification: enabled

    This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
  • 我的git使用的是brew install git的版本:
    1
    2
    $ which git
    /usr/local/bin/git

    参考材料

    Not working on OS X 10.11 due to SIP #78
    Proxychains4 with brew for MacOs error #109
    code signing blocked mmap() #159

Posted on

问题

由于使用了Multipeer Connectivity和NSOutputStream，在某些网络环境切换的情况下，总是会遇到这样的crash：

Signal 13 was raised. SIGPIPE

查找资料后，发现最简单的解决方案就是忽略这个错误：

signal(SIGPIPE, SIG_IGN);

但实际的结果是我们设置了还是会继续出现闪退

原因

排查了很久后才发现，问题的原因是BugTags也会控制这个开头，默认是不忽略，而且这个默认显然代码是主动调用了，而不是我们期望的不调用就不设置：

1
2
3
4
/**
 * 是否忽略 PIPE Signal (SIGPIPE) 闪退，默认 NO
 */
@property(nonatomic, assign) BOOL ignorePIPESignalCrash;

解决方案

设置BugTags的对应开关即可：

1
2
3
4
// Bugtags
BugtagsOptions *options = [[BugtagsOptions alloc] init];
options.ignorePIPESignalCrash = YES;
[Bugtags startWithAppKey:BugTagsAPPKEY invocationEvent:BTGInvocationEventNone options:options];

思考

这个问题我们排查了很久，一直在找我们自己的原因，但其实这种bug因为跟网络环境有关系不容易重现；
其实反思后发现，排查这个问题我们应该先做一个事情，就是手动出发SIGNAL 13，看闪退是否被正确忽略；
而我们恰恰没做这个事情，思路上的疏漏导致了之前的大量工作变成了无用功。

参考材料

如何在 iOS 上避免 SIGPIPE 信号导致的 crash (Avoiding SIGPIPE signal crash in iOS)
NSStream close
Writing OutputStreams
[深入浅出Cocoa]iOS网络编程之NSStream
How to make a NSStream instance reusable?

Posted on

问题

有个视频播放页面需要手动控制页面的横竖屏状态，使用setStatusBarOrientation可以达到这个效果；
但是很奇怪的事情发生了，我们发现代码在某台机器的某种情况下会出现setStatusBarOrientation调用无效。

原因

直接的原因是我们使用了BugTags，并且在白名单用户登录后打开了BugTags的悬浮小球，悬浮小球出现的时候setStatusBarOrientation调用就会无效；

分析后发现真正的原因是，页面已经不是the top-most full-screen view controller了：

The setStatusBarOrientation:animated: method is not deprecated outright. It now works only if the supportedInterfaceOrientations method of the top-most full-screen view controller returns 0

解决方案

知道原因就简单了，需要全屏的时候隐藏BugTags的悬浮球即可

BTGInvocationEventNone

参考

setStatusBarOrientation:animated: not working in iOS 6
setStatusBarOrientation 未生效的解决办法

Posted on

前言

之前用的Jekyll，最大的痛点是对Markdown的代码格式支持的不是很好，尝试过一些方法，不过都不太理想；
最近偶然看到Hexo的介绍，决定尝试一下；
迁移过程中有些小Tips觉得有必要小结下，对于迁移的人来说还是很有用的。

迁移步骤

  • 我的系统是Mac OS 10.12.1

  • 我原来的Jekylly代码在这个仓库下：https://github.com/linyehui/linyehui.github.io

  • 代码备份

    • 从master建立分支用于代码备份（多留个心眼，后面发现很有用），备份用的分支：release-jekyll
    • 保险起见，我把本地的github 仓库也备份了下

  • 创建一个新的github仓库用于存储我的hexo blog代码：linyehui-hexo-blog，git clone到本地，得到hexo的本地根目录：linyehui-hexo-blog

  • 初始化hexo本地环境

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    git clone https://github.com/linyehui/linyehui-hexo-blog
    cd linyehui-hexo-blog
    npm install -g hexo-cli

    hexo init

    npm install hexo --save
    npm install hexo-generator-index --save
    npm install hexo-generator-archive --save
    npm install hexo-generator-category --save
    npm install hexo-generator-tag --save
    npm install hexo-server --save
    npm install hexo-deployer-git --save
    npm install hexo-deployer-heroku --save
    npm install hexo-deployer-rsync --save
    npm install hexo-deployer-openshift --save
    npm install hexo-renderer-marked@0.2 --save
    npm install hexo-renderer-stylus@0.2 --save
    npm install hexo-generator-feed@1 --save
    npm install hexo-generator-sitemap@1 --save

    这一步完成的时候，你就可以在根目录下执行hexo server，并且可以在浏览器上看到Hello World页面了

  • 配置下_config.yml，这里就是各种名字的配置，配置完了之后，浏览器预览没问题就行了

  • 配置theme，我用的是iissnan/hexo-theme-next

    1
    2
    3
    4
    5
    6
    7
    # git clone到另外一个目录，然后复制到./linyehui-hexo-blog/themes/next目录下
    git clone https://github.com/iissnan/hexo-theme-next

    # 复制hexo-theme-next目录到./linyehui-hexo-blog/themes/next

    # 修改_config.yml中的这行文件，主题名字和目录名一致
    theme: next

    根据自己的需要修改下主题的配置：./linyehui-hexo-blog/themes/next/_cofig.yml

  • 迁移之前博客的文章

    • 把Jekyll版本的_posts目录下的文件复制到./linyehui-hexo-blog/source/_posts/
    • 把之前根目录下的媒体文件目录：media（图片）复制到./linyehui-hexo-blog/source/media

    浏览器中预览下，首页应该能看到你的文章了，数据迁移非常简单，就这一步

  • 创建tags文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    $ cd linyehui-hexo-blog
    $ hexo new page tags

    # 文件内容如下：
    title: 标签
    date: 2016-12-08 12:36:06
    type: "tags"
    comments: false
    ---

  • 上面都没问题，就可以发布了

    1
    2
    ## 发布前记得generate，保险起见带上--generate参数
    hexo deploy --generate

    每次发布，你都会发现你的github仓库的master分支只有两次commit，也就是说hexo deploy把老的master分支给删除了……

  • 发布没问题，我就把新的代码仓库下的文件给入库了，记得配置下.gitignore

    1
    2
    3
    4
    5
    .DS_Store
    .deploy_git
    db.json
    node_modules
    public

  • 到这一步blog的主体功能已经迁移完成，剩下的就是些美化、图标、头像，这里就不细说了

迁移Tips

  • hexo deploy 每次会将master分支删除后重新创建，迁移之前的代码切记要建立分支进行备份
  • hexo deploy 所做的事情：删除现有的master分支，并建立新的master分支，把hexo目录下的.deploy_git目录push到master分支上
  • source/_posts目录支持按年份划分目录，_config.yml中这么配置就行了：
    1
    new_post_name: :year/:year-:month-:day-:title.md # File name of new posts

参考文章

Jekyll迁移到Hexo搭建个人博客
将博客从Jekyll迁移至Hexo

Posted on

问题描述

对一个NSMutableArray进行排序，却造成了内存泄漏……

代码说明：

在多线程的流程中，存在一个NSMutableArray *sortList；

对sortList进行排序，一开始用的方法是这样的，有内存泄漏：

1
2
3
NSArray *sortedSendQuery = [self.sortList sortedArrayUsingFunction:frameDataCompare context:NULL];
[self.sortList removeAllObjects];
[self.sortList addObjectsFromArray:sortedSendQuery];

修正后的代码只有一行，没有内存泄漏：

1
[self.sortList sortUsingFunction:frameDataCompare context:nil];

原因分析

NSArray的排序方法是：sortedArrayUsingFunction
NSMutableArray的排序方法是：sortUsingFunction
self.sortList是一个NSMutableArray，直接使用NSMutableArray的排序方法sortUsingFunction不需要进行内存复制，可以提高性能；

除了性能问题，由于在多线程中使用，而且如果NSMutableArray中的object内存分配来自于其他线程的，那么不必要的内存复制会导致内存泄漏，出现的内存泄漏问题类似于：
Memory leaks from Multidimensional array: NSMutableArray, NSArray, addObject and insertObjectAtIndex

结论

对于NSMutable的使用，要留意调用正确的方法，能不做类型转换就不做

Posted on

问题描述

使用ARC的过程中，由于循环引用或者其他使用不当，会造成对象的内存没有及时释放，而这些内存在页面关闭的时候又会随着页面的生命周期一起释放，这就给我们排查“内存泄漏”带来了麻烦；

这种内存问题用Leaks是找不出问题的，因为这些内存其实只是释放不及时，而不是没有释放。

解决方案

使用Instruments Allocations的Mark Generation功能能帮助我们排查出这种问题。

使用之前先说几个Instruments的调试技巧

1、调试内存可以用Debug模式来调试，但是记得在工程设置中把Debug模式的Debug Information Format设置成：DWARF with dSYM File，否则无法在Instruments中看到出问题的符号对应的代码

2、性能调试真机调试的时候有时候连接不上，试试重启手机，实在还是不行，可以换成Debug模式，相对没那么容易连接不上手机(修改方法：Edit Scheme->Profile->Build Configuration 修改成Debug)

一个典型案例，问题描述

假定我们有一个页面MainViewController，打开这个页面后会开始进行视频直播，在直播的过程中会出现内存没有及时释放，比如10分钟后应用的内存占用已经达到了200MB，但是页面一关闭内存有都正确释放了。

针对这样的一个问题我们应该怎么来排查呢？

排查步骤

1、Xcode中启动Profile工具
image

2、选择Allocations工具，点击红色按钮开始“录制”，这时Instruments会启动我们的应用
image

3、打开有内存释放问题的页面，稍微等一下，等页面的常规初始化完成，比如等个10秒钟

4、从Instruments右下角的区域切换到“Display Settings” Tab页，并点击“Mark Generation”生成第一个Generation：Generation A；
这个相当于是我们判断内存没有及时释放的起始点
image

5、为了让没有及时释放的内存泄漏问题，累积的更多一点，第二次Mark的时间可以稍微多等久一点（等多久这个取决于你的内存问题出现所需要的时间，比如2分钟），然后再次点击“Mark Generation”，这个时候你就会发现两次Generation之间的内存增长，而这里面的增长其实就是我们所寻找的没有及时释放的内存：

image

6、点击小箭头查看更详细的信息，根据内存占用的比例，找到占用比例最高的，并且不断展开，直到找到我们自己的代码，这就是出问题的地方了。
image

Posted on

需求

1、使用AudioEngine进行音频采集，并加入部分EQ等效果器

2、将混音后的音频输出为PCM的Buffer

3、将PCM Buffer编码为AAC

遇到的坑

AudioEngine的这个方法有Bug: installTapOnBus

1
- (void)installTapOnBus:(AVAudioNodeBus)bus bufferSize:(AVAudioFrameCount)bufferSize format:(AVAudioFormat * __nullable)format block:(AVAudioNodeTapBlock)tapBlock;

iOS 10一下的版本，installTapOnBus的第二个参数bufferSize设置是无效的，
比如我设置bufferSize为1024，如果我的format中的bytePerFrame是4，那么最后出来的bufferSize应该是1024*4=4096才对，但是在iOS 10一下的版本，出来的bufferSize每次都是66148

如果我们要进行AAC编码，那么AAC编码的bufferSize必须是能够被1024整除的，而66148是无法被1024整除

如果AAC编码的时候没有对齐bufferSize和1024，就会出现音频数据丢失的情况

解决这个问题的两个角度

1、让installTapOnBus出来的数据能够被1024整除

2、自己用做对齐的事情，那么部分音频数据的采集时间戳就需要自己构造

我个人比较偏向第一种，这样就不存在构造时间戳的问题。

解决方案

第一步：installTapOnBus的Block中设置frameLength

1
2
3
4
5
6
7
const uint32_t frameLength = 1024;
[_inputNode installTapOnBus:0 bufferSize:frameLength format:[_inputNode outputFormatForBus:0] block:
	^(AVAudioPCMBuffer * _Nonnull buffer, AVAudioTime * _Nonnull when) {
		// iOS 10以下需要这么设置才可以缩短Block回调的Buffer大小和同时也能缩短Block回调的时间间隔
		// linyehui 2016-11-11
		buffer.frameLength = frameLength;
}];

参考：I want to call 20 times per second the installTapOnBus:bufferSize:format:block:

第二步：不要使用AVAudioPCMBuffer的mutableAudioBufferList

如果你使用了步骤一的代码，那么installTapOnBus回调出来的AVAudioPCMBuffer，不要使用mutableAudioBufferList，必须使用audioBufferList。

因为mutableAudioBufferList的mDataByteSize是frameCapacity，而audioBufferList的mDataByteSize是真实的frameLength