Xcode 自動版本號

做開發者肯定有過這樣的煩惱:版本號提交錯了!

編譯和測試的版本多了,難免提交的時候才發現版本號搞錯了。要不就是後台版本號正確,前台的版本號忘記更改。其實,可以讓前台自動獲取後台的版本號數據,比如這樣:

後台的版本號還是要自己手動寫啊!大版本號也就罷了,不同的程序有自己不同的風格,有的甚至不是數字這就略過了,那麼構[……]

點擊跳轉以繼續閱讀

一個自動排序的 Swift 棧

一年前,我在 git 上發布了一個用 Swift 實現的棧,一共有兩個版本。因為 Swift 自身並沒有實現這個東西——儘管官方的教程中泛型的部分就是用這個棧舉的例子。

也許是人家覺得這個太簡單了吧

總之,這次我又來玩這個東西了,因為 HMM 的 Viterbi 算法需要做修剪,不然路徑太多無謂地增加計算量——畢竟,我們都關心第一名,誰會去注意第二名呢?

所以,這個棧也是基於原生 Arr[……]

點擊跳轉以繼續閱讀

我給落格輸入法的用戶群添加了個自動回復機器人

如題圖,我給落格輸入法的用戶群弄了個機器人,隨著落格輸入法的用戶越來越多,一些慕名而來的新手也多了。很多常見問題重複提問,搞得人焦頭爛額,如果能有個機器人,就像 Siri 那樣,讓它自動捕捉那些關鍵字然後回复這些用戶,豈不美哉?這樣用戶能夠得到精心編輯的答案,而我也能空餘出更多的時間去寫wan代you碼xi。

當然,這樣的機器人我是見過的,所以我想一定有現成的東西,顯然,搜索之下我先找到了這[……]

點擊跳轉以繼續閱讀

Swift 中判斷字符串是否有 Emoji 表情

更新:網絡上流傳的 emoji 代碼點不太完整,我按照維基百科的資料重新整理了一下,文中的 Swift 版本代碼已更新。

很多時候我們需要判斷一個字符、或者說是一句話裡是不是包含了emoji,使用 Swift 語言開發 app 也不例外,比如可以使用正則表達式——但很遺憾,似乎不同的語言對於正則表達式的支持區別, \u [……]

點擊跳轉以繼續閱讀

落格輸入法 是怎麼實現 app 設置而不需要 完全訪問 權限的?

眾所周知,在 iOS 平台上自從 8.0 版本開始,可以為 iOS 開發第三方的輸入法鍵盤了,而這些鍵盤可以被放在 AppStore 銷售了,不過,同時也有著十分嚴格的權限規則。

對此,蘋果為第三方的鍵盤設計了兩種權限,一種是最小的,只有最基本的鍵盤功能的權限、另一種則相對較多,鍵盤獲取了“完全訪問”權限之後基本上就和 安卓 上鍵盤差不多,可以訪問聯繫人、可以聯網等等。

不過[……]

點擊跳轉以繼續閱讀

無法加載 “” 與標識捆綁從筆尖引用圖像 “com.xxx.xxx”

今天遇到一個奇怪的問題,程序運行一點問題都沒有但終端報錯如下

其實就是題目上的錯誤,這個問題看上去挺簡單——不就是引用的圖片丟失了麼……

其實不然,由於名字是 "" 所以你根本找不到究竟是哪個圖片丟失了——實際上一個都沒有丟。

畢竟程序裡邊的資源一個都沒有[……]

點擊跳轉以繼續閱讀

寫 落格輸入法 的這半年裡獲得的 一點人生經驗

說出來你們可能不信,落格輸入法起初是我的一個練手項目,它叫小飛

但在動手寫它之前,其實我就已經抱怨過很多次了,說自己要寫一款好用的輸入法,因為我用雙拼,而現存的輸入法,都不怎麼重視雙拼這個群體,同時,就全拼來講,各種廣告彈窗小紅點也把它們本身整句輸入啊實用功能啊這些優點給埋沒了。

一直到 2015 年 11 月 7 日,我第一次有了動手寫一個輸入法的想法:

現在iOS上的輸入法大都臃腫[……]

點擊跳轉以繼續閱讀

CloudKit 優化指南

最近給落格輸入法加入了一個叫做“對數雲”的東西,其實不難,比使用 iCloud Document 要簡單,不過網上的資料不太多,你通過那些上手教程來現充應該不是問題,但想要提升用戶體驗,就不是那麼容易了。這裡我們就一起來看看,怎麼樣才能讓 CloudKit 運行得更暢快。

CKDatabaseOperation

一般來說,你獲取一條數據可能是這樣的:
[crayon-6902e54dbfeb[……]

點擊跳轉以繼續閱讀

讓 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 結束的時候進行清理。也就是說,它有一套必要的緩存機制——畢竟,實時釋放的話誰能保證你的局部變量要不要留下來給後續的代碼使用呢?

但顯然,這個必[……]

點擊跳轉以繼續閱讀

SourceKitService 佔用大量內存和 CPU 的解決辦法

在使用 Xcode 進行 Swift 語言開發軟件的時候,不少人在項目中後期都會遇到這麼一個問題,如題圖那樣:SourceKitService 佔用大量的 CPU 和內存,甚至直接導致系統卡死。

那麼,這到底是怎麼一回事呢?在 StuckOverflow 上的高票答案是這麼說的:

在活動監視器裡找到 SourceKitService 雙擊它,看它打開了哪些目錄,去把緩存刪除然後強[……]

點擊跳轉以繼續閱讀

如何學習自然碼輔碼?

自然碼是個比較古老的雙拼方案了,有多古老?古老到現在不少用戶都根本不知道它還有一套輔碼方案。

自然碼的輔碼稱不上是形碼,它之所以被稱為是輔碼,就是因為這套方案的設計初衷還是作為輔助,所以它並不能像小牛輔碼那樣做到非常低的重碼率——但是加上音的話,用起來還是很高效。

為什麼就算如此還說它輸入高效呢?因為它設計之初就是為了輔助,这就直接决定了这套方案十分容易被接受和学习!有多简单?就是偏旁[……]

點擊跳轉以繼續閱讀