ACM_Someone like you

摘要： UI丑卻要繼續(xù)做的感言： 對UI不滿意的時候，就會覺得丑爆了,時間長了，卻丑習(xí)慣了。 論前一陣子Tabbar 多丑，丑得最后不要tabbar了...但是自定義tabbar 和遇到的問題解決的過程可以記錄一下 目標(biāo)效果： 并有切換效果，但是并沒說清楚，具體切換效果，比如粘滯，彈性？ 于是我做了一個彈性 閱讀全文

摘要： 總體邏輯： 客戶端：對稱加密數(shù)據(jù)，上傳。。。回執(zhí)對稱解密 同理服務(wù)端：獲取上傳數(shù)據(jù) 對稱解密 。。。下發(fā)：對稱加密 當(dāng)且僅當(dāng)?shù)卿浗涌诤?拉新（更新nonce 和 key的接口）是對稱加密上傳 非對稱解密 1.加密庫選擇 ： Libsodium 2.加密對象： （1）整體：這個我們最后放棄了，因為如果 閱讀全文

摘要： 今天 老板說，群~你的警告??蠻多的。。。我拍了胸脯，下周項目總結(jié)時候一定會完美解決！！！ 于是我得把項目中全部警告解決了，加油🆙。（去除警告的目的，防止?jié)撛诳赡芤l(fā)的問題，不僅僅是老板讓我處理，我就處理的😘） 自己項目中警告如下： （1）創(chuàng)建了實例變量卻沒使用。。。不使用就刪除 👌 （2）自 閱讀全文

摘要： 這周主要做了 ETH錢包：（1）錢包列表展示錢包價值（2）在錢包內(nèi)發(fā)起一個Transation交易 （3）獲取交易詳情 當(dāng)前熱錢包部分， 對于以上三個功能最大的需求功能，最大阻礙是精度問題和超大數(shù)的的基本運(yùn)算 一.錢包價值展示 參考imToken, imToken主做ETH錢包三年多，相當(dāng)專業(yè)，有太 閱讀全文

摘要： 第一版本的錢包的目的是實現(xiàn)熱錢包，所以創(chuàng)建錢包是在服務(wù)端創(chuàng)建，回執(zhí)給客戶端助記詞,keystore,方便用戶備份，導(dǎo)入操作。這里有一個很大的質(zhì)疑：服務(wù)端操作錢包安全嗎？相對于冷錢包而言，當(dāng)然不那么安全，所以為了提高安全等級， 將要實現(xiàn)：交互加密，代碼混淆 //防破解數(shù)據(jù) 開源交互api等方式 //本 閱讀全文

摘要： 前言：沒想到迅雷的區(qū)塊鏈大會開完也沒多久，我就要和區(qū)塊鏈結(jié)緣了。從區(qū)塊鏈錢包做起。 這里說說這周學(xué)習(xí)的主要成果： 一 區(qū)塊鏈錢包：是一個管理工具，數(shù)字錢包密鑰（即公鑰和私鑰）的管理工具。 私鑰: （明文私鑰）是一個64位的16機(jī)制哈希字符串。這個私鑰非常重要：“誰掌握了私鑰，誰就掌握了錢包使用權(quán)”。 閱讀全文

摘要： 完全來自于 iOS 多線程安全與可變字典 的學(xué)習(xí) 基本相同，舉一反三 直接上樣例代碼 是我參照網(wǎng)上，根據(jù)當(dāng)前業(yè)務(wù)需求改的。 其實好多人在這里喜歡用類別處理。我個人覺得用類別 極其容易和普通方法混淆，所以為了降低耦合度，增強(qiáng)代碼理解性和可讀性。這里單獨創(chuàng)建類挺好的。用時候使用這個自定義的安全數(shù)組就好了 閱讀全文

摘要： 這周最大的收獲是稍稍通透了 多線程安全字典的重要性。 誘因是，發(fā)現(xiàn)了有字典壞地址錯誤 果斷以為是 value 或者 key 是可能出現(xiàn)了空值，補(bǔ)充了潛在的判斷，雖然有的位置已經(jīng)預(yù)判斷的，但是真正賦值的時候并沒判斷呀，補(bǔ)充上了。 這種問題線下時候，我們基本0復(fù)現(xiàn)，所以迭代一個版本用戶檢驗的時候還是報這 閱讀全文

摘要： 所有字符串的公共前綴最長字符串 特點：（1）公共所有字符串前綴 （好像跟沒說一樣。。。） （2）在字典樹中特點：任意從根節(jié)點觸發(fā)遇見第一個分支為止的字符集合即為目標(biāo)串 參考問題：https://leetcode.com/problems/longest-common-prefix/descripti 閱讀全文

摘要： 一字典樹 字典樹，又稱單詞查找樹，Trie樹，是一種樹形結(jié)構(gòu)，哈希表的一個變種 二.性質(zhì) 根節(jié)點不包含字符，除根節(jié)點以外的每一個節(jié)點都只包含一個字符； 從根節(jié)點到某一節(jié)點，路徑上經(jīng)過的字符串連接起來，為該節(jié)點對應(yīng)的字符串； 每個節(jié)點的所有子節(jié)點包含的字符都不相同。 根節(jié)點不包含字符，除根節(jié)點以外的每 閱讀全文