讓 iTrem 2 + zsh 啟動不再等待!

iTerm 作為一個 mac 裡自帶終端的替代品真的是太好用了,功能多、界面也好看。配合zsh+皮膚,終端從此也美麗(題圖)。

不過,zsh 啟動總是很慢,雖然說每次啟動前輸入的內容還是不會丟失,但總等著也不是個事(說句實在話,我就這麼忍受了好多年……)

總之,其實這個問題是可以被解決的:

進入 iTerm2 的偏好設置裡,在 Profiles 裡編輯你的配置,在配置右側的 Ge[……]

點擊跳轉以繼續閱讀

在 Swift 中使用 cmph

CMPH 的全稱是 ç最小完美哈希庫 ,是一個很著名的用 C 寫成的最小完美哈希庫,什麼是完美哈希?

完美哈希

這裡我們不講原理,你只需要知道傳統的哈希有衝突,我們需要靠各種算法來處理衝突就可以了,對於哈希,總是需要一個表,這個表裡預留了很多位置,然後計算出來的值就是這些位置的坐標,你可以把對應的數據放到坐標裡。

但這時候有一個問題,如果[……]

點擊跳轉以繼續閱讀

在字符串中 快速查找

很多時候,我們需要在字符串中執行查找,以判斷過濾指定的內容出來。比如過在落格輸入法當中,就需要用輔碼過濾出需要的候選詞。

一般來說,查找和對比肯定是數字來的最快,不過在詞庫上總不能把所有的詞彙都轉換為數字(雖然理論上可行……)在字符串的搜索上,我們有很多種辦法來實現,這裡我就說一下我自己的思路:

組<String>

由於我的詞庫輔碼篩選只對兩字或者三字詞彙生效,那麼我考慮[……]

點擊跳轉以繼續閱讀

基於動態規劃的整句輸入法

一般來說,我們不會在用動態規劃算法求解的問題上稱呼它為“動態規劃“,而是稱之為“隱馬爾可夫模型“,不過,如果我們單純用動態規划算法來求解一個普通的有向無環圖,那麼就只能說是動態規劃了……

這次我們要來說的,是基於詞庫的整句輸入法。而不是基於狀態轉移的隱馬爾可夫模型求解。

詞庫

由於不需要模型,我們的整句輸入是基於詞彙的,就需要一個詞庫。這個詞庫裡應該記錄了普通人大部分的常用詞彙,而且有一[……]

點擊跳轉以繼續閱讀

ios 為視障用戶支持 VoiceOver

其實很少用戶知道,ios系統其實有一套完整的輕鬆訪問機制,很多盲人或者說視障用戶都喜歡使用蘋果手機

所以說,作為一名開發者,我覺得不論是從產品銷售面還是作為責任,都應該做好完善的輕鬆訪問支持。

不過好在,得益於蘋果嚴格的開發規範,所以一般只要你的app已經通過審核能夠上架,那麼基本上 VoiceOver會 就已經能夠很好的識別你 app 中的大部分內容了,比較通用的,比如 tabV[……]

點擊跳轉以繼續閱讀

iOS 平台 SQLite 性能優化

開始

在 ios 平台,數據永久化的存儲方式就那麼幾種,比如說coredata,比如說realm,還有nosql的幾種方案,但是很遺憾,nosql的幾種方案支持的功能都還是太少,這樣就讓對它們的選擇顯得十分雞肋——畢竟,如果是簡單的應用的話,那就還不如其他方案來的方便快捷——雖然nosql是趨勢。

這次我們來談談另一種比較常見的儲存方案——sqlite,這個東西很厲害,它是一個用c實現的[……]

點擊跳轉以繼續閱讀

如何自定義 落格輸入法 ?

如何自定義落格輸入法

在落格輸入法中,我為你提供了強大的自定義功能。不論是簡單地新建一種雙拼方案,還是導入一份五筆輸入法的碼表,它都能完成。

首先,我們從概念說起

按鍵映射方案

落格輸入法用它來生成對應的映射方案,比如智能abc、比如自然碼等等。按鍵映射方案有兩個文件,比如“智能ABC.plist”那麼就要有對應的“智能ABC_rev.plist”,後者不是必須,但如果你想開啟“按鍵[……]

點擊跳轉以繼續閱讀

獲取 中文 維基百科語料

最近在做輸入法的詞庫,實現新的整句輸入模型,(回頭我會把之前的基於詞的整句輸入模型講講),新的整句輸入模型是基於 HMM (也就是隱馬爾可夫模型)來做的,當然了,由於我個人設備資金等有限,只做了二階矩陣。不過即使如此,模型還是需要訓練的。

當然,不是說用小說名著來訓練就不好,只不過很難找到各行各業的相關小說,畢竟,它們覆蓋的面積太單一了,這其實並不是高質量的語料庫。說起高質量,那自然是非維基[……]

點擊跳轉以繼續閱讀

swift 中內存狂飆的問題

在使用 Swift 語言進行開發的時候,很多朋友會莫名奇妙地遇到內存爆滿的問題,明明有 ,明明釋放了內存,卻還是讓程序的內存佔用隨著循環而一路飆升。

這裡其實並不是出現了內存洩露,這其實是 的一個機制:在每一個主 Runloop 結束的時候進行清理。也就是說,它有一套必要的緩存機制——畢竟,實時釋放的話誰能保證你的局部變量要不要留下來給後續的代碼使用呢?

但顯然,這個必[……]

點擊跳轉以繼續閱讀